Thanks guys, this should work for us. We
just wanted to make sure it made sense to use the same DialogUserManager
instance for both UAC and UAS functionality, which I really think it does.
From: Jason Fischl
[mailto:jason.fischl@xxxxxxxxx]
Sent: 23 April 2009 09:58
To: Brody, Chris - Acision
Cc: Adam Roach;
resiprocate-users@xxxxxxxxxxxxxxx
Subject: Re: [reSIProcate-users]
Separate DUM UAC/UAS?
I'm pretty sure that you
should be able to do this with DUM with a single instance of dum. You can
provide a hint to the TransportSelector by setting the port in the via. So when
you create your dum instance, make sure you add two (or more) Transports on
each of the ports that you want to support. When you create a SipMessage in dum
you just set the port on the via to the transport that you want it to use. You
can do this in a generic way using
DialogUsageManager::setOutgoingMessageInterceptor.
I am a bit rusty but this approach should work for you.
Jason
On Wed, Apr 22, 2009 at 9:31 PM, Brody, Chris - Acision <chris.brody@xxxxxxxxxxx> wrote:
Ideally we would like to have incoming traffic coming into one port
(5060 - UAS, according to spec) and have outgoing traffic (UAC) originate from
a different port, say 5080. With a commercial SIP stack, this would be a
standard configuration. In fact, if we used a SipStack instance without DUM, it
would have been possible to originate UAC traffic from a different port.
However, with the DUM, it appears that we can only configure one port number
for both incoming traffic (UAS) and originating outgoing traffic (UAC).
This is the only thing that does not seem possible with a single DUM instance
right now. It does not appear too hard to fix.
Thanks,
Chris
> -----Original Message-----
> From: Adam Roach [mailto:adam@xxxxxxxxxxx]
> Sent: 22 April 2009 20:17
> To: Brody, Chris - Acision
> Cc: 'resiprocate-users@xxxxxxxxxxxxxxx'
> Subject: Re: [reSIProcate-users] Separate DUM UAC/UAS?
>
> Dispatching the messages to multiple TUs, which seems to be where you're
> having difficulty, is actually the easiest part of the problem to solve.
> For example, you could build a shim TU that takes your UAS DUM and your
> UAC DUM as constructor arguments. Then, when the shim TU receives a
> message from the stack, it checks whether it is a request or a response,
> and sends it to the appropriate DUM instance.
>
> However, you're going to run into some odd situations with some messages
> in a dialog associated with one DUM, and others in that same dialog
> associated with the other. I'd hate to have to design the changes
> internal to DUM to make this happen -- they're going to be very complex
> and difficult to get right.
>
> I suspect there's a better way to handle whatever underlying problem
> you're trying to solve. Why do you think you want two DUMs?
>
> /a
>
> Brody, Chris - Acision wrote:
> > Hello,
> >
> > Another thing we would like to do is use different DialogUsageManager
> instance for a UAC function and UAS function. Apparently, it is possible
> to connect multiple DUM instances to a single SipStack instance, but to
> coordinate the message processing for the two DUM instances is a bit of a
> challenge given a standard select loop such as the following:
> > for (/*...*/;;) {
> >
fdset.reset();
> >
> >
mStack->buildFdSet (fdset);
> >
> > int err
= fdset.selectMilliSeconds(250);
> > (error
check code is omitted)
> >
> >
mStack->process (fdset);
> >
while(mDumUas->process()) ;
> > }
> >
> > Any suggestions and/or pointers?
> >
> > P.S. In general we do not find the DUM to be very well documented,
> especially in the areas of memory ownership such as AppDialog,
> AppDialogSet, etc. We will probably have to make some better documentation
> for ourselves and have just gotten approval to contribute back to the
> reSIProcate community.
> >
> > Thanks,
> > Chris
> >
> > This e-mail and any attachment is for authorised use by the intended
> recipient(s) only. It may contain proprietary material, confidential
> information and/or be subject to legal privilege. It should not be copied,
> disclosed to, retained or used by, any other party. If you are not an
> intended recipient then please promptly delete this e-mail and any
> attachment and all copies and inform the sender. Thank you.
> >
> >
> > _______________________________________________
> > resiprocate-users mailing list
> > resiprocate-users@xxxxxxxxxxxxxxx
> > List Archive: http://list.resiprocate.org/archive/resiprocate-users/
> >
>
This e-mail and any attachment is for authorised use by the intended
recipient(s) only. It may contain proprietary material, confidential
information and/or be subject to legal privilege. It should not be copied,
disclosed to, retained or used by, any other party. If you are not an intended
recipient then please promptly delete this e-mail and any attachment and all
copies and inform the sender. Thank you.
_______________________________________________
resiprocate-users mailing list
resiprocate-users@xxxxxxxxxxxxxxx
List Archive: http://list.resiprocate.org/archive/resiprocate-users/
--
Jason
Sent from Tallinn, Estonia
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
|