Re: [reSIProcate] non-listening (outbound) TCP transports
...
On Mon, Nov 29, 2010 at 7:05 PM, Kennard White
<kennard_white@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel