Subject: Re: [MMUSIC] Eric Rescorla's No Objection on draft-ietf-mmusic-rid-14: (with COMMENT)

From: Adam Roach <[email-masked]>
Date: Tue, 15 May 2018 19:42:05 -0500

> COMMENTS
>>       payload format and the associated SDP media description.  The SDP
>>       rtpmap and/or fmtp attributes are used, for a given PT, to describe
>>       the properties of the media that is carried in the RTP payload.
>>
>>       Recent advances in standards have given rise to rich multimedia
>>       applications requiring support for multiple RTP Streams within a RTP
> Nit; "an RTP"

Fixed everywhere.

>
>>       To expand on these points: [RFC3550] assigns 7 bits for the PT in the
>>       RTP header.  However, the assignment of static mapping of RTP payload
>>       type numbers to payload formats and multiplexing of RTP with other
>>       protocols (such as RTCP) could result in a limited number of payload
>>       type numbers available for application usage.  In scenarios where the
>>       number of possible RTP payload configurations exceed the available PT
> Nit: exceeds

Fixed.

>
>>       a=rid:<rid-id> <direction> [pt=<fmt-list>;]<restriction>=<value>...
>>
>>       An "a=rid" SDP media attribute specifies restrictions defining a
>>       unique RTP payload configuration identified via the "rid-id" field.
>>       This value binds the restriction to the RTP Stream identified by its
>>       RTP Stream Identifier SDES item [I-D.ietf-avtext-rid].  To be clear,
> SDES is kind of an overloaded term at this point.

Expanded on first use: "This specification makes use of the RTP Stream 
Identifier Source Description (SDES) RTCP item"

>
>>       the RtpStreamId SDES item described in [I-D.ietf-avtext-rid].  Such
>>       implementations MUST send it for all streams in an SDP media
>>       description ("m=") that have "a=rid" lines remaining after applying
>>       the rules in Section 6 and its subsections.
>>
>>       Implementations that use the "a=rid" parameter in SDP and that make
> This is pretty hard to follow. Let me see if I understand this.  You
> have a bunch of PTs and then each RID further restricts the parameters
> for the set of PTs that it applies to?

Right.

>
>>       media section ("m-line"); they do not necessarily need to be unique
>>       within an entire RTP session.  In traditional usage, each media
>>       section is sent on its own unique 5-tuple, which provides an
>>       unambiguous scope.  Similarly, when using BUNDLE
>>       [I-D.ietf-mmusic-sdp-bundle-negotiation], MID values associate RTP
>>       streams uniquely to a single media description.
> So you send both MID and RID in this case? That doesn't seem ideal,
> but perhaps it should be stated.

Added: "When RID is used with the BUNDLE mechanism, streams will be 
associated with both MID and RID SDES items."

>>       1.  The answerer ensures that the "a=rid" line is syntactically well
>>           formed.  In the case of a syntax error, the "a=rid" line is
>>           discarded.
>>
>>       2.  Extract the rid-id from the "a=rid" line and verify its
> This is in the imperative mode whereas the other steps are
> descriptive. You probably want them to match

Fixed.

>
>>       1.  The value of the "direction" field is reversed: "send" is changed
>>           to "recv", and "recv" is changed to "send".
>>
>>       2.  The answerer MAY choose to modify specific "a=rid" restriction
>>           values in the answer SDP.  In such a case, the modified value
>>           MUST be more restricted than the ones specified in the offer.
> restrictive?

Sure, I'll take that as an improvement.

>
>>           the offer, then the offerer SHALL discard the "a=rid" line.
>>
>>       3.  If the restrictions have been changed between the offer and the
>>           answer, the offerer MUST ensure that the modifications can be
>>           supported; if they cannot, the offerer SHALL discard the "a=rid"
>>           line.
> Should you be checking for "more restricted"

Good catch. Now:

  3. If the restrictions have been changed between the offer and the
     answer, the offerer MUST ensure that the modifications are more 
restrictive
     than they were in the original offer, and that they can be 
supported; if
     not, the offerer SHALL discard the "a=rid" line.

>
>>           comparison necessarily requires an understanding of the meaning
>>           of codec parameters, rather than a rote byte-wise comparison of
>>           their values.
>>
>>       6.  If the "a=rid" line contains a "pt=", the offerer verifies that
>>           the attribute values provided in the "a=rid" attributes are
> Why did you break this out. It seems to just be an addition (5)
>
>

(5) checks that the list of PTs is valid. (6) checks that the values 
associated with those PTs are valid. It's going to be two different 
checks. I think it's better broken out as a separate step.

You can view the diffs between -14 and -15 at 
<https://www.ietf.org/rfcdiff?url1=draft-ietf-mmusic-rid-14&url2=draft-ietf-mmusic-rid-15>

/a