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

[Paul Kyzivat <[e-mail]>]

On 5/2/2011 10:13 AM, Salvatore Loreto wrote:
> 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.

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

> /Sal
>
> On 5/2/11 3:45 PM, Peter Musgrave wrote:
>> 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
>>
>> On 2011-05-01, at 11:41 AM, Shekh-Yusef, Rifaat (Rifaat) wrote:
>>
>>> 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==============================>|
>>> | | | |
>>> | | | |
>>> | | | |
>>>
>>>
>>>
>>> _______________________________________________
>>> splices mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/splices
>> _______________________________________________
>> splices mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/splices
> _______________________________________________
> splices mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/splices
>