[VoiceOps] Phone auth for incoming calls?

[Alex Balashov]

Agree with everything Ryan said, with the caveat that TLS for TLS's sake is, in my own humble opinion, a terrible idea from a troubleshooting and general complexity perspective. Use where absolutely necessary and nowhere else. 

On August 8, 2018 7:37:13 PM EDT, Ryan Delgrosso <ryandelgrosso at gmail.com> wrote:
>OK so to expand on my previous smug-ness
>
>Upsides:
>
>  * No more signaling nat issues. Literally zero. If you want to be
>    super-sneaky run your edge over TLS port 443 and most things wont
>    touch you.
>  * No retransmission's or registration avalanches. They simply cannot
>    happen since you need a tcp session first.
> * No packet fragmentation issues. Send massive bloated SDP's and never
>    worry about pruning headers again. If you are doing sip SIMPLE send
>    mime bodies in messages if you want. Its all good.
> * Faster convergence (if you reset the TCP connections to your devices
>    it will usually trigger an instantaneous proxy advance)
>  * Real-HA on carrier grade SBC's works just fine and TCP state is
>    maintained across pairs (Acme, Perimeta etc)
>  * Never chase lost signaling
>
>
>Downsides:
>
>  * Conventional HA doesnt work so well. Your reg/subscription etc will
>   all be in the context of a single TCP session (with or without TLS).
>    This means for that second when you restart your proxy the session
>    is lost and MUST be re-establised by the client.
>  * SIP Outbound support, which would basically be the answer here
>    basically doesn't exist in a usable fashion for reliable dual-reg.
>    Device support is partial and broken. Its not good. There are
>    potential solutions but it involves real commitment to this right
>    now and the gulf of experience between having and not isnt huge.
> * Moderately more load since TCP state must be retained, but on modern
>    hardware this is so trivial its almost not worth mentioning.
>  * Need to re-learn KPI's for network. The entire signaling profile
>    changes. Its just a different animal.
> * Most of your sniffer-based diagnostic tools become useless (for tls)
>    since packets wont be readable. This is dodged with an edge that
>    will feed encrypted traffic to a collector.
>
>
>Suggestions:
>
>STRONGLY recommend terminating TCP/TLS at the edge and still running 
>core in straight UDP with jumbo frames. You dont want a cascde of tcp 
>session reestablishments
>
>I have a growing SP network today doing this with great success and
>also 
>advise my consulting clients to take this path.
>
>
>
>On 8/8/2018 12:36 PM, Alex Balashov wrote:
>> On Wed, Aug 08, 2018 at 12:21:09PM -0700, Carlos Alvarez wrote:
>>
>>> So...who else on the list uses TCP and has any comments about it?
>> We are not an ITSP and are Polycom-only with a trivial number of
>> endpoints, but we do use it and it works just fine.
>>
>> However, we have numerous customers, some of whom use TCP
>predominantly
>> for thousands of endpoints. It works just fine.
>>
>> In terms of downsides:
>>
>> In addition to a historical lack of (RFC 3261-mandated) support,
>there
>> are of course theoretical trade-offs involved in using TCP. There's
>> more overhead, and connection state to be maintained on the server
>side,
>> which of course consumes resources — resources considered trivial
>> nowadays, but once upon a time, when RFC 3261 was ratified (2002),
>> perhaps not. As with all things TCP, it can also present a DoS vector
>if
>> you don't limit the number of connections somewhere.
>>
>> The congestion control/end-to-end delay aspects of TCP are certainly
>not
>> as important now as they were at a time when the public IP backbone
>and
>> was in an entirely different place in its evolution. Also, nowadays
>the
>> congestion/windowing algorithms used in TCP can be tweaked to
>something
>> more efficient.
>>
>> I think the most damning thing about using TCP is perceived to be the
>> relative difficulty of failing over TCP session state to a different
>> host. UDP does not require connection state, so as long as you have
>some
>> means of handling requests in a relatively stateless fashion, things
>can
>> just carry on as they did before in the event of an IP takeover
>without
>> anyone having to "reconnect". This is one area where the big
>enterprise
>> boxes certainly trump the open-source ecosystem, where transparent
>TCP
>> failover *for SIP* doesn't really exist, although in my opinion the
>> whole issue is getting a bit moot with the way cloud infrastructure
>and
>> virtualisation networking is evolving.
>>
>> -- Alex
>>


-- Alex

--
Sent via mobile, please forgive typos and brevity.