[reSIProcate] Forcing use particular Transport

[Scott Godin]

On Thu, Nov 4, 2010 at 12:58 AM, Kennard White
<kennard_white at logitech.com>wrote:

> 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 :-).
>

Interesting.  : )


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

Right - if the application populates the header, then the stack will not
touch it.  You could use a message decorator to "fixup" the Via before
sending on the wire.


> 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.
>

Not sure offhand - I would have to dig through the code to answer that.  : )


> 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
>>>>
>>>
>>>
>>
>
> _______________________________________________
> 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/20101104/6d5eb220/attachment.htm>