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

From: Flemming Andreasen <[email-masked]>
Date: Thu, 7 Jul 2016 10:42:32 -0400

Greetings MMUSIC

This is to announce a 3 week WGLC on the draft:

     https://www.ietf.org/id/draft-ietf-mmusic-rid-06.txt

as Proposed Standard. Please review and provide any comments you may 
have on the document by Thursday, July 28, 2016. Comments should be sent 
to the document authors and the MMUSIC WG list. If you review the 
document but do not have any comments, please send a note to that effect 
as well.

Thanks

-- Flemming (MMUSIC co-chair)

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 12 Jul 2016 16:30:01 +0200

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  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Adam Roach <[email-masked]>
Date: Thu, 14 Jul 2016 19:58:30 -0500

On 7/12/16 09:30, Magnus Westerlund wrote:
> 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.

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

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

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

I'm fine moving the paragraph.

> 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?

> What the above section 6 text doesn't cover is multiparty cases, when 
> a receiver can receive RTP streams from multiple endpoints matching a 

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?

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

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

> representation or something else?

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

> should be precluded from definition and registration by other documents.

Done.

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

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

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

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

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

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

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

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

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

> Section 11 refer to the simulcast document.

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

>    o  a specification of appropriate attribute values for this attribute

Yep; I've added one.

Thanks!

/a