[reSIProcate] Some questions about dum

[Scott Godin]

>OK, what about the overrideHostAndPort setting. Will this do

>what I want? Apparently it can't mean the host and port to 

>listen on.

 

No - this will override the Contact Address - you would use this in NAT scenarios - when you now what your public IP Address/port will be.  In order to try to force the outbound transport used - you would need to set the Via header directly before sending - the problem is that you don't always have access to the request/response messages before they are sent in DUM.  There is a profile options to fix the transport port:

//If set dum will provide a port in the via for requests sent down to the stack.  This

//will tell the transport selector to only look at those transports using this port.

//Default is 0 (Disabled).

//WARNING:  Setting this can cause undesirable behaviour in the case when you want

//          DNS entries to decided your transport and you are supporting TLS.

//          For example: if you add UDP:5060, TCP:5060 and TLS:5061 and setFixedTransportPort 

//          to 5060 - then the TLS transport cannot be used.

virtual void setFixedTransportPort(int fixedTransportPort);

 

>When I add several transports with different IP addresses,

>will I know on which IP address and port a message was

>received or should I better use several DUM objects instead?

 

There is a method of the SipMessage class that you can use to retrieve the interface/port the message was received on.

 

>Another question: Is it correct that all dum functions will 

>return "immediately" without doing any actual sending?

 

Yes.

 

>Should I create a thread then, that calls the dum->process()

>method to perform actual processing? 

 

Yes.  Please look at the following for more info:

http://warsaw.sjc.purplecomm.com/wiki/index.php?title=DUM_Threading

http://warsaw.sjc.purplecomm.com/wiki/index.php?title=FAQ#How_does_the_buildFdSet.2C_select.2C_process_loop_work.3F

 

>If this approach is correct approach, does dum implement 

>any critical sections or mutexes to avoid a call to a 

>function like dum->send(...) while the thread is executing

>the dum->process() function?

 

No - see the notes in the link above.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20051006/fa416ee5/attachment.htm>