Subject: [Insipid] Out-of-Dialog REFER

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 20 Mar 2014 02:11:02 +0000

Folks,

During this last meeting, there was a discussion of how to handle OOD 
REFER messages.  Grabbing just a part of the flow in Section 9.9 of the 
Session-ID solution draft, we have this:

Session ID Bob Alice Carol | | | {A,N} |<-----INVITE--------| | {B,A} 
|------200 OK------->| | {A,B} |<------ACK----------| | | | | {B,A} 
|--INVITE {hold}---->| | {A,B} |<-200 OK------------| | {B,A} |--- ACK 
----------->| | | | | {X,N} |--REFER------------>|(Refer-To:Carol) |
It is this last line (and related lines) that I believe folks wanted to 
take to the list to resolve.

In this example, Bob is using an OOD REFER to transfer the call between 
Alice and Bob to Carol and using the Session-ID {X,N}.  A desire was 
expressed in the meeting that, even though this is an OOD REFER, the 
Session-ID should have some relationship with the session to which it 
relates.

So, Bob could use {B,A}, which would identify exactly what Session-ID 
this is.  Alternatively, Bob could use {B,N} so as to associate this new 
session with Bob, but allow Alice to pick a new UUID "Y".

Perhaps there are other ways people want this to be handled?

What do folks want here?

Paul

---

From: James Polk <[email-masked]>
Date: Mon, 24 Mar 2014 14:07:21 -0500

comments in-line below

At 09:11 PM 3/19/2014, Paul E. Jones wrote:
>Folks,
>
>During this last meeting, there was a discussion of how to handle 
>OOD REFER messages.  Grabbing just a part of the flow in Section 9.9 
>of the Session-ID solution draft, we have this:
>
>
>  Session ID     Bob                 Alice                 Carol
>                  |                    |                     |
>     {A,N}        |<-----INVITE--------|                     |
>     {B,A}        |------200 OK------->|                     |
>     {A,B}        |<------ACK----------|                     |
>                  |                    |                     |
>     {B,A}        |--INVITE {hold}---->|                     |
>     {A,B}        |<-200 OK------------|                     |
>     {B,A}        |--- ACK ----------->|                     |
>                  |                    |                     |
>     {X,N}        |--REFER------------>|(Refer-To:Carol)     |
>
>It is this last line (and related lines) that I believe folks wanted 
>to take to the list to resolve.
>
>In this example, Bob is using an OOD REFER to transfer the call 
>between Alice and Bob to Carol and using the Session-ID {X,N}.  A 
>desire was expressed in the meeting that, even though this is an OOD 
>REFER, the Session-ID should have some relationship with the session 
>to which it relates.
>
>So, Bob could use {B,A}, which would identify exactly what 
>Session-ID this is.  Alternatively, Bob could use {B,N} so as to 
>associate this new session with Bob, but allow Alice to pick a new UUID "Y".
>

ISTM that the current text doesn't satisfy Hadriel's legitimate 
use-case regarding the ability to track the in-band *and* out-of-band 
REFER, regardless of which dialog-ID these messages have -- so why 
make this operation hard on ourselves? Just use {B,A} for the REFER, 
because both Bob and Alice know the local- and remote-uuid - that's 
my proposal.

Anyone have a different idea (and good technical reasons not to do it 
this way)?

James

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

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 24 Mar 2014 21:09:31 +0000

If the desire is to have that OOD REFER to be logically associated with 
the Session, then that makes sense.  So, regardless of whether the REFER 
is in or out of dialog, the same procedures apply.

Paul

------ Original Message ------
From: "James Polk" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: "Paul E. Jones" <[email-masked]>
Sent: 3/24/2014 3:07:21 PM
Subject: Re: [Insipid] Out-of-Dialog REFER

>>this is. Alternatively, Bob could use {B,N} so as to associate this 
>>new session with Bob, but allow Alice to pick a new UUID "Y".
>>
>REFER, regardless of which dialog-ID these messages have -- so why make 
>this operation hard on ourselves? Just use {B,A} for the REFER, because 
>both Bob and Alice know the local- and remote-uuid - that's my 
>proposal.
>