[stir] Re: [art] Re: Re: Re: For those of you who follow this kind of stuff.

[Roman Shpount <[e-mail]>]

On Wed, Oct 8, 2025 at 3:39 PM Richard Shockey <[e-mail]> wrote:

>  *From: *Roman Shpount <[e-mail]>
>
>
>
> Finally, if we intend to mandate the transmission of personally
> identifiable data with every call, we need to update SIP with a scalable
> and secure transport protocol. Most current carrier SIP implementations
> still use UDP.
>
>
>
> RS> Proof positive that you can’t fix stupid.
>
>
>
> What would you use as an alternative?
>
>
>
> RS> well TCP as a start. I just do not see the appetite for some new
> alternative. The Real Time Voice business is economically challenging at
> best and the people that could do this are either retired or 6 feet under.
> As a side bar I do get calls about RFC 6116 from time to time on the TN to
> URI issue.  OK fine. I get it, but to actually deploy it would probably
> require some form of DoH as the actual query protocol.  Its possible. I
> don’t necessarily advocate it but adding DoH to RFC 6116 could easily be
> handled by other national SDO as required by the regulators.
>
>
>

The problem with TCP or TLS, is that all the messages between two servers
should be sent over one connection. All messages from server to server go
over the same connection, and the responses to these messages can be sent
only over the same connection. If a server slows down processing one
message, no other messages are processed. If the TCP connection fails, a
bunch of responses get lost. If a single packet is dropped, the entire
queue of messages is delayed until the retransmission is received. This
does not work.

If you are interested, consider setting up two SIP proxies to send messages
only over a TLS link exhibiting 2-3% packet loss, and then run a load test.
Then do the same thing when sending messages over UDP. You would be amused
at what you see.
_____________
Roman Shpount