IETF Logo Mail Archive

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

"Olle E. Johansson" <oej@edvina.net> Wed, 14 July 2021 06:04 UTC

Return-Path: <oej@edvina.net>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0513A115A; Tue, 13 Jul 2021 23:04:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NiiM9y5RSK2S; Tue, 13 Jul 2021 23:04:14 -0700 (PDT)
Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 146203A1158; Tue, 13 Jul 2021 23:04:12 -0700 (PDT)
Received: from smtpclient.apple (h-176-10-205-16.A165.corp.bahnhof.se [176.10.205.16]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 30C951900; Wed, 14 Jul 2021 08:04:08 +0200 (CEST)
From: "Olle E. Johansson" <oej@edvina.net>
Message-Id: <FFB02EC8-F437-4469-82F1-052B3052FBCC@edvina.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_6C469E1C-3465-4993-970C-7E4D896C53DF"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
Date: Wed, 14 Jul 2021 08:04:06 +0200
In-Reply-To: <CAD5OKxuW5PCQQHT7nYrrD6zJuuppPYhUTqyw5q-_rKdKYKaMLw@mail.gmail.com>
Cc: "stir@ietf.org" <stir@ietf.org>, sipcore@ietf.org
To: Roman Shpount <roman@telurix.com>
References: <B0BBFDFA-4203-4660-A982-80A5B8DED746@contoso.com> <CAHBDyN57-8-ctw8L-5ob_ti2azBwEGqyEApGVSMwJgNM68Uscw@mail.gmail.com> <CAD5OKxsy3xODy2mXHJcKB=ihwdOeLLYiLaDpORa4B33j7TUuhw@mail.gmail.com> <FDA56FC9-ADDD-4A5C-8624-3F0CC822E230@edvina.net> <CAD5OKxvYMERn9++0-igHxCLf5=DwPGH7E-T+OzH1NNiGZp0tHA@mail.gmail.com> <357B6EDB-C403-4539-B760-F76118F3E7B5@edvina.net> <CAD5OKxuW5PCQQHT7nYrrD6zJuuppPYhUTqyw5q-_rKdKYKaMLw@mail.gmail.com>
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/2-ZZM2Lw416L01QaP8YeAcUkFn0>
Subject: Re: [stir] [Acme] NYTimes.com: How Do You Stop Robocalls?
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Jul 2021 06:04:20 -0000


> 13 juli 2021 kl. 17:35 skrev Roman Shpount <roman@telurix.com>:
> 
> On Tue, Jul 13, 2021 at 3:11 AM Olle E. Johansson <oej@edvina.net <mailto:oej@edvina.net>> 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
> 
> 
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.


/O

v2.23.0 | Report a Bug | By Email