| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index |
>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.