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

Paul Kyzivat <pkyzivat@cisco.com> Fri, 22 April 2011 17:26 UTC

Return-Path: <pkyzivat@cisco.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 5C4E4E07DE for <splices@ietfc.amsl.com>; Fri, 22 Apr 2011 10:26:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.443
X-Spam-Level:
X-Spam-Status: No, score=-110.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 xjG6YcoFxlNt for <splices@ietfc.amsl.com>; Fri, 22 Apr 2011 10:26:43 -0700 (PDT)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfc.amsl.com (Postfix) with ESMTP id F2C10E07CB for <splices@ietf.org>; Fri, 22 Apr 2011 10:26:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=12449; q=dns/txt; s=iport; t=1303493203; x=1304702803; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=+MPcWi93xG4BlAxcO//TTSdJP7hFUBipkRg64QBbjlQ=; b=MVag8xQS7obWd1xqqkwPpR8dT01drvwEus40DkTdB6AqzANShi1YspqQ XHny1n/halMnbOyR4YJ3agbv4nv1v/wJ1jesOJLAe6sj9hGuvCVnnScMu u18SJzx6FfUvTiYKrfUgQTnQ3O/t5RITiNXUufEHlc8FyVyqmLOa6IATj g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAMa5sU2rRDoH/2dsb2JhbAClXXeIcKAJnE2FdgSOLYQH
X-IronPort-AV: E=Sophos;i="4.64,254,1301875200"; d="scan'208";a="300142514"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-3.cisco.com with ESMTP; 22 Apr 2011 17:26:42 +0000
Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3MHQfjl009563 for <splices@ietf.org>; Fri, 22 Apr 2011 17:26:42 GMT
Message-ID: <4DB1BA51.4080307@cisco.com>
Date: Fri, 22 Apr 2011 13:26:41 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: splices@ietf.org
References: <6369CB70BFD88942B9705AC1E639A33822CAF444FA@DC-US1MBEX4.global.avaya.com>
In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CAF444FA@DC-US1MBEX4.global.avaya.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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 17:26:44 -0000

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.

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

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

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

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

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

	Thanks,
	Paul