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

["Roni Even" <[e-mail]>]

Hi Magnus,
I agree that it is important to specify what the constrains represent, is it
of the encoded stream or the actual resolution requested or sent .
If it is the encoded constrains based on your proposed change it is not
clear what  the following text means ." In the case that  stream orientation
signaling is used to modify the intended  display orientation, this
attribute refers to the width of the   stream when a rotation of zero
degrees is encoded.
Roni


-----Original Message-----
From: mmusic [mailto:[e-mail]] On Behalf Of Magnus Westerlund
Sent: Tuesday, November 03, 2015 4:33 AM
To: mmusic (E-mail); [e-mail]
Subject: Re: [MMUSIC] My review comments of draft-pthatcher-mmusic-rid-02

Hi,

I have addition to my review comments.

For the rid-attributes that has to do with constraints on the resolution. I
think they should be more explicit that this constraint applies to the
encoded stream that the sender produces.

In most cases it should be as simple to add "of the encoded stream" with a
reference to: 
https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-grouping-taxonomy/

Like this.

   o  max-width, for spatial resolution in pixels of the encoded
       stream.  In the case that
       stream orientation signaling is used to modify the intended
       display orientation, this attribute refers to the width of the
       stream when a rotation of zero degrees is encoded.

Cheers

Magnus Westerlund

Den 2015-10-31 kl. 18:06, skrev Magnus Westerlund:
> 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  [phone]
> Färögatan 6                 | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>


-- 

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

_______________________________________________
mmusic mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mmusic