[reSIProcate] non-listening (outbound) TCP transports

[Scott Godin]

...

On Mon, Nov 29, 2010 at 7:05 PM, Kennard White
<kennard_white at logitech.com>wrote:

> Hi,
>
> As part of testing the resip/repro epoll behavior, I have a test
> application that generates many parallel connections over parallel TCP
> transports. I treat these as RFC5626 outbound-like connections (e.g., behind
> a NAT). As such, there will never be incoming TCP connections to these
> transports: they are always outgoing. Thus there is no need to
> bind/listen/accept these ports. And in my case I need the free ports to
> enable more outgoing connections.
>
> I have implemented changes to support this (see attached patch file), but
> it raises several questions that I'd like to address before commiting. While
> my immediate need for this feature is to reclaim ports, that is an edge
> case. The more typical usage is for true RFC5626 outbound connections.
>
> 1. The patch adds a new constructor argument "int transportFlags" to the
> various Transport classes. It has default argument so backwards compat ok.
> Is this is reasonable approach? Is there a less intrusive way to do this? I
> could use a magic value for the port number, but that seems non-obvious and
> creates issues with Contact headers (next issue).
>

The only other thought I had is to create 2 new transport types that are
used to pass to SipStack::addTransport only  ie: TCP_NOBIND and TLS_NOBIND -
however I think your approach here is fine as well, however it will require
similar changes to DialogUsageManage::addTransport if we want to expose the
new flag to DUM users.
Note:  Your changes to SipStack::addTransport should include passing the
transport flags to the TLS transport as well, since the NOBIND mode could
apply to it.


> 2. What should the stack use for default Contact header value in this case?
> RFC5626 doesn't address this: it seems to assume standard 3261 behavior even
> though the contact address is un-routable. Currently (with this patch), the
> Transport is still configured with an interface&port, and this is used in
> the Contact header. Two options I can think of: insert some hard-coded
> well-known unroutable address (is there such a thing?), or use the transport
> information of the actual outgoing connection.
>

Great question - would love to hear from the RFC authors on this one - I'll
see what I can find out.  I think just putting the unroutable address/port
passed when adding the transports in the contact header is fine.  I'm pretty
sure this is what most SIP UA's do that are expecting RFC5626 behavior.  The
only reference I found in RFC5626 was:  "If the registrar did not
support outbound, the UA has potentially registered an un-routable contact.
 It is the responsibility of the UA to remove any inappropriate Contacts.".
 To me this seems to indicate that sending an unroutable contact is legal,
and that it's up to the application to correct issues that arise if
"outbound" is not supported.


> Thoughts?
>
> 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/20101201/a79dcf86/attachment.htm>