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

Brett Tate <> Wed, 07 January 2015 17:15 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B547B1A0055 for <>; Wed, 7 Jan 2015 09:15:46 -0800 (PST)
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 oxqln_SIik1L for <>; Wed, 7 Jan 2015 09:15:44 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3A9781A005F for <>; Wed, 7 Jan 2015 09:15:44 -0800 (PST)
Received: by with SMTP id i50so1132047qgf.25 for <>; Wed, 07 Jan 2015 09:15:43 -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=EKWTGjj9GAZQ+feZpdGNgeLS82aWkIrQqqvsq2k6fJk=; b=F+InzeY8IyRG2wgkk/Sh5wYisxGsxfDEcE7btCcwPKstaRDH/OTA5r9O0lpm23hMfu pI9lEJHY0ESMMV4YJnT8D7XsC9IQ4QSUVjIlg6jlSejvInpNw8ROG5M/XQomuKa7Mo4M 6oAW/pU20xp4xz6IFPpDhSma0Z2j12NFIqAB2Q1MSD3eIiVOaMHuZuTWYHff5muH1S9/ py/7610thYiao9W6Y3xIlMnfBzJcv291g7s5JCIamGpDuH3I2WvTig73G/BZIvJjsKca /muYACfHX3UxEkUCo834RfGPK3Bgvw8Z6fuijqy2UP56DvPxUw8FABxY7Lmth4T0Pc4h FG9Q==
X-Gm-Message-State: ALoCoQmPJNfCfplxDCgL7jyJ98dF2NiXgBOlbR+UlM00oX35rizRr8nV31eRi8fjE2o1WKxp92SA
X-Received: by with SMTP id d49mr6140026qgf.18.1420650943235; Wed, 07 Jan 2015 09:15:43 -0800 (PST)
From: Brett Tate <>
References: <> <emc65956fd-4c3f-492a-82dd-4586cc3bdf69@sydney>
In-Reply-To: <emc65956fd-4c3f-492a-82dd-4586cc3bdf69@sydney>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQLIFQyXe0b+k5PD9r6Oz5Jjs6p88prE49Xg
Date: Wed, 07 Jan 2015 12:15:42 -0500
Message-ID: <>
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: Wed, 07 Jan 2015 17:15:46 -0000


Thanks for the response; reply is inline.

> >> >Suggested text: "A CANCEL request sent by an intermediary
> >> >MUST construct a Session-ID header value exactly like the
> >> >INVITE's Session-ID."
> >>
> >>  OK, your text down below made this clearer for me.
> >>  I agree we should do as you say.
> >
> >Potentially should make a slight modification to the
> >suggested text so that it only applies to CANCEL outside
> >of dialog.
> Why say that?  Why not have any CANCEL follow this rule?

I don't have a strong opinion either way.  Allowing different behavior
within dialog, allows the CANCEL to be more accurate (for example, the local
or remote values may have changed between re-INVITE and CANCEL).  Either
way, the draft would potentially need to clarify if a CANCEL's Session-ID is
allowed to update (or has no impact upon) the dialogs session-id value (for
building CANCEL's 2xx, re-INVITE's 487, et cetera).


> OK, I get your point.   How about this added to the end
> of the next-to-the-last paragraph in Section 6:
> "The one exception is when the UA sends a CANCEL message,
> in which case the Session-ID header value will be identical
> to the original INVITE."

It sounds okay to me although "will be" potentially needs a normative
modification if not indicated elsewhere; however it may need updating based
upon outcome of the above discussion.


> >I still don't know your working definition of essential.
> >The Record-Route and Route stuff should be present to comply
> >with RFC 3261 (without requiring local policy to override
> >RFC 3261 default behavior) since B2BUA is not altering Contact
> >values. However, Record-Route and Route are not essential
> >for understanding Session-ID stuff within the example.
> >
> >If the ACK reflects the 2xx's Contact URI, I don't have a
> >strong opinion if the example shows the Record-Route and
> >Route stuff since easy to assume that loose routing is
> >occurring and Record-Route/Route deemed non-essential.
> OK, you want this added to F2 and F3?
> Record-Route: <;lr>

Since version 11's F5 ACK reflects the 2xx's Contact URI, I don't have a
strong opinion what occurs concerning the Record-Route and Route stuff.

If Record-Route and Route are deemed essential, yes the Record-Route should
be added to F2 and F3.  The Route would also need to be added to F5.

If Record-Route and Route are deemed non-essential, the Record-Route added
to version 11 F4 can be removed.

> >>  >> >Section 9.4


> >>We could just remove the text "(to change the UUID to M')"
> >>or change it to something else. I'm not sure what we
> >>should change it to that will not be a mile long. Suggestions?
> >
> >Based upon my following paragraph, you can likely leave as-is.
> Which following paragraph?  This one here right below?


> >Based upon section 9.3, the draft does not require an
> >intermediary to send a request solely to update Session-ID.
> >Does the draft require an endpoint such as the Single Focus
> >Conference Server to send a request solely to update the
> >Session-ID (if became inaccurate such as when turn 2 separate
> >calls into a conference)? Either way, it would help if
> >there were normative statements within sections 6 and 7
> >indicating that they MAY, SHOULD, or MUST send a request
> >to update the Session-ID if local UUID becomes inaccurate.
> I don't think there will be a case where the endpoint
> does not know the Session-ID.  The text in 9.4 is just
> confusing.  This re-INVITE updates the UUID to M' only as a
> side effect.  The real reason for sending the re-INVITE is
> to put the endpoint into the real target conference.  (Note
> that the initial call would drop the user into the IVR system.)
> What I'd like to suggest is to remove the words "(to change
> the UUID to M')", because that is not the main reason for
> that exchange.

The proposed change is okay with me.


> Agreed.   Section 6 now has this as the next-to-the-last
> paragraph.  Sound OK?

See reply concerning "next-to-the-last paragraph in Section 6".