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

Brett Tate <> Mon, 27 October 2014 16:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E6EFD1A0ABD for <>; Mon, 27 Oct 2014 09:27:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 VJcIgDEexqEM for <>; Mon, 27 Oct 2014 09:27:17 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E92871A07BC for <>; Mon, 27 Oct 2014 09:27:15 -0700 (PDT)
Received: by with SMTP id z107so2377644qgd.12 for <>; Mon, 27 Oct 2014 09:27:15 -0700 (PDT)
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=oEO5iyXHHWfQp0c9EAL27f3sg0j7O+yDIJWxYTxg8nY=; b=OzadeLZg6ZMEs0Y4VOV95hGilFEpvDo/JgiDAaYxp3vHW0FxwfB0nCy3mryOx1EB2k I4LLaO30NpRcGfowlpQ2Wvnqrq2+90zT8ezd1zOLqiKVTrM+uYzKiIwsU9t8ZvtNNF6V xGQF2XM52SVOm4m/fMHB9AY5jaRd/2J1IHGzrhTcNLOSc+zNpbZa+59QtBSFgM/OCkbg SaSErbR3AsGNlWpW0e/DpZPsVT4hhRRW6EJIbAXlU18gMM8tA6Cj8SeUvu8q/6dYsS/6 Nyeb9PnwuYC8bXhR9kXbQBuaQyh/zz8ZT1qdmBpZ0z5sKjMIiGPnSkMGTj+PQqCZ/9xd hUmw==
X-Gm-Message-State: ALoCoQn06cxgniRjHbitGzQ1n/p0oQAPiP6rf0lz8Nkc/Vf2qVuxyC1MZnJ22Te6vyPO0NE+UaVv
X-Received: by with SMTP id w90mr32455618qgw.18.1414427235112; Mon, 27 Oct 2014 09:27:15 -0700 (PDT)
From: Brett Tate <>
References: <> <em20d0761c-6a62-43c5-90ec-2407be5915e4@sydney>
In-Reply-To: <em20d0761c-6a62-43c5-90ec-2407be5915e4@sydney>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGbdhhKQ3DvBXA6l1QrPhU34HqbiZyszd5A
Date: Mon, 27 Oct 2014 12:27:14 -0400
Message-ID: <>
To: "Paul E. Jones" <>,,
Content-Type: text/plain; charset="UTF-8"
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: Mon, 27 Oct 2014 16:27:20 -0000


Thanks for the response; reply is inline.

> >Section 7 paragraph 6: Concerning early dialogs, the CANCEL correlates
> >to the INVITE instead of a specific early dialog. Thus the paragraph
> >should likely be reworded to always reflect the INVITE when CANCEL not
> >traversing a dialog. For instance if received multiple 18x creating
> >multiple early dialogs and received Session-IDs {B1, A} and {B2, A},
> >the current paragraph appears to recommend that the CANCEL include one
> >of these within the CANCEL.
> I'm not entirely clear on what you're suggesting.  All the current
> paragraph
> says is that if an intermediary sends a CANCEL and it doesn't have the
> value
> B1, for example, it is to use {A, "null"} as the Session-ID.

I'm indicating that a CANCEL should not reflect early dialog information; it
should reflect the INVITE.  Otherwise you'd be having to select a single
Session-ID from 1 of potentially many early dialogs to place within the
CANCEL (which isn't associated with a specific early dialog).  My comment is
similar to my Section 9.8.1 figure 10 comment.

Current text:

" A CANCEL request sent by an intermediary that has not received a UUID
   from the destination UA MUST construct a Session-ID header value
   exactly like the INVITE to that UA, with the known "local-uuid" value
   for the initiating UA and the null UUID as the "remote-uuid" value
   for the destination UA."

Suggested text: "A CANCEL request sent by an intermediary MUST construct a
Session-ID header value exactly like the INVITE's Session-ID."

Similar text should likely be added to section 6; for instance, maybe after
the next-to-last paragraph which indicates UAs MUST take care concerning
forking interaction.

> >Section 7 paragraph 7: Should potentially recommend what should occur
> >when B2BUA sends re-INVITE without SDP to obtain SDP to setup another
> >session.
> >More specifically, should the re-INVITE contain a new 3PCC generated
> >UUID?
> >The other options would be to resurrect the discarded UUID or use the
> >currently connected session's UUID.
> What changes in the text are you proposing?  The temporary value would
> persist until such time as a the 3PCC device learns what the actual UUID
> values are for Alice or Bob.  If a re-INVITE is sent, the 3PCC device
> would send
> either the same fabricated UUID to Bob if it does not know Alice's UUID.
> Or,
> it will send Alice's UUID if it knows it.

The 3PCC device can send a re-INVITE without SDP to Alice to connect Alice
to device X instead of Bob.  X's UUID would be within the Session-ID of
re-INVITE's ACK; however I'm currently not sure what UUID the draft is
recommending the 3PCC to place within re-INVITE.  Allowing the 3PCC device
to do whatever (or interpret however) it wants is okay with me; however I
thought the draft might want to clarify what should occur.

For instance, see RFC 3725 section 10.2 figure 13.  After the Controller
sends re-INVITE to place the Called Party (Bob) on hold, the Controller
sends re-INVITE (message 4) to connect Pre-Paid User (Alice)  to Media
Server (X).  I'm attempting to understand which UUIDs should go within
message 4's Session-ID.

> >Section 9.1: Concerning the SIP messages, the B2BUA appears to be a
> >proxy.
> >Thus from a RFC 7092 perspective, I guess that it is a Proxy-B2BUA that
> >hasn't originated any requests.
> B2BUAs don't have to originate requests.  This example (and all others
> that
> use B2BUA) shows a classic B2BUA.  I don't think it will help to make this
> clearer introducing a new type of device like "Proxy-B2BUA".

I was just commenting that the example looked like a proxy instead of a
B2BUA.  However if intentional, that is okay with me.

> >Section 9.1: The F4 Contact or F5 Request-URI potentially need a
> >different ip-address (although maybe reflecting missing Record-Route
> >without "lr").
> >F4 Contact reflects F3 Contact and doesn't match F5 Request-URI.
> I think you're saying that F4 needs to contain a Record-Route header.
> Correct?

Yes; unless Record-Route and Route were considered non-essential headers
(and the Request-URI was reflecting B2BUA's Record-Route entry which had no

Concerning draft-ietf-insipid-session-id-11... if Record-Route and Route are
considered essential, Record-Route should likely be added to F2 and F3; and
Route should likely be added to F5.

> >Section 9.1: Concerning F6, the B2BUA's Via header appears to be
> >missing.
> >And existing Via should contain a received parameter.
> Fixed (I think; please check the next draft I'll post for this all
> other corrections).

The fix looks okay to me.

> >Section 9.4 bullet 4: Potentially should clarify why this example is
> >quickly updating the Session-ID but section 9.3 example does not.
> I'm not sure what you are referring to here.  Nowhere do we purposely go
> out of the way to update a Session-ID.  Those values are only updated
> when there is otherwise a reason to send a message.

Figure 4 indicates "(to change the UUID to M')" within several locations
when sending re-INVITE.  Similarly section 8 has MUST statements which
appear to require the MCU to update the Session-ID.  Thus if the MCU didn't
otherwise have a need to send the re-INVITE, section 8 appears to require
sending re-INVITE to fix the Session-ID.

> >Section 9.8.1 figure 10: What should be the CANCEL session-id if Bob-1
> >had
> >sent two 18x creating two early dialogs with Session-IDs {B1x, A} and
> >{B1y, A}?
> I don't fully understand your question.  However, if there is a single
> call initiated from Alice to Bob-1, then there would only be {B1} at
> Bob-1, not {B1x} and a {B1y}.  If you're asking about the case where
> Alice made two separate calls to Bob-1, then Alice would be using two
> separate {A1} and {A2} values.

See my section 7 paragraph 6 comment.  If it helps, consider situation of
Alice having an outbound B2BUA which sends CANCEL while Bob's B2BUA is using
a simultaneous ringing service (instead of Call Forward No Answer service).
Should Alice's B2BUA include Session-ID {A, B1} or {A, B2} within the CANCEL
sent to Bob's B2BUA?

If I understand correctly, Figure 10 and section 7 paragraph 6 currently
imply that Alice's outbound B2BUA would send CANCEL with Session-ID {A, B1}
or Session-ID {A, B2} instead of Session-ID {A, N}.  I'm suggesting that
Figure 10 and section 7 paragraph 6 potentially be updated to indicate that
Session-ID {A, N} would be sent.

> >Section 10 last bullet: Should potentially reword the bullet. I'm not
> >sure if second sentence is indicating to ignore unknown parameters,
> >remove
> >unknown parameters, or something else (like reiterating that the above
> >bullets do not apply to them).
> I tried to fix that.  Please let me know if this is clearer.

Sounds okay to me.