Re: [reSIProcate-users] Separate DUM UAC/UAS?
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.