[reSIProcate] Forcing use particular Transport

[Scott Godin]

Some additional information that may help:

When you pre-populate the Via header, the code to select the source
transport is at TransportSelector::determineSourceInterface line 427.
The source transport is set to the target's transport.

The code to populate the top Via header is in TransportSelector::transmit at
line 677.  You can see that the transport type will be populated if it is
empty:
            if (topVia.transport().empty())
            {
               topVia.transport() = Tuple::toData(source.getType());
            }

Transmit target is stored in the TransactionState::mTarget - it's lifetime
is related to the lifetime of the transaction.

Scott

On Thu, Nov 4, 2010 at 4:13 PM, Scott Godin <sgodin at sipspectrum.com> wrote:

>
>
> 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/20101110/247c324c/attachment.htm>