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

[Paul Kyzivat <[e-mail]>]

I just went through the latest version and have some comments:

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.

    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/

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.

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?

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?

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/

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.

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

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.

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

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.

	Thanks,
	Paul