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

[James Polk <[e-mail]>]

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

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




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

James


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