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

[Magnus Westerlund <[e-mail]>]

Hi,

Here are my WG last call comments.

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? Already RFC 3264 is quite clear that this is 
possible. If possible I would avoid repeating this as a reason. I think 
RTP/RTCP MUX is a more relevant limitation that takes a significant 
chunk out of the PT 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.

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

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.

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.

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.

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).

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?

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?

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.

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.

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.

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.

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.

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)

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.

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.

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.

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.

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


I think actually doing this like a form ensures that all is covered.


Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------