Re: [reSIProcate] Forcing use particular Transport

[Kennard White <kennard_white@xxxxxxxxxxxx>]

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@xxxxxxxxxxxx> wrote:

Thanks! I tried it out and it worked just fine.

Kennard

On Fri, Oct 29, 2010 at 5:11 PM, Scott Godin <sgodin@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel