Subject: [MMUSIC] Comments to draft-alvestrand-mmusic-msid-00.txt

From: "Miguel A. Garcia" <[email-masked]>
Date: Fri, 14 Sep 2012 15:58:04 +0200

<as an individual>

Here are some comments to the MSID draft.

- General. I think it would be good to describe in general the structure 
of the draft. First indicating that it is going to extend the SSRC 
grouping framework by adding new grouping relations, and then saying that 
Section 4 describes how WebRTC implementations will benefit and use the 
already described extension.

- On section 1.1, I would like to see the authors framing the discussion 
a bit more. It is central to this draft to understand what an "RTP 
session is". Preferable, this there should be a pointer to RFC 3550 where 
RTP session is defined. And perhaps the draft should highlight the points 
of that definition that are most relevant for this draft (for example, 
that RTP and RTCP sent to two different ports are part of the same RTP 
session). I was just expecting something similar to the first two 
paragraphs of Section 3 in RFC 5576.

- Section 1.1, paragraphs 2 and 3 seem incomplete sentences to me. I was 
expecting that the sentence indicate what is the desired achievement of 
the indicated RFCs. I guess the desired effect is to create a relation 
between two or more RTP streams. Here is some proposed rewording:

The SSRC mechanism [RFC5576] can be used to associate RTP media streams 
when those RTP media streams are part of the same RTP session. The 
semantics of this mechanism prevent the association of RTP media streams 
that are spread across different RTP sessions.

The SDP grouping framework [RFC5888] can be be used to group RTP 
sessions. In the particular case when an RTP session has one and only one 
SSRC contributor, it is possible to associate RTP media streams spread 
across different RTP sessions. However, generally speaking, RTP sessions 
are composed of several SSRC contributors, in which case, the SDP 
grouping framework cannot be used for this purpose.

- Section 2. I would have expected this section to begin with an overall 
solution description, for example:

This document extends the Source-Specific Media Attributes framework 
[RFC5576] by adding a new "msid" attribute to the "a=ssrc" attribute in 
SDP. This new attribute allows endpoints to associate RTP media streams 
of diverse RTP sessions, as well as it allows to add application-specific 
association information.

- Section 2, second paragraph starts with a description of how to 
generate an "ID" without having defined what this "ID" is all about. 
Probably this paragraph should be moved after... the grammar, but the 
grammar does not have an "ID" either.

- Section 2, 4th paragraph should be prepended with: The extension 
defined in this document allows applications to exchange 
application-specific data in relation with the RTP Media stream associations.

- Section 2, grammar. The grammar should start with an anchor to RFC 
5576, since this document is an extension of it. Besides that, I am 
confused if the extension of the msid attribute is an extension to the 
"a=ssrc" attribute or the "a=ssrc-group".

- Section 2, Note on generation algorithm. I don't see the point of this 
note when the previous text has indicated that this is a 
randomly-generated string. I guess this should be deleted.

- Section 2, towards the end. I infer from the text, but not clearly saw 
it. I guess you are trying to express:

Endpoints MAY update the SDP by grouping and ungrouping RTP media streams 
as tehy wish. Implementations need to be ready to receive updates of the 
grouping at any time.

- Section 3, 2nd paragraph: "This OPTIONAL attributes". Well, all 
attributes are optional, so I don't see the point in having the word 
OPTIONAL here.

- Section 3. The ABNF of the msid-semantic needs to be anchored to the 
a=ssrc-group ABNF.

- Section 4, first paragraph says:

    The semantic for WebRTC Media Streams is "WMS".

I understand the principle, but you need to put the reader into context. 
How about some introductory paragraph:

This document creates a new semantic to be used to group several RTP 
Media streams into a WebRTC Media Stream. The associated token to this 
semantic is "WMS". WebRTC implementations will to signal the association 
of these RTP media streams into a WebRTC Media Stream should use the 
"WMS" token for their purpose.

Nits:

- The last sentence in the abstract refers the reader to the RTCWEB WG 
and list. I believe this should be changed to MMUSIC now.

- I would rename Section 1 to "Requirements for a new RTP media stream 
association mechanism".

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 15 Sep 2012 06:28:19 -0700

Thanks for the detailed comments! Will prepare an updated version, hold 
it for a little while in case of further comments, and then submit.

One pusbhack as a matter of principle: I do not believe it is good to 
add introductions that try to give a tutorial in the technologies that 
we are designing extensions to. At some level, introductions are going 
to get it wrong, and they won't be updated if the underlying documents 
change, years later, leaving wrong text in surprising places.

I do agree very much with making the definitions easily findable by 
adding pointers to the relevant documents and sections.

                        Harald

On 09/14/2012 06:58 AM, Miguel A. Garcia wrote:
> - General. I think it would be good to describe in general the 
> structure of the draft. First indicating that it is going to extend 
> the SSRC grouping framework by adding new grouping relations, and then 
> saying that Section 4 describes how WebRTC implementations will 
> benefit and use the already described extension.
>
> - On section 1.1, I would like to see the authors framing the 
> discussion a bit more. It is central to this draft to understand what 
> an "RTP session is". Preferable, this there should be a pointer to RFC 
> 3550 where RTP session is defined. And perhaps the draft should 
> highlight the points of that definition that are most relevant for 
> this draft (for example, that RTP and RTCP sent to two different ports 
> are part of the same RTP session). I was just expecting something 
> similar to the first two paragraphs of Section 3 in RFC 5576.
>
> - Section 1.1, paragraphs 2 and 3 seem incomplete sentences to me. I 
> was expecting that the sentence indicate what is the desired 
> achievement of the indicated RFCs. I guess the desired effect is to 
> create a relation between two or more RTP streams. Here is some 
> proposed rewording:
>
> The SSRC mechanism [RFC5576] can be used to associate RTP media 
> streams when those RTP media streams are part of the same RTP session. 
> The semantics of this mechanism prevent the association of RTP media 
> streams that are spread across different RTP sessions.
>
> sessions. In the particular case when an RTP session has one and only 
> one SSRC contributor, it is possible to associate RTP media streams 
> spread across different RTP sessions. However, generally speaking, RTP 
> sessions are composed of several SSRC contributors, in which case, the 
> SDP grouping framework cannot be used for this purpose.
>
> - Section 2. I would have expected this section to begin with an 
> overall solution description, for example:
>
> [RFC5576] by adding a new "msid" attribute to the "a=ssrc" attribute 
> in SDP. This new attribute allows endpoints to associate RTP media 
> streams of diverse RTP sessions, as well as it allows to add 
> application-specific association information.
>
> - Section 2, Note on generation algorithm. I don't see the point of 
> this note when the previous text has indicated that this is a 
> - Section 2, towards the end. I infer from the text, but not clearly 
> saw it. I guess you are trying to express:
>
> Endpoints MAY update the SDP by grouping and ungrouping RTP media 
> streams as tehy wish. Implementations need to be ready to receive 
> updates of the grouping at any time.
>
> I understand the principle, but you need to put the reader into 
> context. How about some introductory paragraph:
>
> semantic is "WMS". WebRTC implementations will to signal the 
> association of these RTP media streams into a WebRTC Media Stream 
> should use the "WMS" token for their purpose.
>
>
> Nits:
>