Hi,
I've been playing with SO_REUSEPORT (included in kernel since 3.9) and Kamailio quite successfully.
I have a branch for this in my personal fork (https://github.com/grumvalski/kamailio/tree/tcp_reuseport) that I've been planning to submit as a PR since a while.
If you agree I can do it to start the discussion.

Regards,

Federico


On Wed, Dec 7, 2016 at 9:36 AM, Daniel-Constantin Mierla <miconda@gmail.com> wrote:
Hello,

I will try to follow up with more on this discussion after I get the
time to check the resources at the links you mentioned. I know that
forcing a source port for a tcp connection was not reliable, but things
may have changed with newer versions of kernels.

Cheers,
Daniel


On 05/12/2016 14:01, Daniel Pocock wrote:
>
> 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-to-a-specific-local-port-with-winsock-so-reuse
>
>
>
> _______________________________________________
> sr-dev mailing list
> sr-dev@lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

--
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com


_______________________________________________
sr-dev mailing list
sr-dev@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev