Re: [MMUSIC] WGLC on draft-ietf-mmusic-rid-06

[Adam Roach <[e-mail]>]

On 7/12/16 09:30, Magnus Westerlund wrote:
> 1. Section 2:
>
>    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 limited number of payload
>    type numbers available for application usage.
>
> Is still the state of the implementations such that overriding a 
> static payload doesn't work?

If you're counting by implementation, I don't know how prevalent it is. 
If you 're counting by deployed instances, it's fiercely high. There is 
one major, major vendor in the SIP space that uses a stack in many of 
its endpoints which rejects any offer that attempts to assign values to 
PTs less than 96. It's wrong and annoying, but it's very widely 
deployed, and it effectively forces all other implementations to limit 
their remapping to the 96-127 range.

> 2. Section 4:
>
>    This value binds the restriction to the RTP Stream identified by its
>    RTP Stream Identifier SDES item [I-D.ietf-avtext-rid].
>
> The draft is missing a statement making clear that if one implements 
> mmusic-rid, then one is required to also implement avtext-rid using 
> RFC 2119 langauge. Yes, I realize implicitly that this is the case, 
> but I think one should make it explicit so that no one glancing it 
> through misses this aspect and to avoid future debates.

Done.

> I also think there exist a question if one MUST include the SDES item, 
> in the RTP stream, even when the PT is

I think I know where you're going with this sentence. Updated:

An "a=rid" SDP media attribute specifies constraints 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, 
implementations
that use the "a=rid" parameter in SDP MUST support the RtpStreamId
SDES item described in {{I-D.ietf-avtext-rid}}. Such implementations
MUST send it for all streams in an m-section that has "a=rid" lines
remaining after applying the rules in {{sec-sdp_o_a}} and its subsections.


> 3. Section 4:
>
>    This framework MAY be used in combination with the "a=fmtp" SDP
>    attribute for describing the media format parameters for a given RTP
>    Payload Type.  In such scenarios, the "a=rid" constraints (Section 5)
>    further constrain the equivalent "a=fmtp" attributes.
>
> I wonder if this should include a bit of clearer purpose declration 
> here. By using rid one can hopefully create more generic PTs that are 
> focused on the codec and basic payload type configuration, and thus 
> put the more detailed contrains to the rid. The introduction hints at 
> this but I would prefer if this is made clearer as intended result of 
> using rid.
>
> Possibly this may better belong in this Section 2 paragraph:
>
>   The additional constraints on individual streams are indicated with a
>    new "a=rid" SDP attribute.  Note that the constraints communicated
>    via this attribute only serve to further constrain the parameters
>    that are established on a PT format.  They do not relax any existing
>    restrictions.

I'm fine moving the paragraph.

> 4. Section 4:
>
>    This framework MAY be used in combination with the "a=fmtp" SDP
>    attribute for describing the media format parameters for a given RTP
>    Payload Type.
>
> I wonder if "MAY" is really the right RFC2119 word here. I don't see 
> how you can't use a=fmtp to define the PTs. Because this leads my 
> thought in the direction that you can use a=rid only and not use the 
> whole PT declration mechansism with m= lines, a=rtpmap and a=fmtp. I 
> don't believe this is the intention here.

I don't follow what you're saying here. If we didn't already have text 
in here requiring a=fmtp if it's needed to interpret the type without 
a=rid, I'd think it was that. But since we mention that requirement a 
couple of places, I have to assume that's not what you mean.

Can you propose some text?

> 5. Section 4:
>
>    A given
>    "rid-id" MUST NOT be repeated in a given media description ("m="
>    section).
>
> So this indicates a uniqueness requirement on media description level, 
> but does not discuss how a receiver gets to correctly identify the RTP 
> Stream within an RTP session to the Media Description, as this is what 
> an actual receiver needs to deal with.
>
> Section 6 says:
>
>    Note that "rid-id" values are only required to be unique within a
>    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.
>
> What the above section 6 text doesn't cover is multiparty cases, when 
> a receiver can receive RTP streams from multiple endpoints matching a 
> particular media description, something that can occur in declarative 
> use cases. In this case, one could add the CNAME will work as clear 
> separator.

Sure. I'm not familiar with declarative receive situations, so I have a 
hard time reasoning about them. I'm aware of the use of SDP in 
conjunction with SAP for declarative sending, but can't come up with an 
analog for receive. Can you give an example?

> Then there are the declarative interpretation that each media 
> description is an RTP session. And in some cases, that could mean that 
> one thinks multiple media sources fits a particular media description. 
> I have no idea if there are actual deployed cases of this. However, I 
> think the reasonable way forward here is to document the assumption 
> that this is based on that even in declarative cases where there might 
> be multiple endpoints that sends according to a specific media 
> description, this only supports one media source.
>
> To conclude, I think the text about this needs be extended to cover 
> the different cases better and make clear that there exist a 
> requirement here. And the assumption that we don't need to solve 
> multiple media sources from the same endpoint sent according to one 
> media description (declarative usage).

At one point, we debated whether to include declarative uses of RID, 
with my inclination being to forbid its use (since the rationale for 
defining it largely doesn't exist with declarative use cases). I was 
convinced that allowing its use was at worst harmless, and that it would 
be trivial to specify. It's sounding increasingly less trivial, so my 
inclination is to go back to disallowing it (or, at least, leaving it to 
another document to specify if a need arises).


>
> 6. Section 5:
>
>    o  max-bpp, for maximum number of bits per pixel, calculated as an
>       average of all samples of any given coded picture.  This is
>       expressed as a floating point value, with an allowed range of
>       0.0001 to 48.0.
>
> Does this need a clarification that any values outside of the range 
> will be encoded with the closest value allowed?

I'm not sure we need to accommodate people putting invalid values in 
here any more than we need to accommodate people putting emoji in here 
-- and out-of-range values are invalid.

> Secondly, the floating point value, how many digits of decimals are 
> allowed? Is this intended to fit in an 32-bit or 64-bit floating point 
> representation or something else?

Added "These values MUST be encoded with at most four digits to the 
right of the decimal point."

> 7. Section 5:
>
>    While
>    this document does not define constraints for audio codecs, there is
>    no reason such constraints should be precluded from definition and
>    registration by other documents.
>
> I think this could add that additional media types are also possible. 
> Possible formulation:
>
>    While this document does not define constraints for audio codecs or 
> any other media types than video, there is no reason such constraints 
> should be precluded from definition and registration by other documents.

Done.

>
> 8. section 6.2.2:
>
>   3.  If the "a=rid" line contains a "pt=", the list of payload types
>        is verified against the list of valid payload types for the media
>        section (that is, those listed on the "m=" line).  Any PT missing
>        from the "m=" line is removed from the set of valued in the
>        "pt=".
>
> This may need handling of the case if the last action results in that 
> the set of PTs in "pt=" becomes empty, then the whole a=rid line needs 
> to be discarded. This as the RID was intended for a limited set of 
> PTs, rather than the default any PT which no "pt=" implies.

Good catch. I've added text:
     If no values are left in the "pt=" parameter after this processing, 
then the "a=rid" line is removed.



> 9. Section 6.2.2:
>
>    5.  If the "depend" constraint is included, the answerer MUST make
>        sure that the listed rid-ids unambiguously match the rid-ids in
>        the SDP offer.  Any "a=rid" lines that do not are removed.
>
> I fail to find a definition of the "depend" constraint in the 
> document. I do find an example using it in addition to the above text.

Huh. I don't know how we missed this. I thought it was in here at some 
point, but it must have been edited out...?

Anyway:

  * depend, to identify other streams that the stream depends on. The value
    is a comma-separated list of rid-ids. These rid-ids identify RTP streams
    that this stream depends on in order to allow for proper interpretation.


> 10. Section 6.4:
>
>        Note that this matching must be performed
>        semantically rather than on literal PT values, as the remote end
>        may not be using symmetric PTs.  For the purpose of this
>        comparison: for each PT listed on the "a=rid" line in the answer,
>        the offerer looks up the corresponding "a=rtpmap" and "a=fmtp"
>        lines in the answer.
>
> I am a bit worried that this is still misunderstood to mean that one 
> can do "byte comparison" of the parameters for a PT. The reality of 
> this comparison is after all that you must compare the parameters that 
> are required to be the same between offer and answer. And that is 
> payload format specific. I would suggest that one makes it clear that 
> in many cases this semantically comparison requires payload format 
> understanding.

Added:

    Note that this semantic comparison
    necessarily requires an understanding of the meaning of codec 
parameters,
    rather than a rote byte-wise comparison of their values.

> 11. Section 7.
>
> Needs to be clarified requirements on being able to determine which 
> rid-identifier that applies to a received RTP stream. So if multiple 
> m= lines are defined and they are not all separate RTP sessions, 
> additional method for determining media description to RTP stream are 
> required. Multi-party also needs to be handled.

Again, since there's no real itch to scratch for declarative SDP, and 
it's getting (even more!) complicated, I propose removing it, with a 
statement that we don't define its use, although allow for a future 
document to do so.

> 12. Section 8.2.3 and 8.2.4:
>
> So even if H.264 supports macroblock internal partitions for 4x4 and 
> 8x8 sub-blocks the calculation for the constraints are done on the 
> macroblock sizes that is 16x16 for luminance, see Section 3.78 of 
> H.264 specification. Thus the conversion factor should in both these 
> cases be 256 pixels per MB.
>
> https://www.itu.int/rec/T-REC-H.264-201602-I/en (pdf version is free)

Thanks. I've changed it to 256 and added math.

> 13. Section 10:
>
>
> rid-fmt-list      = "pt=" fmt *( "," fmt )
>                      ; fmt defined in {{RFC4566}}
>
> When I verified the ABNF by running Bill Fenner's parser on it I got 
> the "fmt undefinded". One way of avoiding this is to actually define 
> fmt as prose value, by saying that it is an external reference.
>
> fmt          = <as defined in RFC4566>
>
>
> 14. Section 10:
>
> "alpah-numeric" is also undefined. And it is not obvious from where 
> this definition is taken. SP and DIGIT are present in RFC5234 and I 
> assume those definitions are to be used.

RFC 4566 defines:

    ; generic sub-rules: primitives
    alpha-numeric =       ALPHA / DIGIT


I have accordingly added:

alpha-numeric     = < as defined in RFC4566 >


>
>
> In addition I have to note that if one would use the "alpha-numeric" 
> definition from SDP (RFC4566) then one can't use any of the allowed 
> UTF-8 values from the SDES item in the SDP rid-identifier as the 
> alpha-numeric only support 7-bit ascii characters.

Because of the nature of these identifiers, we really, really don't need 
to support esoterica here. Limiting the SDP syntax to alphanumerics is 
intentional.

> 15. Section 10:
>
> Discrepancy between SDES item and "rid-identifer". To my understanding 
> there exist no limitations in the SDES item against using space or 
> other separators. Such free form is not supported by current 
> "rid-identifier" definition. This effiects both "rid-syntax" and 
> rid-list constructs.

As above, I don't think we need to support arbitrary strings here -- the 
limited set more than serves our purpose, and the more permissive we 
are, the more likely SDP parsers are to get get this wrong. In 
particular, allowing spaces would make our syntax ambiguous. We're going 
to have to use *some* character as a separator between rid-id and 
rid-dir, and going through contortions to allow that character to also 
be allowed in rid-id is a lot of work for literally zero benefit.

> 16. Section 11.2:
>
> I understand the desire to have this example is "depend" is defined. 
> However, I do note that this is an simulcast example which you in 
> Section 11 refer to the simulcast document.

Sure, I'll add "See {{I-D.ietf-mmusic-sdp-simulcast}} for additional 
detail about simulcast usage."

>
> 17. Section 12.1:
>
> I don't think this section manages to hit all of the registration 
> requirements for new SDP attributes:
>
> From RFC4566:
>
>
>    o  contact name, email address, and telephone number
>
>    o  attribute name (as it will appear in SDP)
>
>    o  long-form attribute name in English
>
>    o  type of attribute (session level, media level, or both)
>
>    o  whether the attribute value is subject to the charset attribute
>
>    o  a one-paragraph explanation of the purpose of the attribute
>
>    o  a specification of appropriate attribute values for this attribute


Yep; I've added one.

Thanks!

/a