[reSIProcate] non-listening (outbound) TCP transports

Kennard White kennard_white at logitech.com
Mon Nov 29 18:05:19 CST 2010


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20101129/f25d1912/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: resip-tpflags1.patch
Type: application/octet-stream
Size: 9839 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20101129/f25d1912/attachment.obj>


More information about the resiprocate-devel mailing list