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

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 12 Feb 2014 21:55:00 +0000

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

---

From: James Polk <[email-masked]>
Date: Thu, 13 Feb 2014 02:17:16 -0600

Paul and Paul

I'll remove the q&a that I agree with, leaving only the points that 
need further context or correction.

At 03:55 PM 2/12/2014, Paul E. Jones wrote:
>Actually, some issues do appear to be resolved, but I didn't 
>positively acknowledge.
>
>Comments below...
>

<snip>

>>There is nothing standard that you can put in a reINVITE that will 
>>tell the receiver to transfer the call.

I'll add that you're correct too, and that this above bullet should 
have been separated into (at least) two bullets for each step. I knew 
what I wanted to explain, and just cut the text down *too* much. This 
mistake is on me.

Of course the REFER request "...tell(s) the receiver to transfer the call. "

I'll just split out the one bullet the necessary, but concise, 
bullets to explain what we mean.

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

If I may inject - M' is the UUID for this conference. Another 
conference involving this combination - or another combination - of 
MCUs would have a different UUID (say, M'', or M*)... which would be 
distributed by another series of  INVITE transactions. As the draft says

"...A conference bridge, or MCU, needs a way to identify itself when 
contacting another MCU. RFC 4579 [RFC4579] defines the 'isfocus' 
Contact: header parameter just for this purpose. "

in the first paragraph of section 9.6.

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

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

I'll take input from those that know SIP better than me on this one 
(Robert, Keith, Paul K, others...)...

James

>Paul
>
>_______________________________________________
>insipid mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/insipid

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Feb 2014 14:47:00 -0500

On 2/13/14 3:17 AM, James Polk wrote:
> Paul and Paul
>
> I'll remove the q&a that I agree with, leaving only the points that need
> further context or correction.

Its been awhile, and hard to get my head back into this.
And its hard to figure out which things below are my own comments.
But I'll comment as best I can.

> I'll add that you're correct too, and that this above bullet should have
> been separated into (at least) two bullets for each step. I knew what I
> wanted to explain, and just cut the text down *too* much. This mistake
> is on me.
>
> I'll just split out the one bullet the necessary, but concise, bullets
> to explain what we mean.

OK. I'll wait to see what you come up with.

>> 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

So? The whole point is so that in figure 8 MCU-3 will identify itself as 
M' to Robert. So why shouldn't MCU-3 and MCU-2 identify themselves as M' 
to MCU-1.

I'm looking for some rationale and logic for when and why the MCU uses a 
unique UUID of its own and when it uses one it was given.

> If I may inject - M' is the UUID for this conference. Another conference
> involving this combination - or another combination - of MCUs would have
> a different UUID (say, M'', or M*)... which would be distributed by
> another series of  INVITE transactions. As the draft says

Sure. This is simple if each MCU has a unique URI that identifies the 
conference. (E.g. sip:[email-masked], sip:[email-masked], ...)

Then the MCU always knows what conference it is dealing with and can use 
the proper UUID.

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

Why not? Presumably that session is used to share media between the 
MCUs, which is legitimately part of the conference.

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

You seem to have some clear vision of how these are used that guides the 
way you are specifying this. But AFAICT you haven't explained that 
vision, and clearly I don't share it. So your choices seem entirely 
arbitrary to me.

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

> (Robert, Keith, Paul K, others...)...

This isn't a question that existing sip specs have an answer to. The 
"session" being defined here is a new abstract concept, built on 
existing concepts such as dialogs, UAs, B2BUAs. This was my issue with 
the whole notion of session-id.

It seems that these are *choices*. It isn't clear to me if they are 
choices that we should make in this document, or if these are choices 
that implementers should make on a case by case basis.

If these are to be left as implementer choices, then I think this draft 
should call these out as choices, say that it is up to the implementer 
to make them, and explain the sorts of criteria that are relevant to the 
choice.

	Thanks,
	Paul