Re: [reSIProcate-users] Separate DUM UAC/UAS?

[Jason Fischl <jason.fischl@xxxxxxxxx>]

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