Subject: Re: [Insipid] Posted draft-ietf-insipid-session-id-06

From: "Dawes, Peter, Vodafone Group" <[email-masked]>
Date: Fri, 22 Aug 2014 08:44:18 +0000

Hi James, 
I have reviewed the ABNF and the signalling flows and my comments and questions are below.

Best regards,
Peter

lines 304 - 325	
The ABNF definition does not seem to follow the usual order (e.g. remote-uuid is defined before it is used). I suggest:

    session-id    = "Session-ID" HCOLON local-uuid

    	*(SEMI sess-id-param)
					 
	sess-id-param = remote-param / generic-param
	
	remote-param  = "remote" EQUAL remote-uuid
	
	remote-uuid   = sess-uuid / null
	
	local-uuid    = sess-uuid / null
	
    	sess-uuid     = 32(DIGIT / %x61-66)  ;32 chars of [0-9a-f]

    	null          = 32("0") 

line 953 onwards
Below Fig. 6, the description of the conferencing focuses using the same UUID is not clear. ""Regardless of which MCU (1 or 2) a UA contacts for this conference, once the above exchange has been received and acknowledged, the UA will get the same {M',N} UUID pair from the MCU for the complete Session ID.""
	a) does not say how the inter-MCU dialogs are ended, or if they are
	b) does not say when the signalling exchange between the MCUs happens. Do cases exist where the MCUs will not use the same UUID?
	c) the MCU UUID will be received when the MCU contacts the UA but the text suggests it happens the other way around
	d) not stated whether this applies to the re-INVITE case, the WebEx case or both"

lines 1015-1016
Fig. 7 typo. Should say e.g.  "This will identify the MCU as what RFC 4579 calls a conference-aware SIP entity."

lines 1018-1021
Fig. 7, the description below the figure is not clear: ""An MCU that receives this {M',N} UUID pair in an inter-MCU transaction, can communicate the M' UUID in a manner in which it was received (though this time this second MCU would be the UAC MCU), unless local policy dictates otherwise.""
	a) what does "in a manner in which it was received" mean in terms of the protocol?
	b) What is a UAC MCU?
	c) what behaviour does local policy control?

lines 1080-1091
Fig. 8 typo the ACK from the B2BUA to Alice should be {B,A}

lines 1111-1114
Fig. 8 the two ACK messages in the figure need to be described in the text below the figure. 

line 1149
Fig. 9, for the 181 Call Fwd provisional response, it seems to me that {B1,A}, indicating that Bob 1 is forwarding the call, would be ok as a session ID. Why must the session ID be {N,A}?

-----Original Message-----
From: Dawes, Peter, Vodafone Group 
Sent: 30 July 2014 16:29
To: 'James Polk'; Paul E. Jones; [email-masked]
Cc: [email-masked]
Subject: RE: [Insipid] Posted draft-ietf-insipid-session-id-06

Hello James,
Thanks for looking into my comments and questions, many of which are answered. Below I have tried to explain more clearly a few that I think still need to be investigated. I will also review the signalling flows and send comments if any...

Best regards,
Peter

[comment#01 lines 167 - 169]
The draft uses two terms to refer to the value of the Session-ID header field, namely "Session Identifier" and "Session-ID", e.g. from the Table of Contents:

   3. Session Identifier Requirements and Use Cases..................4
   4. Constructing and Conveying the Session Identifier..............4
      4.1. Constructing the Session Identifier.......................4
      4.2. Conveying the Session Identifier..........................4
   5. Transmitting the Session Identifier in SIP.....................6 .
   9. Various Call Flow Operations Utilizing the Session ID.........10
      9.1. Basic Session ID Construction with 2 UUIDs...............10 .
      9.6. Cascading Conference Bridge Support for the Session ID...17
         9.6.1. Calling into Cascaded Conference Bridge for the Session
         ID.........................................................18
.
      9.8. Session ID Handling in 100 Trying SIP Response and CANCEL
      Request.......................................................20
         9.8.1. Session ID Handling in a 100 Trying SIP Response....20
         9.8.2. Session ID in a CANCEL SIP Request..................21
      9.9. Session ID in an out-of-dialog REFER Transaction.........22

I think it would be clearer to replace all "Session ID" with "Session Identifier"

[comment#02 lines 444]
You clarified that the text
>If an intermediary receives a SIP message without a Session-ID header
>    value ,
means that the Session-ID header field is "non-existent"

I think better wording would be " If an intermediary receives a SIP message without a Session-ID header field, "

[comment#03 lines 444-449]
For the following paragraph in clause 7 Processing by Intermediaries

If an intermediary receives a SIP message without a Session-ID header
   value, the intermediary MAY assign a "local-uuid" value to represent
   the sending endpoint and insert that value into all signaling
   messages on behalf of the sending endpoint.  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.

If Alice sends a dialog-creating SIP message that does not have a Session-ID header field, then an intermediary MAY assign and insert a "local-uuid" value. What if Alice sends another dialog-creating SIP message (i.e. simultaneous dialogs)? The text says that the intermediary inserts the "local-uuid" value in all signalling messages with no limits on time or dialog. I guess it should say "all signaling messages in that dialog".

[comment#04 general]
In many places the draft does not clearly and consistently identify the header field value (which is also the local-uuid), the "remote" parameter name, and the value that the "remote" parameter contains. Looking at the example:

Session-ID: ab30317f1a784dc48ff824d0d3715d86;
                 remote=47755a9de7794ba387653f2099600ef2

I think the terminology should be as follows:
header field is Session-ID: ab30317f1a784dc48ff824d0d3715d86; remote=47755a9de7794ba387653f2099600ef2
field name is Session-ID
field value is ab30317f1a784dc48ff824d0d3715d86
local-uuid is ab30317f1a784dc48ff824d0d3715d86
"remote" parameter contains 47755a9de7794ba387653f2099600ef2

which would match the description in RFC3261 "Many existing header fields will adhere to the general form of a value followed by a semi-colon separated sequence of parameter-name, parameter-value pairs
							field-name: field-value  *(;parameter-name=parameter-value)"

changes are as follows

[comment#05 lines 369 - 375]
change:
To comply with this specification, non-intermediary SIP UAs MUST
   include a Session-ID header in all SIP messages transmitted as
   a part of a communication session.  The UUID of the transmitter of
   the message MUST appear in the "local-uuid" portion of the Session-ID
   header-value.  The UUID of the peer device, if known, MUST appear as
   the "remote" parameter following the transmitter's UUID.  

to:
To comply with this specification, non-intermediary SIP UAs MUST
   include a Session-ID header field in all SIP messages transmitted as
   a part of a communication session.  The UUID of the transmitter of
   the message MUST appear as the value (local-uuid) of the Session-ID
   header field.  The UUID of the peer device, if known, MUST appear in
   the "remote" parameter following the transmitter's UUID.  

[comment#06 lines 390-403]
change:
A non-intermediary UA that receives a Session-ID header MUST take
   note of the first UUID value (i.e., the "local-uuid") that it
   receives in the Session-ID header and assume that that is the UUID of
   the peer endpoint within that communications session.  UAs MUST
   include this received UUID value as the "remote" parameter when
   transmitting subsequent messages, making sure not to change this UUID
   value in the process of moving the value internally from the "local-
   uuid" field to the "remote-uuid" field.

   It should be noted that messages received by a UA might contain a
   "local-uuid" value that does not match what the UA expected the far
   end UA's UUID to be.  It is also possible to for the UA to receive a
   "remote-uuid" value that does not match the UA's assigned UUID for
   the session.

to:
A non-intermediary UA that receives a Session-ID header MUST take
   note of the Session-ID header field value (i.e., the local-uuid) 
and assume that that is the UUID of
   the peer endpoint within that communications session.  UAs MUST
   include this received UUID value in the "remote" parameter when
   transmitting subsequent messages, making sure not to change this UUID
   value in the process of moving the value internally from the field value to the "remote " parameter.

   It should be noted that messages received by a UA might contain a
value (local-uuid)  that does not match what the UA expected the far
   end UA's UUID to be.  It is also possible to for the UA to receive a
   "remote" parameter containing a value that does not match the UA's assigned UUID for
   the session.

[comment#07 lines 422-427 ]
change:
It is also important to note that if an intermediary in the network
   forks a session, the initiating UA may receive multiple responses
   back from different endpoints, each of which contains a different
   UUID ("local-uuid") value.  UAs MUST take care to ensure that the
   correct UUID value is returned in the "remote" parameter when
   interacting with each endpoint.

to:
It is also important to note that if an intermediary in the network
   forks a session, the initiating UA may receive multiple responses
   back from different endpoints, each of which contains a different
   value (local-uuid).  UAs MUST take care to ensure that the
   correct UUID value is returned in the "remote" parameter when
   interacting with each endpoint.

[comment#08 lines 444-449]
change:
If an intermediary receives a SIP message without a Session-ID header, the intermediary MAY assign a "local-uuid" value to represent
   the sending endpoint and insert that value into all signaling
   messages on behalf of the sending endpoint.  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.

to:
If an intermediary receives a SIP message without a Session-ID header
   , the intermediary MAY assign a local-uuid to represent
   the sending endpoint and insert a Session-ID header with the local-uuid value into all signaling
   messages on behalf of the sending endpoint.  If the intermediary is
   aware of a remote-uuid that identifies the receiving UA, it MUST
   insert a "remote" parameter containing the remote-uuid value if also inserting the local-uuid value.

[comment#09, lines 463-493]
change:
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.

   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.

   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.

to:
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" parameter and set the
   Session-ID field value (local-uuid) to the null UUID.  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" parameter and MAY set the Session-ID header field value (local-uuid) to
   a locally created UUID or the null UUID.  In all cases
   when the intermediary knows the UUID of the destination UA, the
   intermediary MUST set the UUID of the destination UA as the
  Session-ID header field value (local-uuid) and insert the originating UA's UUID into the
   "remote " parameter when sending a provisional response.

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

   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
   value (local-uuid); call this temporary UUID X.  The request will
   still have a "remote " parameter containing the nulll UUID; call this value N.

[comment#10]
similar changes for local-uuid and "remote" parameter from clause 8 onwards.

[comment#11]
change:
9.1. Basic Session ID Construction with 2 UUIDs

      Session ID
         ---     Alice            B2BUA             Bob            Carol
        {A,N}      |----INVITE----->|                |
        {A,N}      |                |----INVITE----->|
        {B,A}      |                |<---200 OK------|
        {B,A}      |<---200 OK------|                |
        {A,B}      |------ACK------>|                |
        {A,B}      |                |------ACK------>|
                   |<==============RTP==============>|

             Figure 1 - Session ID Creation when Alice calls Bob

   General operation of this example:

      o UA-Alice populates the "local-uuid" portion of the Session-ID
        header-value.

      o UA-Alice sends its UUID in the SIP INVITE, and populates the
        "remote" parameter with a null value (32 zeros).

to:
9.1. Basic Session ID Construction with 2 UUIDs

      Session ID
         ---     Alice            B2BUA             Bob            Carol
        {A,N}      |----INVITE----->|                |
        {A,N}      |                |----INVITE----->|
        {B,A}      |                |<---200 OK------|
        {B,A}      |<---200 OK------|                |
        {A,B}      |------ACK------>|                |
        {A,B}      |                |------ACK------>|
                   |<==============RTP==============>|

             Figure 1 - Session ID Creation when Alice calls Bob

   General operation of this example:

      o UA-Alice sends its UUID in the SIP INVITE, and populates the
        "remote" parameter with a null value (32 zeros).

i.e. combine the first two bullets into one.

-----Original Message-----
From: James Polk [mailto:[email-masked]] 
Sent: 19 June 2014 22:02
To: Dawes, Peter, Vodafone Group; Paul E. Jones; [email-masked]
Subject: Re: [Insipid] Posted draft-ietf-insipid-session-id-06

At 04:05 AM 6/19/2014, Dawes, Peter, Vodafone Group wrote:
>Content-Language: en-US
>Content-Type: multipart/alternative;
> 
>boundary="_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99870C73C3VOEXM31Winterna_"
>
>Hi Paul,
>I have read through the latest session-id solutions draft 
><http://www.ietf.org/id/draft-ietf-insipid-session-id-06.txt>http://www
>.ietf.org/id/draft-ietf-insipid-session-id-06.txt
>and I have the comments below, organized by the line number in the 
>draft. I havenâ€™t yet checked the details of all of the signalling 
>scenarios in clause 9 so I might have some more comments later.

Peter

Thanks for doing this review.

Comments are in-line with the questions/comments you have...

>
>Rgds,
>Peter
>
>
>Line
>Draft Text
>Comment or Question
>line 95
>9.5. Single Focus Conferencing using WebEx ....................16 Is an 
>internet draft allowed to refer to a commercial product, i.e. WebEx?

This is only in the examples section of the document. Because it is used so pervasively throughout the industry, and has a substantially different model to other conferencing systems (it uses another protocol - the secure form of HTTP), we thought it wise to have in the doc (but only in the example text).

>lines 149 - 152
>This draft presents a new identifier, referred to as the Session 
>Identifier, or "Session ID", and associated syntax intended to overcome 
>the issues that exist with the currently defined call identifiers.
>It would help to describe the scope of this new identifier, e.g. SIP 
>only, SIP and H.323, or something else.

reading the opening paragraphs of the Intro section should answer this for anyone

>lines 169 - 171
>The terms "Session Identifier" and "Session ID" 
>refer to the value of the identifier, whereas "Session-ID" refers to 
>the header used to convey the identifier.
>It would be clearer to refer to the value using only "Session 
>Identifier" throughout.

Sometimes we need to talk about the value "of" 
the header, and others we need to talk about the header itself.

>line 170
>"Session-ID" refers to the header
>Change to "Session-ID" refers to the SIP header field

I'm not sure what you are getting at, this is a SIP doc (ITU's SG16 just introduced its own version of the Session-ID header (under H.460) this week).

>line 187
>[I-D.ietf-insipid-session-id-reqts] .
>Now RFC7206

indeed

>196 - 197
>The version number in the UUID indicates the manner in which the UUID 
>is generated, I did not see version number defined in the draft

it's one number always, version 5 -- and the present doc does say that.

>lines 202 - 211
>When generating a version 5 UUID, endpoints or intermediaries MUST
>    utilize the following "name space ID" (see Section 4.3 of [RFC4122]):
>
>        uuid_t NameSpace_SessionID = {
>            /* a58587da-c93d-11e2-ae90-f4ea67801e29 */
>            0xa58587da,
>            0xc93d,
>            0x11e2,
>            0xae, 0x90, 0xf4, 0xea, 0x67, 0x80, 0x1e, 0x29
>        }
>The procedure and syntax being described by the draft are not clear to me.

look to "Section 4.3 of [RFC4122]" for this

>lines 225 - 228
>Note that if an intermediary is stateless and the endpoint on one end
>    of the call is replaced with another endpoint due to some service
>    interaction, the values used to create the UUID might change  and, if
>    so, the intermediary will compute a different UUID.
>a) If an endpoint is replaced then I would expect the UUID to always 
>change but the text says "might"
>b) text says "the values used to create the UUID" but the draft does 
>not describe a UUID creation algorithm
>c) text says that intermediary is stateless but also says that the 
>intermediary will compute  a different UUID. Surely a stateless 
>intermediary does not compute a UUID

hmm, I have the only mention of the word "stateless" on line 215...

a) this is only under the condition of the intermediary being stateless.
b) ? , we state the UUID reference RFC for creating it several times in this section (RFC 4122, S3)
c) not "that" but "if" an intermediate is stateless.

>line 327
>null          = 32("0")
>since 32 zeros is a valid UUID, it might be 
>better to use the string "null" for the NULL value.

I'll consult with my co-editor and the WG

>lines 451 - 454
>If an intermediary receives a SIP message without a Session-ID header
>    value , the intermediary MAY assign a "local-uuid" value to represent
>    the sending endpoint and insert that value into all signaling
>    messages on behalf of the sending endpoint.
>a) Does the intermediary receive an empty 
>Session-ID header field, or a message with no Session-ID header field?
>b) messages can be originated in both 
>directions, so is it always local-uuid that is 
>assigned or is it sometimes remote-uuid?
>c) the text "all signalling messages" does not 
>seem specific enough e.g. the sending endpoint 
>might initiate a completely new dialog

a) not empty, "non-existent"
b) always local, except under the conditions of section 10
c) new dialog means new UUIDs in both directions

>lines 471 - 473
>, the intermediary MUST
>    place the one known UUID in the "remote-uuid" field  and set the
>    "local-uuid" field to the null UUID value.
>Might be clearer to say "use the one known UUID 
>as the "remote-uuid" since "remote-uuid" is not 
>a header field or a header field parameter. Likewise for "local-uuid"

"since "remote-uuid" is not a header field or a 
header field parameter". The local-uuid is a 
header-value and the remote-uuid is a header-parameter, always.

>line 493
>MUST construct a Session-ID header value
>MUST use a Session-ID header value

what if there isn't a Session-ID: there in the 
first place? Then "use" (something that's non-existent) isn't right.

>line 511
>MCUs, including cascaded MCUs ,
>Is "cascaded MCU" a well understood term?

I guess the real question is if the implementor 
understands what the word cascade is. S9.6 gives 
good diagrams of the most common use-cases.

>lines 543 - 546
>Intermediary devices, such as proxies  or session border controllers,
>    or network diagnostics equipment might assume that when they see two
>    or more sessions with different Session Identifiers, but with one
>    UUID in common, that the sessions are part of the same conference.
>Maybe proxies should be left off the list of 
>devices that will examine the session identifier

folks look for proxy when talking about SIP, and 
it it's left off some list involving servers, it'll be a distract (best case)

>line 566
>"N" represents a null UUID
>

I'll talk to my co-editor about this

>lines 585 - 586
>UA-Alice populates the "local-uuid" portion of the Session-ID
>         header-value.
>This bullet seems to be redundant and could be deleted

I'm lost here. There are three instances of the 
word "populates", and UA-Alice isn't on page 11 
(line 585-86). There is a "Bob's UUID populates 
the "remote-uuid"... ", which I'd like to keep

>line 554
>9. Various Call Flow Operations Utilizing the Session ID
>I think it would help if at least one of the 
>signalling examples shows SIP (and maybe SDP). 
>For a while, I was confused about whether 
>"local-uuid" and "remote-uuid" were header field 
>parameters and then wondered why the only IANA 
>registration was for a "remote" parameter.

Instead of this, look at the top of page 7 for the Session-ID: example.

>line 1423
>11. Security Considerations
>At the London meeting, security was identified 
>as an open issue that needs to be fully 
>analysed. Does this analysis still need to be done?

We're always open to more comments. The SecAD 
(Sean Turner ?) has been contacted, but hasn't 
gotten back to us or the chairs...

Again, thanks for the thorough review

James

>
>
>
>From: insipid [mailto:[email-masked]] On Behalf Of Paul E. Jones
>Sent: 10 April 2014 04:53
>To: [email-masked]
>Subject: [Insipid] Posted draft-ietf-insipid-session-id-06
>
>Folks,
>
>I just uploaded a revised version of the Session 
>ID solution draft.  In this draft, we did the following:
>    * Added text to Section 7 (intermediaries) 
> to describe handling of provisional responses
>        * WIth one typo "intermediaries 
> transmits" (will fix that in the next version)
>    * Changed the UUID values used for OOD REFER 
> (Section 9.9) per list discussion
>    * Added one new paragraph on security considerations
>Please have a look at the draft and suggest 
>other things we need to address, including any 
>issues you believe we need to raise in the security considerations.
>
>Thanks,
>Paul
>
>_______________________________________________
>insipid mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/insipid