Re: [rtcweb] To multiplex or not!

Magnus Westerlund <magnus.westerlund@ericsson.com> Wed, 20 July 2011 07:44 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 529A321F8A71 for <rtcweb@ietfa.amsl.com>; Wed, 20 Jul 2011 00:44:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.54
X-Spam-Level:
X-Spam-Status: No, score=-106.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 pC0iq1YTH1MR for <rtcweb@ietfa.amsl.com>; Wed, 20 Jul 2011 00:44:03 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 814B721F8A56 for <rtcweb@ietf.org>; Wed, 20 Jul 2011 00:44:03 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-cd-4e2687424853
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 61.9F.20773.247862E4; Wed, 20 Jul 2011 09:44:02 +0200 (CEST)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Wed, 20 Jul 2011 09:44:02 +0200
Message-ID: <4E268741.408@ericsson.com>
Date: Wed, 20 Jul 2011 09:44:01 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Matthew Kaufman <matthew.kaufman@skype.net>
References: <4E259484.20509@ericsson.com> <4E25B37D.9080404@skype.net>
In-Reply-To: <4E25B37D.9080404@skype.net>
X-Enigmail-Version: 1.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] To multiplex or not!
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Jul 2011 07:44:04 -0000

On 2011-07-19 18:40, Matthew Kaufman wrote:
> On 7/19/2011 7:28 AM, Magnus Westerlund wrote:
>> a) MUST be sent as Individual flows for each component.
>>
>> b) MUST be multiplexed into a single transport flow.
>>
>> c) SHOULD be multiplexed into a single transport flow, but the RTCWEB
>> peer MUST be able to send them as individual flows.
>>
>> I would love if people can indicate their choice or preferences.
> 
> C. But I'm not sure that the "must" needs to be anything more than "you 
> just make two peer connection objects, one for each". (In other words, 
> any API that allows for multiplexing almost certainly allows for 
> non-multiplexing)... this assumes that the multiplexing is implicit, of 
> course. With explicit multiplexing it is even harder... the API needs to 
> support turning on and off the multiplexing shim as well, something I'm 
> not in favor of.

I am far from certain that it is that simple. First of all, two
different RTP sessions, one for audio and one for video that goes over
different UDP flows, still has an association, for example the used
CNAME to indicate that these flows can be synchronized and are from the
same end-point. If the API definition is such that a stream object
implies a synchronization context when sending, then moving the streams
to two different objects fails to have that separation in semantics.

I think the MUST is important in the aspect that it is a clear agreement
to get this to work. How, that is for us to work out together with W3C.

Thus, I wouldn't rule out that actual need for some option that you can
set to get non-multiplexed. It might be conceptually much simpler for a
developer than to actually understand how you need to spit streams and
then add additional binding properties to these media streams which
could be an alternative design.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------