Subject: [MMUSIC] Updated MSID draft - version -06

From: Harald Alvestrand <[email-masked]>
Date: Fri, 27 Jun 2014 00:12:12 +0200

Flemming kindly pointed out to me that I had not actively notified the 
list about my new version of the -msid draft that was published on June 6.

Here's the changelog - the "detailed procedures" section has the 
"initial offer / initial answer" and so on format that was recommended 
by the chairs, so it may be of interest to this group.

Harald

C.12.  Changes from -05 to -06

    Addressed issues found in Fleming Andreassen's review

    Referenced JSEP rather than unified-plan for the M-line mapping model

    Relaxed MSID definition to allow "token-char" in values rather than
    a-z 0-9 hyphen; tightened ABNF by adding length description to it.

    Deleted discussion of abandoned alternatives, as part of preparing
    for publication.

    Added a "detailed procedures" section to the WMS semantics
    description.

    Added IANA registration of the "msid-semantic" attribute.

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 26 Jun 2014 19:51:14 -0400

Thanks Harald

It would be great if people could please take a look at the updated 
draft and see if they have any comments; we would like to get WGLC 
issued soon.

Thanks

-- Flemming (MMUSIC co-chair)

On 6/26/14, 6:12 PM, Harald Alvestrand wrote:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Suhas Nandakumar <[email-masked]>
Date: Fri, 27 Jun 2014 00:56:54 -0700

Hello Harald

  Thanks for the work on this draft. Below are few thoughts inline

* General Comment:
     + We might want to use RTP Taxonomy throughout
     + Replace MediaStream with "WebRTC MediaStream" for clarity
     + Replace MediaStreamTrack with "WebRTC MediaStreamTrack" clarity
     + m-line usage , can it be changed to m=line instead

* Section 1.1
This document adds a new Session Description Protocol (SDP) Grouping
[RFC5888] <http://tools.ietf.org/id/draft-ietf-mmusic-msid-06.html#RFC5888>
relation
between SDP m-lines [RFC4566]
<http://tools.ietf.org/id/draft-ietf-mmusic-msid-06.html#RFC4566> that can
associate application layer identifiers with the binding between media
streams, attaching identifiers to the media streams and attaching
identifiers to the groupings they form.

[Suhas] I am assuming we are referring to RTP Stream here

Section 1.2
SDP gives a description based on m-lines. According to the model used in
[I-D.ietf-rtcweb-jsep]
<http://tools.ietf.org/id/draft-ietf-mmusic-msid-06.html#I-D.ietf-rtcweb-jsep>,
each m-line describes exactly one media source, and if mulitple media
sources are carried in an RTP session, this is signalled using BUNDLE
[I-D.ietf-mmusic-sdp-bundle-negotiation]
<http://tools.ietf.org/id/draft-ietf-mmusic-msid-06.html#I-D.ietf-mmusic-sdp-bundle-negotiation>;
if BUNDLE is not used, each media source is carried in its own RTP session.
[Suhas] suggest updating the above para as

" SDP gives a description based on m-lines. According to the model used in
[I-D.ietf-rtcweb-jsep]
<http://tools.ietf.org/id/draft-ietf-mmusic-msid-06.html#I-D.ietf-rtcweb-jsep>,
each m-line describes exactly one media source (WebRTC MediaStreamTrack),
and if multiple media sources are carried in an RTP session, this is
signaled using BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation]
<http://tools.ietf.org/id/draft-ietf-mmusic-msid-06.html#I-D.ietf-mmusic-sdp-bundle-negotiation>
 mechanism ; if BUNDLE is not used, each media source is carried in its own
RTP session."

Section 1.2 Para 4
[Suhas] Para 3 doesn't force the need for a new mechanism and it is
probably a good idea to add more clarity in Para4 to clarify the need as
below"

"The SDP grouping framework [RFC5888]
<http://tools.ietf.org/id/draft-ietf-mmusic-msid-06.html#RFC5888> can be
used to group m-lines. When an m-line describes one and only one RTP Packet
stream, it is possible to associate RTP media streams across different
m-lines. However, cases such as when a m-line has multiple RTP Packets
streams or the need for an application to specify application-level
information about the association between the m-line and the group, the SDP
grouping framework cannot be used for this purpose"

* Section 1.3 Para 3
WebRTC defines a mapping (documented in [I-D.ietf-rtcweb-jsep]
<http://tools.ietf.org/id/draft-ietf-mmusic-msid-06.html#I-D.ietf-rtcweb-jsep>)
where one SDP m-line is used to describe each MediaStreamTrack, and that
the BUNDLE mechanism [I-D.ietf-mmusic-sdp-bundle-negotiation]
<http://tools.ietf.org/id/draft-ietf-mmusic-msid-06.html#I-D.ietf-mmusic-sdp-bundle-negotiation>
is
used to group MediaStreamTracks into RTP sessions.
[Suhas] we might want to say "MediaStreamTracks into a RTP Session" instead
of "MediaStreamTracks into RTP Sessions"

*Section 1.3 Para 3
Therefore, the need is to specify the ID of a MediaStreamTrack and its
associated MediaStream for each m-line, which can be accomplished with a
media-level SDP attribute.
[Suhas] Can we change it to
"
 Therefore, the need is to uniquely identify the MediaStreamTrack and its
MediaStream for each m-line via a media-level SDP attribute. This would
enable establishing the relationship between RTP Packet Streams that
correspond to same WebRTC MediaStream across m= lines".
"

* Section 2 Title
 [Suhas] Msid is not defined. Also suggest common convention. (MSID vs
Msid) throughout

Section 3

The ABNF of msid-semantic is:

  attribute =/ msid-semantic-attr
  msid-semantic-attr = "msid-semantic:" semantic identifier-list
  semantic = token ; see RFC 4566
  identifier-list = (" " identifier)* / " *"

[Suhas] The identifier-list MUST be msid not generic identifier. Since this
session level grouping applies only to msid or should it apply

* Section 4
[Suhas] Shouldn't we make appData MUST for WMS semantics. Since having a
MediaStream with no tracks into makes much sense. also the ABNF for appdata
is optional in Section 2.

* Section 4
[Suhas] When the m= section is updated to inactive, I am thinking we should
signal the MedaStreamTrack as ended, is that a right assumption ?

* Section 4
   In addition to signaling that the track is closed when its msid
attribute disappears from the SDP, the track will also be signaled as being
closed when all associated SSRCs have disappeared by the rules of
[Suhas] Probably a formatting glitch. The above sentence is incomplete

* Section 4
The association between SSRCs and m-lines is specified in
[I-D.ietf-rtcweb-jsep]
<http://tools.ietf.org/id/draft-ietf-mmusic-msid-06.html#I-D.ietf-rtcweb-jsep>
.
[Suhas] Why is this needed here ?

* Section 4.1 Title
[Suhas] Tracks undefined, suggest we change it to WebRTC MediaStreamTracks
or something like that.

* Section 4.1 Para 1
Non-WebRTC entities will not send msid
[Suhas] Suggest changing will not to may not .. since msid itself is
generic mechanism but WMS is webrtc specific mechanism

* Section 4.1
It follows from the above that media stream tracks in the "default" media
stream cannot be closed by removing the msid attribute; the application
must instead signal these as closed when the SSRC disappears according to
the rules of RFC 3550 section 6.3.4 and 6.3.5 or by disabling the m-line by
setting its port to zero.
[ Suhas ] "default" media stream and tracks aren't defined and we need some
context to explain this.

* Section 4.2.1
 How do we want to support adding  a track that is not part of a Media
Stream ? Should there be a msid line at all ?

* Section 4.2.1
 What should happen if the modified SDP has same msid but a different
trackId in the appData. Should we trigger ended on the old track and
created on the new track ?

Is it worthwhile considering the possibility of sending the TrackId in the
RTP Layer (as header extension) since it can identifies the Media Source
end to end.

*Section 4 - Offer/Answer Procedures
We might want to add some text to explain the following
 - An Offer has WMS semantic include, Answerer doesn't include the semantic
in response --> No WMS used for the session
 - Either Offer/Answer has a semantic which isn't understood by the
end-points --> No MSID mechanism is used and m= lines are rejected

Section 4.1 Says
"If a WebRTC entity sends a description, it MUST include the
msid-semantic:WMS attribute, even if no media streams are sent."
and Section 3 says
"This attribute MUST be present if "a=msid" is used."

So if i add both, it is not clear in the cases of recvonly/inactive streams
in the Offer, if we should include a=msid line If i wanted to include a
empty WMS semantic. So basically what mandates which is not very clear here
?

Section 4.2.2
- We need a line to parse the Semantics

Please let me know If i can help with aligning the draft with Taxonomy and
so on..

Thanks
Suhas Nandakumar

On Thu, Jun 26, 2014 at 4:51 PM, Flemming Andreasen <[email-masked]>
wrote:

> Thanks Harald
>
> It would be great if people could please take a look at the updated draft
> and see if they have any comments; we would like to get WGLC issued soon.
>
> Thanks
>
>> Here's the changelog - the "detailed procedures" section has the "initial
>> offer / initial answer" and so on format that was recommended by the
>> chairs, so it may be of interest to this group.
>>
>> Harald
>>

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 27 Jun 2014 10:41:58 +0200

Just a quick reply to the general comments...

>      + We might want to use RTP Taxonomy throughout

Yes. When the concepts are the same, we should. (what's the timeline for 
the RTP taxonomy?)
Can you help find terms that are not used identically with Taxonomy?

>      + Replace MediaStreamTrack with "WebRTC MediaStreamTrack" clarity

I would push back on that in any section where the section title or the 
same sentence includes "WebRTC".

So far "MediaStreamTrack" is used in the intro (WebRTC in the same 
sentence), section 1.1 (ditto), section 1.3 (WebRTC in heading), section 
4 (WebRTC in heading).

So the only usage concerned would be in Appendix B.

>      + m-line usage , can it be changed to m=line instead

I don't understand this comment - it is highly unusual to use the = sign 
to denote compound words.
It is possible that most occurences should be replaced with "media 
section". Would that be more readable?

>
> * Section 1.1
> This document adds a new Session Description Protocol (SDP) 
> Grouping[RFC5888] 
> <http://tools.ietf.org/id/draft-ietf-mmusic-msid-06.html#RFC5888> relation 
> <http://tools.ietf.org/id/draft-ietf-mmusic-msid-06.html#RFC4566> that 
> can associate application layer identifiers with the binding between 
> media streams, attaching identifiers to the media streams and 
> attaching identifiers to the groupings they form.
>

Since "RTP Stream" is not a defined term in 
draft-ietf-avtext-rtp-grouping-taxonomy - yes, I mean a packet stream, 
which RFC 3550 sometimes refers to as "media stream".
>
>
>
> Section 1.2
> SDP gives a description based on m-lines. According to the model used 
> in [I-D.ietf-rtcweb-jsep] 
> " SDP gives a description based on m-lines. According to the model 
> used in [I-D.ietf-rtcweb-jsep] 
> each m-line describes exactly one media source (WebRTC 
> MediaStreamTrack), and if multiple media sources are carried in an RTP 
> session, this is signaled using BUNDLE 
> <http://tools.ietf.org/id/draft-ietf-mmusic-msid-06.html#I-D.ietf-mmusic-sdp-bundle-negotiation> mechanism 
> ; if BUNDLE is not used, each media source is carried in its own RTP 
> session."

Section 1.2 is not WebRTC specific, so should not use WebRTC terms. The 
model used in JSEP doesn't have an independent formulation, 
unfortunately, but the main thrust of the argument for adopting it is 
that this is the model used by a significant portion of existing 
applications, so adopting that model for JSEP enhances interoperability.

"Media source" is a defined term in -taxonomy-.

> probably a good idea to add more clarity in Para4 to clarify the need 
> as below"
>
> <http://tools.ietf.org/id/draft-ietf-mmusic-msid-06.html#RFC5888> can 
> be used to group m-lines. When an m-line describes one and only one 
> RTP Packet stream, it is possible to associate RTP media streams 
> across different m-lines. However, cases such as when a m-line has 
> multiple RTP Packets streams or the need for an application to specify 
> application-level information about the association between the m-line 
> and the group, the SDP grouping framework cannot be used for this purpose"
This seems good. I'll adopt and/or adapt.

> where one SDP m-line is used to describe each MediaStreamTrack, and 
> that the BUNDLE mechanism [I-D.ietf-mmusic-sdp-bundle-negotiation] 
> <http://tools.ietf.org/id/draft-ietf-mmusic-msid-06.html#I-D.ietf-mmusic-sdp-bundle-negotiation> is 
> [Suhas] we might want to say "MediaStreamTracks into a RTP Session" 
> instead of "MediaStreamTracks into RTP Sessions"

No, because in the case of less than total Bundling, MediaStreamTracks 
will be grouped into multiple RTP sessions, not a single one.
> associated MediaStream for each m-line, which can be accomplished with 
> a media-level SDP attribute.
>  Therefore, the need is to uniquely identify the MediaStreamTrack and 
> its MediaStream for each m-line via a media-level SDP attribute. This 
> would enable establishing the relationship between RTP Packet Streams 
> that correspond to same WebRTC MediaStream across m= lines".
> "

Modulo "would" -> "will" ("would" is the wishful-thinking tense of the 
word, which I like to avoid - can't remember the grammatical name of the 
construct at the moment).

>  [Suhas] Msid is not defined. Also suggest common convention. (MSID vs 

The section is the definition of MSID, I'm not sure how to define the 
term before defining it.

I'd like to have the convention be "msid" (all lower case), but the RFC 
Editor likes capitals in section titles. I'll lowercase it and see if it 
survives. (I lowercased all occurences elsewhere in a previous pass)

> [Suhas] The identifier-list MUST be msid not generic identifier. Since 
> this session level grouping applies only to msid or should it apply

There is no "msid" ABNF construct. The "msid-attr" in section 2 is 
defined in terms of identifier.
So I can't parse this request.

>
> * Section 4
> [Suhas] Shouldn't we make appData MUST for WMS semantics. Since having 
> a MediaStream with no tracks into makes much sense. also the ABNF for 
> appdata is optional in Section 2.

It makes sense to say that it MUST be given. Will do.

>
> * Section 4
> [Suhas] When the m= section is updated to inactive, I am thinking we 
> should signal the MedaStreamTrack as ended, is that a right assumption ?

No, because "inactive" can be resumed.
"Ended" is a final state for a MediaStreamTrack.

> attribute disappears from the SDP, the track will also be signaled as 
> being closed when all associated SSRCs have disappeared by the rules of

In my copy, it continues with "[RFC3550] section 6.3.4 (BYE packet 
received) and 6.3.5 (timeout), and when the corresponding media section 
is disabled by setting the port number to zero.". What does it say in 
your copy?

> <http://tools.ietf.org/id/draft-ietf-mmusic-msid-06.html#I-D.ietf-rtcweb-jsep>.

It's not. Will remove.

>
> * Section 4.1 Title
> [Suhas] Tracks undefined, suggest we change it to WebRTC 
> MediaStreamTracks or something like that.

I think it would be correct to say "non-signalled packet streams".

> generic mechanism but WMS is webrtc specific mechanism

I'll change to "will not send msid with the WMS semantic". This is a 
leftover from before msid-semantic was introduced. Good catch!

>
> * Section 4.1
> It follows from the above that media stream tracks in the "default" 
> media stream cannot be closed by removing the msid attribute; the 
> application must instead signal these as closed when the SSRC 
> disappears according to the rules of RFC 3550 section 6.3.4 and 6.3.5 
> or by disabling the m-line by setting its port to zero.
> [ Suhas ] "default" media stream and tracks aren't defined and we need 
> some context to explain this.

This should be "tracks constructed by the above rule when no 
msid-semantic:WMS is present".
Good catch.

> Stream ? Should there be a msid line at all ?

This is not supported. Should it be?

> created on the new track ?

Yes.

>
> Is it worthwhile considering the possibility of sending the TrackId in 
> the RTP Layer (as header extension) since it can identifies the Media 
> Source end to end.

This is being considered for BUNDLE (appid). I don't want to try to do 
the same thing here, for fear of having duelling specifications.

>  - An Offer has WMS semantic include, Answerer doesn't include the 
> semantic in response --> No WMS used for the session

I don't see a reason for either of these things. Continuing to announce 
the data does no harm.
I can add "MUST ignore a=msid lines where the identifier is listed in a 
msid-semantic: header that the implementation does not support".

> So if i add both, it is not clear in the cases of recvonly/inactive 
> streams in the Offer, if we should include a=msid line If i wanted to 
> include a empty WMS semantic. So basically what mandates which is not 
> very clear here ?

4.1 is about WebRTC implementations. These MUST send msid-semantic:WMS, 
whether or not they have any a=msid in the SDP.

Non-WebRTC implementations that don't send a=msid don't have to send 
msid-semantic:.

Non-WebRTC implementations that send a=msid MUST send msid-semantic: so 
that it's possible to figure out what they mean by their a=msid lines.

Non-WebRTC implementations that use a different msid-semantic: must 
follow the rules for that semantic.

I don't see what's not clear here, but would appreciate suggestions for 
more text to make it clearer.

> - We need a line to parse the Semantics

Good catch. It needs to verify that the msid-semantic says WMS. (Since 
all of section 4.2 is about WMS, this is the only one we need to specify 
rules for.

>
> Please let me know If i can help with aligning the draft with Taxonomy 
> and so on..

Help appreciated!

>
>
> Thanks
> Suhas Nandakumar
>
> On Thu, Jun 26, 2014 at 4:51 PM, Flemming Andreasen 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Thanks Harald
>
>     It would be great if people could please take a look at the
>     updated draft and see if they have any comments; we would like to
>     get WGLC issued soon.
>
>     Thanks
>
>         Flemming kindly pointed out to me that I had not actively
>         notified the list about my new version of the -msid draft that
>         was published on June 6.
>
>         Here's the changelog - the "detailed procedures" section has
>         the "initial offer / initial answer" and so on format that was
>         recommended by the chairs, so it may be of interest to this group.
>
>         Harald
>
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 27 Jun 2014 13:46:22 +0000

The timeline for the taxonomy draft is that it is essentially ready for WGLC as soon as enough CLUE, RTCWEB and MMUSIC people have looked at it to say it is consistent with the documentation in that WG.

Is anyone reviewing (or indeed has reviewed it) from the MMUSIC perspective, or in respect of specific documents in the MMUSIC working group.

Keith 

> -----Original Message-----
> From: mmusic [mailto:[email-masked]] On Behalf Of 
> Harald Alvestrand
> Sent: 27 June 2014 09:42
> To: Suhas Nandakumar; Flemming Andreasen
> Cc: [email-masked]
> Subject: Re: [MMUSIC] Updated MSID draft - version -06
> 
> Yes. When the concepts are the same, we should. (what's the 
> timeline for the RTP taxonomy?) Can you help find terms that 
> are not used identically with Taxonomy?
> 
> 
> 
> I would push back on that in any section where the section 
> title or the same sentence includes "WebRTC".
> 
> So far "MediaStreamTrack" is used in the intro (WebRTC in the 
> same sentence), section 1.1 (ditto), section 1.3 (WebRTC in 
> heading), section 4 (WebRTC in heading).
> 
> I don't understand this comment - it is highly unusual to use 
> the = sign to denote compound words.
> It is possible that most occurences should be replaced with 
> "media section". Would that be more readable?
> 
> 
> 
> 	 
> 	 
> 
> 	* Section 1.1
> 	This document adds a new Session Description Protocol 
> (SDP) Grouping[RFC5888] 
> <http://tools.ietf.org/id/draft-ietf-mmusic-msid-06.html#RFC58
> 88>  relation between SDP m-lines [RFC4566] 
> <http://tools.ietf.org/id/draft-ietf-mmusic-msid-06.html#RFC45
> 66>  that can associate application layer identifiers with 
> the binding between media streams, attaching identifiers to 
> the media streams and attaching identifiers to the groupings 
> they form.
> 	
> 	
> draft-ietf-avtext-rtp-grouping-taxonomy - yes, I mean a 
> packet stream, which RFC 3550 sometimes refers to as "media stream".
> 
> 
> 
> 	
> 	
> 
> 	Section 1.2
> 	SDP gives a description based on m-lines. According to 
> the model used in [I-D.ietf-rtcweb-jsep] 
> <http://tools.ietf.org/id/draft-ietf-mmusic-msid-06.html#I-D.i
> etf-rtcweb-jsep> , each m-line describes exactly one media 
> source, and if mulitple media sources are carried in an RTP 
> session, this is signalled using BUNDLE 
> <http://tools.ietf.org/id/draft-ietf-mmusic-msid-06.html#I-D.i
> etf-mmusic-sdp-bundle-negotiation> ; if BUNDLE is not used, 
> each media source is carried in its own RTP session.
> 	
> 	" SDP gives a description based on m-lines. According 
> to the model used in [I-D.ietf-rtcweb-jsep] 
> <http://tools.ietf.org/id/draft-ietf-mmusic-msid-06.html#I-D.i
> etf-rtcweb-jsep> , each m-line describes exactly one media 
> source (WebRTC MediaStreamTrack), and if multiple media 
> sources are carried in an RTP session, this is signaled using 
> BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation] 
> <http://tools.ietf.org/id/draft-ietf-mmusic-msid-06.html#I-D.i
> etf-mmusic-sdp-bundle-negotiation>  mechanism ; if BUNDLE is 
> not used, each media source is carried in its own RTP session."
> 	
> 
> 
> Section 1.2 is not WebRTC specific, so should not use WebRTC 
> terms. The model used in JSEP doesn't have an independent 
> formulation, unfortunately, but the main thrust of the 
> argument for adopting it is that this is the model used by a 
> significant portion of existing applications, so adopting 
> that model for JSEP enhances interoperability.
> 
> 	[Suhas] Para 3 doesn't force the need for a new 
> mechanism and it is probably a good idea to add more clarity 
> in Para4 to clarify the need as below" 
> 	
> 	
> <http://tools.ietf.org/id/draft-ietf-mmusic-msid-06.html#RFC58
> 88>  can be used to group m-lines. When an m-line describes 
> one and only one RTP Packet stream, it is possible to 
> associate RTP media streams across different m-lines. 
> However, cases such as when a m-line has multiple RTP Packets 
> streams or the need for an application to specify 
> application-level information about the association between 
> the m-line and the group, the SDP grouping framework cannot 
> be used for this purpose"
> 
> <http://tools.ietf.org/id/draft-ietf-mmusic-msid-06.html#I-D.i
> etf-rtcweb-jsep> ) where one SDP m-line is used to describe 
> each MediaStreamTrack, and that the BUNDLE mechanism 
> <http://tools.ietf.org/id/draft-ietf-mmusic-msid-06.html#I-D.i
> etf-mmusic-sdp-bundle-negotiation>  is used to group 
> MediaStreamTracks into RTP sessions. 
> 	
> 	[Suhas] we might want to say "MediaStreamTracks into a 
> RTP Session" instead of "MediaStreamTracks into RTP Sessions"
> 
> 
> No, because in the case of less than total Bundling, 
> MediaStreamTracks will be grouped into multiple RTP sessions, 
> not a single one.
> 
> 
> 	
> 	
> 	*Section 1.3 Para 3
> 	Therefore, the need is to specify the ID of a 
> MediaStreamTrack and its associated MediaStream for each 
> m-line, which can be accomplished with a media-level SDP attribute.
> 	 Therefore, the need is to uniquely identify the 
> MediaStreamTrack and its MediaStream for each m-line via a 
> media-level SDP attribute. This would enable establishing the 
> relationship between RTP Packet Streams that correspond to 
> same WebRTC MediaStream across m= lines".
> 	"
> 
> 
> Modulo "would" -> "will" ("would" is the wishful-thinking 
> tense of the word, which I like to avoid - can't remember the 
> grammatical name of the construct at the moment).
> 
> 
> 
> 	
> 	
> 	* Section 2 Title
> 	 [Suhas] Msid is not defined. Also suggest common 
> convention. (MSID vs Msid) throughout
> 
> 
> The section is the definition of MSID, I'm not sure how to 
> define the term before defining it.
> 
> I'd like to have the convention be "msid" (all lower case), 
> but the RFC Editor likes capitals in section titles. I'll 
> lowercase it and see if it survives. (I lowercased all 
> occurences elsewhere in a previous pass)
> 
> 
> 
> 	
> 	
> 	Section 3
> 
> 	[Suhas] The identifier-list MUST be msid not generic 
> identifier. Since this session level grouping applies only to 
> msid or should it apply
> 
> 
> There is no "msid" ABNF construct. The "msid-attr" in section 
> 2 is defined in terms of identifier.
> 	[Suhas] Shouldn't we make appData MUST for WMS 
> semantics. Since having a MediaStream with no tracks into 
> makes much sense. also the ABNF for appdata is optional in Section 2.
> 
> 
> 	[Suhas] When the m= section is updated to inactive, I 
> am thinking we should signal the MedaStreamTrack as ended, is 
> that a right assumption ?
> 
> 
> 	   In addition to signaling that the track is closed 
> when its msid attribute disappears from the SDP, the track 
> will also be signaled as being closed when all associated 
> SSRCs have disappeared by the rules of
> In my copy, it continues with "[RFC3550] section 6.3.4 (BYE 
> packet received) and 6.3.5 (timeout), and when the 
> corresponding media section is disabled by setting the port 
> number to zero.". What does it say in your copy?
> 
> 
> 
> 
> 	* Section 4
> 	The association between SSRCs and m-lines is specified 
> <http://tools.ietf.org/id/draft-ietf-mmusic-msid-06.html#I-D.i
> etf-rtcweb-jsep> .
> 	
> 	[Suhas] Tracks undefined, suggest we change it to 
> WebRTC MediaStreamTracks or something like that.
> 
> 
> 	[Suhas] Suggest changing will not to may not .. since 
> msid itself is generic mechanism but WMS is webrtc specific mechanism
> 
> 
> I'll change to "will not send msid with the WMS semantic". 
> This is a leftover from before msid-semantic was introduced. 
> Good catch!
> 
> 
> 
> 
> 	
> 	
> 	* Section 4.1
> 	It follows from the above that media stream tracks in 
> the "default" media stream cannot be closed by removing the 
> msid attribute; the application must instead signal these as 
> closed when the SSRC disappears according to the rules of RFC 
> 3550 section 6.3.4 and 6.3.5 or by disabling the m-line by 
> 	[ Suhas ] "default" media stream and tracks aren't 
> defined and we need some context to explain this.
> 
> 
> 	 How do we want to support adding  a track that is not 
> part of a Media Stream ? Should there be a msid line at all ?
> 
> 
> 	 What should happen if the modified SDP has same msid 
> but a different trackId in the appData. Should we trigger 
> ended on the old track and created on the new track ?
> 
> 
> Yes.
> 
> 
> 
> 	
> 	
> 	Is it worthwhile considering the possibility of sending 
> the TrackId in the RTP Layer (as header extension) since it 
> can identifies the Media Source end to end.
> 
> 
> This is being considered for BUNDLE (appid). I don't want to 
> try to do the same thing here, for fear of having duelling 
> specifications.
> 
> 
> 
> 	
> 	
> 	 - An Offer has WMS semantic include, Answerer doesn't 
> include the semantic in response --> No WMS used for the session
> 	 - Either Offer/Answer has a semantic which isn't 
> understood by the end-points --> No MSID mechanism is used 
> and m= lines are rejected 
> 	
> 
> 
> I don't see a reason for either of these things. Continuing 
> to announce the data does no harm.
> I can add "MUST ignore a=msid lines where the identifier is 
> listed in a msid-semantic: header that the implementation 
> does not support".
> 
> 
> 
> 	 
> 	Section 4.1 Says
> 	"If a WebRTC entity sends a description, it MUST 
> include the msid-semantic:WMS attribute, even if no media 
> streams are sent."
> 	and Section 3 says
> 	So if i add both, it is not clear in the cases of 
> recvonly/inactive streams in the Offer, if we should include 
> a=msid line If i wanted to include a empty WMS semantic. So 
> basically what mandates which is not very clear here ?
> 
> 
> 4.1 is about WebRTC implementations. These MUST send 
> msid-semantic:WMS, whether or not they have any a=msid in the SDP.
> 
> Non-WebRTC implementations that don't send a=msid don't have 
> to send msid-semantic:.
> 
> Non-WebRTC implementations that send a=msid MUST send 
> msid-semantic: so that it's possible to figure out what they 
> mean by their a=msid lines.
> 
> Non-WebRTC implementations that use a different 
> msid-semantic: must follow the rules for that semantic.
> 
> I don't see what's not clear here, but would appreciate 
> suggestions for more text to make it clearer.
> 
> 
> 
> 	
> 	
> 	Section 4.2.2
> Good catch. It needs to verify that the msid-semantic says 
> WMS. (Since all of section 4.2 is about WMS, this is the only 
> one we need to specify rules for.
> 
> 
> 
> 	
> 	
> 	Please let me know If i can help with aligning the 
> draft with Taxonomy and so on..
> 
> 
> Help appreciated!
> 
> 
> 
> 
> 	
> 	
> 	Thanks
> 	Suhas Nandakumar
> 
> <[email-masked]> wrote:
> 	
> 
> 		Thanks Harald
> 		
> 		It would be great if people could please take a 
> look at the updated draft and see if they have any comments; 
> we would like to get WGLC issued soon.
> 		
> 		Thanks
> 		
> 			Flemming kindly pointed out to me that 
> I had not actively notified the list about my new version of 
> the -msid draft that was published on June 6.
> 			
> 			Here's the changelog - the "detailed 
> procedures" section has the "initial offer / initial answer" 
> and so on format that was recommended by the chairs, so it 
> may be of interest to this group.
> 			
> 			Harald
> 			
> 			   Referenced JSEP rather than 
> unified-plan for the M-line mapping model
>

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 27 Jun 2014 11:18:51 -0400

[updated subject]

Per Keith's question below, has anybody in the MMUSIC group reviewed the 
RTP taxonomy draft:

https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-grouping-taxonomy/

If so, please let the group and chairs know.

Thanks

-- Flemming

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 27 Jun 2014 13:02:06 -0400

The following are my comments on the -06 version:

Sections 2 & 2 (ABNF):

There is an error in the ABNF:

should be

      identifier-list = *(" " identifier) / " *"

Also, to formally check ABNF that extends 4566 it is necessary to merge 
the ABNFs. To facilitate this it would be good to ensure that all the 
new ABNF names introduced are unique across 4566. And since some 
implementers may need to merge many extensions, it would good to avoid 
defining new names that are overly generic and prone to collision. In 
particular, I suggest the following renamings would improve things:

identifier -> msid
appdata -> msid-data
semantic -> msid-semantic
identifier-list -> msid-list

Note: I'm not saying that these currently cause any conflicts. I don't 
think they do with 4566 itself, and I have no idea if they conflict with 
other extensions to 4566. I'm suggesting this as a matter of prudence 
and readability.

Section 3 says:

    This attribute MUST be present if "a=msid" is used.

This is true, but stronger constraints ought to be applied:

    Every identifier mentioned in an msid-semantic line MUST also
    appear in at least one a=msid line.

    The identifier in every a=msid line MUST be mentioned in
    *at least* (or perhaps *exactly*) one a=msid-semantic line.

Section 4.1:

The section refers to "WebRTC entity", but AFAIK there is no definition 
of this. I presume you don't mean to restrict this to browsers. IIUC you 
probably mean any entity that supports msid-semantic:WMS. Could you 
clarify the text?

Section 4.2:

This section should probably be called "Detailed Offer/Answer procedures".

The following:

    These procedures ...

    They are specifically applicable to the WMS semantic; other semantics
    will have their own consideration.

Is this really true? ISTM that there are some basic O/A procedures that 
apply to all msid-semantics. Specifically,

- If a particular msid-semantic is mentioned in an offer, and it is
   supported by the answerer, then a corresponding msid-semantic
   MUST be mentioned in the answer. (The absence indicates that it
   is not supported.)

So I think there is need of a "generic" set of O/A procedures. And then 
there can be additional O/A procedures specific to WMS. The existing 
sections 4.2.1 - 4.2.5 are just the WMS-specific ones.

Section 4.2.1:

This section should say something about msid-semantic. Some of the text 
from section 4.1 might do the job:

    If a WebRTC entity sends a description, it MUST include the msid-
    semantic:WMS attribute, even if no media streams are sent.

That covers everything I noticed.

	Thanks,
	Paul

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 28 Jun 2014 09:26:18 +0200

On 06/27/2014 07:02 PM, Paul Kyzivat wrote:
> Also, to formally check ABNF that extends 4566 it is necessary to
> merge the ABNFs. To facilitate this it would be good to ensure that
> all the new ABNF names introduced are unique across 4566. And since
> some implementers may need to merge many extensions, it would good to
> avoid defining new names that are overly generic and prone to
> collision. In particular, I suggest the following renamings would
> improve things:
>
> identifier -> msid
> appdata -> msid-data
> think they do with 4566 itself, and I have no idea if they conflict
> with other extensions to 4566. I'm suggesting this as a matter of
> prudence and readability.

I think this actually reduces readability, but that's a matter of taste.

One of our failiures with ABNF is that we never implemented a
modularization facility with official syntax for "identifier = <defined
in other document>".

>    *at least* (or perhaps *exactly*) one a=msid-semantic line.

Not a bad idea. The wildcard identifier (*) counts as
> Section 4.1:
>
> The section refers to "WebRTC entity", but AFAIK there is no
> definition of this. I presume you don't mean to restrict this to
> browsers. IIUC you probably mean any entity that supports
> msid-semantic:WMS. Could you clarify the text?

With the split in -overview recently into "WebRTC browsers" and "WebRTC
devices", this is actually limited to WebRTC browsers, since the SDP in
question only appears on the Javscript API, and implementing the
Javascript API is only a requirement for browsers....

> Is this really true? ISTM that there are some basic O/A procedures
> that apply to all msid-semantics. Specifically,
>
> So I think there is need of a "generic" set of O/A procedures. And
> then there can be additional O/A procedures specific to WMS. The
> existing sections 4.2.1 - 4.2.5 are just the WMS-specific ones.

My problem is that I don't want to write the generic ones, because I
don't have any idea what they should say.

This is a generic problem with the generic mechanism - we can't define
rules for what doesn't exist yet, and it's not possible to see what
parts of the rules are true for any use of msid and what parts of the
rules are true for WMS only before we start seeing a second usage.

At the moment we have zero value to the generic mechanism, because we
have zero potential usages of it. Writing something that has zero value
does not appeal greatly to me.

I suggested earlier that we might instead rip out the whole generalized
mechanism and go back to msid being WMS only. I got no responses on that
suggestion (neither positive or negative - it was ignored).

This suggestion of another set of for-now-useless sections in the
document makes me reiterate that proposal. Can you comment on it?

>
> Section 4.2.1:
>
> This section should say something about msid-semantic. Some of the
> text from section 4.1 might do the job:
>

Yes.

-- 
Surveillance is pervasive. Go Dark.

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 30 Jun 2014 13:43:57 -0400

> I think this actually reduces readability, but that's a matter of taste.
I'm with Paul on this one and would prefer something along the lines of 
what he suggested.

> Javascript API is only a requirement for browsers....
Are you suggesting any changes here (seems to me we shouldn't limit the 
mechanism to just browsers, which I think was Paul's point as well) ?
> does not appeal greatly to me.
For an MMUSIC document extending SDP, we do need O/A sections following 
the structure of RFC 3264. If you need help writing those, the chairs 
can try and find somebody to assist.

> document makes me reiterate that proposal. Can you comment on it?
My initial reaction for an MMUSIC document would be against that, but 
can you provide a pointer or resend the proposal so we can take another 
look and discuss it.

Thanks

-- Flemming

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 30 Jun 2014 13:53:01 -0400

I haven't fully reviewed it. But I've been checking alignment with clue 
usage. And one question I have is which way references should point.

Right now the taxonomy has a section called Mapping from Existing Terms. 
This has come CLUE terms in it, and effectively defines them relative to 
the terms defined in the concepts section. Some of these definitions are 
different in detail from those in the CLUE documents, though for the 
most part the same in spirit.

Obviously this can only be done for usages that are known before the 
taxonomy is finally published as an RFC. After that, documents that 
define their own terms relative to the taxonomy will have to publish the 
relationship in their own document.

What should we do in our effort to rationalize the clue terminology with 
the taxonomy?

- copy the description of the clue term from the taxonomy into the
   clue documents, and retain it in the taxonomy.

- remove the description of the clue term from the taxonomy and put
   an appropriate definition into the clue docs, relating to the
   terms defined in the concepts section of the taxonomy.

Note that we may want to delay the publication of the taxonomy until 
this can be completed.

Also, CLUE has been using the term MCU, which wasn't defined in the 
taxonomy, but has since been added. The taxonomy definition looks good, 
better than the one currently in clue. But the clue definition is 
specialized to clue, in that we assume the MCU is capable of supporting 
the CLUE features.

ISTM that for this one the "right" answer is for clue to define a new 
term (e.g., CLUE-MCU) that is a specialization of the taxonomy 
definition of MCU. That unfortunately means we will have to update all 
of our documents.

This seems to be something that will come up a lot in general - 
specializations of concepts that are generic in the taxonomy.  I wonder 
if the taxonomy should talk about this.

	Thanks,
	Paul

On 6/27/14 11:18 AM, Flemming Andreasen wrote:
>> The timeline for the taxonomy draft is that it is essentially ready
>> for WGLC as soon as enough CLUE, RTCWEB and MMUSIC people have looked
>> at it to say it is consistent with the documentation in that WG.
>>
>> Is anyone reviewing (or indeed has reviewed it) from the MMUSIC
>> perspective, or in respect of specific documents in the MMUSIC working
>> group.
>>
>> Keith
>>

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 30 Jun 2014 20:02:32 +0200

On 06/30/2014 07:43 PM, Flemming Andreasen wrote:
> I'm with Paul on this one and would prefer something along the lines
> of what he suggested.
>
> Are you suggesting any changes here (seems to me we shouldn't limit
> the mechanism to just browsers, which I think was Paul's point as well) ?

The requirement (the "MUST implement") is on WebRTC browsers, not WebRTC
devices.

> For an MMUSIC document extending SDP, we do need O/A sections
> following the structure of RFC 3264. If you need help writing those,
> the chairs can try and find somebody to assist.

I have those. What I object to is writing two of them.

> can you provide a pointer or resend the proposal so we can take
> another look and discuss it.

What's the argument, based in an use case, for leaving the generic
mechanism in?

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 30 Jun 2014 14:12:44 -0400

> mechanism to just browsers, which I think was Paul's point as well) ?

I'm not certain. I *think* that the two ends need to agree on how this 
works and is used. If one end is a browser, then the other end may need 
to understand about MediaStreams and MediaStreamTracks, and follow these 
rules. That's true whether the other end is also a browser or not.

And an endpoint that sometimes talks to browsers may want to use the 
same mechanisms even when no browser is present.

IOW, istm that this is really about rules for use of the WMS semantic, 
not rules for browsers.

But I'm not sure I understand it properly.

>> don't have any idea what they should say.

I don't think this is so hard. It is very similar to general O/A 
requirements for the grouping framework.

> can try and find somebody to assist.

I've already started "helping". I am willing to continue doing so.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 30 Jun 2014 14:18:36 -0400

> The requirement (the "MUST implement") is on WebRTC browsers, not WebRTC

I don't understand. Suppose I have a browser talking to a non-browser. 
And the non-browser end decides to add an m-line that represents another 
m-line. To be specific, suppose it decides to add video where previously 
there was only audio. And the video "goes with" the audio.

Doesn't it need to use this stuff to indicate the relationship?

	Thanks,
	Paul

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 30 Jun 2014 19:02:24 +0000

As an individual, I see the taxonomy document as the document other documents will reference for the definitions they use.

i.e. the CLUE, MMUSIC and RTCWEB documents might well have paragraphs in their near the start of their documents that says:

"xx	Definitions

<term1>: see draft-ietf-avtext-taxonomy
<term2>: see draft-ietf-avtext-taxonomy

Therefore it really needs to be published as soon as we want to publish the first of those other documents. That first document may well not be a CLUE document.

Some of the backward type references you identify could well be examples, so these will be informative (as currently given), and therefore not necessary to hold in relation to publication.

Regards

Keith

> Paul Kyzivat
> Sent: 30 June 2014 18:53
> To: [email-masked]
> Subject: Re: [MMUSIC] RTP taxonomy draft review [Re: Updated 
> MSID draft - version -06]
> 
> I haven't fully reviewed it. But I've been checking alignment 
> with clue usage. And one question I have is which way 
> references should point.
> 
> This has come CLUE terms in it, and effectively defines them 
> relative to the terms defined in the concepts section. Some 
> of these definitions are different in detail from those in 
> the CLUE documents, though for the most part the same in spirit.
> 
> Obviously this can only be done for usages that are known 
> before the taxonomy is finally published as an RFC. After 
> that, documents that define their own terms relative to the 
> taxonomy will have to publish the relationship in their own document.
> 
> What should we do in our effort to rationalize the clue 
> terminology with the taxonomy?
> 
> Note that we may want to delay the publication of the 
> taxonomy until this can be completed.
> 
> Also, CLUE has been using the term MCU, which wasn't defined 
> in the taxonomy, but has since been added. The taxonomy 
> definition looks good, better than the one currently in clue. 
> But the clue definition is specialized to clue, in that we 
> assume the MCU is capable of supporting the CLUE features.
> 
> ISTM that for this one the "right" answer is for clue to 
> define a new term (e.g., CLUE-MCU) that is a specialization 
> of the taxonomy definition of MCU. That unfortunately means 
> we will have to update all of our documents.
> 
> This seems to be something that will come up a lot in general 
> - specializations of concepts that are generic in the 
> taxonomy.  I wonder if the taxonomy should talk about this.
> 
> 	Thanks,
> 	Paul
> 
> > Per Keith's question below, has anybody in the MMUSIC group 
> reviewed 
> > the RTP taxonomy draft:
> >
> > 
> >> perspective, or in respect of specific documents in the MMUSIC 
> >> working group.
> >>
> >> Keith
> >>
> >>> From: mmusic [mailto:[email-masked]] On Behalf Of Harald 
> >>> Alvestrand
> >>> Sent: 27 June 2014 09:42
> >>> Yes. When the concepts are the same, we should. (what's 
> the timeline 
> >>> for the RTP taxonomy?) Can you help find terms that are not used 
> >>> identically with Taxonomy?
> >>>
> >>>
> >>>
> >>>          + Replace MediaStreamTrack with "WebRTC 
> MediaStreamTrack" 
> >>> clarity
> >>>
> >>>
> >>> I would push back on that in any section where the 
> section title or 
> >>> the same sentence includes "WebRTC".
> >>>
> >>> sentence), section 1.1 (ditto), section 1.3 (WebRTC in heading), 
> >>> section 4 (WebRTC in heading).
> >>>
> >>> I don't understand this comment - it is highly unusual to 
> use the = 
> >>> sign to denote compound words.
> >>> the binding between media streams, attaching identifiers to the 
> >>> media streams and attaching identifiers to the groupings 
> they form.
> >>>
> >>>
> >>> draft-ietf-avtext-rtp-grouping-taxonomy - yes, I mean a packet 
> >>> stream, which RFC 3550 sometimes refers to as "media stream".
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>     Section 1.2
> >>>     SDP gives a description based on m-lines. According 
> to the model 
> >>> source, and if mulitple media sources are carried in an 
> RTP session, 
> >>> this is signalled using BUNDLE 
> >>>     " SDP gives a description based on m-lines. According to the 
> >>> model used in [I-D.ietf-rtcweb-jsep] 
> sources are 
> >>> carried in an RTP session, this is signaled using BUNDLE 
> >>> Section 1.2 is not WebRTC specific, so should not use 
> WebRTC terms. 
> >>> The model used in JSEP doesn't have an independent formulation, 
> >>> unfortunately, but the main thrust of the argument for 
> adopting it 
> >>> is that this is the model used by a significant portion 
> of existing 
> mechanism and it 
> >>> is probably a good idea to add more clarity in Para4 to 
> clarify the 
> >>> need as below"
> >>>
> >>>
> application-level 
> >>> information about the association between the m-line and 
> the group, 
> >>> the SDP grouping framework cannot be used for this purpose"
> >>>
> >>>     [Suhas] we might want to say "MediaStreamTracks into a RTP 
> >>> Session" instead of "MediaStreamTracks into RTP Sessions"
> >>>
> >>>
> >>> MediaStreamTracks will be grouped into multiple RTP 
> sessions, not a 
> >>> single one.
> >>>
> >>>
> >>>
> >>>
> >>>     *Section 1.3 Para 3
> MediaStreamTrack 
> >>> and its associated MediaStream for each m-line, which can be 
> >>> accomplished with a media-level SDP attribute.
> >>> relationship between RTP Packet Streams that correspond to same 
> >>> WebRTC MediaStream across m= lines".
> >>>     "
> >>>
> >>>
> tense of 
> >>> the word, which I like to avoid - can't remember the grammatical 
> >>> name of the construct at the moment).
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>     * Section 2 Title
> >>>      [Suhas] Msid is not defined. Also suggest common convention. 
> >>> (MSID vs Msid) throughout
> >>>
> >>>
> >>> The section is the definition of MSID, I'm not sure how to define 
> >>> the term before defining it.
> >>>
> >>> I'd like to have the convention be "msid" (all lower 
> case), but the 
> >>> RFC Editor likes capitals in section titles. I'll 
> lowercase it and 
> >>> see if it survives. (I lowercased all occurences elsewhere in a 
> >>> previous pass)
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>     Section 3
> >>>
> identifier. 
> >>> Since this session level grouping applies only to msid or 
> should it 
> >>> apply
> >>>
> >>>
> semantics. Since 
> >>> having a MediaStream with no tracks into makes much 
> sense. also the 
> >>> ABNF for appdata is optional in Section 2.
> >>>
> >>>
> >>>     [Suhas] When the m= section is updated to inactive, I am 
> >>> thinking we should signal the MedaStreamTrack as ended, is that a 
> >>> right assumption ?
> >>>
> >>>
> >>>        In addition to signaling that the track is closed when its 
> >>> msid attribute disappears from the SDP, the track will also be 
> >>> signaled as being closed when all associated SSRCs have 
> disappeared 
> >>> by the rules of
> >>> received) and 6.3.5 (timeout), and when the corresponding media 
> >>> section is disabled by setting the port number to zero.". 
> What does 
> >>> it say in your copy?
> >>>
> >>>
> >>>
> >>>
> >>>     * Section 4
> >>>     [Suhas] Suggest changing will not to may not .. since msid 
> >>> itself is generic mechanism but WMS is webrtc specific mechanism
> >>>
> >>>
> >>>     It follows from the above that media stream tracks in the 
> >>> "default" media stream cannot be closed by removing the msid 
> >>> attribute; the application must instead signal these as 
> closed when 
> >>> the SSRC disappears according to the rules of RFC 3550 
> section 6.3.4 
> >>> and 6.3.5 or by disabling the m-line by setting its port to zero.
> >>>
> >>>      How do we want to support adding  a track that is 
> not part of a 
> >>> Media Stream ? Should there be a msid line at all ?
> >>>
> >>>
> >>>      What should happen if the modified SDP has same msid but a 
> >>> different trackId in the appData. Should we trigger ended 
> on the old 
> >>> track and created on the new track ?
> >>>
> >>>
> >>> Yes.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>     Is it worthwhile considering the possibility of sending the 
> >>> TrackId in the RTP Layer (as header extension) since it can 
> >>> identifies the Media Source end to end.
> >>>
> >>>
> >>> This is being considered for BUNDLE (appid). I don't want 
> to try to 
> >>> do the same thing here, for fear of having duelling 
> specifications.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>      - An Offer has WMS semantic include, Answerer 
> doesn't include 
> >>> the semantic in response --> No WMS used for the session
> understood by 
> >>> the end-points --> No MSID mechanism is used and m= lines are 
> >>> rejected
> >>>
> >>>
> >>>
> >>> I don't see a reason for either of these things. Continuing to 
> >>> announce the data does no harm.
> >>> I can add "MUST ignore a=msid lines where the identifier 
> is listed 
> >>> in a msid-semantic: header that the implementation does not 
> >>> support".
> >>>
> >>>
> >>>
> >>>
> >>>     Section 4.1 Says
> >>> recvonly/inactive streams in the Offer, if we should 
> include a=msid 
> >>> line If i wanted to include a empty WMS semantic. So 
> basically what 
> >>> msid-semantic: so that it's possible to figure out what 
> they mean by 
> >>> their a=msid lines.
> >>>
> >>> Good catch. It needs to verify that the msid-semantic says WMS. 
> >>> (Since all of section 4.2 is about WMS, this is the only 
> one we need 
> >>> to specify rules for.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>     Please let me know If i can help with aligning the draft with 
> >>> Taxonomy and so on..
> >>>
> >>>
> >>> Help appreciated!
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>     Thanks
> >>>     Suhas Nandakumar
> >>>
> look at the 
> >>>             Flemming kindly pointed out to me that I had not 
> >>> actively notified the list about my new version of the 
> -msid draft 
> >>> that was published on June 6.
> >>>
> >>> and so on format that was recommended by the chairs, so 
> it may be of 
> >>> interest to this group.
> >>>
> >>>             Harald
> >>>
> >>>                Deleted discussion of abandoned 
> alternatives, as part 
> >>> of preparing
> >>>                for publication.
> >>>

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 01 Jul 2014 08:35:42 +0200

On 06/30/2014 08:18 PM, Paul Kyzivat wrote:
> And the non-browser end decides to add an m-line that represents
> another m-line. To be specific, suppose it decides to add video where
> previously there was only audio. And the video "goes with" the audio.
>

OK, I was off on the wrong tangent.

The actual text concerned is this one:

4.1.  Handling of non-signalled tracks

   Non-WebRTC entities will not send msid.  This means that there will
   be some incoming RTP packets that the recipient has no predefined
   MediaStream id value for.

This is a subsection of

4.  Applying Msid to WebRTC MediaStreams

What it SHOULD be saying is

  "Entities that do not implement the WMS semantic will not send
"msid-semantic:WMS".

It's kind of an oxymoron.

What WebRTC entities do and do not do is actually irrelevant to this
spec; it is the task of a completely different document (JSEP) to say
that WebRTC browsers MUST implemenet this spec.

I'll make the correction.