Re: [Insipid] Reviews for INSIPID Session-ID solution draft

["Gonzalo Salgueiro (gsalguei)" <[e-mail]>]

Thanks for reviewing the document, Arun.

Regards,

Gonzalo

Sent from my iPhone

On Aug 3, 2014, at 11:03 PM, "Arun Arunachalam (carunach)" <[e-mail]<mailto:[e-mail]>> wrote:

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-<http://www.iana.org/assignments/sip-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) <[e-mail]<mailto:[e-mail]>> wrote:

Thanks, Arun!

Gonzalo


On Jul 24, 2014, at 1:01 PM, Arun Arunachalam <[e-mail]<mailto:[e-mail]>> wrote:

Hi Gonzalo,

Interested in reviewing the draft.

Let me send the comments to [e-mail]<mailto:[e-mail]>.

Thanks!
Arun

On Jul 24, 2014, at 12:41 PM, "Gonzalo Salgueiro (gsalguei)" <[e-mail]<mailto:[e-mail]>>
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)