Subject: [MMUSIC] Unified Plan for SDP Handling

From: Adam Roach <[email-masked]>
Date: Mon, 15 Jul 2013 14:04:40 -0500

[Cross-posting to RTCWEB; follow-ups to MMUSIC, please]

After significant work, Justin, Martin and I have managed to produce a 
compromise plan that provides a high degree of interoperability with 
existing devices (and future non-WebRTC devices) while not being 
excessively onerous for WebRTC implementations or applications that use 
them. It's been a tricky balancing act, but I think we've found a good 
mix between the two that can form a solid basis for the working group to 
move forward.

Rather than summarize the key points of the document in this email, I 
direct interested parties to section 2 of the document, which summarizes 
the key aspects of the plan in eight relatively concise bullet points.

I apologize for the late publication date of this document -- there's 
actually been a lot more work put into coming up with a unified draft 
than I originally anticipated, and the production of this document took 
at least two weeks longer than I expected it to.

Note that this document is intended to be a plan for the work to be done 
in this area, and not a specification in itself. The intention is that 
its contents are used as the basis for work in several other drafts -- 
some new, some not -- that form the corpus of work necessary for RTCWEB 
(and potentially CLUE) to move forward. Except in rare cases, the 
document does not attempt to explicitly call out venues or documents for 
such work, as we (or, at the very least, I) anticipate guidance from the 
various working group chairs to assist in such decisions.

Comments prior to Berlin would be very helpful, although this will 
clearly be a point of significant discussion at the face-to-face meeting.

Document link:

http://www.ietf.org/id/draft-roach-mmusic-unified-plan-00.txt

/a

---

From: Roman Shpount <[email-masked]>
Date: Mon, 15 Jul 2013 16:46:49 -0400

Quick nit on the draft: In initial examples with "group:BUNDLE S1 S2 S3"
mid attributes should be "a=mid:S1", "a=mid:S2", and "a=mid:S3", not "a=mid:1",
"a=mid:2", "a=mid:3"
_____________
Roman Shpount

---

From: "Roni Even" <[email-masked]>
Date: Tue, 16 Jul 2013 23:28:37 +0300

Adam,
For correlation when the SSRC is not known in the SDP look at
http://tools.ietf.org/id/draft-even-mmusic-multiple-streams-02.txt and the
option to use SDES and not only RTP header extension.

BTW: there are other cases when the SSRC is not known using SDP before the
RTP stream arrives like when an MCU switch the video. Note that SDES is
distributed to the session when the source joins the RTP session which can
be long before the RTP media is sent to a specific receiver in the group.

Roni

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Adam Roach
> Sent: 15 July, 2013 10:05 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [MMUSIC] Unified Plan for SDP Handling
> 
existing
> devices (and future non-WebRTC devices) while not being excessively
> onerous for WebRTC implementations or applications that use them. It's
> been a tricky balancing act, but I think we've found a good mix between
the
> two that can form a solid basis for the working group to move forward.
> 
direct
> interested parties to section 2 of the document, which summarizes the key
> aspects of the plan in eight relatively concise bullet points.
> 
actually
> been a lot more work put into coming up with a unified draft than I
originally
> anticipated, and the production of this document took at least two weeks
> longer than I expected it to.
> 
in
> this area, and not a specification in itself. The intention is that its
contents are
> used as the basis for work in several other drafts -- some new, some not
--
> that form the corpus of work necessary for RTCWEB (and potentially CLUE)
to
> move forward. Except in rare cases, the document does not attempt to
> explicitly call out venues or documents for such work, as we (or, at the
very
> least, I) anticipate guidance from the various working group chairs to
assist in
> such decisions.
> 
> Comments prior to Berlin would be very helpful, although this will clearly
be a
> point of significant discussion at the face-to-face meeting.
> 
> Document link:
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Adam Roach <[email-masked]>
Date: Tue, 16 Jul 2013 15:38:50 -0500

> option to use SDES and not only RTP header extension.

Roni:

Thanks for the pointer. That's an interesting approach; however, for 
RTCWEB at least, need a solution that also works with DTLS-SRTP.

/a

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 16 Jul 2013 18:05:38 -0400

> RTCWEB at least, need a solution that also works with DTLS-SRTP.

Acronym collision: This uses RTCP Source Description packets, not SDP Security Descriptions.

I think the (related) app-id approach described in http://tools.ietf.org/html/draft-even-mmusic-application-token-00.txt will also be of interest.

--
Jonathan Lennox
[email-masked]

---

From: "Roni Even" <[email-masked]>
Date: Wed, 17 Jul 2013 07:16:44 +0300

Adam,
I gave the wrong link before. I meant the one Jonathan pointed to
Roni

> From: Jonathan Lennox [mailto:[email-masked]]
> Sent: 17 July, 2013 1:06 AM
> To: Adam Roach
> Cc: Roni Even; [email-masked]
> Subject: Re: [MMUSIC] Unified Plan for SDP Handling
> 
> 
> >> http://tools.ietf.org/id/draft-even-mmusic-multiple-streams-02.txt
> >> and the option to use SDES and not only RTP header extension.
> >
> > Roni:
> >
> I think the (related) app-id approach described in
> http://tools.ietf.org/html/draft-even-mmusic-application-token-00.txt will
> also be of interest.
> 
> --
> Jonathan Lennox
> [email-masked]

---

From: Stefan Håkansson LK <[email-masked]>
Date: Wed, 17 Jul 2013 14:08:53 +0000

> mix between the two that can form a solid basis for the working group to

Thanks for doing this work, I hope that we now finally can get going on 
specifying this up (and I hope it won't take too long to do so!).

I think this looks like a really good start, and there is a lot I like 
(e.g. the independent signaling per MediaStreamTrack).

I have a couple of specific questions/comments, coming from a very 
WebRTC centric (sorry for that) perspective:

* Simulcast: In the current API model, MediaStreamTrack is about the 
lowest you can get to. And the same source (camera, microphone) can 
source several MediaStreamTrack - and each of those can use individual 
constraints for width, height, framerate, etc. So in a WebRTC context, 
there seem to me we would not need the simulcast solution you have 
included. The different resolutions can be sent as different 
MediaStreamTrack's - meaning they would be separate m-lines.

* Direction attribute: The current WebRTC API is "sender" oriented: the 
application can select MediaStream(Track)'s to send. Would it for WebRTC 
make sense to have all m-lines being unidirectional (send/recvonly)? (If 
they should be sendrecv we also need to specify when a return track 
should reuse an existing m-line, and when a new m-line should be created.)

Stefan

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 17 Jul 2013 12:38:04 -0400

Adam,

While I see there can be some value to extending O/A to allow for 
smaller critical sections, I fear that it is going to be very messy to 
get "right". Some messy things:

- Glare between a partial O/A and a full O/A
- Is a partial O/A permitted in a sip reINVITE? Can you have
   an offerless reINVITE where the response contains a partial offer?
   Or can these only be done in UPDATE?
- In SIP, processing of concurrent reINVITEs/UPDATEs containing
   partial SDP updates. This seems to already be a
- How to assign version numbers to the full SDP as a result
   of partial updates
- I'm not sure your algorithm for resolving glare when adding
   streams works in all cases. (More below on this.)

These (and ones I haven't thought of) *may* all be resolvable. But this 
certainly complicates the already complex O/A process - maybe to the 
point that many get it wrong. (I don't want to write rfc6337bis!)

My concern with the glare resolution algorithm is that for it to work 
both sides must realize that glare occurred. And I think there are 
common sequences when one side won't realize it.

I'm reluctant to buy into a scheme that depends on this without knowing 
it it will be implementable.

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Wed, 17 Jul 2013 12:07:50 -0500

> - Glare between a partial O/A and a full O/A

...is glare. Resolve as normal. For SIP, that means timers.

>   Or can these only be done in UPDATE?

No, no, and no. In SIP, the protocol machinery would not allow INVITE or 
UPDATE to complete concurrently in opposite directions for any amount of 
overlap. We aren't proposing a change to SIP state machines here, only 
to the offer/answer model. This necessarily means that we need to carry 
partial offers and partial answers in something else -- probably INFO.

>   partial SDP updates. This seems to already be a

You left this unfinished, but I *think* it was going to make the same 
point I did in my response above.

> - How to assign version numbers to the full SDP as a result

Section 3.4.1: "... the SDP version is incremented by one..."

> These (and ones I haven't thought of) *may* all be resolvable. But 
> this certainly complicates the already complex O/A process - maybe to 
> the point that many get it wrong. (I don't want to write rfc6337bis!)
>

I'm not saying I didn't miss it, but I did work through as many 
permutations as I could think of, and none of them are left out by the 
algorithm described in section 3.4.1.

That said, I did my analysis in the context of WebRTC, and assumed a 
reliable, in-order delivery channel for messages. I recognize that we 
don't have that for SIP, and that messages in the same direction can be 
reordered. I admit that this does raise some interesting scenarios that 
may require additional work to resolve.

> I'm reluctant to buy into a scheme that depends on this without 
> knowing it it will be implementable.

I understand your reluctance, and don't want to gloss over it. This is 
but one plank in the overall plan, and it represents what we think is 
the best (but not only) solution to this specific requirement. If the 
issues prove intractable, we could fall back to an alternate scheme, 
such as the designated-offerer I describe in 
draft-roach-rtcweb-glareless-add-00, or the token-passing scheme 
described by Ted Hardie (cf. 
http://www.ietf.org/mail-archive/web/rtcweb/current/msg07361.html).

/a

---

From: Adam Roach <[email-masked]>
Date: Wed, 17 Jul 2013 15:23:39 -0500

> MediaStreamTrack's - meaning they would be separate m-lines.

That's what we meant to convey with this (section 2, bullet 1): "This 
does not preclude 'application level' simulcasting; i.e., the creation 
of multiple media stream tracks from a single source."

It's true that we don't broach the issue of how to indicate the need for 
simulcast via a WebRTC javascript API. I think this is something that 
would be future work, probably in the W3C. I'm going to leave any 
further explanation to Justin, as most of the simulcast ideas in the 
document came from him.

> make sense to have all m-lines being unidirectional (send/recvonly)?

I understand how this makes things cleaner in general. The issue I have 
is that it interacts poorly with legacy uses.

>   (If

I agree that this could stand to be spelled out more clearly. I do not 
think that doing so will prove particularly controversial.

/a

---

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 18 Jul 2013 13:06:04 +0000

Dear Adam, all,

good to see significant progress.

One aspect I still struggle to understand is the need for the "msid" attribute.

The draft says:

2.  Solution Overview

   At a high level, the solution described in this document can be
   summarized as follows:

   1.  Each media stream track is represented by its own unique m-line.
       This is a strict one-to-one mapping; a single media stream track
       cannot be spread across several m-lines, nor may a single m-line
       represent multiple media stream tracks. ...

   3.  Each m-line contains an MSID value to correlate it with a Media
       Stream ID and the Media Stream Track ID.

3.2.2.  Correlating Media Stream Tracks with m-lines

   Media Stream Tracks IDs are correlated with M-Lines directly by
   including an MSID in each m-line.  The MSID also provides the Media
   Stream ID.  (Note the format of the MSID used here is slightly
   different than what was proposed in the current MSID draft as that
   draft assumed multiple tracks in a single m-line and this proposal
   moves to a solution where there is a one to one relation between the
   Track and MSID.  This work assumes the MSID draft will be updated to
   match the syntax used user which simply provides the value of the
   MediaStream ID and MediaStreamTrack ID on an "a=msid" line.  )

The draft lacks a related references, but seems to refer to draft-ietf-mmusic-msid-00. However, it is assuming some not yet documented modifications of that draft, which does not simplify the understanding (hopefully only a problem for a short time). What you have in mind seems no longer an extension of the a=ssrc attribute but an own SDP attribute. 

Unfortunately there is no definition of media stream track.

More fundamentally, do we require the term "media stream track" at all (rather than simply speaking about m-lines), if there is a one-to-one mapping to a unique m-line?
And do we require an extra identifier for it, in addition of the position (that could also be expressed by an ordinal number in some separate protocol or for cross-referencing within SDP) of the m-line in the SDP?
I suspect the need for a new identifier of the m-line/media stream track has something to do with partial SDP offers? But could the identifier not still be the ordinal number with respect to the "full" SDP (or the next free number if an m-line is added), and be restricted to partial offers?

The msid attribute also assings a "media stream ID", but your draft does not describe at all what that ID would be used for.

Thomas

---------------------------------- 
Dr. Thomas Belling 
3GPP Standardisation
Nokia Siemens Networks 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Adam Roach
Sent: Monday, July 15, 2013 9:05 PM
To: [email-masked]
Cc: [email-masked]
Subject: [MMUSIC] Unified Plan for SDP Handling

After significant work, Justin, Martin and I have managed to produce a compromise plan that provides a high degree of interoperability with existing devices (and future non-WebRTC devices) while not being excessively onerous for WebRTC implementations or applications that use them. It's been a tricky balancing act, but I think we've found a good mix between the two that can form a solid basis for the working group to move forward.

Rather than summarize the key points of the document in this email, I direct interested parties to section 2 of the document, which summarizes the key aspects of the plan in eight relatively concise bullet points.

I apologize for the late publication date of this document -- there's actually been a lot more work put into coming up with a unified draft than I originally anticipated, and the production of this document took at least two weeks longer than I expected it to.

Note that this document is intended to be a plan for the work to be done in this area, and not a specification in itself. The intention is that its contents are used as the basis for work in several other drafts -- some new, some not -- that form the corpus of work necessary for RTCWEB (and potentially CLUE) to move forward. Except in rare cases, the document does not attempt to explicitly call out venues or documents for such work, as we (or, at the very least, I) anticipate guidance from the various working group chairs to assist in such decisions.

Comments prior to Berlin would be very helpful, although this will clearly be a point of significant discussion at the face-to-face meeting.

Document link:

/a

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 18 Jul 2013 15:40:42 +0200

> The draft lacks a related references, but seems to refer to draft-ietf-mmusic-msid-00. However, it is assuming some not yet documented modifications of that draft, which does not simplify the under…

I'll fix the MSID draft once I-D submission reopens. Yes, when an MSID 
is to be assigned for a whole M-line, it needs to be its own attribute, 
not an a=ssrc attribute (and that is the only change that needs to be 
made, I think).
> More fundamentally, do we require the term "media stream track" at all (rather than simply speaking about m-lines), if there is a one-to-one mapping to a unique m-line?

I think it would actually be better if this draft talked in terms of 
media sources (as defined in the taxonomy draft I noted in my review), 
and just mentioned that in the case of WebRTC, a media source 
corresponds to the JavaScript object called MediaStreamTrack.

> The msid attribute also assings a "media stream ID", but your draft does not describe at all what that ID would be used for.

The ID of a WEBRTC MediaStream is defined in 
http://dev.w3.org/2011/webrtc/editor/getusermedia.html#attributes

---

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 18 Jul 2013 14:21:13 +0000

Thanks Harald,

I understand the Media Stream ID and Media Stream Track ID appear in the W3C API.

However, this does not necessarily mean they need to be signaled end-to-end (rather than being only of local significance for the interactions between the JavaScript application and the API, and being mapped to/from some other SDP properties such as the ordinal number of the SDP m-line).

If something important was missing in SDP up to now, we certainly need to add it. But we should not duplicate information. This is what I try to find out. And obviously, requiring mandatory SDP extensions does not simplify interoperability with existing SDP peers.

Thomas

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Harald Alvestrand
Sent: Thursday, July 18, 2013 3:41 PM
To: [email-masked]
Subject: Re: [MMUSIC] Unified Plan for SDP Handling - msid attribute and media stream track

...

The ID of a WEBRTC MediaStream is defined in http://dev.w3.org/2011/webrtc/editor/getusermedia.html#attributes

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 18 Jul 2013 16:51:03 +0200

On 07/18/2013 04:21 PM, Belling, Thomas (NSN - DE/Munich) wrote:
> However, this does not necessarily mean they need to be signaled 
> end-to-end (rather than being only of local significance for the 
> interactions between the JavaScript application and the API, and being 
> mapped to/from some other SDP properties such as the ordinal number of 
> the SDP m-line).
>

Well... if we want to have the same ID attached to the same 
MediaStreamTrack at both ends, the ID has to be carried somehow.

If there's no need for the ID to be the same, we don't need it. But so 
far, I think the consensus in the W3C WG is that it needs to be the same.

> If something important was missing in SDP up to now, we certainly need 
> to add it. But we should not duplicate information. This is what I try 
> to find out. And obviously, requiring mandatory SDP extensions does 
> not simplify interoperability with existing SDP peers.
>

That's why the MSID spec has a section on what to do when you get tracks 
without MSIDs.

> Thomas
>
> *From:[email-masked] [mailto:[email-masked]] *On 
> Behalf Of *ext Harald Alvestrand
> *Sent:* Thursday, July 18, 2013 3:41 PM
> *To:* [email-masked]
> *Subject:* Re: [MMUSIC] Unified Plan for SDP Handling - msid attribute 
> and media stream track
>

---

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 18 Jul 2013 15:18:24 +0000

That is where my confusion starts:
The MSID draft, and also your related backward compatibility procedures, assumes that multiple tracks can be described by one m-line.
This is no longer true.

For the MediaStreamTrack ID, I still suspect that a standardized mapping to m-line ordinal numbers could now be sufficient to have the same IDs at both sides

For the MediaStream, the API description says:
Each MediaStream<http://dev.w3.org/2011/webrtc/editor/getusermedia.html#idl-def-MediaStream> object can contain zero or more tracks, in particular audio and video tracks. All tracks in a MediaStream are intended to be synchronized when rendered. Different MediaStreams do not need to be synchronized.

This sounds like a lipsynch group in SDP.
The group name can then serve as MediaStrem ID.  Each m-line outside such a group would probably have a separate MediaStream,  and the m-line ordinal number could then serve as MediaStream ID.

From: ext Harald Alvestrand [mailto:[email-masked]]
Sent: Thursday, July 18, 2013 4:51 PM
To: Belling, Thomas (NSN - DE/Munich)
Cc: [email-masked]
Subject: Re: [MMUSIC] Unified Plan for SDP Handling - msid attribute and media stream track

Well... if we want to have the same ID attached to the same MediaStreamTrack at both ends, the ID has to be carried somehow.

If there's no need for the ID to be the same, we don't need it. But so far, I think the consensus in the W3C WG is that it needs to be the same.

That's why the MSID spec has a section on what to do when you get tracks without MSIDs.

Thomas

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of ext Harald Alvestrand
Sent: Thursday, July 18, 2013 3:41 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [MMUSIC] Unified Plan for SDP Handling - msid attribute and media stream track

---

From: Justin Uberti <[email-masked]>
Date: Thu, 18 Jul 2013 23:43:00 -0400

On Wed, Jul 17, 2013 at 4:23 PM, Adam Roach <[email-masked]> wrote:

> That's what we meant to convey with this (section 2, bullet 1): "This does
> not preclude 'application level' simulcasting; i.e., the creation of
> multiple media stream tracks from a single source."
>
> simulcast via a WebRTC javascript API. I think this is something that would
> be future work, probably in the W3C. I'm going to leave any further
> explanation to Justin, as most of the simulcast ideas in the document came
> from him.

Consider the parallel with layered coding - in that case, you have multiple
dependent encodings of the track, but it's doubtful you want the recipients
to end up with multiple MediaStreamTracks and display them all in their UI.

This mechanism is basically a way to say that I have a single
MediaStreamTrack coming in, and while there might be multiple independent
or dependent encodings of it on the wire, the recipient should only create
and display a single MediaStreamTrack on its side.

> I understand how this makes things cleaner in general. The issue I have is
> that it interacts poorly with legacy uses.
>
>
>    (If
> ______________________________**_________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/mmusic<https://www.ietf.org/mailman/listinfo/mmusic>
>

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 19 Jul 2013 07:49:37 -0700

This is weird - I see your reply but i don't see Stephan's email 

On Jul 18, 2013, at 8:43 PM, Justin Uberti <[email-masked]> wrote:

>> That's what we meant to convey with this (section 2, bullet 1): "This does not preclude 'application level' simulcasting; i.e., the creation of multiple media stream tracks from a single source."
>> 
>> It's true that we don't broach the issue of how to indicate the need for simulcast via a WebRTC javascript API. I think this is something that would be future work, probably in the W3C. I'm going to leave any further explanation to Justin, as most of the simulcast ideas in the document came from him.
> 
> Consider the parallel with layered coding - in that case, you have multiple dependent encodings of the track, but it's doubtful you want the recipients to end up with multiple MediaStreamTracks and display them all in their UI.
> 
> This mechanism is basically a way to say that I have a single MediaStreamTrack coming in, and while there might be multiple independent or dependent encodings of it on the wire, the recipient should only create and display a single MediaStreamTrack on its side.
>> 
>> 
>> I understand how this makes things cleaner in general. The issue I have is that it interacts poorly with legacy uses.
>> 
>> 
>>>   (If
>> I agree that this could stand to be spelled out more clearly. I do not think that doing so will prove particularly controversial.
>> 
>> 
>> /a

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 19 Jul 2013 07:53:04 -0700

I like this - it looks like a reasonable way forward

---

From: Matt Fredrickson <[email-masked]>
Date: Thu, 18 Jul 2013 16:28:12 -0500

Please forgive me for coming a bit late to the discussion on this, but what
types of "legacy devices" are being targeted?  At least from what I have
seen, most legacy equipment doesn't support ICE, definitely does not
support DTLS-SRTP, most do not support SDES-SRTP, none bundling, none
rtcp-mux, etc.

I believe that there might be some sort of legacy interop with disabling of
bundling, rtcp-mux possibly as well, and supporting SDES or non encrypted
sessions.  Otherwise, I don't know what legacy devices means in the context.

Is there a place where a definition of a "legacy device" (as mentioned in
your draft) is given in the webrtc specs?

Matthew Fredrickson

On Mon, Jul 15, 2013 at 2:04 PM, Adam Roach <[email-masked]> wrote:

> them. It's been a tricky balancing act, but I think we've found a good mix
> between the two that can form a solid basis for the working group to move
> forward.
>
> actually been a lot more work put into coming up with a unified draft than
> I originally anticipated, and the production of this document took at least
> two weeks longer than I expected it to.
>
> in this area, and not a specification in itself. The intention is that its
> contents are used as the basis for work in several other drafts -- some
> new, some not -- that form the corpus of work necessary for RTCWEB (and
> potentially CLUE) to move forward. Except in rare cases, the document does
> not attempt to explicitly call out venues or documents for such work, as we
> (or, at the very least, I) anticipate guidance from the various working
> group chairs to assist in such decisions.
>
> be a point of significant discussion at the face-to-face meeting.
>
> Document link:
>
> http://www.ietf.org/id/draft-**roach-mmusic-unified-plan-00.**txt<http://www.ietf.org/id/draft-roach-mmusic-unified-plan-00.txt>
>
> /a
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>

---

From: Stefan Håkansson LK <[email-masked]>
Date: Sun, 21 Jul 2013 06:03:58 +0000

On 7/19/13 5:43 AM, Justin Uberti wrote:
>
>
>
> On Wed, Jul 17, 2013 at 4:23 PM, Adam Roach <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     That's what we meant to convey with this (section 2, bullet 1):
>     "This does not preclude 'application level' simulcasting; i.e., the
>     creation of multiple media stream tracks from a single source."
>
>     It's true that we don't broach the issue of how to indicate the need
>     for simulcast via a WebRTC javascript API. I think this is something
>     that would be future work, probably in the W3C. I'm going to leave
>     any further explanation to Justin, as most of the simulcast ideas in
>     the document came from him.
>
>
> Consider the parallel with layered coding - in that case, you have
> multiple dependent encodings of the track, but it's doubtful you want
> the recipients to end up with multiple MediaStreamTracks and display
> them all in their UI.

I think it is not a good parallel. With layered encoding you need the 
base layer to have any use of any enhancement layer. With simulcast of 
the other hand every stream is a complete representation and can be used 
on its own.

> MediaStreamTrack coming in, and while there might be multiple
> independent or dependent encodings of it on the wire, the recipient
> should only create and display a single MediaStreamTrack on its side.

That's fine. What I was saying was that in a WebRTC context we don't 
really need this functionality for simulcast, and using it would require 
a new set of API functionality. But I understand Adam's response as that 
simulcast can be solved using 'application level' simulcasting, so there 
is really no issue.

>     I understand how this makes things cleaner in general. The issue I
>     have is that it interacts poorly with legacy uses.
>
>
>            (If
>     I agree that this could stand to be spelled out more clearly. I do
>     not think that doing so will prove particularly controversial.
>
>
>     /a
>     _________________________________________________
>     mmusic mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/mmusic
>     <https://www.ietf.org/mailman/listinfo/mmusic>
>
>