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

From: Stefan Håkansson LK <[email-masked]>
Date: Wed, 8 May 2013 10:54:15 +0200

This should probably have gone to this list as well.

-------- Original Message --------
Subject: Re: [rtcweb] Fwd: New Version Notification for 
draft-uberti-rtcweb-plan-00.txt
Date: Wed, 8 May 2013 10:52:56 +0200
From: Stefan Håkansson LK <[email-masked]>
To: <[email-masked]>

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
MediaStreamTrack

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
SSRC's.

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: ** <[email-masked] <mailto:[email-masked]>>
> Date: Thu, May 2, 2013 at 10:46 PM
> Subject: New Version Notification for draft-uberti-rtcweb-plan-00.txt
> To: Justin Uberti <[email-masked] <mailto:[email-masked]>>
>
>
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

_______________________________________________
rtcweb mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb