Re: [Insipid] Requirement for Intermediaries to Update Session ID for other parties

"Paul Giralt (pgiralt)" <> Tue, 07 June 2016 19:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3D1B612D504 for <>; Tue, 7 Jun 2016 12:20:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.947
X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uJb5f2qpdIwy for <>; Tue, 7 Jun 2016 12:20:11 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A5AD812D0C5 for <>; Tue, 7 Jun 2016 12:20:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3637; q=dns/txt; s=iport; t=1465327211; x=1466536811; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=f3XGkGkl3o49IpkbppVPmk7ML3ciVRrZ9dnHelP2PGY=; b=kgH0FMMdue94VY8d34SK9QwgsVCmLYK4SOHpSKM2G4c8GDNUErLyBU96 9UZkmW63xuSn4nA30R81ILAAJLfBrdAievv+A7AOpq+Hz9Udg/86wFZbs GaCOrQMepbMa9zteh235H3PW7hgkqfwYYUoJIUTgBTdLueU32eUZIMhMd E=;
X-Files: signature.asc : 842
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AlBQC1HVdX/5xdJa1cgz6BWbpmgXmGE?= =?us-ascii?q?wKBQjoSAQEBAQEBAWUnhEYBAQMBI1YFCwIBCEICAjIlAQEEDhOIGQirYZEbAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBDg6GJ4F3CIJOh0Ergi4FmEsBgy2BaYkQgWqNN?= =?us-ascii?q?oY9iSEBJQQrggIFHBaBNYl+fwEBAQ?=
X-IronPort-AV: E=Sophos;i="5.26,434,1459814400"; d="asc'?scan'208";a="112588362"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jun 2016 19:20:10 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id u57JKADf015632 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 7 Jun 2016 19:20:10 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 7 Jun 2016 15:20:09 -0400
Received: from ([]) by ([]) with mapi id 15.00.1104.009; Tue, 7 Jun 2016 15:20:09 -0400
From: "Paul Giralt (pgiralt)" <>
To: Brett Tate <>
Thread-Topic: [Insipid] Requirement for Intermediaries to Update Session ID for other parties
Thread-Index: AdHA2312D/wUckGRTgeNOtz38IHE2AAN6GUA
Date: Tue, 7 Jun 2016 19:20:09 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/signed; boundary="Apple-Mail=_FE932CE8-E3D0-4152-9BE1-4ECA61161778"; protocol="application/pgp-signature"; micalg=pgp-sha512
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>
Subject: Re: [Insipid] Requirement for Intermediaries to Update Session ID for other parties
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: SIP Session-ID discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 07 Jun 2016 19:20:13 -0000


Thanks for the reply. I have some comments / questions inline. I’m not trying to be argumentative in my comments - I really just want to make sure we have a strong argument for SHOULD so really just want to make sure these reasons are valid.

> 1) A proxy can't really do it.

Would a proxy ever do anything that would require it do to it? A proxy will just be forwarding messages back and forth for the most part.

> 2) I assume proxy B2BUA's that only initiate BYE's would not want to do it
> except when sending BYE.

Why would they “not want to”?

> 3) Because it causes extra traffic and potential for glare, the
> administrator might not want the extra messaging to occur solely to update
> the UUID.

The potential for glare is a potentially good argument, but is “extra messaging” really an issue?

> 4) The request might not reach the device that the intermediary is
> attempting to update.  Thus, it could be completely useless extra traffic.

This doesn’t seem like a good reason not to try to update.

> 5) Methods that the intermediary is willing to use for the update might not
> be within the received Allow header.

This is a good one, although I would think re-INVITE is always available (or whatever is being used for session refresh), so is there really ever a case where there is no way to do it? I noticed you said “willing to use” which I’m sure you did intentionally. That doesn’t mean there is no way, but if there was a requirement, then they would have to.

> 6) It can cause the intermediary to be part of an infinite change loop
> unless use re-INVITE without offer.

Simplest way to update would be whatever message is being used for session refresh. That should not cause problems.

> 7) The intermediary might not have auth credentials to allow the change to
> be successful.

How would this happen?

> 8) Because of race conditions and other things, the intermediary initiated
> messaging intended to correct the UUID could cause other locations to switch
> to an incorrect value.

Why would this happen?