[VoiceOps] New blog article: Kamailio as an SBC - five years on
ryandelgrosso at gmail.com
Tue Jun 19 16:03:18 EDT 2018
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the VoiceOps