Re: [Insipid] Reviews for INSIPID Session-ID solution draft
Arun Arunachalam <carunach@cisco.com> Mon, 04 August 2014 03:03 UTC
Return-Path: <carunach@cisco.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 DADAA1B2826 for <insipid@ietfa.amsl.com>; Sun, 3 Aug 2014 20:03:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 plVqZDIfumYY for <insipid@ietfa.amsl.com>; Sun, 3 Aug 2014 20:03:02 -0700 (PDT)
Received: from av-tac-jap.cisco.com (skinny-sumo.cisco.com [64.104.15.102]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0BA1B2822 for <insipid@ietf.org>; Sun, 3 Aug 2014 20:03:02 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from fire.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-jap.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id s74330un022478 for <insipid@ietf.org>; Mon, 4 Aug 2014 12:03:00 +0900 (JST)
Received: from rtp-carunach-8715.cisco.com (rtp-carunach-8715.cisco.com [10.116.111.198]) by fire.cisco.com (8.14.5+Sun/8.13.8) with ESMTP id s7432s8O027662; Sun, 3 Aug 2014 20:02:55 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_694F4B37-2F6C-4C14-A38A-994869D099A1"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Arun Arunachalam <carunach@cisco.com>
In-Reply-To: <999A3253-0F6E-4172-BC5B-8B851BC60019@cisco.com>
Date: Sun, 03 Aug 2014 23:02:54 -0400
Message-Id: <0663B39E-2E3F-4B03-AC7C-BC5C83324DD7@cisco.com>
References: <4DB16225-A09D-4B9A-ADAB-9C2B23FE3D57@cisco.com> <49405AE0-0C44-4260-849B-22621387581A@cisco.com> <999A3253-0F6E-4172-BC5B-8B851BC60019@cisco.com>
To: insipid@ietf.org
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/insipid/VDRZZQ0RRJJVtEY7AYgy4bXTOis
X-Mailman-Approved-At: Sun, 03 Aug 2014 21:07:20 -0700
Cc: "Arun Arunachalam (carunach)" <carunach@cisco.com>, "Gonzalo Salgueiro (gsalguei)" <gsalguei@cisco.com>
Subject: Re: [Insipid] Reviews for INSIPID Session-ID solution draft
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: Mon, 04 Aug 2014 03:03:06 -0000
Hi Folks, Reviewed the draft and have a few questions and comments (marked in blue color). Section 4.1 (page 4) Intermediaries that insert a Session-ID header into a SIP message on behalf of a sending User Agent MUST utilize version 5 UUIDs to ensure that UUIDs for the communication session are consistently generated. If an intermediary does not know the tag value for an endpoint, the intermediary MUST NOT attempt to generate a UUID for that endpoint. Typically, an INVITE from an endpoint will have a From tag. Can you give an example where the intermediary doesn't know the tag value? Section 4.3 (page 5) For conferencing scenarios, it is also useful to have a two-part Session Identifier where the conference focus specifies one UUID for each conference participant. The above statement could be interpreted as the conference focus generating one UUID that is different for each conference participant. To avoid confusion, we could say, "conference focus specifies same UUID for all participants in a conference". Section 7 (page 8) If the intermediary is aware of a "remote" value that identifies the receiving UA, it MUST insert that value if also inserting the "local-uuid" value. Please change "remote" to "remote-uuid" Section 7 (page 8) When intermediaries transmits a 100 (Trying) provisional responseand Typo. Please change to "When intermediary transmits a 100 (Trying) provisional response and" Section 7 (page 8 and 9) To keep continuity for the reader, is it possible to move the last paragraph in this section forward such that it reads .... .... Devices that initiate communication sessions following the procedures for third party call control MUST fabricate a UUID value that will be utilized only temporarily. Once the responding endpoint provides a UUID value in a response message, the temporary value MUST be discarded and replaced with the endpoint-provided UUID value. Refer to the third-party call control example for an illustration. If a SIP intermediary initiates a dialog between two UAs in a 3PCC scenario, the SIP request in the initial INVITE will have a non-null "local-uuid" value; call this temporary UUID X. The request will still have a null "remote-uuid" value; call this value N. The SIP server MUST be transaction stateful. The UUID pair in the INVITE will be {X,N}. A non-redirected or rejected response will have a UUID pair {A,X}. This transaction stateful, dialog initiating SIP server MUST replace its own UUID, i.e., X, with a null UUID (i.e., {A,N}) as expected by other UAS (see Section 9.7 for an example). Whenever there is a UA that does not implement this specification communicating through a B2BUA, the B2BUA MAY become dialog stateful and insert a UUID value into the Session-ID header on behalf of the UA according to the rules stated in Section 6. When intermediaries transmits a 100 (Trying) provisional responseand when the UUID of the destination UA is unknown, the intermediary MUST place the one known UUID in the "remote-uuid" field and set the "local-uuid" field to the null UUID value. When an intermediary transmits any other provisional response and when the UUID of the destination UA is unknown, the intermediary MUST place the one known UUID in the "remote-uuid" field and MAY set the "local-uuid" field to a locally created UUID value or the null UUID value. In all cases when the intermediary knows the UUID of the destination UA, the intermediary MUST insert the UUID of the destination UA in the "local-uuid" field and insert the originating UA’s UUID into the "remote-uuid" field when sending a provisional response. ...... ..... Section 9.1 (page 11) UA-Bob receives Session-ID and generates and replaces its "local-uuid" portion of the Session-ID header-value UUID to construct the whole/complete Session-ID header-value, at the same time transferring Alice’s UUID unchanged to the "remote- uuid" portion of the Session-ID header-value in the 200 OK SIP response. Not sure why we need to say "replaces its local-uuid". Can we just says "UA-Bob receives Session-ID, generates a UUID and sets it as "local-uuid" portion of Session-ID header-value to construct the whole/complete…"? Section 9.2 (page 13) o UA-Alice receives the 200 OK with the Session ID {C,A} and both responds to UA-Carol with an ACK (just as in Figure 1 - switches places of the two UUID fields), and generates a NOTIFY to Bob with a Session ID {A,B} indicating the call transfer was successful. Typo. Change "and both responds" to "and responds" Section 9.3 (page 13) o Bob sends a reINVITE to Alice (with the Session-ID "local-uuid" = Bob’s UUID and "remote-uuid" = Alice’s UUID), informing her to transfer her existing call to Carol. How does Bob request Transfer via a Re-invite? RFC-5589 uses REFER for this purpose in all transfer scenarios. Section 9.4 (page 15) What is unique about this call is the second step: the conference server calls back with a reINVITE request with its second UUID, but maintaining the UUID Alice sent in the first INVITE. Please change "the conference server calls back with a..." to "the conference servers sends a ..." Section 9.8.1 (page 21) The SIP server (imagine this is a B2BUA), upon receiving Alice’s INVITE, and generates the optional provisional response 100 Trying. Typo. Please change to " The SIP server (imagine this is a B2BUA), upon receiving Alice’s INVITE, generates the optional provisional response 100 Trying. Section 12.1 (page 24) Hyperlink "http://www.iana.org/assignments/sip-" is broken. Please change to "http://www.iana.org/assignments/sip-parameters" Thanks! Arun On Jul 24, 2014, at 1:02 PM, Gonzalo Salgueiro (gsalguei) <gsalguei@cisco.com> wrote: > Thanks, Arun! > > Gonzalo > > > On Jul 24, 2014, at 1:01 PM, Arun Arunachalam <carunach@cisco.com> wrote: > >> Hi Gonzalo, >> >> Interested in reviewing the draft. >> >> Let me send the comments to insipid@ietf.org. >> >> Thanks! >> Arun >> >> On Jul 24, 2014, at 12:41 PM, "Gonzalo Salgueiro (gsalguei)" <gsalguei@cisco.com> >> wrote: >> >>> Hi - >>> >>> The chairs met and had a WG sync while here in Toronto. Conversations with the draft authors clearly indicate that we are getting very close to WGLC for the Session-ID draft (http://tools.ietf.org/html/draft-ietf-insipid-session-id). The chairs feel it would be helpful if we were to get additional reviews prior to WGLC. The group of people in the To field have been suggested as good candidates to review the draft in preparation for LC. If you have the bandwidth and are willing to provide a review it would be greatly appreciated. >>> >>> [Note: Peter - I know you recently sent your review to the list but I have left you on the list since you said you planned to get back to reviewing the examples.] >>> >>> Cheers, >>> >>> Gonzalo >>> (as co-chair) >> >
- [Insipid] Reviews for INSIPID Session-ID solution… Gonzalo Salgueiro (gsalguei)
- Re: [Insipid] Reviews for INSIPID Session-ID solu… R.Jesske
- Re: [Insipid] Reviews for INSIPID Session-ID solu… Gonzalo Salgueiro (gsalguei)
- Re: [Insipid] Reviews for INSIPID Session-ID solu… Gonzalo Salgueiro (gsalguei)
- Re: [Insipid] Reviews for INSIPID Session-ID solu… Arun Arunachalam
- Re: [Insipid] Reviews for INSIPID Session-ID solu… Brett Tate
- Re: [Insipid] Reviews for INSIPID Session-ID solu… Arun Arunachalam
- Re: [Insipid] Reviews for INSIPID Session-ID solu… R.Jesske
- Re: [Insipid] Reviews for INSIPID Session-ID solu… Paul E. Jones
- Re: [Insipid] Reviews for INSIPID Session-ID solu… R.Jesske
- Re: [Insipid] Reviews for INSIPID Session-ID solu… Paul Kyzivat
- Re: [Insipid] Reviews for INSIPID Session-ID solu… Paul E. Jones
- Re: [Insipid] Reviews for INSIPID Session-ID solu… Paul E. Jones
- Re: [Insipid] Reviews for INSIPID Session-ID solu… Paul E. Jones
- Re: [Insipid] Reviews for INSIPID Session-ID solu… R.Jesske
- Re: [Insipid] Reviews for INSIPID Session-ID solu… Paul Kyzivat
- Re: [Insipid] Reviews for INSIPID Session-ID solu… Paul E. Jones
- Re: [Insipid] Reviews for INSIPID Session-ID solu… Paul Kyzivat