Re: [MMUSIC] [rtcweb] SDP work needed for WebRTC stuff

Magnus Westerlund <> Wed, 12 December 2012 10:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 964B221F84FD; Wed, 12 Dec 2012 02:37:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.204
X-Spam-Status: No, score=-106.204 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zQQ8QzGVCHzI; Wed, 12 Dec 2012 02:37:28 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 4183C21F84FB; Wed, 12 Dec 2012 02:37:27 -0800 (PST)
X-AuditID: c1b4fb25-b7fb26d000006129-37-50c85e65c6a4
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id A5.41.24873.56E58C05; Wed, 12 Dec 2012 11:37:26 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id; Wed, 12 Dec 2012 11:37:24 +0100
Message-ID: <>
Date: Wed, 12 Dec 2012 11:37:24 +0100
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <BLU405-EAS2665AFEC5A0D3FBF6070B6393480@phx.gbl>
In-Reply-To: <BLU405-EAS2665AFEC5A0D3FBF6070B6393480@phx.gbl>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFLMWRmVeSWpSXmKPExsUyM+JvjW5a3IkAg52TOCz2L7nMbLHi9Tl2 i47JbBZTlz9msVj7r53dgdVjyu+NrB6Pe86weSxZ8pPJY/LjNuYAligum5TUnMyy1CJ9uwSu jIdfrrEUXFOsePb2NHsD4zapLkZODgkBE4lPHw4yQ9hiEhfurWfrYuTiEBI4yShx8MELFghn OaPEjTs3GEGqeAW0JW5O283UxcjBwSKgKjFvWS1ImE3AQuLmj0Y2EFtUwFdi1p5fTBDlghIn Zz5hAbFFBGQlOi+uYgWZySzQwShxeM8TsM3CAg4Sx9b+gdr8j1mi/esOsA5OAVuJX7t/skKc JymxaFonWJxZwEDiyKI5rBC2vETz1tlgg4SAjmto6mCdwCg0C8nyWUhaZiFpWcDIvIqRPTcx Mye93GgTIzC8D275rbqD8c45kUOM0hwsSuK81lv3+AsJpCeWpGanphakFsUXleakFh9iZOLg lGpg5Ct8WalgdrTH5eSGR0Z/Vu2doJ/oVGfX1m4merKgOl+3yCl5frL0B+6pOy2Ysy7d7zdy Zq35KbO799tx/r0VSXfP/QstqJPq+5p1sKPj8+o5YmyPp74oTT+TsOhpw5xDJd457Gf2BO/X 3f+haatJll+Zp40yR0xXm+pEodW3z59NFe1cGr1aiaU4I9FQi7moOBEA2oFXBD0CAAA=
Cc: "'Cullen Jennings (fluffy)'" <>,, 'mmusic WG' <>
Subject: Re: [MMUSIC] [rtcweb] SDP work needed for WebRTC stuff
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 12 Dec 2012 10:37:28 -0000


My Personal view on this topics.

On 2012-12-11 06:01, Bernard Aboba wrote:
> I do not think that a single meeting, virtual or actual, will suffice to
> get things back on track.  We need a fundamental change of approach.

Fully agreed. One of the issues, is that not a single individual of use
across 5-6 WG have a complete picture of the issues we are stepping into
with the fundamental issues that are in the center of this. This will
require multiple individuals having knowledge on different aspects to
fill in details and educate the others on the diverse issues.

> The basic problem is that WebRTC work items have been dispersed between
> a number of WGs other than RTCWEB.  Within these WGs, WebRTC is only a
> sideline.

I am not certain that is the fundamental issue here. I think the very
basic problem is that we are attempting for fork lift SDP into a clear
specification supporting multi-stream RTP sessions and dealing with the
diverse landscape of relationships that exists in multi-media
applications between a large number of terminologies that include
concepts such as:

- Multi-party
- Multiple media sources, i.e. camera microphones
- Media Mixes or Compositions
- Synchronization Contexts
- End-point concepts, virtual, distributed, etc.
- Diverse signalling models
- Simulcast
- Layered Encoding
- Transport robustification, i.e RTP Retransmission, Duplications, FEC.
- Different transports, aggregated over single unicast, multiple unicast
flows, multicast
- Different security mechanisms

This coupled with that the people putting in requirements on this are
working on different type of systems or applications, RTCWEB/WebRTC and
CLUE just being two. We also have existing users of RTP that made
different assumptions in extensions and signalling.

It was very evident in RTCWEB and AVTEXT that we are lacking common
terminology to even discuss the above and what it means in different

Then we haven't even discussed what happens the minute you drag the word
"Legacy" into any of the above debates for actual solutions. But now I
am getting ahead of myself. I think the most important is to build a
good description of the different functionalities and their
relationships that we today believe are necessary to deal with currently
and in the near future.

> As a result, work items such as BUNDLE (which require non-trivial
> analysis and discussion) have found themselves a needle in a haystack of
> other items, getting a fraction of the attention that they need to move
> forward.  

Yes, bundle is something that covers parts of the above and clearly
related. I, however think more close to the core of the issues is the
multiple stream issues and how we deal with relationships. However, I
think failing to take the related topics into account and think that
this will be quickly resolved will only result in generating even more

I also believe that in the end we are going to have to take some though
decisions when it comes how to deal with existing definitions. Either
replace them or basically deprecate some behaviors.

> While allocating some substantial time at an in-person RTCWEB/MMUSIC
> interim can help, for that time to be well spent will require
> substantial preparation.  As an example, I could see a virtual AVTEXT
> interim being scheduled for mid-January at which Jonathan Lennox’s
> hierarchy draft could be given substantial time and an MMUSIC virtual
> interim in the same time frame which could be devoted to one or two
> important topics (e.g. BUNDLE, SCTP).

Fully agreed. This takes preparations and hard work.


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: