[reSIProcate] Forcing use particular Transport

[Kennard White]

Hi Scott,

This Via technique you pointed out doesn't seem to work for TCP. The reason
is that transmit() first uses findTransportByDest(), and if TCP it will try
findConnection(). It will then re-use that connection (and its Transport)
rather than the Transport I requested in the Via header. UDP does have this
problem because there is no cache of active connections (well, unless there
is a flow key, but that isn't my problem today :-).

As an additional issue, it doesn't "fix" the Via header to indicate the
actual Transport that it picked.

I notice that the Tuple "target" argument to transmit() has a transport
member. Where does this "target" originate, what is its lifetime? Perhaps
more importantly, can I arrange to somehow set target.transport? I doubt it
especially if a DNS lookup is involved, but thought it worth asking.

Thanks,
Kennard

On Fri, Oct 29, 2010 at 6:04 PM, Kennard White
<kennard_white at logitech.com>wrote:

> Thanks! I tried it out and it worked just fine.
>
> Kennard
>
>
> On Fri, Oct 29, 2010 at 5:11 PM, Scott Godin <sgodin at sipspectrum.com>wrote:
>
>> There is an existing way to do this.  Instead of passing a empty Via
>> header down to the stack and letting it populate it after the transport is
>> selected, you can pre-set it to the IP address of the interface that you
>> would like the request to be routed out.  This is what DUM uses when use the
>> Profile setting setFixedTransportInterface and setFixedTransportPort.
>>
>>       ///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);
>>       virtual int getFixedTransportPort() const;
>>       virtual void unsetFixedTransportPort();
>>
>>       ///If set dum will provide a interface in the via for requests sent
>> down to the stack.  This
>>       ///will tell the transport selector to only look at those transports
>> using this interface.
>>       ///Default is Data::Empty (Disabled).
>>       virtual void setFixedTransportInterface(const Data&
>> fixedTransportInterface);
>>       virtual const Data& getFixedTransportInterface() const;
>>       virtual void unsetFixedTransportInterface();
>>
>> Scott
>>
>> On Fri, Oct 29, 2010 at 4:55 PM, Kennard White <
>> kennard_white at logitech.com> wrote:
>>
>>> Hi,
>>>
>>> I'm opening up multiple Transports within one stack to enable a test
>>> scenario. I'd like to route particular SipMessage over to a particular
>>> Transport, as decided by app. I've made patch that allows app to call
>>> msg->setForceTransport() to control this. This is analgous to the existing
>>> forceTarget() call.
>>>
>>> Is this a reasonable approach? Is there a better (existing) mechanism?
>>>
>>> I've attached the patch.
>>>
>>> Thanks,
>>> Kennard
>>>
>>> _______________________________________________
>>> resiprocate-devel mailing list
>>> resiprocate-devel at resiprocate.org
>>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20101103/74aff49f/attachment.htm>