On 6/19/2018 12:24 PM, Alex Balashov wrote:
Abandoning SIP over UDP is a major topic for me these days. Once upon a time SBC's were a great place to prune packets to limbo under the 1500 byte MTU bar, but as we all know this is a losing battle with the bloating of SDP's and the supported header, and can cause random breakage. Furthermore with the internet at large becoming increasingly hostile towards UDP as a transport due to the massive DDOS possibilities many UDP protocols offer, the sip over udp client space is becoming increasingly difficult. Moving access-side to TCP offers literally nothing but upside, with one exception, failover, as you well identified. Of course an open-source SBC in software carried with it the possibility for automation and orchestration, and if you go TCP, then there's literally no excuse to not encrypt everywhere and go TLS with LetsEncrypt. TLS signaling also carries the benefit of carving through ALG's and anti-competitive ISP practices. I don't think most of the ITSP industry has moved to that insight yet, although anecdotally, it appears that the metastasis of increasingly tenacious ALGs is creating a NAT support crisis.
Worth noting here that i think its going to be regulatory issues that force this first on the peering side with SHAKEN/STIR (somewhat forced acronyms) advocating the cryptographic signing of invites at the hop-on point. This is pretty much guarenteed to break most current peering relationships and force carriers into at minimum TCP to support the signature payloads. Getting a handle on moving to TCP/TLS now will simply make you more effective when the inevitable happens. FWIW I fully support signing of invites and identity headers, but the proposals in SHAKEN/STIR i think are barking up an unsustainable bureaucracy tree that makes me want to watch Brazil.