source port for TCP & TLS connections - sr-dev

5 Dec 2016

RFC 3261 doesn't appear to require anything more than the default random
selection of source port for transports like TCP and TLS

Section 18[1] even appears to anticipate that two proxies communicating
over reliable transports may have two different connections open at the
same time, one for requests initiated in each direction.

However, I've seen a couple of situations where using the listening port
as the source port would be beneficial:

- peer has buggy implementation that tries to connect back to source
port / rport (which should only happen for unreliable transports),
observed in reSIProcate[2]

- firewall policy is particularly strict and prefers or even expects
specific source ports to be used

- potentially halves the number of sockets / FDs required (better use of
system resources)

It is not hard to configure a TCP (or TLS) client socket to use a
specific[3] source port, although as that example[3] demonstrates, there
could be situations where a socket is not fully closed and a new one
can't be opened immediately for the same source/dest port combination. 
That type of issue doesn't arise for randomly selected source ports.

Has anybody else tried setting a fixed source port for TCP/TLS
connections and can you share any observations about this for better or
worse?

Has anybody seen similar behaviour to the bug[2] in other SIP
implementations?

We are thinking about implementing this as an optional feature in
reSIProcate, partly to help people mitigate the impact of peers who have
the bug #137.

Regards,

Daniel

1. https://tools.ietf.org/html/rfc3261#section-18

2. https://www.resiprocate.org/bugzilla/show_bug.cgi?id=137

3.
http://stackoverflow.com/questions/2605182/when-binding-a-client-tcp-socket…