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

Brett Tate <brett@broadsoft.com> Wed, 07 January 2015 17:15 UTC

Return-Path: <brett@broadsoft.com>
X-Original-To: insipid@ietfa.amsl.com
Delivered-To: insipid@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B547B1A0055 for <insipid@ietfa.amsl.com>; Wed, 7 Jan 2015 09:15:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxqln_SIik1L for <insipid@ietfa.amsl.com>; Wed, 7 Jan 2015 09:15:44 -0800 (PST)
Received: from mail-qg0-f52.google.com (mail-qg0-f52.google.com [209.85.192.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A9781A005F for <insipid@ietf.org>; Wed, 7 Jan 2015 09:15:44 -0800 (PST)
Received: by mail-qg0-f52.google.com with SMTP id i50so1132047qgf.25 for <insipid@ietf.org>; Wed, 07 Jan 2015 09:15:43 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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 10.140.106.52 with SMTP id d49mr6140026qgf.18.1420650943235; Wed, 07 Jan 2015 09:15:43 -0800 (PST)
From: Brett Tate <brett@broadsoft.com>
References: <79ffc790857a19d32895ff5a677b6620@mail.gmail.com> <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: <2dda73c28d58d8ffee252652610e04dd@mail.gmail.com>
To: draft-ietf-insipid-session-id@tools.ietf.org, insipid@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/insipid/GNVGcrS-1VuQ9SJNuPCa414vuG4
Subject: Re: [Insipid] draft-ietf-insipid-session-id-10: comments
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Session-ID discussion list <insipid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/insipid>, <mailto:insipid-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/insipid/>
List-Post: <mailto:insipid@ietf.org>
List-Help: <mailto:insipid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/insipid>, <mailto:insipid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Jan 2015 17:15:46 -0000

Hi,

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

<snip>

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

<snip>

> >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: <sip:server10.biloxi.example.com;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

<snip>

> >>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?

Yes.

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


<snip>

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