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

[Paul Kyzivat <[e-mail]>]

On 4/22/2011 6:42 PM, Shekh-Yusef, Rifaat (Rifaat) wrote:
>
>
>> -----Original Message-----
>> From: Peter Musgrave [mailto:[e-mail]]
>> Sent: Friday, April 22, 2011 5:00 PM
>> To: Shekh-Yusef, Rifaat (Rifaat)
>> Cc: Paul Kyzivat; [e-mail]
>> Subject: Re: [splices] Answering a Call Using Two Separate Devices proposal
>>
>> Hi Rifaat,
>>
>> Overall I think this works.
>>
>> 1) Use of INVITE from phone to PC to signal addition of video:
>>
>> The current mechanism (with an new INVITE to the PC from the phone) seems
>> likely to me to cause the call to ring on the PC - and I think having a call
>> that is already in progress ring a second device as a means of signalling the
>> availability of video will not be the ideal user experience
>>
> I personally think it is a reasonable user experience, but I can go either way on this.
> Do other people have an opinion on this?

IMO when the offer to escalate to video is received, the user will 
typically need *some* kind indication and control. Absent some 
predefined policy, it seems reasonable to "alert", though its probably 
not reasonable to alert via a loud jangly noise. :-)

The Alert-Info urn mechanism is designed to support this sort of thing.
And I think that is preferable to the PC trying to "figure out" what it 
should do.

Policy can bypass this in various ways:
- accept video by default, but in recvonly mode until the user
   does something overt to initiate sending video

- accept video by default, but send some canned image rather
   than live video of the user.

>> When the accept on the PC results in the:
>>      | REFER Refer-To: urn:sip-action:call:answer
>>                    |
>> message from the PC to the phone does it make sense for the PC to subscribe to
>> the dialog-state of the call at this point? (In fact would it hurt to have the
>> coupled devices always subscribed to each other's dialog state?)
>>
> I just wanted to optimize the use of these subscriptions and avoid any unnecessary ones until it is really needed.
> But in general, it seems like a reasonable approach to me.
> Anybody else has some thoughts on this?

I think this can vary.
Some might not want their PC doing stuff like this all the time.
But if you permit it, you can get a nicer user experience.

>> Then when a reINVITE with video is offered the PC will receive a notification
>> and it can offer the user a choice to accept the call there - with some pop-up
>> and beep (or whatever). If the user accepts then it could send a REFER to the
>> phone to make it offer video to the PC.

IIUC, you are then back to trying to do session establishment with 
sub/not - bad idea.

Perhaps it could REFER the phone to get it to send an invite to the PC, 
but that gets complicated.

>> (I first thought of using an INVITE
>> with JOIN from PC to phone - but then the video offer comes from the PC and
>> forces the phone to build a video answer based on the PCs offer - which seems
>> a bad idea).

Not evident why that is so bad.
Or the PC could send an offerless invite to the phone, and the 
capabilities in the contact would let the phone know to offer video.

> It complicates matters a little bit, but it would work.

>> 2) As an aside, how does lipsync on sending and playout get handled in this
>> configuration?
>>
> I have some thoughts around this, but not enough to be able to put a proposal on the table.
> If you or anybody else has some thoughts on this, I would appreciate it if you can share it with us.

That could be difficult. Not a subject I know about.

	Thanks,
	Paul