Re: [Insipid] draft-ietf-insipid-session-id-10: comments

"Paul E. Jones" <> Mon, 09 February 2015 23:00 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 73D0E1A8A62 for <>; Mon, 9 Feb 2015 15:00:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.012
X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id K0DBYCMFN_oO for <>; Mon, 9 Feb 2015 15:00:33 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D9AF31A8A52 for <>; Mon, 9 Feb 2015 15:00:32 -0800 (PST)
Received: from [] ([]) (authenticated bits=0) by (8.14.9/8.14.9) with ESMTP id t19N0TCb025622 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Feb 2015 18:00:30 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=dublin; t=1423522831; bh=AIkHFZ2ql5ek/pi8LhsC0fCzLaUa2r8bvJ6+/ux7FZQ=; h=From:To:Subject:Date:In-Reply-To:Reply-To; b=DsGzmD0l2I1J4XW9qmbIF8r3OnE/T6seQeGkQEyOcJbJgvYqhqXyEMBKp/wL4ZF/J 03kCHY04Hu229O0BY6lLhWA3OTpZPRdMZGtN8EdUNdzHZP7EeeLUwkme/keu7OC8Cx to+vPuzQpIri1Q/yssPCuZSDH43+BTQYETWmPqoU=
From: "Paul E. Jones" <>
To: Paul Kyzivat <>,
Date: Mon, 09 Feb 2015 23:00:30 +0000
Message-Id: <emf2131218-0ce9-4525-a4f4-527b9d4231ab@helsinki>
In-Reply-To: <>
User-Agent: eM_Client/6.0.21372.0
Mime-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Insipid] draft-ietf-insipid-session-id-10: comments
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: "Paul E. Jones" <>
List-Id: SIP Session-ID discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 09 Feb 2015 23:00:34 -0000


>>That would be true of intermediaries like PBXes that are switching 
>>from one leg to another. It's only in situations where the 
>>is going to do something that causes endpoints to have the wrong value
>>that they need to ensure they convey the right value. If the SBC is 
>>in the business of switching call legs from one device to another like 
>>PBX does, it would not have to maintain this state at all.
>I think *most* B2BUAs will sometimes need to originate messages. E.g.,
>- send a BYE to terminate a session by policy
>- send a session timer refresh.
>Any B2BUA that will ever originate a message needs to maintain this 

Fair point, though this is not really altering a value -- which is what 
most of Section 7 deals with.  In this case, it would be just using 
known values to initiate messages.

But, I don't think we speak about that.  Want to suggest a blurb to say?

Maybe some "Finally, " text at the end (after that "Having said the 
foregoing," paragraph I proposed to Brett) like this:

Finally, intermediaries compliant with this specification that initiate 
messages not in response to having received a message from a remote 
endpoint, such as sending a BYE to terminate a dialog, MUST ensure that 
the proper Session-ID value is conveyed in that message.  If the UUID of 
the remote endpoint is known, that value MUST be used as the 
"local-uuid" value of the transmitted message.  If the UUID of the 
remote endpoint is unknown, then the intermediary MUST use either the 
null UUID (preferred) or fabricate a UUID to populate the "local-uuid" 
field.  Likewise, if the UUID of the receiving endpoint is known, that 
value must be included in the "remote-uuid" field.  If the UUID of the 
receiving endpoint is unknown, the "remote-uuid" field must be set to 
null UUID.