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

[Paul Kyzivat <[e-mail]>]

On 4/25/2011 12:26 AM, [e-mail] wrote:
> 
> Hi,
> 
> The base of the handling one session between two separate devicesis to 
> coordinate the two separate devices.
> 
> Comparing with the 3pcc, refer 
> action(draft-yusef-dispatch-action-ref-00) is a new way. And I think it 
> is interesting.
> 
> But considering Alice can handle the two devicesat the same time, I 
> think Alice can answer the call using PC without the refer-action 
> indication by the desk phone.

I'm not sure what you mean here.
In the original scenario, I think "Alice answers the call using the PC"
means that Alice interacts with the PC in order to cause the desk phone
to answer.

Without using something like refer-action, the PC could only answer the
call itself, thus putting audio on the PC rather than the phone. That's
fine if its what Alice wants, but its a different scenario.

> Then, during the adding video stream stage, Alice's desk phone send 
> INVITE(with video) to Alice's PC. I think Alice PC can accept the INVITE 
> request by Alice's manual action, while not by the refer-action indication.

Yes, that is certainly possible.
What is tricky is what appears on the UI of the PC in this circumstance.
Some possibilities:
- appears as a "normal" (new) video call from Alice
- appears as a "normal" (new) video call from Bob
- appears as something special - a request for video support
  from the desk phone.

To get this to be anything but the first of the above will require
*something* we don't currently have.

> One discussion here: the INVITE sent by Alice's desk phone would make 
> the SDP from Bob's Re-INVITE. This is something like 3pcc,

Yes.

> a simple desk 
> phone can not have such feature. So, when the session has been anchored 
> on some traditional SIP desk phone, AS(3pcc) seams MUST be need.

*something* with the intelligence to coordinate multiple devices, and
with an awareness of what devices are available to be coordinated, must
be present.

Anybody who wants such a capability will need to arrange to have a
suitable device available. It could be a UA owned by the user (e.g. a PC
with sufficient software, or a smart phone), or it could be a service
residing at or near the user's registrar. In this respect it isn't much
different from an answering machine.

	Thanks,
	Paul

> Thanks,
> 
> Gao
> 
> 
> [e-mail] 写于 2011-04-23 00:02:56:
> 
>  > Hi,
>  >
>  > I would like to discuss the following proposal for addressing the
>  > scenario of answering a call using two separate devices:
>  >
>  >
>  > 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 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 answer the call
>  > | | | |
>  > | REFER Refer-To: urn:sip-action:call:answer |
>  > |-------------------->| | |
>  > | 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
>  > | | | |
>  > | | | INVITE Alice [A/V] |
>  > | | |<--------------------|
>  > | | INVITE 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.
>  > | | | |
>  > | INVITE [Video] | | |
>  > |<--------------------| | |
>  > | 180 | | |
>  > |-------------------->| | |
>  > | | | |
>  > The user can either answer the video call using his PC, or his Desk 
> Phone.
>  > If the user chose to answer the incoming video call using his Desk Phone,
>  > the following REFER will be sent to 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 uses her PC and attempt to initiate a new video call. Because the
>  > PC is aware that another device is logged in using the same AOR, it will
>  > try to find if there is any existing dialog on the other device by
>  > subscribing to the dialog event package
>  > | | | |
>  > | SUBSCRIBE dialog | | |
>  > |-------------------->| | |
>  > | 200 OK | | |
>  > |<--------------------| | |
>  > | NOTIFY | | |
>  > |<--------------------| | |
>  > | OK | | |
>  > |-------------------->| | |
>  > | | | |
>  > The PC discovers 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
>  > attach the new video call to the existing audio call or not. In this
>  > case Alice chose to attach the new video call to the existing audio call
>  > | | | |
>  > | | | |
>  > | INVITE [Video] | | |
>  > | Target-Dialog: dialog1 | |
>  > |-------------------->| | |
>  > | 100 | | |
>  > |<--------------------| | |
>  > | | re-INVITE [A/V] | |
>  > | |-------------------->| |
>  > | | | re-INVITE [A/V] |
>  > | | |-------------------->|
>  > | | | 200 OK [A/V] |
>  > | | 200 OK [A/V] |<--------------------|
>  > | |<--------------------| |
>  > | 200 OK [Video] | | |
>  > |<--------------------| | |
>  > | | | |
>  > | | | |
>  > |<----dialog2-------->|<---dialog1------------------------------->|
>  > | | | |
>  > | |<======audio==============================>|
>  > |<============================video==============================>|
>  > | | | |
>  > | | | |
>  > | | | |
>  >
>  >
>  > Regards,
>  > Rifaat
>  >
>  > _______________________________________________
>  > splices mailing list
>  > [e-mail]
>  > https://www.ietf.org/mailman/listinfo/splices
>  >
> 
> --------------------------------------------------------
> ZTE  Information  Security  Notice:  The  information  contained  in  this  mail  is  solely  property  of  the  sender's  organization.  This  mail  communication  is  confidential.  Recipients  named  above  are  obligated  to  maintain  secrecy  and  are  not  permitted  to  disclose  the  contents  of  this  communication  to  others.
> This  email  and  any  files  transmitted  with  it  are  confidential  and  intended  solely  for  the  use  of  the  individual  or  entity  to  whom  they  are  addressed.  If  you  have  received  this  email  in  error  please  notify  the  originator  of  the  message.  Any  views  expressed  in  this  message  are  those  of  the  individual  sender.
> This  message  has  been  scanned  for  viruses  and  Spam  by  ZTE  Anti-Spam  system.
> 
> 
> 
> _______________________________________________
> splices mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/splices