Re: [MMUSIC] RTP taxonomy draft review [Re: Updated MSID draft - version -06]

[Paul Kyzivat <[e-mail]>]

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:
> [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
>
>
> On 6/27/14, 9:46 AM, DRAGE, Keith (Keith) 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
>>
>>> -----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
>>>
>>>
>>>
>>>
>>> .
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>