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

Paul Kyzivat <> Wed, 11 February 2015 22:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5138B1A8941 for <>; Wed, 11 Feb 2015 14:23:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ah4k-2Bb29lk for <>; Wed, 11 Feb 2015 14:23:31 -0800 (PST)
Received: from ( [IPv6:2001:558:fe16:19:96:114:154:164]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 302371A86F0 for <>; Wed, 11 Feb 2015 14:23:28 -0800 (PST)
Received: from ([]) by with comcast id rANp1p00558ss0Y01APTWD; Wed, 11 Feb 2015 22:23:27 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id rAPS1p00f3Ge9ey01APT1Q; Wed, 11 Feb 2015 22:23:27 +0000
Message-ID: <>
Date: Wed, 11 Feb 2015 17:23:25 -0500
From: Paul Kyzivat <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: "Paul E. Jones" <>,
References: <emf2131218-0ce9-4525-a4f4-527b9d4231ab@helsinki>
In-Reply-To: <emf2131218-0ce9-4525-a4f4-527b9d4231ab@helsinki>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20140121; t=1423693407; bh=8dHLcBCv4rJJ4z63+wLCus6GtQCcSRZUIgrXy4r5QQk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=XYVqhY2g1i02a6lx985uZYzqWSK50hZJ35Ps7LVzsYrF5xxLeM49DOoK7XqJrCuUJ 0cVkfFeIDPSgUUNrNQUysJB1oCf8rsIFts/VsSBhscn2ma7WQwcQSYii0GdfuIiyLB /f5RJtGEwFOkTLyEyuY7rSL/nz34rpOMPVBp38r1dQkgeWzlamVKvIOctsG6ntAv6y 2ESLotf+OKnKPpt5jEEJpOXRdFSZXeAVesnzo9TevHgtBVWl27hR7/WtmEv2PRsBX2 BGOFmClUz5jMJU4cgGMLxr3oN8MFshwsqsDwgBJ+nePitUSDww7IrMQQY9JyVrmGJO H1QPSsvJ1VOlQ==
Archived-At: <>
Subject: Re: [Insipid] draft-ietf-insipid-session-id-10: comments
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Session-ID discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 11 Feb 2015 22:23:33 -0000

On 2/9/15 6:00 PM, Paul E. Jones wrote:
> Paul,
>>> That would be true of intermediaries like PBXes that are switching calls
>>> from one leg to another. It's only in situations where the intermediary
>>> 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 not
>>> in the business of switching call legs from one device to another like a
>>> 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
>> state.
> 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.

The point is that such devices must keep state remembering the values to 

> 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.
> ====

I think that almost works, depending on what "is known" means.
A box that doesn't maintain state about the last values used could be 
considered to "not know" the values when sending a new message.
Also, from the perspective of the intermediary, both of the endpoints 
are "remote endpoints".

If the intermediary is between Alice and Bob, and it has seen a message 
containing {A,B}, then when originating a message toward Bob it should 
include {A,B}, and when originating a message toward Alice it should use 

But I think *saying* that in a clear way is going to require more text.