From nobody Tue Jul 13 23:04:20 2021 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@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" Message-Id: 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: Cc: "stir@ietf.org" , sipcore@ietf.org To: Roman Shpount References: <357B6EDB-C403-4539-B760-F76118F3E7B5@edvina.net> X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [sipcore] [stir] [Acme] NYTimes.com: How Do You Stop Robocalls? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2021 06:04:20 -0000 --Apple-Mail=_6C469E1C-3465-4993-970C-7E4D896C53DF Content-Type: multipart/alternative; boundary="Apple-Mail=_829BDC92-E4C0-45F4-BEC1-8239DF7FFF29" --Apple-Mail=_829BDC92-E4C0-45F4-BEC1-8239DF7FFF29 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > 13 juli 2021 kl. 17:35 skrev Roman Shpount : >=20 > On Tue, Jul 13, 2021 at 3:11 AM Olle E. Johansson > 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=E2=80=99s still a lot of work to do on the server2server case. >=20 >=20 > 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 >=20 >=20 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=E2=80=99s 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 --Apple-Mail=_829BDC92-E4C0-45F4-BEC1-8239DF7FFF29 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

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> = 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=E2=80=99s 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=E2=80=99s 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
= --Apple-Mail=_829BDC92-E4C0-45F4-BEC1-8239DF7FFF29-- --Apple-Mail=_6C469E1C-3465-4993-970C-7E4D896C53DF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: http://edvina.net iQGzBAEBCAAdFiEEAsV9zKckq/QkNi1DMKLWpfU/lUYFAmDuflYACgkQMKLWpfU/ lUYvBQv+IJRRU16hXgWXUVDuAwQalLBb9PnKdUpcGh3CXD8ysZ/8m2R41jXCkbUJ sFvL5KmC9ykhUcsIgyFqRGcfAQg9Jx6DsJdfKxAUAjvv5qUsPQnl8rucNmrW1sw9 SmfTIdi5EKlBb1CK8zIgJ5FuSHyYFwiVUUxiSdFmDmug92S8JkrNtGcFs0sNdTwy kzoQYolgvCeeAa1iw5d0oFHyeY2Ft7nkmFV5OcNnIQgA/QFlFNO/9fW+UzgGG5u6 x3mqVDLbzGVG+tfOTol0KFjrC4mxs2I+2gtfMr9nrdvFbdxNzSzzp10J+grtSLVd zipUivZcLsT1fTF6lFr+JwIvuQE3uRScRuUXf2i/JNO+BHLL0RFmqvmua5KVvgTA l76F9X8ulDJtPcD+Uprgee3wYjZGydQN4ykvgycMNKZEQ4zmDlR5azYi+/N/nayq en/2EWO1JrFC7n/5U9kp5CoFiCIe/nAPXJ2CphlNaxvmyo7zhiY+p+SnplzLYSo/ 05oKPS2u =+y2F -----END PGP SIGNATURE----- --Apple-Mail=_6C469E1C-3465-4993-970C-7E4D896C53DF-- From nobody Wed Jul 14 23:30:52 2021 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B03DA3A1EC4 for ; Wed, 14 Jul 2021 23:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=telurix.com 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 Yhc7XORkKP6t for ; Wed, 14 Jul 2021 23:30:36 -0700 (PDT) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0AA33A1ECE for ; Wed, 14 Jul 2021 23:30:30 -0700 (PDT) Received: by mail-qk1-x72a.google.com with SMTP id j184so4168798qkd.6 for ; Wed, 14 Jul 2021 23:30:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kA5hhIRwULR4v70ES7tOB5nq7KuDl7xBRq4gyd0uCZY=; b=XEGi5JlgWrUfIyTeFKfqYhOXAsQDxSljmXM/G3snKu4qQR1UNM0WHCQkJd+hfwW5aY zjcIvpvm98Z3nmLw27HZTEh/o9aVexuxlZvVEdaAFiEauxaDtpyabngn+EqIQufdkvJu tRkeeAqBujG7VN+T+Gqh6ETzRtG80oW9NHCL8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kA5hhIRwULR4v70ES7tOB5nq7KuDl7xBRq4gyd0uCZY=; b=n+stvv6Eq1LYpC5/6viVf8PKhSsBSTz4vLj4ADH9qu7A4Ec/r7INC7ZFrtnFVraITc tP7muQ5wsXecs7VRq4XgyTl3jxlRy4VmuCweYp1p0ooR8M+i6kyz0yD3Ip0PFwfSImxF kPrqymjAvp2CJpW4Xh/ARMEDff3mP6KzMYu2qHeTHK/LH6a+2JyoOKvAoHBCOkrsSA0J h4bA0CqHRUwQ6U2fVEOuXisMOZfSC7NYLjBTl3l+cCSkMtm12qZlenhIG5iY8HIuovft ovrRQqVuFDqfuhCwffHi6DQopRw6Qph6Gfqv3g8pJo6BMXEmRCOwF1t7uAzjnB+TKJcD trwA== X-Gm-Message-State: AOAM533XhYzdEe86BbPLFnmXJHQFv87b4mHO4CND5Q2gLfShgMcJ5Fau mfMvrGQVFOaaghe2xROYL0KhP0mah1/XTw== X-Google-Smtp-Source: ABdhPJxnyt8yv+so6qMsMVqNSROpCkG8kd13GaCrwRfHnE2ZW1Rgeg5IFmrwjNPYiWxmNykyaKf8uA== X-Received: by 2002:a37:bb81:: with SMTP id l123mr2195387qkf.50.1626330629477; Wed, 14 Jul 2021 23:30:29 -0700 (PDT) Received: from mail-yb1-f173.google.com (mail-yb1-f173.google.com. [209.85.219.173]) by smtp.gmail.com with ESMTPSA id b2sm1720952qtp.7.2021.07.14.23.30.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Jul 2021 23:30:28 -0700 (PDT) Received: by mail-yb1-f173.google.com with SMTP id c16so567232ybl.9; Wed, 14 Jul 2021 23:30:27 -0700 (PDT) X-Received: by 2002:a25:c9c7:: with SMTP id z190mr3264410ybf.21.1626330627668; Wed, 14 Jul 2021 23:30:27 -0700 (PDT) MIME-Version: 1.0 References: <357B6EDB-C403-4539-B760-F76118F3E7B5@edvina.net> In-Reply-To: From: Roman Shpount Date: Thu, 15 Jul 2021 02:30:16 -0400 X-Gmail-Original-Message-ID: Message-ID: To: "Olle E. Johansson" Cc: "stir@ietf.org" , SIPCORE Content-Type: multipart/alternative; boundary="00000000000059807705c7239b1d" Archived-At: Subject: Re: [sipcore] [stir] [Acme] NYTimes.com: How Do You Stop Robocalls? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2021 06:30:51 -0000 --00000000000059807705c7239b1d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 14, 2021 at 2:04 AM Olle E. Johansson wrote: > 13 juli 2021 kl. 17:35 skrev Roman Shpount : > > On Tue, Jul 13, 2021 at 3:11 AM Olle E. Johansson wrote: > >> I would love to have a discussion on that - either on the sipcore list o= r >> somewhere else. I gave a lot of input to the SIPconnect update but there= =E2=80=99s >> 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=E2=80=99s some hint in RFC 3263= if I > remember correctly that if there is a DNS name in the route header, DNS s= rv > 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 --00000000000059807705c7239b1d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jul 14, 2021 at 2:04 AM Olle E. Johansson <oej@edvina.net> wrote= :
13 juli 2= 021 kl. 17:35 skrev Roman Shpount <roman@telurix.com>:

On Tue, Jul 13, 2021 at 3:11 AM Oll= e E. Johansson <oej@= edvina.net> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
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=E2=80=99s still a l= ot of work to do on the server2server case.

<= /blockquote>

The areas I wanted to investigate were:
1. Handling TLS connection failure at all stages of an INVITE transa= ction. 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 p= roxy 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,= =C2=A0etc
5. Look at SIP-over-QUIC as a next-generation secure SI= P transport
=C2=A0
What do you think is the right way to proceed to deal w= ith these issues? I want to limit the scope of this on addressing the issue= s related to set up=C2=A0a high scale TLS SIP connection between two servic= e providers. I think these issues need to be addressed rather urgently, con= sidering 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 res= ources.

I know there are also multiple issues rela= ted to TLS SIP connectivity from clients, but they might be slightly=C2=A0d= ifferent than=C2=A0high-scale server-to-server connections.

A good list. One thing that comes up now and then= when meeting SIP developers is dialog survival.

W= e 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 les= s documented survivability. There=E2=80=99s some hint in RFC 3263 if I reme= mber correctly that if there is a DNS name in the route header, DNS srv may= apply.

I never quite und= erstood why target refresh request updates Contact=C2=A0and not the entire = route set. It is generally useful to update the list of proxies used for th= e dialog.=C2=A0
_____________
= Roman Shpount
--00000000000059807705c7239b1d-- From nobody Wed Jul 14 23:58:12 2021 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 439003A1F89 for ; Wed, 14 Jul 2021 23:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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 bFwAuv8cwkZi for ; Wed, 14 Jul 2021 23:58:06 -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 A9A7C3A1F83 for ; Wed, 14 Jul 2021 23:58:05 -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 15E811900; Thu, 15 Jul 2021 08:58:02 +0200 (CEST) From: "Olle E. Johansson" Message-Id: <17ED4B2F-D445-4E35-B722-995EC9D4567B@edvina.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_99E2CD5E-AF7D-44CB-9DE0-F2B48D8720E2" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Thu, 15 Jul 2021 08:57:56 +0200 In-Reply-To: Cc: SIPCORE To: Roman Shpount References: <357B6EDB-C403-4539-B760-F76118F3E7B5@edvina.net> X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [sipcore] [stir] [Acme] NYTimes.com: How Do You Stop Robocalls? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2021 06:58:11 -0000 --Apple-Mail=_99E2CD5E-AF7D-44CB-9DE0-F2B48D8720E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 15 Jul 2021, at 08:30, Roman Shpount wrote Only addressing sipcore for now. > On Wed, Jul 14, 2021 at 2:04 AM Olle E. Johansson > wrote: >> 13 juli 2021 kl. 17:35 skrev Roman Shpount >: >>=20 >> On Tue, Jul 13, 2021 at 3:11 AM Olle E. Johansson > 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=E2=80=99s still a lot of work to do on the server2server case. >>=20 >>=20 >> 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 >=20 > =20 > 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=E2=80=99s = a separate port for server2server, which solves that problem. /O >=20 > 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. >>=20 > A good list. One thing that comes up now and then when meeting SIP = developers is dialog survival. >=20 > 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=E2=80=99s some hint in RFC = 3263 if I remember correctly that if there is a DNS name in the route = header, DNS srv may apply. >=20 > 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.=20 > _____________ > Roman Shpount --Apple-Mail=_99E2CD5E-AF7D-44CB-9DE0-F2B48D8720E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 15 Jul 2021, at 08:30, Roman Shpount <roman@telurix.com> = wrote
Only = addressing sipcore for now.

On Wed, Jul 14, 2021 at = 2:04 AM Olle E. Johansson <oej@edvina.net> wrote:
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> 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=E2=80=99s 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=E2=80=99s 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=E2=80=99s 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

= --Apple-Mail=_99E2CD5E-AF7D-44CB-9DE0-F2B48D8720E2-- From nobody Wed Jul 21 00:41:01 2021 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA5D83A082E for ; Wed, 21 Jul 2021 00:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 gmODfhpLRH9a for ; Wed, 21 Jul 2021 00:40:55 -0700 (PDT) Received: from mail-vk1-xa33.google.com (mail-vk1-xa33.google.com [IPv6:2607:f8b0:4864:20::a33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6CC03A0829 for ; Wed, 21 Jul 2021 00:40:49 -0700 (PDT) Received: by mail-vk1-xa33.google.com with SMTP id x125so358694vkf.0 for ; Wed, 21 Jul 2021 00:40:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=nl8sLBJ7B0uCjLCpkUFJmWErJZveVNvz2A/Fjn2Nm6A=; b=HmBcU/il5zoUsVZenu0GW3ZZ90dAErltn3XAxnxsvaBaSEbXFotBtycLbJnnazapYm GbS70cv0vaxphjsT42tICHq0RLQrEgs1dAYXJr6wG4kOCPiKjZvNFcnTHLwhtSItCwVk uxzufF0ci5tfl1WkaiCp720hyjb2wRVm9D1kS85K4A9las519spWJ10h6BZg3X0xrRUL Hq1zd42Mw1GN2g14urBkyyGiuJzokj14mVkuROHzZ9mLijdgvfL0+KW9qv6wWWechhEU VhnSWNH5rEmzQRUvpAdS9QzYPD4xhzZzUR2QPiMoSwfxTVF+DI30SXRbBLeJ+FNvL8yR 6KCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=nl8sLBJ7B0uCjLCpkUFJmWErJZveVNvz2A/Fjn2Nm6A=; b=pgCmImf1RNMKyuWsmN/iPekJVkEe0YjB4Tk5iChL4PdmRvtDGSjbH0Wo2FQPrsvHpT nCOiAXmIzVuv5QdI7mmEru6jZW362Scy+BRx2YZFOelVHv2OJxaC4Rqd3m/NC1196dXz xJyWWgWloGw7wotUIEQMqhUVNccAviDDMWZ3IVf77oZukTIA8ZrUHpeZACK3rVpymT8A AM1EyxMyAmupRH3KzBn+G0p5OPJ6aa/auGnAUbv/RX30gukoZ3d8dXo4q+vcPtXJ/05Q 6NkJwvfD264NYtRY9La1E+2jAsrnAgBY8UZ5bD6u+tO7MGs6b8r/yVZG5OrX1OE0cyod o7Uw== X-Gm-Message-State: AOAM532t6dHM76q+uFVrRgvV+MkGtXoFOwHtVEwb2frR7vzgcL9WOY6z Hn4kW+dd15nR5coceHn4L+xJ9sYkm5ewTi0YXklEoELwAmi5Tw== X-Google-Smtp-Source: ABdhPJxw7ntd9VyaX/2yIPEhTqgmpt06VGqpfizmQ6qgDFVOL6bLx8HXoq/1jNToe67Hr/7tpyD6Q2fMywYL7e13mUA= X-Received: by 2002:a1f:cf47:: with SMTP id f68mr30316311vkg.7.1626853248522; Wed, 21 Jul 2021 00:40:48 -0700 (PDT) MIME-Version: 1.0 From: Filippos Vasilakis Date: Wed, 21 Jul 2021 09:40:37 +0200 Message-ID: To: sipcore@ietf.org Content-Type: multipart/alternative; boundary="000000000000faddd205c79d49b8" Archived-At: Subject: [sipcore] response context association on stateful proxies X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2021 07:41:00 -0000 --000000000000faddd205c79d49b8 Content-Type: text/plain; charset="UTF-8" Hi everyone, According to RFC 3261, a stateful proxy in section 16: A stateful proxy must have a mechanism to maintain the target set as responses are received and associate the responses to each forwarded request with the original request. My question is, how do we implement this association? You have the original request, then this is forked to many new requests (the target set) and each request from the target set might have one or more response (the response context). However, once you fork the original request, you have a completely new transaction, that the proxy plays the client role, while for the original request, the proxy plays the server role. So my question is how do you implement the matching/association between the original request/transaction and the new forked requests/responses/transaction? Is it enough to work match only on the branch ids of the transaction from each side, or something more is needed? I am surprised that RFC 3261 doesn't come up with a suggestion/recommendation on that (I mean, it has been super helpful in any other place with insights on implementations). /Filippos --000000000000faddd205c79d49b8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone,

According to RFC 326= 1, a stateful proxy in section 16:

A stateful proxy must have a mech= anism to maintain the target set as
=C2=A0 =C2=A0responses are received = and associate the responses to each forwarded
=C2=A0 =C2=A0request with = the original request.

My question is, how do we implemen= t this association? You have the original request, then this is forked to m= any new requests (the target set) and each request from the target set migh= t have one or more response (the response context). However, once you fork = the original request, you have a completely new transaction, that the proxy= plays the client role, while for the original request, the proxy plays the= server role.

So my question is how do you implement the matc= hing/association between the original request/transaction and the new forke= d requests/responses/transaction? Is it enough to work match only on the br= anch ids of the transaction from each side, or something more is needed?

I am surprised that RFC 3261 doesn't come up wit= h a suggestion/recommendation on that (I mean, it has been super helpful in= any other place with insights on implementations).

/Filippos
<= /div> --000000000000faddd205c79d49b8-- From nobody Tue Jul 27 13:10:45 2021 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 320263A109D; Tue, 27 Jul 2021 13:10:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.35.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sipcore@ietf.org Message-ID: <162741664405.4357.2194886272596595988@ietfa.amsl.com> Date: Tue, 27 Jul 2021 13:10:44 -0700 Archived-At: Subject: [sipcore] I-D Action: draft-ietf-sipcore-rfc4028bis-05.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2021 20:10:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core WG of the IETF. Title : Session Timers in the Session Initiation Protocol (SIP) Authors : Christer Holmberg Steve Donovan Jonathan Rosenberg Filename : draft-ietf-sipcore-rfc4028bis-05.txt Pages : 26 Date : 2021-07-27 Abstract: This document defines an extension to the Session Initiation Protocol (SIP). This extension allows for a periodic refresh of SIP sessions through a re-INVITE or UPDATE request. The refresh allows both user agents and proxies to determine whether the SIP session is still active. The extension defines two new header fields: Session- Expires, which conveys the lifetime of the session, and Min-SE, which conveys the minimum allowed value for the session timer. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc4028bis/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-rfc4028bis-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-rfc4028bis-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 27 13:29:15 2021 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 853DD3A1178 for ; Tue, 27 Jul 2021 13:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 y-5_6xHaUkQG for ; Tue, 27 Jul 2021 13:29:01 -0700 (PDT) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (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 E7D0A3A1175 for ; Tue, 27 Jul 2021 13:29:00 -0700 (PDT) Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-11v.sys.comcast.net with ESMTP id 8SiBm5PRrjtOr8ThDmtuwB; Tue, 27 Jul 2021 20:28:59 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1627417739; bh=HCYl05wR8LrNnbZHIFMqu1RR0GWmsrhERrcBEcVHoTA=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=aaShgUo/o+H8caN2LTvwvV+AlsWT71AtlTTmbChJSqBkWKgqPAnPb48zC3Y1v9oI0 Dql/qOZu87Vson/OERwzgS3kocFHwc4j+BV4J+sDS+c4ezYxk0sUyR65vxue5zQZK0 zZglhTgRbakketwuBCq4X6lc7P7/tJhTDNGKcG3cK3vluMwxarwjfb3q7u59eiMQTp jgrU+c2jj7GZfO5Gbl8KzjTAod1kpqUyillZhik0aHoBG0saITYK59tKZ4ISQs24SW NVP3xDmGUGN9rPaVImsXrYam7PbIf/m3/4YFt+u2jX8M2AOTXejju4+bqEyGxzb6Sh g8LSKUJgnGyhg== Received: from MacBook-Air.localdomain ([24.62.227.142]) by resomta-ch2-08v.sys.comcast.net with ESMTPA id 8Th9mpmBVPmFw8ThBmyxXj; Tue, 27 Jul 2021 20:28:59 +0000 X-Xfinity-VAAS: gggruggvucftvghtrhhoucdtuddrgedvtddrgeejgddugedtucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuvehomhgtrghsthdqtfgvshhipdfqfgfvpdfpqffurfetoffkrfenuceurghilhhouhhtmecufedtudenucenucfjughrpefuvfhfhffkffgfgggjtgfgsehtjeertddtfeejnecuhfhrohhmpefrrghulhcumfihiihivhgrthcuoehprghulhdrkhihiihivhgrthestghomhgtrghsthdrnhgvtheqnecuggftrfgrthhtvghrnhepgeegtdetveefveduveegvdffffeuudfhfeevtddtfedtieffveegueevffdulefhnecuffhomhgrihhnpehivghtfhdrohhrghenucfkphepvdegrdeivddrvddvjedrudegvdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopeforggtuehoohhkqdetihhrrdhlohgtrghlughomhgrihhnpdhinhgvthepvdegrdeivddrvddvjedrudegvddpmhgrihhlfhhrohhmpehprghulhdrkhihiihivhgrthestghomhgtrghsthdrnhgvthdprhgtphhtthhopehsihhptghorhgvsehivghtfhdrohhrghdprhgtphhtthhopegthhhrihhsthgvrhdrhhholhhmsggvrhhgsegvrhhitghsshhonhdrtghomh X-Xfinity-VMeta: sc=0.00;st=legit To: "Christer.Holmberg@ericsson.com" References: <162741664405.4357.2194886272596595988@ietfa.amsl.com> Cc: SIPCORE From: Paul Kyzivat Message-ID: <88f4b4ed-11b5-3185-1c67-3fb6f3425aae@comcast.net> Date: Tue, 27 Jul 2021 16:28:55 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <162741664405.4357.2194886272596595988@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-rfc4028bis-05.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2021 20:29:13 -0000 Christer, IIUC this is just a copy of 4028 reformatted using current tools. I presume this is just intended as a starting point for upcoming revisions. Do I have it right? Thanks, Paul On 7/27/21 4:10 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Session Initiation Protocol Core WG of the IETF. > > Title : Session Timers in the Session Initiation Protocol (SIP) > Authors : Christer Holmberg > Steve Donovan > Jonathan Rosenberg > Filename : draft-ietf-sipcore-rfc4028bis-05.txt > Pages : 26 > Date : 2021-07-27 > > Abstract: > This document defines an extension to the Session Initiation Protocol > (SIP). This extension allows for a periodic refresh of SIP sessions > through a re-INVITE or UPDATE request. The refresh allows both user > agents and proxies to determine whether the SIP session is still > active. The extension defines two new header fields: Session- > Expires, which conveys the lifetime of the session, and Min-SE, which > conveys the minimum allowed value for the session timer. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc4028bis/ > > There is also an htmlized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-rfc4028bis-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-rfc4028bis-05 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Tue Jul 27 14:21:19 2021 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8323A0820 for ; Tue, 27 Jul 2021 14:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com 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 WqknfpgLfUnm for ; Tue, 27 Jul 2021 14:21:12 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00054.outbound.protection.outlook.com [40.107.0.54]) (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 43FEE3A081C for ; Tue, 27 Jul 2021 14:21:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kdMQjua1MUTRtYSeXAUH/mGFMjM+G53bRppQ7SN2UXVwbM1MIYZOgsiS4r9Aa7/FP+2INqOFsAwZFVf8Qg0aTqKynx7zc3fuT4Snsht15hdpgN4SAwGZ5jY1DfXrT4bdi2gvI9CL4yi7LGVnaG8OWM7jkHBBZTpdIDfO/LxoGdmDWwKugMmHIOfaul8B4T9TfUCAH7e2zMR1TUJtSvUr5o59mLTfAoiutBIBdN3tadPVq9egY0USSdRatpm2uPz/v958mJoI0f7BPoi4+TqhRbQM6E1deKFwUAx+02pZ0ejLg3wvbXiOLTQihQWmobCm9DepWum+LBZ2AwoPQopWVQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Q+5lO6uvNBZvAXhhS9Kh7mLZTT/gtfqGDc35n0e+4v0=; b=KDiQYM5ZBr39wxO21MAmxWHPHeHRnils9BwhMy9/uGjO19cujO1z/eg4QXMup23H1x5DLOvlBLumGyv9XtBFBgAdI3lBSB4Lkz3qOoFAesp7rHraxCxp+hx9Zj28VjrdlD5kIYUELfBPhEE16ipDfA3Z0dLbj0XTeBis9YBKJS6xwKkhYcTyoCwELFWtK53lCmbccBAvvkUmwDwlXEdysSerVxUBt00c1WgBcS02XvkM+N7rn0C8SKdaNR7o2KNW8FHd/o+Uojf26ix215Jd0CuTC4siddEUPjVzgZd5cnggyGL14o7TlDwZ+KtZl+V1sfyHvJnqUP+Qaycb14anuw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Q+5lO6uvNBZvAXhhS9Kh7mLZTT/gtfqGDc35n0e+4v0=; b=Z6ZG4klt6YGsCOxRrS5iDOOrb3PEMNpNGxmue+HGjR7uKn71+e3GyyrARc0aQk5xuY8Lmdkeb/ZuEXxT51ms7C8Su7xE556a9Tz+aT+U072JxPawGls5NEjoOr/uFzaIGc8Ek8CofA7p3MpqWgORk77m82To5M/PcAGi2M0exms= Received: from HE1PR07MB4441.eurprd07.prod.outlook.com (2603:10a6:7:9f::27) by HE1PR0701MB2682.eurprd07.prod.outlook.com (2603:10a6:3:90::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.11; Tue, 27 Jul 2021 21:21:06 +0000 Received: from HE1PR07MB4441.eurprd07.prod.outlook.com ([fe80::8cb8:b3b2:b265:d65f]) by HE1PR07MB4441.eurprd07.prod.outlook.com ([fe80::8cb8:b3b2:b265:d65f%5]) with mapi id 15.20.4373.018; Tue, 27 Jul 2021 21:21:06 +0000 From: Christer Holmberg To: Paul Kyzivat CC: SIPCORE Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-rfc4028bis-05.txt Thread-Index: AQHXgyOEsaGN75qDyk+dzh+oTqAB5qtXRcOAgAAOU9A= Date: Tue, 27 Jul 2021 21:21:06 +0000 Message-ID: References: <162741664405.4357.2194886272596595988@ietfa.amsl.com> <88f4b4ed-11b5-3185-1c67-3fb6f3425aae@comcast.net> In-Reply-To: <88f4b4ed-11b5-3185-1c67-3fb6f3425aae@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: comcast.net; dkim=none (message not signed) header.d=none;comcast.net; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ba888797-915a-4219-3617-08d95144720e x-ms-traffictypediagnostic: HE1PR0701MB2682: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 6m8sEMQL2S3NgeSdyQIT9MQ9Bashiytlp3NBauw+qBhE0FqvHrwSitUYTEC5lZRRWIUcB/t4gGt5Wbydcj/6Yh4JD7IrB5glwvv6H6c5rFzbFZwZSz3H9OYJLivj2u8T0iIXrkXgpdkHKfYBN5JnOYTkmk9p08imdHDhfcg8mDfcDHxDlCYD3pWNqeDp2UVbv+L13oEnKAKEGUeNAc2iFoI86BjIR6eyZ0P9XfXeFP4+nQ6oUd2zXYs9WYhvZZaNntctOEIc7xaCyZp4r2kc9ars9VoHqpF0aqVtLprx3+ZSNQ8gQs9UOrswR3Zabuj6duhcawwqtKLkVK5c87yROJr7C44YjkXvNDdAMSaTMsExy1HjgjoqOKlcd1OPJ75KK/Hy/ToGbnPkrK0pAEDovSi+NudJU9OERvpPXEvuawtrUNFCIFZWKr06SB3gyOY6wbfi2OWZ55ju/Ow+7R/MWPjd+ESoO2fLJtm0qaM2iHP/SbC4cRiFji5h38/enHM8jEaJkUOi1fYR3lc9BTL69VT4g6RtfTsJXFpwI42wnADHAChTOXqkG+d6emCuIQEcXlgy2hqPCOLSH+OGM8feoY+LR7QIrMhrDTCngu7FclIoJ+2ys3fvlNGI4g2nrQ/3rdewhstfJ915fnt5icZpqmdYAnw/OGA7kxvi1kz42cwNz0MVoBkIyULcdUEt6V9QkMrWtll5YXs2QPujJUNm9z+53E9Iji56Kiktfv4puFqwN1jcu/mfqzdoB4JSyUDLffbcDw6HkbBQDHI44v9ltrphm8c/XIeB9brUVsSFTj8hNSh9WvMbIlUQeJNEnqAisikl+nD4fCbafRF7fGheAA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4441.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(9686003)(33656002)(8676002)(52536014)(7696005)(55016002)(83380400001)(8936002)(316002)(4326008)(66574015)(966005)(86362001)(71200400001)(508600001)(66946007)(186003)(26005)(53546011)(6506007)(64756008)(66476007)(66556008)(76116006)(2906002)(44832011)(122000001)(5660300002)(6916009)(38070700005)(66446008)(38100700002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?azZBbUJFRTl4dlNzVjRHV0VKTGFHZnRkbktXc013MURySnA1dEFoNEtxVUNR?= =?utf-8?B?VnlQSjl6VWxGQklOS09hS1RTYndwdlFqbk01Tng2MTZ1dWZvVG02NldNQkJj?= =?utf-8?B?R0pMNElJSFF0dEdSU2pvSnExRHpDU3hHMGZxMk0wMmtYb0I3Z01VVG10Wmpy?= =?utf-8?B?YUFYbzg0bDNuRDZFdGFjR3FSQ2h3RkU3cDhLR2FLS3ZRTkowc283aE9kKy9E?= =?utf-8?B?cUtmTHo3bEhJV2VpRlU1c3lGTlRrNjV6MzQvVVFuSDQvY2p4RisyZmc2Y0hK?= =?utf-8?B?VWZvYlM4ZFBxU3FKRlpjcGhzZVpSbFVYVExjM09qM05PWno4bllsNm4yb3I5?= =?utf-8?B?bXlFYVlOYmpPVU0yZGlwSnF4UkZPWmxoZ0ZsVzhhRUgxNzc4ZElPdVlYYkx1?= =?utf-8?B?SUl4QjltVEc4aGdNb3dKaVl6aDQzOUFyS1d5Zzd6SFU2ajB5MlY0dUE1eCtk?= =?utf-8?B?WE4veitEa21kamoxVC9FRGlYb0hPSlBPWnU0enpSOGJDVmwyYm5mMEx3ZzV3?= =?utf-8?B?WnNiNGRGWkpUTzZVVkJIVTJsVzJyd0dKRHJEZE1mbnZuTENaUUp2QjVMWXhL?= =?utf-8?B?c1p3MTJ4MmdUYU90MTNSWTNWd1FOMldNUkVWSTgxdWtjVlhaVWRzSyttVHBz?= =?utf-8?B?M0NmaFZKMmJiUEk2OEQyVm9Iem1YRDlXRGNkL1orRjAwdEtLd3BraG56QWty?= =?utf-8?B?MDY4aWRpdm1VYzRUQldheTF1QTlEWHA0WGtMK3ZtS2xLeEpTOGhmN3N6bGEy?= =?utf-8?B?R0IrdE82UEtzbGlUWWluSzFJSS9xcFNINVpDeHVNWGk4Zm1Hb1I4TlhsTFJQ?= =?utf-8?B?SkNNRXFvZTlvOW0wRlZQNXkya1NLL3dOcy9Wa3NtUmUxMUVaditRMXZ4NU5M?= =?utf-8?B?NGJjN0trWGxmQnpWYXIxNTdXQnViWmUrQmtxMk84Z1FMNGF1SXgzSXdRT3Z5?= =?utf-8?B?cGsrUUFDdzR2UXdxckkySkVYMERWdFVkcUgwU1dPMkhFc0xCNENnczcwS3FJ?= =?utf-8?B?aVNKa0Vxd29NK1RLckdYWGFhaTJJQXRJVmgxa0RBUk5QYnNKbm9Tdm01eWUy?= =?utf-8?B?VzcyWWdmYkNISy9LcU5pdTdQY2FPRUlZU00vOE5QMXZ5Wmo3N3pwUjBCQVhK?= =?utf-8?B?UGQva0xzT0tMZlVlQ1VWSXMzMXg4S2JQZFQ5aVp3MWt3MmVKc01MdXJkOUYz?= =?utf-8?B?NG4yOE0zYUxJTVlQZDZnNkNqdWp4emZnWms2cVZkVDlzK3hMUnorVS9VckYw?= =?utf-8?B?U2ZXdVVBdUdGdWRRcm1qS1B1UXc3Z2ZTZ2hvM3JQMW5tSXByU2thTnN4MnJS?= =?utf-8?B?MG55Qm9vZlpXdmQycG1OaXlWb1Rpa1M5MWQ5RTRMalNqbVB0NHVEOE5TTmNn?= =?utf-8?B?ZXJhUWhyTWZXUzBOZ1piS0dFMWh1R0s1elp2SmJGVWlvaElmVHdSL1pZSjU4?= =?utf-8?B?MmRjZlJPV0VGcE5KdW5jTWNYYlJhR0NTa0YvclEza2VCaDI3aFZMSWVLc2NZ?= =?utf-8?B?eEcveGRuUTJMQ0FaSmZmOUtGOHZiUndkNzlaV3BLNUxXdkd6V3NFcWdxUWZs?= =?utf-8?B?cURTc1VJdWtqcmRUV3NOV2FQSWJHRG5ueTJFcm8xbjVRdllyQnNCSy9mSjhM?= =?utf-8?B?Znk1YXcvSW9NMzhhZkUyVEtaQWR4VDF4S2tjTVdiYTFmcjNKN3BHSXlMUnh3?= =?utf-8?B?eUdGemJBSFdQcmhkY1gxVk5wQmM2aDZBellWTVVGN1cwdVQ1MmRiZ0YvS25v?= =?utf-8?Q?h7JaIDpBc6zdlWiGKEiq4drNElqaQBhmFMGKy4l?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB4441.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ba888797-915a-4219-3617-08d95144720e X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2021 21:21:06.1166 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: FPSH0KyJAAlJP7C+Shxjet9v/Uv6Vjg6UpuPAAphC8rMc1LM5P5f9GyLPnI69RMK6P/OayDMZo+PVs++3RO+pdq9jkyH1Rn9vl8EApby+FM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2682 Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-rfc4028bis-05.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2021 21:21:18 -0000 SGksDQoNCj5JSVVDIHRoaXMgaXMganVzdCBhIGNvcHkgb2YgNDAyOCByZWZvcm1hdHRlZCB1c2lu ZyBjdXJyZW50IHRvb2xzLg0KPkkgcHJlc3VtZSB0aGlzIGlzIGp1c3QgaW50ZW5kZWQgYXMgYSBz dGFydGluZyBwb2ludCBmb3IgdXBjb21pbmcgcmV2aXNpb25zLiBEbyBJIGhhdmUgaXQgcmlnaHQ/ DQoNCkNvcnJlY3QuIA0KDQpJIGFjdHVhbGx5IHdyb3RlIGFuIGUtbWFpbCBhYm91dCB0aGF0IHdo ZW4gc3VibWl0dGluZyB0aGUgbmV3IHZlcnNpb24sIGJ1dCBpdCBzZWVtcyBpdCBnb3Qgc3R1Y2tl ZCBpbiBteSBEcmFmdHMgZm9sZGVyLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCk9uIDcv MjcvMjEgNDoxMCBQTSwgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIHdyb3RlOg0KPiANCj4gQSBO ZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQt RHJhZnRzIGRpcmVjdG9yaWVzLg0KPiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBT ZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wgQ29yZSBXRyBvZiB0aGUgSUVURi4NCj4gDQo+ICAg ICAgICAgIFRpdGxlICAgICAgICAgICA6IFNlc3Npb24gVGltZXJzIGluIHRoZSBTZXNzaW9uIElu aXRpYXRpb24gUHJvdG9jb2wgKFNJUCkNCj4gICAgICAgICAgQXV0aG9ycyAgICAgICAgIDogQ2hy aXN0ZXIgSG9sbWJlcmcNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgU3RldmUgRG9ub3Zh bg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICBKb25hdGhhbiBSb3NlbmJlcmcNCj4gCUZp bGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtc2lwY29yZS1yZmM0MDI4YmlzLTA1LnR4dA0KPiAJ UGFnZXMgICAgICAgICAgIDogMjYNCj4gCURhdGUgICAgICAgICAgICA6IDIwMjEtMDctMjcNCj4g DQo+IEFic3RyYWN0Og0KPiAgICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGFuIGV4dGVuc2lvbiB0 byB0aGUgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sDQo+ICAgICAoU0lQKS4gIFRoaXMgZXh0 ZW5zaW9uIGFsbG93cyBmb3IgYSBwZXJpb2RpYyByZWZyZXNoIG9mIFNJUCBzZXNzaW9ucw0KPiAg ICAgdGhyb3VnaCBhIHJlLUlOVklURSBvciBVUERBVEUgcmVxdWVzdC4gIFRoZSByZWZyZXNoIGFs bG93cyBib3RoIHVzZXINCj4gICAgIGFnZW50cyBhbmQgcHJveGllcyB0byBkZXRlcm1pbmUgd2hl dGhlciB0aGUgU0lQIHNlc3Npb24gaXMgc3RpbGwNCj4gICAgIGFjdGl2ZS4gIFRoZSBleHRlbnNp b24gZGVmaW5lcyB0d28gbmV3IGhlYWRlciBmaWVsZHM6IFNlc3Npb24tDQo+ICAgICBFeHBpcmVz LCB3aGljaCBjb252ZXlzIHRoZSBsaWZldGltZSBvZiB0aGUgc2Vzc2lvbiwgYW5kIE1pbi1TRSwg d2hpY2gNCj4gICAgIGNvbnZleXMgdGhlIG1pbmltdW0gYWxsb3dlZCB2YWx1ZSBmb3IgdGhlIHNl c3Npb24gdGltZXIuDQo+IA0KPiANCj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2Ug Zm9yIHRoaXMgZHJhZnQgaXM6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtc2lwY29yZS1yZmM0MDI4YmlzLw0KPiANCj4gVGhlcmUgaXMgYWxzbyBhbiBodG1s aXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvaHRtbC9kcmFmdC1pZXRmLXNpcGNvcmUtcmZjNDAyOGJpcy0wNQ0KPiANCj4gQSBkaWZm IGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1zaXBjb3JlLXJmYzQwMjhiaXMtMDUN Cj4gDQo+IA0KPiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91 cyBGVFAgYXQ6DQo+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+IA0KPiAN Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2lw Y29yZSBtYWlsaW5nIGxpc3QNCj4gc2lwY29yZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCj4gDQoNCg==