[splices] draft-loreto-splices-disaggregated-media-02: competing protocol analysis
Adam Roach <adam@nostrum.com> Tue, 26 July 2011 18:26 UTC
Return-Path: <adam@nostrum.com>
X-Original-To: splices@ietfa.amsl.com
Delivered-To: splices@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5591E11E8082 for <splices@ietfa.amsl.com>; Tue, 26 Jul 2011 11:26:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.263
X-Spam-Level:
X-Spam-Status: No, score=-102.263 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCOrU6BjQmeN for <splices@ietfa.amsl.com>; Tue, 26 Jul 2011 11:26:31 -0700 (PDT)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 663465E8001 for <splices@ietf.org>; Tue, 26 Jul 2011 11:26:30 -0700 (PDT)
Received: from dhcp-1418.meeting.ietf.org ([130.129.20.24]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p6QIQNR9030458 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 26 Jul 2011 13:26:24 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <4E2F06CF.4080403@nostrum.com>
Date: Tue, 26 Jul 2011 14:26:23 -0400
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: draft-loreto-splices-disaggregated-media@tools.ietf.org, splices@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 130.129.20.24 is authenticated by a trusted mechanism)
Subject: [splices] draft-loreto-splices-disaggregated-media-02: competing protocol analysis
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: Tue, 26 Jul 2011 18:26:32 -0000
Section 4.1.4 of draft-loreto-splices-disaggregated-media-02 currently describes a (rather clever) way to move a SIP session from one client in a disaggregated system to another, so as to allow the device that owns the SIP association with the far-end to be removed from the call. I like it. It actually does a good job of showing that the system in question actually isn't an all-entities-are-equal federation of peer devices. In fact, it *does* have a critical central controller of sorts, and we need to be able to take steps to move that critical central controller functionality around. (This is inherent in any system that requires no support from the far end, since someone needs to own the SIP session). However, then we get into section 5. I'm not sure what section 5 is trying to talk about, since it discusses a model that is not relevant to any of the described solutions. Even the INVOKE-based one being proposed by this document. Even more interestingly, I note that the transfer-of-control approach in section 4.1.4 can be applied equally well to any central-control model. MBUS, for example. Or MEGACO. So the statement "transferring the SIP dialog from a controller to a new one using REFER and Replaces is complex and requires support from the far end" isn't really true -- everyone can use the section 4.1.4 INVITE/Replaces approach to move control around. The INVOKE-based approach described in this document is hardly unique in this respect. On top of this, the analysis in section 3.1.1 and 3.2.1 both have the rather gonzo "issue" of "you need to implement the protocol." That's true of *any* solution -- INVOKE included -- so it's hardly a distinguishing factor. If you want to try to quantify the ease of implementation, that might be a useful discussion. But simply saying "you have to implement something" is always, always, always true for a new mechanism. So, once you make a more honest analysis of the other protocols, section 3.1.1 actually ends up looking like this: The Mbus protocol introduces the following issue: Local network: Mbus uses multicast with a limited scope for message transport. The multicast limits the coordination mechanism only to groups of devices that are connected to a local network. So Mbus can be used in a disaggregated media scenario only if all the different devices under the user control, or at least the one the user wants to involve in the communication, are attached to the same local network. And section 3.2.1 looks like this: The Megaco protocol introduces the following issues: None. /a
- [splices] draft-loreto-splices-disaggregated-medi… Adam Roach
- Re: [splices] draft-loreto-splices-disaggregated-… Worley, Dale R (Dale)
- Re: [splices] draft-loreto-splices-disaggregated-… Salvatore Loreto
- Re: [splices] draft-loreto-splices-disaggregated-… Worley, Dale R (Dale)