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

Brett Tate <> Wed, 28 January 2015 17:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2FC821A87E8 for <>; Wed, 28 Jan 2015 09:16:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.579
X-Spam-Status: No, score=-0.579 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Hge2y7VO3LdF for <>; Wed, 28 Jan 2015 09:16:24 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D99841A87D0 for <>; Wed, 28 Jan 2015 09:16:23 -0800 (PST)
Received: by with SMTP id x12so17002009qac.11 for <>; Wed, 28 Jan 2015 09:16:23 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=WiWtnqNaE/af8dgGSm094RuAED+vwWyrX7Rxuq9+5is=; b=WxK9UYH6lJ/CQ5297mCpJHhEPYSTWtqNPjRLCcDpnx3fkeddv9ATUKvR1DOQlspctA IJxRP7XkwK2pZbxvaZBJGPAauvsXjtuzP42b3ThbxxDW2osZYyFNw3/EE4Aue+toisjg 83b8GsAJpnoXhc27Eo6D89rjMQjId9gexIu8bxhwLjWKkqqjDjupRLvmNCVhGgc57ABV vrf26o9wGPzvt4Ld6VNUmMgqsW/m4fJf9Z7dYZnuhoGmVLSLpNqO1PiwZ+XEoqLI1YiC kH0MZApp5MG/7Lf9TbKBFnGjSUL4YU64pXXoR7qzB5Rv/BOlLw8gwUwiAbd+ZiPSeWJw ePUg==
X-Gm-Message-State: ALoCoQmo/C5LvTyBQ0pnuT3J0U4gUCbI6oEOEnKF867MFpXPiD3lZFLyTkC55KaivIdU9pysC+F6
X-Received: by with SMTP id k8mr17804qay.82.1422465383151; Wed, 28 Jan 2015 09:16:23 -0800 (PST)
From: Brett Tate <>
References: <> <em33532e55-2ddf-4522-bd6b-26e617877498@sydney>
In-Reply-To: <em33532e55-2ddf-4522-bd6b-26e617877498@sydney>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFxD+tqsfpSP3N2pRhOs7kZZ3JDAJ2T3DDQ
Date: Wed, 28 Jan 2015 12:16:22 -0500
Message-ID: <>
Content-Type: text/plain; charset="UTF-8"
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, 28 Jan 2015 17:16:26 -0000


Thanks for the response; reply is inline.

> If it is answering on behalf of a remote endpoint and knows
> what the "Session-ID" header value is, it should include
> that value.
> If it does not know (e.g., the remote endpoint has never
> sent one), I think it should follow the same logic we
> describe for provisional responses.  What if we make this
> change:
> "When an intermediary transmits a provisional
> response >>or a response to a CANCEL request<<, ..."

I don't think that it is adequate.

> Are there other such cases?

A B2BUA can generate requests and responses on behalf of both sides.  In my
opinion, section 7 covers some individual situations; however, it appears to
be missing the general case of tracking remote/local UUIDs and then using
the UUIDs when generating (instead of relaying) subsequent requests and
responses associated with the "session".

> >That is the issue. The UPDATE changed the UUID so it
> >no longer matches the value sent within prior INVITE
> >and subsequent CANCEL. Thus I'm trying to determining
> >which remote UUID that the B2BUA should or must include
> >within the CANCEL's 2xx, INVITE's 487 response, and
> >non-2xx's ACK when the To tags reflect that same dialog
> >that was updated.
> Perhaps I need a picture.  Can you tell me again why the
> UPDATE would change the UUIDs?

>From an intermediary perspective, it is irrelevant why something on each
side decided to change the supplied UUID.  My understanding is that the
draft requires (or will require) the intermediary to track the change so
that it MAY/SHOULD/MUST be used when the intermediary generates (instead of
relays) subsequent requests and responses associated with the "session".

Concerning "why the UPDATE would change the UUIDs" ... as mentioned within, a B2BUA
interaction occurred which replaced a user or user's device on one
side while call setup was occurring on the other side.

The picture is the trapezoid model with B2BUAs instead of proxies (i.e.
caller, B2BUA1, B2BUA2, called) with potential forking and replacements
(i.e. "session" changes for a particular dialog).  The B2BUAs generate 487
instead of relaying them.

> >>  Is this just a repeat of the previous?
> >
> >Almost; the distinction is that the CANCEL is sent
> >within dialog (i.e. cancelling a re-INVITE).
> There should be no difference in the UUID values uses
> with either in-dialog or OOD, as it's sent in relation
> to the "session".

The "session" changed.  Consider hypothetical that B2BUA received INVITE
outside of dialog with {A, N}.  Forking during call setup resulted in {A, B}
and {A, C}.  Because of services while still inviting (and messages sent
over early dialog), the Session-IDs became {X, B} and {Y, C}.  If the CANCEL
with {A, N} was received out of dialog, what should be the Session-ID of
CANCEL's 200 and INVITE's 487 if sent with To tag reflecting dialog of {X,
B}?  If B2BUA then sent CANCEL and the subsequently received 487 (for
INVITE) indicated {C, whatever} with To tag of {Y, C} dialog, what should be
the Session-ID of the 487's ACK?  I assume "whatever" is irrelevant; however
I'm not sure if (and why) ACK's local UUID should be A or Y.

> In the event that a UUID value changed (which should
> only be because an actual endpoint somewhere downstream
> changed to another endpoint), that new UUID value should
> be used going forward.  So if some intermediary device
> sees this:
> {A.B} -->
>   <-- {B,A}
> And then some new message comes through with a new value
> for A (and quite possibly B) as follows:
> {C,F} -->
> If it is going to be responding to messages and use the
> Session ID values, it should immediately take note of
> {C,F} coming from the left side.

I get that; however then CANCEL received outside of dialog indicated {A, B}.
If the B2BUA subsequently generates ACK to the called party over what is/was
{C, F}, should the Session-ID be {A, F} or {C, F} (assuming received 487
indicated "F")?