Subject: [MMUSIC] My review comments of draft-pthatcher-mmusic-rid-02

From: Magnus Westerlund <[email-masked]>
Date: Sat, 31 Oct 2015 18:06:48 +0900

Hi,

On my flight to Yokohama I reviewed the draft and have the following 
comments. Note, I haven't checked this against the other postings on 
open issues. Note, this might looks like a lot, but most issues are 
quite small and questions of clarity of text.

1. Abstract:

"a) effectively identify the Source RTP Streams within a RTP Session,"

I wonder over this text. What "identity" is referenced? Media source is 
identified otherwise, e.g. MID.

2. Section 1:

    Recent advances in standards such as RTCWEB and NETVC have given rise
    to rich multimedia applications requiring support for multiple RTP
    Streams with in a RTP session

I fail to see how NETVC is relevant in this?

3. Section 1:

    o  The restricted RTP PT space in specifying the various payload
       configurations,

It is not clear which restriction that is mentioned here.

4. Section 3 (maybe):

The document needs better definitions, especially I am missing a proper 
definition and name for the PT + RID constraints. What I see Section 
uses "RTP Payload Configuration". I think that word is a bit unclear, as 
that can equally mean what is configured to apply the PT.

5. Section 4.

    1.  RTP PT Space Exhaustion: [RFC3550] defines payload type (PT) that
        identifies the format of the RTP payload and determine its
        interpretation by the application.  [RFC3550] assigns 7 bits for
        the PT in the RTP header.  However, the assignment of static
        mapping of payload codes to payload formats and multiplexing of
        RTP with other protocols (such as RTCP) could result in limited
        number of payload type numbers available for the application
        usage.  In scenarios where the number of possible RTP payload
        configurations exceed the available PT space within a RTP
        Session, there is need a way to represent the additional
        constraints on payload configurations and to effectively map a
        Source RTP Stream to its corresponding constraints.

I would really prefer this was reformulated to clarify that that the PT 
exhaustion is primarily a result of overloading usage of various types 
rather than the basic encoding and packetization parameters identification.

6. Section 4:

Note that the bullets both are labelled as 1.

7. Section 4:

         Recently, there is a
        rising trend with real-time multimedia applications supporting
        multiple sources per endpoint with various temporal resolutions
        (Scalable Video Codec) and spatial resolutions (Simulcast) per
        source.

This sentence is way to overloaded and should be split into the 
different trends.

8. Section 5.

    Though the 'rid-level' attributes specified by the 'rid' property
    follow the syntax similar to session-level and media-level
    attributes, they are defined independently.

This appear to not be working as the delimitation of rid-level 
attributes are not made clear. The formal syntax says that the only 
separator is ";", but that is not explained here. Clarification of how 
this is expected to work is needed.

9. Section 7.

With current lack of wording it appears that it is allowed to use a 
specific rid-identifier, e.g. "a" for different sets of constraints in 
various different m= sections. I wonder if that really should be 
allowed? Might be simpler to restrict the re-use of labels across 
multiple m= sections only in cases where there RID attributes are the same.

10. Section 7.1-

I think the handling of the "pt" value is unclear. To my understanding 
you may? exclude it and have it apply to all PT formats in m= line. 
However that is not well formulated. It is unclear that if you may 
included all PTs in the pt= parameter. This applies also to the 
following O/A steps also.

11. Section 7.1:

Bullet 3:

(usually corresponding to RTP payload types)

To my understanding RID is currently restricted to RTP, thus, it is not 
"usually corresponding".

12. Section 7.2:

    2.  If the "a=rid" line contains a "pt=" parameter, 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).
        If there is no match for the Payload Type listed in the "a=rid"
        line, then remove the "a=rid" line.

I wonder if removing the whole line is the right approach here. If one 
would remove the attributes the answerer don't understand then one would 
get more information back to the offerer. The offerer could identify the 
attributes not supported. Yes, the offerer may have to not use the rid, 
but in some cases it could do that despite missing some constraints. 
What functionality do we really want here?

13. Section 7.3:

    Note: in the case that the answerer uses different PT values to
    represent a codec than the offerer did, the "a=rid" values in the
    answer use the PT values that were sent in the offer.

I think this gets confusing as the answering SDP will not correctly 
describe the streams going to the answerer. If I remember correctly, the 
answer may actually add new PTs and they must be possible to include in 
the RID line. Thus, I wonder if this rule can work. Yes, I agree having 
to map them is difficult, and they are actually directionality dependent.

14. Section 8.

I wonder if one can work the length consideration into the general SDES 
item description.

15. Section 8.
Although draft-ietf-avtext-sdes-hdr-ext does discuss information change 
as a reason for needing to send the data. However, I think the RID 
information for a particular SSRC is a bit of specific case. Thus, I 
wonder if one should expand a bit on the actual SDES item and its needs.

16. Section 10.

    int-param-val     = 1*DIGIT

Should this really be totally unlimited in length. I can understand that 
one needs to support long values, but having no limitation, is that safe 
and reasonable to parse?

17. Section 10.

    param-val         = *( %x20-58 / %x60-7E )
                        ; Any printable character except semicolon

Lets get back to escaping. I know this has been raised. But, I think 
what is currently specified is to limiting. The first part is the 7-bit 
ascii, that appears to limiting considering SDP's UTF-8 support.

The next issue is really about delimiting parameters in a good way, that 
also can support adaptation of parameters without having to redefine the 
completely in the future.

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