Re: [sipcore] [stir] [Acme] NYTimes.com: How Do You Stop Robocalls?

["Olle E. Johansson" <[e-mail]>]

> On 15 Jul 2021, at 08:30, Roman Shpount <[e-mail]> wrote
Only addressing sipcore for now.

> On Wed, Jul 14, 2021 at 2:04 AM Olle E. Johansson <[e-mail] <mailto:[e-mail]>> wrote:
>> 13 juli 2021 kl. 17:35 skrev Roman Shpount <[e-mail] <mailto:[e-mail]>>:
>> 
>> On Tue, Jul 13, 2021 at 3:11 AM Olle E. Johansson <[e-mail] <mailto:[e-mail]>> wrote:
>> I would love to have a discussion on that - either on the sipcore list or somewhere else. I gave a lot of input to the SIPconnect update but there’s still a lot of work to do on the server2server case.
>> 
>> 
>> The areas I wanted to investigate were:
>> 1. Handling TLS connection failure at all stages of an INVITE transaction. Design a test suite for proxies and SBC to test this behavior.
>> 2. Support for multiple bidirectional TLS connections between two SIP endpoints or two clusters of SIP endpoints
>> 3. Dealing with slow proxy thread or slow proxy in the cluster when processing SIP transactions
>> 4. Best practices for high-performance TLS connections between proxies, including connection reuse, connection resumption, cipher suites, etc
>> 5. Look at SIP-over-QUIC as a next-generation secure SIP transport
> 
>  
> What do you think is the right way to proceed to deal with these issues? I want to limit the scope of this on addressing the issues related to set up a high scale TLS SIP connection between two service providers. I think these issues need to be addressed rather urgently, considering both the growing SIP message size as well as privacy concerns and regulations. It is time to move from UDP, and if implemented correctly TLS connection should be more reliable and only require about 10% extra CPU resources.
We may want to draft a problem statement for the TLS part to start with - documenting both server2server (domain2domain) and client to domain issues.  I think it is critical to document the issues before moving forward.

There are many issues when you start looking at it, like the connection reuse document that states that a server should request a client cert in order to do connection reuse - but not how to determine if a connection is a server2server or a client2server connection. In XMPP there’s a separate port for server2server, which solves that problem.

/O
> 
> I know there are also multiple issues related to TLS SIP connectivity from clients, but they might be slightly different than high-scale server-to-server connections.
>> 
> A good list. One thing that comes up now and then when meeting SIP developers is dialog survival.
> 
> We have many solutions for failover if a server dies, meaning we can always set up a new dialog. But when a server inside a route set dies, we have less documented survivability. There’s some hint in RFC 3263 if I remember correctly that if there is a DNS name in the route header, DNS srv may apply.
> 
> I never quite understood why target refresh request updates Contact and not the entire route set. It is generally useful to update the list of proxies used for the dialog. 
> _____________
> Roman Shpount