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

Peter Musgrave <peter.musgrave@magorcorp.com> Sat, 23 April 2011 11:17 UTC

Return-Path: <peter.musgrave@magorcorp.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 93755E066C for <splices@ietfc.amsl.com>; Sat, 23 Apr 2011 04:17:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 Y0ewSL35h4ex for <splices@ietfc.amsl.com>; Sat, 23 Apr 2011 04:17:21 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfc.amsl.com (Postfix) with ESMTP id 08ACFE0660 for <splices@ietf.org>; Sat, 23 Apr 2011 04:17:20 -0700 (PDT)
Received: by iwn39 with SMTP id 39so1217958iwn.31 for <splices@ietf.org>; Sat, 23 Apr 2011 04:17:20 -0700 (PDT)
Received: by 10.43.60.200 with SMTP id wt8mr2188825icb.358.1303557440663; Sat, 23 Apr 2011 04:17:20 -0700 (PDT)
Received: from [192.168.1.109] ([204.237.32.134]) by mx.google.com with ESMTPS id 13sm1455044ibo.25.2011.04.23.04.17.17 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 23 Apr 2011 04:17:18 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Peter Musgrave <peter.musgrave@magorcorp.com>
In-Reply-To: <4DB21850.4000509@cisco.com>
Date: Sat, 23 Apr 2011 07:17:16 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <50D5201E-A013-4EF5-AA6C-CA7D007B5BFF@magorcorp.com>
References: <6369CB70BFD88942B9705AC1E639A33822CAF444FA@DC-US1MBEX4.global.avaya.com> <4DB1BA51.4080307@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CAF4465A@DC-US1MBEX4.global.avaya.com> <BF60C410-7062-4824-92F3-7F655986ECA3@magorcorp.com> <6369CB70BFD88942B9705AC1E639A33822CAF44765@DC-US1MBEX4.global.avaya.com> <4DB21850.4000509@cisco.com>
To: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Apple Mail (2.1084)
Cc: "splices@ietf.org" <splices@ietf.org>
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: Sat, 23 Apr 2011 11:17:21 -0000

On 2011-04-22, at 8:07 PM, Paul Kyzivat wrote:

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

In the absence of this subscription ISTM the phone cannot know the PC is present (or that the call application is running). In this case would it send the INVITE to the PC and then use the lack of a TRYING to conclude that video should be rejected ?


I agree with your point that putting SUB/NOT in the session establishment path when adding video is not a good idea.

Peter