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

[Roman Shpount <[e-mail]>]

On Wed, Jul 14, 2021 at 2:04 AM Olle E. Johansson <[e-mail]> wrote:

> 13 juli 2021 kl. 17:35 skrev Roman Shpount <[e-mail]>:
>
> On Tue, Jul 13, 2021 at 3:11 AM Olle E. Johansson <[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.

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