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

["Paul E. Jones" <[e-mail]>]

Paul,

Finally getting back to your comments.  We held off on most of these 
comments until we made traction on the backward-compatibility stuff.  
Actually, some issues do appear to be resolved, but I didn't positively 
acknowledge.

Comments below...


>Section 6:
>
>    The exception to including the UUID of the transmitting entity
>    mentioned above is in the case of provisional responses that occur
>    before the destination UA has generated its UUID. The 100 (Trying)
>    response and the 181 (Call Forwarding) response are examples of such
>    provisional responses. In these cases, the sending intermediary
>    places the one known UUID in the remote-uuid field, and leaves the
>    "local-uuid" blank. This placement is always where a UA expects to
>    receive its UUID value in SIP responses.
>
>The above calls for a syntactically incorrect header field. If you want 
>to allow the local-uuid to be omitted then the syntax needs to be 
>updated. Or else specify that the local-uuid must be set to the NULL 
>value.

This one I think is now addressed via use of the "null" UUID in the -04 
draft.  You'll see the same in the forthcoming -05.


>
>    For any purpose the UA has for the Session Identifier, it MUST 
>assume
>    that the Session Identifier is {A,B} where "A" is the UUID value of
>    this endpoint (i.e., "local-uuid") and "B" is the UUID value of the
>    peer endpoint (i.e., "remote-uuid"), taken from the most recently
>    received message within this session. Note that when comparing
>    Session Identifiers for equivalence, the identifier {A,B} is equal 
>to
>    the set {B,A}.
>
>s/the set/the identifier/

Corrected.


>The last paragraph of Section 6 says:
>
>    Cascading MCUs all utilize the same UUID value ("local-uuid" portion
>    of the Session-ID header-value) for all participants of the cascaded
>    conference. An MCU conveys the UUID value to utilize via the "local-
>    uuid" portion of the Session-ID header-value in an INVITE to a 
>second
>    MCU.
>
>Then Section 8 says more about MCUs. But there is nothing normative. If 
>you want to say anything about this then I think it would be better to 
>make it normative, even if it is optional to use.

We made some changes to Section 6 and Section 8.  When the -05 is 
published, please consider what further changes we should make.


>Is the intent that when a conference focus (MCU-2) receives an INVITE, 
>and the caller (MCU-1) indicates isFocus, that MCU-2 SHOULD adopt the 
>uuid received in that INVITE as its own for the duration of that 
>dialog?

Yes.


>Section 9.1:
>
>The general operation description makes a distinction between "the 
>originating transmitter" and "UA-Alice". These seem to be the same. Is 
>there a point to the distinction?

These are the same.  I'll change it to UA-Alice, since the rest of the 
text appears to refer to UA-Alice and UA-Bob.


>Section 9.2:
>
>      o UA-Bob reINVITEs Alice to call Carol, using a REFER transaction,
>        as described in [RFC3515]. UA-Alice is initially put on hold,
>        then told in the REFER who to contact with a new INVITE, in this
>        case UA-Carol. This Alice-to-Carol dialog will have a new Call-
>        ID, therefore it requires a new Session-ID header-value. The
>        wrinkle here is we can, and will, use Alice's UUID from her
>        existing dialog with Bob in the new INVITE to Carol.
>
>The phrasing above is misleading. I suggest:
>
>s/reINVITEs/requests/

Changed.


>  Section 9.3:
>
>      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.
>
>I've mentioned this before...
>
>There is nothing standard that you can put in a reINVITE that will tell 
>the receiver to transfer the call. I'm inclined to suggest you just 
>drop this example. But if you want it, then you must explain what magic 
>you are assuming that triggers the transfer.

You're entirely correct, but it's also common for PBX systems to perform 
call transfers "behind the scenes".  I'll put in an editor's note 
capturing your point and asking for guidance.  This can be discussed via 
email or during the meeting in London.  One argument might be that if we 
remove it, it does no harm because endpoints don't even know they are 
being transferred, therefore they would have no reason to change the 
UUID.  Thus, we could safely remove the text. Another argument might be 
that having this helps to answer any questions that arise related to 
such situations.


>Section 9.6:
>
>I presume that after the initial INVITE from MCU-1 to MCU-2 that MCU-2 
>SHOULD use M' as its local UUID. If so, why doesn't it use M' as its 
>own in the response to that invite, resulting in {M',M'}?

M' refers to the MCU's UUID.  It sends that to each of the conference 
participants.  It also sends that to each of the MCUs with which it 
wants to bring into a cascaded conference.  However, it's not clear 
which message you are suggesting should be {M',M'}.  The session 
established between the MCU-1 and MCU-2 would not use {M',M'}, if that's 
what you're asking.  The sessions established between MCUs are still 
distinct sessions and the session IDs need to be distinct.  MCU-2 and 
MCU-3 are supposed to use M' with participants that join the conference.


>The examples also don't go far enough to show the effect they want. For 
>this you should show two callers calling in, to two different MCUs and 
>both getting M' back.

We have a new 9.6.1 that shows this example.  I'm not sure if that 
should be its own sub-section just appended to 9.6.  Thoughts?


>Section 9.9:
>
>The "(Target-Dialog:Carol)" must be wrong since there is no dialog with 
>Carol at that point. I think what you want is "(Refer-To:Carol)". There 
>will be a Target-Dialog, but it isn't especially interesting here. If 
>you want to mention it, then you might call it 
>"(Target-Dialog:Bob-Alice)".

I think "Refer-To: Carol" is the right thing here.


>  Is there a reason for using X & Y rather than reusing B & A? E.g.:
>
>          {B} |--REFER------------>|(Refer-To:Carol) |
>         {A,B} |<-202 Accepted------| |
>                      | | |
>         {A,B} |<NOTIFY {100 Trying}| |
>         {B,A} |-200 OK------------>| |
>
>ISTM this is at least as justified as an MCU using the same uuid for 
>all the dialogs in the same conference.

Yeah, one might make that argument.  The issue with this one was that it 
was OOD.  If we want that OOD exchange to be considered a part of the 
same session, then we would re-use {A,B}.  However, I think the thought 
here was that the OOD REFER case is a whole other call and that means a 
whole other session.  Bob could have used {B} as the UUID, but re-using 
{A} (thus {A,B}) is different from the conference case, since we lose 
the uniqueness of the two sessions.

I think we need to decide whether that OOD REFER should be considered 
the same or a different session.

Paul