[reSIProcate] non-listening (outbound) TCP transports
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).
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.
Thoughts?
Thanks,
Kennard
Attachment:
resip-tpflags1.patch
Description: Binary data