[Sipping] comments on draft-loreto-sipping-context-id-requirements-01.txt
Jonathan Rosenberg <jdrosen@cisco.com> Mon, 23 March 2009 05:48 UTC
Return-Path: <jdrosen@cisco.com>
X-Original-To: sipping@core3.amsl.com
Delivered-To: sipping@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CDC63A6AB8 for <sipping@core3.amsl.com>; Sun, 22 Mar 2009 22:48:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.558
X-Spam-Level:
X-Spam-Status: No, score=-6.558 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fr8fr-BKLy2Z for <sipping@core3.amsl.com>; Sun, 22 Mar 2009 22:48:23 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 323683A6A98 for <sipping@ietf.org>; Sun, 22 Mar 2009 22:48:23 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.38,406,1233532800"; d="scan'208";a="272273850"
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 23 Mar 2009 05:49:12 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n2N5nCd2019754 for <sipping@ietf.org>; Sun, 22 Mar 2009 22:49:12 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2N5nCAx022721 for <sipping@ietf.org>; Mon, 23 Mar 2009 05:49:12 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Mar 2009 22:49:12 -0700
Received: from [10.21.77.250] ([10.21.77.250]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Mar 2009 22:49:12 -0700
Message-ID: <49C6DE1C.1090008@cisco.com>
Date: Sun, 22 Mar 2009 20:55:56 -0400
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: IETF Sipping List <sipping@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 23 Mar 2009 05:49:12.0707 (UTC) FILETIME=[17E65D30:01C9AB7B]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3679; t=1237787352; x=1238651352; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20<jdrosen@cisco.com> |Subject:=20comments=20on=20draft-loreto-sipping-context-id -requirements-01.txt |Sender:=20; bh=wfcJJ3B9jfJwUIc1XkFYChANvEk4bprdAWmdpz+yjrA=; b=ChuUavgc9VNnPyTe0j6ER95ci4+uXzSDFyKNXxk5AAPr+fQCeJszaOs+E4 d+98goUfPuIbXKz4Pq+LxZRCBjzqniId30IjGVjQFHzlE9dy19ki5C9Lx927 5qs54XK1ml;
Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; );
Subject: [Sipping] comments on draft-loreto-sipping-context-id-requirements-01.txt
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipping>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Mar 2009 05:48:24 -0000
Thanks for continuing to work this, Salvatore. My main comment, as others have commented, is that the draft provides a great set of use cases. However, it makes the fundamental assumption that the right way to solve this is by having multiple dialogs from user A to user B, and then have them correlated. I am *far* from convinced this is the right solution. So, focusing strictly on requirements, I'd like to see this document retitled to something like, "Requirements for Supporting Disaggregated Media", and keep the use cases, except delete the bits that suggest that the problem is multiple dialogs. For example, in section 2.1, the first two paragraphs are good, but the last two *assume* the multiple dialog solution. Other suggestions for similar use cases: * voice/video from a deskphone and application sharing from PC * voice from a deskphone and video to/from a TV attached to a set top box with a camera * the UI for the call on a mobile phone but the audio coming out of a speakerphone in a room There are lots more. I think the draft just should enumerate these. The requirement, then, is a mechanism which allows these use cases. I personally think that the solution should be *completely invisible* to the far end of the call. In all cases, all of the various devices under Alice's control (where Alice is the one with a multiplicity of devices) need some kind of enhancement to make this work; I would very much like to avoid the need for Bob to do *anything* to make this work. The reason is simple: its much, much easier for a user to upgrade (or their provier to upgrade) the devices under their control to get a feature that benefits them, than it is to require *everyone else* to upgrade in order to get a feature to work which benefits me. The document has this requiremnt: REQ3 UAs that do not implement the correlation mechanism and, thus, do not understand the correlation information they received should be able to handle the individual SIP dialogs that were supposed to be correlated as well as possible. That is, the correlation mechanism should not keep them from trying to handle the SIP dialogs. this is not nearly strong enough. I think the real requirement is: REQ3: The mechanism should not require any changes to the far side of the session. I also don't think 3pcc is a particularly good solution either; besides the issues raised in the threads about requiring one device to be controller and the resulting complications, it also results in a really suboptimal user experience because the slave phones think this is just a normal call when its not. As a simple example, the caller ID on one of the slave phones would probably show the controller and not the far end. As another example, consider a PC doing video and audio on the hardphone. What if the hardphone can also do video, and the user hits the video button on the phone? Most likely this creates two video streams. Ugh. Indeed, the hardphone would ideally indicate that there already WAS video in progress, but on a PC. All of this means you can't really just 'fool' the slave phone into sending media somewhere - you really want it to be much smarter about this situation and be well aware that there is disaggregated media. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 111 Wood Avenue South Cisco Fellow Iselin, NJ 08830 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com
- [Sipping] comments on draft-loreto-sipping-contex… Jonathan Rosenberg
- Re: [Sipping] comments on draft-loreto-sipping-co… Paul Kyzivat
- Re: [Sipping] comments ondraft-loreto-sipping-con… Elwell, John