[MMUSIC] Fwd: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt

Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> Wed, 08 May 2013 08:54 UTC

Return-Path: <stefan.lk.hakansson@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 5100321F8F53 for <mmusic@ietfa.amsl.com>; Wed, 8 May 2013 01:54:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.949
X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id oi17WyNTOmFO for <mmusic@ietfa.amsl.com>; Wed, 8 May 2013 01:54:19 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se []) by ietfa.amsl.com (Postfix) with ESMTP id 1932921F8EDA for <mmusic@ietf.org>; Wed, 8 May 2013 01:54:18 -0700 (PDT)
X-AuditID: c1b4fb30-b7f3a6d0000007a4-f3-518a12b8cc85
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain []) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id C1.07.01956.8B21A815; Wed, 8 May 2013 10:54:16 +0200 (CEST)
Received: from [] ( by esessmw0184.eemea.ericsson.se ( with Microsoft SMTP Server id; Wed, 8 May 2013 10:54:16 +0200
Message-ID: <518A12B7.6090409@ericsson.com>
Date: Wed, 8 May 2013 10:54:15 +0200
From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= <stefan.lk.hakansson@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: mmusic@ietf.org
References: <518A1268.8090107@ericsson.com>
In-Reply-To: <518A1268.8090107@ericsson.com>
X-Forwarded-Message-Id: <518A1268.8090107@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFJMWRmVeSWpSXmKPExsUyM+Jvre4Ooa5Ag52/bCymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujO5nL9gLJspXzJ/UzdLAuEKyi5GDQ0LAROL3ac0uRk4gU0zi wr31bF2MXBxCAqcYJfoPvmWHcNYwSrQtmcgMUsUroC0xb8szNhCbRUBFYtOSgywgNptAoMT1 /7+YQGxRgSiJf293M0LUC0qcnPkErEZEQFhixtu/YL3CAjESlz8tBKsXApq55/tzVhCbU0BH Ys3Gf+wQF5lLHN90A6yXWcBW4sKc61C2vETz1tnMEL26Eu9e32OdwCg4C8m6WUhaZiFpWcDI vIqRPTcxMye93HwTIzD8Dm75bbCDcdN9sUOM0hwsSuK8yVyNgUIC6YklqdmpqQWpRfFFpTmp xYcYmTg4pRoYa5JOODn+O3eYy1j9mrzP3N262RN9LPXP7575w/21KIf+5LCMK/P53df7rdtX /sZadKpgyb6WXzmPz9jz3Nght20py7m+rYI8n4xsZseHqyhPbBDk3x+vZ2Jw/73d2mvMfBfX Gtu/7q1c9MRgWQ7nlkNLXm8+sFdYJkDY2zj7qfOhAxGWsXEzlViKMxINtZiLihMBxczhsw0C AAA=
Subject: [MMUSIC] Fwd: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 May 2013 08:54:25 -0000

This should probably have gone to this list as well.

-------- Original Message --------
Subject: Re: [rtcweb] Fwd: New Version Notification for 
Date: Wed, 8 May 2013 10:52:56 +0200
From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
To: <rtcweb@ietf.org>

I think this could work. There are some parts that I like a lot (and,
yes, I tend to have a narrow rtcweb centric perspective):

* The (3-way) handshake is well aligned with the API (where the sending
app initiates the sending of media)

* That simulcast and layered encoding is supported

* The text about end-points ensuring that its SSRC's are unique - I
think this enables mixers/translators to form arbitrary RTP sessions

* It is outlined how sending, or stop sending, is signaled per

One thing I do not understand is why the imageattr is signaled in the
sending direction in the examples. Is not this info anyway part of the
bitstream and will become apparent during the decoding process? It would
be more natural to signal imageattr from the receiver (e.g. the receiver
telling the sender the size of the video display). (An alternative would
be to not signal it at all but leave it to app proprietary signaling and
the APIs available to the sending application).

I think that an alternative for simulcast could be that, instead of
sending several resolutions for the same MediaStreamTrack, it was
designed so that a separate MediaStreamTrack would have to be used (and
the tracks would of course have to be synced) for each resolution. The
primary reason is that the application can only really handle data down
to the MediaStreamTrack level - there are no handles below that level in
the API's currently.

I thing that strikes me is that perhaps we could lift out the msid
signaling into its own block, that established the MediaStream and
MediaStreamTrack structure of the outgoing media and how is relates to

The MediaStream-id/MediaStreamTrack-id info is only relevant to WebRTC
endpoints and could be ripped out if the endpoint is legacy, and the
remaining SDP would have fewer strange (to legacy) elements.

On 2013-05-03 08:08, Justin Uberti wrote:
> Scribbled down the basic concepts of what I have been referring to as
> "Plan B" - a way to signal multiple MediaStreamTracks in SDP without
> needing a separate m= line for each.
> Hopefully this will make discussion of this topic easier.
> ---------- Forwarded message ----------
> From: ** <internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>>
> Date: Thu, May 2, 2013 at 10:46 PM
> Subject: New Version Notification for draft-uberti-rtcweb-plan-00.txt
> To: Justin Uberti <justin@uberti.name <mailto:justin@uberti.name>>
> A new version of I-D, draft-uberti-rtcweb-plan-00.txt
> has been successfully submitted by Justin Uberti and posted to the
> IETF repository.
> Filename:        draft-uberti-rtcweb-plan
> Revision:        00
> Title:           Plan B: a proposal for signaling multiple media sources
> in WebRTC.
> Creation date:   2013-05-03
> Group:           Individual Submission
> Number of pages: 15
> URL: http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt
> Status: http://datatracker.ietf.org/doc/draft-uberti-rtcweb-plan
> Htmlized: http://tools.ietf.org/html/draft-uberti-rtcweb-plan-00
> Abstract:
>     This document explains how multiple media sources can be signaled in
>     WebRTC using SDP, in a fashion that avoids many common problems and
>     provides a simple control surface to the receiver.
> The IETF Secretariat
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

rtcweb mailing list