Re: [sr-dev] source port for TCP & TLS connections

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… _______________________________________________ sr-dev mailing list sr-dev(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev