Subject: Re: [splices] Answering a Call Using Two Separate Devices proposal

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Sun, 1 May 2011 11:41:14 -0400

Hi,

In the following flow, I have tried to incorporate all the feedback that I received so far.
The only open issue that I am aware of is the issue of what to present to the user on the PC when the phone initiates a video call to the PC (see (#) below).

Can you please review the flow below and let me know if we have any other open issues?

Regards,
 Rifaat

   Alice                 Alice                Proxy                  Bob
    PC                 Desk Phone                                      
    |                     |                     |                     |
    |                     |                     |                     |
Both Alice's devices subscribe to the reg event package, which allows each device to 
discover the capabilities of the other device based on the feature tags provided by each device.
The Desk Phone knows that the PC supports Video, while the PC knows that the Desk Phone only supports audio.
    |                     |                     |                     |
    |                     | SUBSCRIBE reg       |                     |
    |                     |-------------------->|                     |
    |                     | 200 OK              |                     |
    |                     |<--------------------|                     |
    |                     |                     |                     |
    | SUBSCRIBE reg       |                     |                     |
    |------------------------------------------>|                     |
    | 200 OK              |                     |                     |
    |<------------------------------------------|                     |
    |                     |                     |                     |
    |                     |                     |                     |
The two devices also subscribe to the dialog of each other.
    |                     |                     |                     |
    |                     |                     |                     |
    | SUBSCRIBE dialog    |                     |                     |
    |-------------------->|                     |                     |
    | 200 OK              |                     |                     |
    |<--------------------|                     |                     |
    |                     |                     |                     |
    | SUBSCRIBE dialog    |                     |                     |
    |<--------------------|                     |                     |
    | 200 OK              |                     |                     |
    |-------------------->|                     |                     |
    |                     |                     |                     |
    |                     |                     |                     |
The scenario starts with an audio call from Bob to Alice
    |                     |                     |                     |
    |                     |                     | INVITE Alice [Audio]|
    |                     |                     |<--------------------|
    |                     | INVITE Alice [Audio]|                     |
    |                     |<--------------------|                     |
    | INVITE Alice [Audio]|                     |                     |
    |<------------------------------------------|                     |
    |                     |                     |                     |
Let's assume that Alice used her PC to instruct the phone to answer the call    
    |                     |                     |                     |
    | REFER Refer-To: urn:sip-action:call:answer;transducer=speaker|headset
    |-------------------->|                     |                     |
    | 200 OK              |                     |                     |
    |<--------------------|                     |                     |
    |                     |                     |                     |
    |                     | 200 OK [Audio]      |                     |
    |                     |-------------------->|                     |
    |                     |                     | 200 OK [Audio]      |
    |                     |                     |-------------------->|
    | CANCEL              |                     |                     |
    |<------------------------------------------|                     |
    |                     |                     |                     |
    |                     |<---dialog1------------------------------->|
    |                     |                     |                     |
    |                     |<======audio==============================>|
    |                     |                     |                     |
    |                     |                     |                     |
    
(*)

    |                     |                     |                     |
    |                     |                     |                     |
    |                     |                     |                     |
The following is a re-INVITE from the remote party (Bob) to add video to the existing audio call
    |                     |                     |                     |
    |                     |                     | reINVITE Alice [A/V]|
    |                     |                     |<--------------------|
    |                     | reINVITE Alice [A/V]|                     |
    |                     |<--------------------|                     |
    |                     | 100 Trying          |                     |
    |                     |-------------------->|                     |
    |                     |                     | 100 Trying          |
    |                     |                     |-------------------->|
    |                     |                     |                     |
The Desk Phone cannot handle video, but it knows that the PC can handle video, 
so the Desk Phone initiates a new video INVITE to the PC.
Alert-Info is used to control the alerting level. 
    |                     |                     |                     |
    |                     |                     |                     |
(#) | INVITE [Video]      |                     |                     |
    |        Alert-Info: whatever               |                     |
    |<--------------------|                     |                     |
    | 180                 |                     |                     |
    |-------------------->|                     |                     |
    |                     |                     |                     |
The user can answer the video call using his PC, which would result on 
200 OK with video answer being sent to the phone.
If the user chose to answer the incoming video call using his Desk Phone, 
the following REFER will be sent to the PC, before the 200 OK with the 
video answer is sent from the PC.
    |                     |                     |                     |
    | REFER Refer-To: urn:sip-action:call:answer                      |
    |<--------------------|                     |                     |
    | 200 OK              |                     |                     |
    |-------------------->|                     |                     |
    |                     |                     |                     |
    | 200 OK [Video]      |                     |                     |
    |-------------------->|                     |                     |
    |                     |                     |                     |
    |                     | 200 OK [A/V]        |                     |
    |                     |-------------------->|                     |
    |                     |                     | 200 OK [A/V]        |
    |                     |                     |-------------------->|
    |                     |                     |                     |
    |<----dialog2-------->|<---dialog1------------------------------->|
    |                     |                     |                     |
    |                     |<======audio==============================>|
    |<============================video==============================>|
    |                     |                     |                     |
    |                     |                     |                     |

Now let's assume that Alice is the side that wants to add video to the 
existing audio call. The scenario continues after the (*) above.

Alice can use her phone to add video to the existing audio call. The phone
must present a UI to Alice to allow her to do just that. If Alice chooses
to use her phone, the following REFER will be sent from the phone to the PC, 
which will instruct the PC to immediately send an INVITE with video offer

    | REFER Refer-To: urn:sip-action:call:join;dialog=dialog1;media=video
    |<--------------------|                     |                     |
    | 200 OK              |                     |                     |
    |-------------------->|                     |                     |
    |                     |                     |                     |

Alice can use her PC to add video to the existing audio call.
The PC knows that there is an existing dialog between the Desk Phone 
and Bob and present this to Alice for her to choose if she wants to 
add video to the existing audio call or not. In this case Alice chose 
to add video to the existing audio call, so the PC sends the following
request:
    |                     |                     |                     |
    |                     |                     |                     |
    | INVITE with Join [Video]                  |                     |
    |-------------------->|                     |                     |
    | 100                 |                     |                     |
    |<--------------------|                     |                     |
    |                     | re-INVITE [A/V]     |                     |
    |                     |-------------------->|                     |
    |                     |                     | re-INVITE [A/V]     |
    |                     |                     |-------------------->|
    |                     |                     | 200 OK [A/V]        |
    |                     | 200 OK [A/V]        |<--------------------|
    |                     |<--------------------|                     |
    | 200 OK [Video]      |                     |                     |
    |<--------------------|                     |                     |
    |                     |                     |                     |
    |                     |                     |                     |
    |<----dialog2-------->|<---dialog1------------------------------->|
    |                     |                     |                     |
    |                     |<======audio==============================>|
    |<============================video==============================>|
    |                     |                     |                     |
    |                     |                     |                     |
    |                     |                     |                     |

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 01 May 2011 18:09:43 -0400

Yes, this seems reasonable to me. The specific refer actions are a 
little speculative and can be debated, but for now they're just 
examples, and I think we could work them out.

I've included one suggested wording revision inline below.

	Thanks,
	Paul

P.S. While we don't necessarily need to deal with it here and now, ISTM 
it would be useful to work out some best practices for how to manage 
multiple media in order to get the best user experience. E.g.:

- when/how do devices with multiple media capabilities announce those
   capabilities? (This scenario has suggested doing so in registrations.
   Are the same capabilities announced as contact params on INVITEs,
   etc.?)

- Should media capabilities be announced in SDP, even if there is no
   intent to use them at the moment? E.g. using the SDP capneg framework,
   or perhaps by "offering" extra media with port set to zero, or with
   a=inactive?

- when forced to make an offer (by receipt of an INVITE without offer),
   what media should be offered? Should the UAS defer the decision until
   it can alert and get feedback to the alert about which media the
   callee wants to use? Or should UAs be user configurable with the media
   to initially offer, so they can offer *something* quickly.

- in the latter case, should the UAS, while alerting, provide a way
   for the user to influence which media are used in the call?
   (via another o/a before answer).

Not having anything like this opens call flows such as this one up to 
much haggling over what assumptions it makes about behavior of the UAs.

> The Desk Phone knows that the PC supports Video, while the PC knows that the Desk Phone only supports audio.

In the last sentence above, it might be clearer to say "The Desk Phone 
*learns* that the PC supports Video, while the PC *learns* that the Desk 
Phone only supports Audio."

---

From: Simon Pietro Romano <[email-masked]>
Date: Mon, 02 May 2011 13:04:16 +0200

Hi Rifaat,

my personal feeling (as an individual) is that most of the open issues 
that arose on the ML have been successfully tackled now. Indeed, this 
thread is extremely interesting and sheds light on the main features 
that any solution should provide.

With my chair hat on, I would suggest that you and Salvatore work 
together on a framework document which does not contain any pointer to 
already identified solutions, but rather highlights the issues and 
defines the requirements. Such document would actually fulfill the 
envisaged milestone of our charter. Once done with this, we can rapidly 
move to subsequent documents which start delving into the details of the 
poptential solutions.

Cheers,

Simon

Il 01/05/2011 17:41, Shekh-Yusef, Rifaat (Rifaat) ha scritto:
> _______________________________________________
> splices mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/splices
>

-- 
                             _\\|//_
                             ( O-O )
    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                     Simon Pietro Romano
               Universita' di Napoli Federico II
                  Computer Science Department
         Phone: +39 081 7683823 -- Fax: +39 081 7684219
                 e-mail: [email-masked]
           http://www.comics.unina.it/simonpietro.romano

     <<Molti mi dicono che lo scoraggiamento è l'alibi degli
    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                          oooO
    ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                           \ (    (   )
                            \_)    ) /
                                  (_/

---

From: Peter Musgrave <[email-masked]>
Date: Mon, 2 May 2011 09:45:44 -0400

Hi Rifaat, 

I think this works well. Thanks for re-stating this clearly. 

I see a couple of next steps here:
- how is in incoming call which has an initial A+V answered?
- how is an outgoing call which has an initial A+V audio created?
- if both ends are "loosely coupled" are there any optimizations or shortcuts that seem worthwhile?

I don't think there is anything too tricky about these - but they will need to be worked through. I agree with Simon that it seems time to start to capture this work in a draft. 

Regards, 

Peter Musgrave

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 2 May 2011 16:13:41 +0200

I think it is a good step forward,

the only comment I have
it is that in order to call it a "loosely coupled" scenario we have 
still to define what happens
if "Alice Desk phone" can not remain in the session for the entire 
session duration...

as the charter defines:

   The objective of this working group is to develop a framework for
   disaggregated media in "loosely-coupled" scenarios, where no single
   device needs to remain in the session for its entire duration and no
   single device needs to act as a master.

/Sal

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 02 May 2011 15:54:03 -0400

> single device needs to act as a master.

Well, one obvious thing to do is, when Alice's desk phone needs to 
leave, it can do a transfer to get out, leaving Bob talking to the PC. 
(This may not be very satisfactory unless the PC can take over the 
audio.) And of course it isn't sufficient if the phone departs unexpectedly.

Another possibility is for one of Alice's devices to *attempt* to set up 
a "conference" with Bob's phone as the focus. That of course requires 
Alice to depend upon Bob's device to have the necessary capabilities. 
IMO a solution that *depends* on that is a bad solution. But it could be 
an optional alternative.

So, for instance, perhaps we start with a call flow such as has been 
presented, that doesn't depend on Bob to do anything special. Once that 
is up and running, if Alice's devices are concerned about their 
stability and want to delegate the coordination to Bob, one of them can 
initiate a call flow to transfer the focus responsibility to Bob. (It 
may take an interesting negotiation to decide which device is best 
suited to this.)

	Thanks,
	Paul

>> I don't think there is anything too tricky about these - but they will
>> need to be worked through. I agree with Simon that it seems time to
>> start to capture this work in a draft.
>>
>> Regards,
>>
>> Peter Musgrave
>>
>>> The only open issue that I am aware of is the issue of what to
>>> present to the user on the PC when the phone initiates a video call
>>> to the PC (see (#) below).
>>>

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Mon, 2 May 2011 20:53:44 -0400

Thanks Paul,

Yes, the actions are just examples and they are open for discussion.
The questions you listed below are good questions that must be answered in a future document that will define the overall solution.

Regards,
 Rifaat

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Sunday, May 01, 2011 6:10 PM
> To: Shekh-Yusef, Rifaat (Rifaat)
> Cc: [email-masked]
> Subject: Re: [splices] Answering a Call Using Two Separate Devices proposal
>
> > The only open issue that I am aware of is the issue of what to present to
> the user on the PC when the phone initiates a video call to the PC (see (#)
> below).
> >

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Mon, 2 May 2011 20:54:55 -0400

Thanks Simon,

I will work with Sal on the new document.

Regards,
 Rifaat

> From: Simon Pietro Romano [mailto:[email-masked]]
> Sent: Monday, May 02, 2011 7:04 AM
> To: Shekh-Yusef, Rifaat (Rifaat); Salvatore Loreto
> Cc: Paul Kyzivat; [email-masked]

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Mon, 2 May 2011 20:58:20 -0400

Thanks Peter,

Yes, these are good next steps. I started working on some of those and I will post them on the list for discussion later on.

Regards,
 Rifaat

> From: Peter Musgrave [mailto:[email-masked]]
> Sent: Monday, May 02, 2011 9:46 AM
> I don't think there is anything too tricky about these - but they will need to
> be worked through. I agree with Simon that it seems time to start to capture
> this work in a draft.
> 
> Regards,
> 
> Peter Musgrave
>

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Mon, 2 May 2011 21:11:28 -0400

How about the following:

   Alice                 Alice                Proxy                  Bob
    PC                 Desk Phone
    |                     |                     |                     |
Alice is on a call with Bob as described below (the result of the
previously discussed flows)
    |                     |                     |                     |
    |<----dialog2-------->|<---dialog1------------------------------->|
    |                     |                     |                     |
    |                     |<======audio==============================>|
    |<============================video==============================>|
    |                     |                     |                     |
Alice's devices have a keep-alive mechanism that allows each one of them
to discover if the other is gone (the mechanism is TBD).
Let us assume that the PC discovers that the phone is gone. The PC is
aware of the dialog with Bob because of the subscription to the dialog
event package. The PC then clears dialog2, but Bob's phone is not yet
aware that Alice's phone is gone and it still has dialog1.
The PC can do the following:
    |                     |                     |                     |
    |                     |                     |                     |
    | INVITE Replaces dialog1                   |                     |
    |------------------------------------------>|                     |
    |                     |                     | INVITE Replaces dialog1
    |                     |                     |-------------------->|
    |                     |                     | BYE                 |
    |                     |    BYE              |<--------------------|
    |                     | x <-----------------|                     |
    |                     |                     | 200 OK              |
    |                     |                     |<--------------------|
    | 200 OK              |                     |                     |
    |<------------------------------------------|                     |
    | ACK                 |                     |                     |
    |------------------------------------------>|                     |
    |                     |                     | ACK                 |
    |                     |                     |-------------------->|
    |                     |                     |                     |

Regards,
 Rifaat

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Salvatore Loreto
> Sent: Monday, May 02, 2011 10:14 AM
> To: [email-masked]
> > I don't think there is anything too tricky about these - but they will need
> to be worked through. I agree with Simon that it seems time to start to
> capture this work in a draft.
> >
> > Regards,
> >
> > Peter Musgrave
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 02 May 2011 21:46:04 -0400

The trouble with this is that it depends on the PC discovering the 
problem before Bob does. If Bob notices first then he will abort the call.

	Thanks,
	Paul

On 5/2/2011 9:11 PM, Shekh-Yusef, Rifaat (Rifaat) wrote:
>      |                     | x<-----------------|                     |
>      |                     |                     | 200 OK              |

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Tue, 3 May 2011 11:28:08 -0400

We should be able to come up with a mechanism that allows for a quick failure discovery between the federated devices that minimizes the chances of the remote party discovering the failure before the other federated device.

But I agree with you that no matter how good is the discovery mechanism, it will not completely eliminate the remote party chances.

Regards,
 Rifaat

> Paul Kyzivat
> Sent: Monday, May 02, 2011 9:46 PM
> To: [email-masked]
> need
> >>>> In the following flow, I have tried to incorporate all the feedback that
> I
> >> received so far.
> >>>> Both Alice's devices subscribe to the reg event package, which allows
> each
> >> device to
> >>>>      | REFER Refer-To: urn:sip-
> action:call:answer;transducer=speaker|headset
> >>>>      | REFER Refer-To: urn:sip-
> action:call:join;dialog=dialog1;media=video