Re: [reSIProcate] Forcing use particular Transport

[Scott Godin <sgodin@xxxxxxxxxxxxxxx>]

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

On Thu, Nov 4, 2010 at 12:58 AM, Kennard White <kennard_white@xxxxxxxxxxxx> 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@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

_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel