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

[Paul Kyzivat <[e-mail]>]

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.

> At 03:55 PM 2/12/2014, Paul E. Jones wrote:
>> 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...
>>
>
> <snip>
>
>
>>>  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'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.

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

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

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:[e-mail], sip:[e-mail], ...)

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

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

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.

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

> I'll take input from those that know SIP better than me on this one
> (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

> James
>
>
>> Paul
>>
>> _______________________________________________
>> insipid mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/insipid
>
>