[reSIProcate] Forcing use particular Transport

[Scott Godin]

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/20101029/e8e66f51/attachment.htm>