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

["DRAGE, Keith (Keith)" <[e-mail]>]

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:[e-mail]] On Behalf Of 
> Harald Alvestrand
> Sent: 27 June 2014 09:42
> To: Suhas Nandakumar; Flemming Andreasen
> Cc: [e-mail]
> Subject: Re: [MMUSIC] Updated MSID draft - version -06
> 
> Just a quick reply to the general comments...
> 
> 
> On 06/27/2014 09:56 AM, Suhas Nandakumar wrote:
> 
> 
> 	Hello Harald 
> 
> 	  Thanks for the work on this draft. Below are few 
> thoughts inline
> 
> 	* General Comment: 
> 	     + 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 MediaStream with "WebRTC MediaStream" for clarity
> 	     + 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#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.
> 	
> 	
> 	[Suhas] I am assuming we are referring to RTP Stream here
> 
> 
> 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] 
> <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 
> [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> ; 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.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.
> 
> "Media source" is a defined term in -taxonomy-.
> 
> 
> 
> 	
> 	
> 	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#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"
> 
> This seems good. I'll adopt and/or adapt.
> 
> 
> 
> 
> 	* 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.i
> etf-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.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.
> 	[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".
> 	"
> 
> 
> 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
> 
> 	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
> 
> 
> 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.
> 
> 
> 
> 	
> 	
> 
> 	* 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
> 
> 
> 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 
> in [I-D.ietf-rtcweb-jsep] 
> <http://tools.ietf.org/id/draft-ietf-mmusic-msid-06.html#I-D.i
> etf-rtcweb-jsep> .
> 	
> 	[Suhas] Why is this needed here ?
> 	
> 
> 
> 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".
> 
> 
> 
> 	
> 	
> 	* 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
> 
> 
> 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.
> 
> 
> 
> 	
> 	
> 	* 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 ?
> 
> 
> This is not supported. Should it be?
> 
> 
> 
> 	
> 	
> 	* 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 ?
> 
> 
> 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.
> 
> 
> 
> 	
> 	
> 	*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 
> 	
> 
> 
> 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
> 	"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 ?
> 
> 
> 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
> 	- 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 
> <[e-mail]> 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 (MMUSIC co-chair) 
> 
> 
> 
> 		On 6/26/14, 6:12 PM, Harald Alvestrand wrote:
> 		
> 
> 			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.
> 			
> 			_______________________________________________
> 			mmusic mailing list
> 			[e-mail]
> 			https://www.ietf.org/mailman/listinfo/mmusic
> 			
> 			
> 
> 
> 		_______________________________________________
> 		mmusic mailing list
> 		[e-mail]
> 		https://www.ietf.org/mailman/listinfo/mmusic
> 		
> 
> 
> 
>