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

["Shekh-Yusef, Rifaat (Rifaat)" <[e-mail]>]

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

(or perhaps when
> the device sees an INVITE with video and no audio it knows not to alert the
> user in the usual way?)
> 
This might be one way to address that.


> One alternative would be:
> 
> 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? 

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

> Regards,
> 
> Peter Musgrave
>