Re: [splices] draft-loreto-splices-disaggregated-media-00

Salvatore Loreto <salvatore.loreto@ericsson.com> Mon, 29 November 2010 15:21 UTC

Return-Path: <salvatore.loreto@ericsson.com>
X-Original-To: splices@core3.amsl.com
Delivered-To: splices@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A37AB28C126 for <splices@core3.amsl.com>; Mon, 29 Nov 2010 07:21:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.556
X-Spam-Level:
X-Spam-Status: No, score=-106.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 aNrd-0kRns8b for <splices@core3.amsl.com>; Mon, 29 Nov 2010 07:21:54 -0800 (PST)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 6436028C12B for <splices@ietf.org>; Mon, 29 Nov 2010 07:21:54 -0800 (PST)
X-AuditID: c1b4fb3d-b7b8cae0000016b1-e0-4cf3c557939e
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 2A.8C.05809.755C3FC4; Mon, 29 Nov 2010 16:23:03 +0100 (CET)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.2.234.1; Mon, 29 Nov 2010 16:23:02 +0100
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 27E102A86; Mon, 29 Nov 2010 17:23:02 +0200 (EET)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D9C994FE7F; Mon, 29 Nov 2010 17:23:01 +0200 (EET)
Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 83DFB4E758; Mon, 29 Nov 2010 17:23:01 +0200 (EET)
Message-ID: <4CF3C555.6080501@ericsson.com>
Date: Mon, 29 Nov 2010 17:23:01 +0200
From: Salvatore Loreto <salvatore.loreto@ericsson.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: "Elwell, John" <john.elwell@siemens-enterprise.com>
References: <4C92532D.4030802@ericsson.com> <4C926390.1090108@cisco.com> <4CE53969.1070906@ericsson.com> <A444A0F8084434499206E78C106220CA038EE02081@MCHP058A.global-ad.net>
In-Reply-To: <A444A0F8084434499206E78C106220CA038EE02081@MCHP058A.global-ad.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: AAAAAA==
Cc: "splices@ietf.org" <splices@ietf.org>
Subject: Re: [splices] draft-loreto-splices-disaggregated-media-00
X-BeenThere: splices@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" <splices.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Mon, 29 Nov 2010 15:21:57 -0000

Hi John,

On 11/26/10 1:10 PM, Elwell, John wrote:
> I still don't like the fact that there is impact on Bob's UA.
supporting new features most likely implies an impact on the UA(s) that 
wants support them.
anyway the features are optional!
> Even though that impact might only be session correlation, this could be quite complex.
if we are able to standardize a good and hopefully general session-id 
mechanism,
then the impact coming from SPLICE is really minimal.

/Sal

> It sounds to me like Bob's UA, on deciding that two SIP dialogs relate to the same session, must somehow merge the two session descriptions (SDP). In the simple case, where one session is audio only and the other is video only, it might be relatively simple, e.g., an assumption that the two need to be lip-synched could be made. But we surely would need to deal with more complex cases, e.g., an additional video stream for presentations, floor control of the presentation stream or other streams, multiple audio and/or video channels for telepresence, grouped media spanning more than one contributing session description, etc.. Multimedia SIP UAs will have no incentive to implement extensions to cover session correlation and merging, so this will constrain interoperability.
>
> John