Re: [splices] Answering a Call Using Two Separate Devices proposal
"Shekh-Yusef, Rifaat (Rifaat)" <rifatyu@avaya.com> Fri, 22 April 2011 19:09 UTC
Return-Path: <rifatyu@avaya.com>
X-Original-To: splices@ietfc.amsl.com
Delivered-To: splices@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 18AD6E076D for <splices@ietfc.amsl.com>; Fri, 22 Apr 2011 12:09:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.266
X-Spam-Level:
X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHtdRBKru+tc for <splices@ietfc.amsl.com>; Fri, 22 Apr 2011 12:09:19 -0700 (PDT)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfc.amsl.com (Postfix) with ESMTP id 4E71EE076F for <splices@ietf.org>; Fri, 22 Apr 2011 12:09:19 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvYAAFMtcU2HCzI1/2dsb2JhbACYKo47dKR5ApkWhWEEkAw
X-IronPort-AV: E=Sophos;i="4.64,255,1301889600"; d="scan'208";a="243008231"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 22 Apr 2011 15:09:09 -0400
X-IronPort-AV: E=Sophos;i="4.64,255,1301889600"; d="scan'208";a="642263107"
Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 22 Apr 2011 15:09:08 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.201]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Fri, 22 Apr 2011 15:09:08 -0400
From: "Shekh-Yusef, Rifaat (Rifaat)" <rifatyu@avaya.com>
To: Paul Kyzivat <pkyzivat@cisco.com>, "splices@ietf.org" <splices@ietf.org>
Date: Fri, 22 Apr 2011 15:09:06 -0400
Thread-Topic: [splices] Answering a Call Using Two Separate Devices proposal
Thread-Index: AcwBEnax3sge/7f4RCuIRU1p6cKrvgACtATA
Message-ID: <6369CB70BFD88942B9705AC1E639A33822CAF4465A@DC-US1MBEX4.global.avaya.com>
References: <6369CB70BFD88942B9705AC1E639A33822CAF444FA@DC-US1MBEX4.global.avaya.com> <4DB1BA51.4080307@cisco.com>
In-Reply-To: <4DB1BA51.4080307@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [splices] Answering a Call Using Two Separate Devices proposal
X-BeenThere: splices@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" <splices.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/splices>, <mailto:splices-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/splices>
List-Post: <mailto:splices@ietf.org>
List-Help: <mailto:splices-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/splices>, <mailto:splices-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Apr 2011 19:09:21 -0000
> -----Original Message----- > From: splices-bounces@ietf.org [mailto:splices-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Friday, April 22, 2011 1:27 PM > To: splices@ietf.org > Subject: Re: [splices] Answering a Call Using Two Separate Devices proposal > > > > On 4/22/2011 12:02 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > 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 > > You mean Alice used her PC to instruct her phone to answer the call. > For the point you are making, it would be equally fine if she had simply > picked up the phone. > Yes. > How do you assume the phone is rendering the audio when instructed to > answer this way. Sending/receiving from the handset isn't very useful > when its on the cradle. Do you assume speaker phone, or that Alice has a > headset connected to the phone? (If the latter, why not simply connect > the headset to the PC?) > My initial thought was to use the speaker phone, but you raise a good point here. Maybe we need to add a parameter to the URN to indicate which transducer to use, e.g REFER Refer-To: urn:sip-action:call:answer;transducer=speaker|headset Alice answered the call on her Desk Phone because she knows it has a better audio quality. Why do you want to connect the headset to the PC? > > | | | | > > | 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. > > Seems reasonable. > > > | | | | > > | 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: > > I don't fully understand what you have in mind here. > Somehow Alice must become aware that video has been offered and she must > do something to accept it. From the diagram I gather that you expect > some sort of alert on the PC, so answering it from the PC makes sense. > > For Alice to answer from the phone there must be some way to do so. > Presumably there would have to be some UI on the phone providing a means > to "accept video". Most likely that means there will be some sort of > alerting on the phone too. (But maybe not *ringing*.) > Yes, that is exactly what I had in mind. > > | | | | > > | 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==============================>| > > | | | | > > | | | | > > Otherwise the above all makes sense. > > > 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 > > This doesn't quite make sense to me - at least the wording. > The PC has a fairly rich UI, and it could *already* know about the call > in progress. And certainly Alice knows she wants to add video to an > existing call rather than make a new call. So I would expect the > interaction between Alice and her PC to first be one of discovering the > existing call that *could* be joined, and then requesting to join. > (Alternatively Alice might decide she doesn't want to join that call - > that she wants to make an independent call from the PC to somebody else.) > Remember that this scenario starts after the (*) above, which means that the PC is not aware of the existing call between the Desk Phone and Bob. Of course Alice is aware of that call and expects the PC to discover that when Alice clicks on her PC and opens the UI that allows here to initiate a video call. > > | | | | > > | 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 | | > > |-------------------->| | | > > I would tweak this - the invite should use Join. > Yeah, good point. > > | 100 | | | > > |<--------------------| | | > > | | re-INVITE [A/V] | | > > | |-------------------->| | > > | | | re-INVITE [A/V] | > > | | |-------------------->| > > | | | 200 OK [A/V] | > > | | 200 OK [A/V] |<--------------------| > > | |<--------------------| | > > | 200 OK [Video] | | | > > |<--------------------| | | > > | | | | > > | | | | > > |<----dialog2-------->|<---dialog1------------------------------->| > > | | | | > > | |<======audio==============================>| > > |<============================video==============================>| > > | | | | > > | | | | > > | | | | > > Otherwise this sounds right on to me. > > Its an example of what I have been talking about all along. You've > described it well. > Ok, great! > Thanks, > Paul > _______________________________________________ > splices mailing list > splices@ietf.org > https://www.ietf.org/mailman/listinfo/splices
- [splices] Answering a Call Using Two Separate Dev… Shekh-Yusef, Rifaat (Rifaat)
- Re: [splices] Answering a Call Using Two Separate… Paul Kyzivat
- Re: [splices] Answering a Call Using Two Separate… Shekh-Yusef, Rifaat (Rifaat)
- Re: [splices] Answering a Call Using Two Separate… Peter Musgrave
- Re: [splices] Answering a Call Using Two Separate… Shekh-Yusef, Rifaat (Rifaat)
- Re: [splices] Answering a Call Using Two Separate… Peter Musgrave
- Re: [splices] Answering a Call Using Two Separate… Paul Kyzivat
- Re: [splices] Answering a Call Using Two Separate… Paul Kyzivat
- Re: [splices] Answering a Call Using Two Separate… Peter Musgrave
- Re: [splices] Answering a Call Using Two Separate… gao.yang2
- Re: [splices] Answering a Call Using Two Separate… Paul Kyzivat
- Re: [splices] Answering a Call Using Two Separate… Elwell, John
- Re: [splices] Answering a Call Using Two Separate… Shekh-Yusef, Rifaat (Rifaat)
- Re: [splices] Answering a Call Using Two Separate… Shekh-Yusef, Rifaat (Rifaat)
- Re: [splices] Answering a Call Using Two Separate… Paul Kyzivat
- Re: [splices] Answering a Call Using Two Separate… Elwell, John
- Re: [splices] Answering a Call Using Two Separate… Shekh-Yusef, Rifaat (Rifaat)
- Re: [splices] Answering a Call Using Two Separate… Paul Kyzivat
- Re: [splices] Answering a Call Using Two Separate… Simon Pietro Romano
- Re: [splices] Answering a Call Using Two Separate… Peter Musgrave
- Re: [splices] Answering a Call Using Two Separate… Salvatore Loreto
- Re: [splices] Answering a Call Using Two Separate… Paul Kyzivat
- Re: [splices] Answering a Call Using Two Separate… Shekh-Yusef, Rifaat (Rifaat)
- Re: [splices] Answering a Call Using Two Separate… Shekh-Yusef, Rifaat (Rifaat)
- Re: [splices] Answering a Call Using Two Separate… Shekh-Yusef, Rifaat (Rifaat)
- Re: [splices] Answering a Call Using Two Separate… Shekh-Yusef, Rifaat (Rifaat)
- Re: [splices] Answering a Call Using Two Separate… Paul Kyzivat
- Re: [splices] Answering a Call Using Two Separate… Shekh-Yusef, Rifaat (Rifaat)