[MMUSIC] Comments on draft-pthatcher-mmusic-rid-00

[Magnus Westerlund <[e-mail]>]

Hi,

I have reviewed the RID draft and have some issues that I think needs 
discussion.


A. First I think we need to consider what goals this draft really have.

A1. Payload Type replacement.

I think this part of the mechanism is underspecified and fails to 
address several issues. I will return to these issues below, but the 
main points are:
- The role of the PT when using RID for this purpose
- The mechanism for describing the code specific parts for the Payload 
format when identifying by the RID only.


A2. Separation between Simulcast and Scalability

Simulcast and Scalability have different requirements. A simulcast 
stream is self contained, while the scalability stream depending on 
packetization has either dependencies on external stream(s) or is 
multiple sub-streams in the same RTP stream. Thus there are important 
differences of what information needs to be expressed. From my 
perspective a complete solution for scalability should be capable of 
expressing constraints also on the sub-streams for the different 
scalability layers.

A3. The intention for aligning the codec parameters across different 
future RTP payload formats and their codec. I think it a good intention, 
but something that I think will need some discussion of how it is 
accomplished.

As one define parameters or select the most appropriate form out of the 
different existing ones one need to have a registry to track the ones 
that are recommended ones.

There is also clearly need for some recommendations on how the work 
around creating new parameters should occur.

Further the applicability of these parameters appear to be per payload 
format. They are the ones that selects or need to define new ones based 
on the formats needs. From my perspective, this needs to be fully 
applicable to regular usage without RID, having these parameters in the 
a=fmtp.


B. The first point related to A1:

"The 'rid' framework MAY also be used to fully describe the RTP payload 
encoding, thus completely skipping the 'a=fmtp' SDP attribute for the 
Payload Types identified in the "a=rid" line."

I think there needs to be more discussion about this. One must have an 
PT value set in the RTP packets. That PT values must be configured to 
something. Thus, the need for at least rtpmap, possibly fmtp.

I think I have two takes on this. The first one is what one does in an 
extreme situation, where not even broadly configured PTs and more 
detailed configurations using RID is sufficient, what does one do? Have 
a dummy PT saying, see RID for more detailed configuration.

The second potential issue, is the question when FMTP can be left out. 
 From my perspective, that can only be left when there are no mandatory 
MIME parameters that needs to be configured for a specific payload 
format that is indicated.

C. The overlap with MID

As the RID is defined, RID ID now serves both as an identifier for a set 
of codec constraints, which actually could be re-used across multiple 
media sources and as a method for indicating the media source. This 
later function is a duplication of the MID SDES item defined in BUNDLE. 
I see benefits in not having to include MID in all cases, but at the 
same time this potentially forces a lot of duplication of RID IDs across 
multiple media sources, rather than re-using a smaller set of 
configurations for a number of media sources.

D. Section 5.

    A given "a=rid" SDP media attribute specifies constraints defining an
    unique RTP payload configuration identified via the "rid-identifier".
    A set of codec-agnostic "rid-level" attributes are defined
    (Section 6) that describe the media format specification applicable
    to one or more Payload Types specified by the "a=rid" line.

There appear to be some overlap here in the definition. I think this 
document better needs to explain the relation between the RTP header PT 
field and the configuration information that expresses and the 
configuration that the RID-identifier expresses which after all is PT=X 
+ a set of additional constraints.

E. Section 8. RID and RTP

Currently what RID is for RTP is not particular clear. To me it would 
make sense to define RID as a piece of source information (SDES). That 
way one could use RTCP to provide the current RID and when necessary, 
for example due to changing it on packet basis, one include the header 
extension.

I would note the use of an RTP header extension for the purpose 
expressed in this document is in contradiction with RFC 5285, Section 4.1:

     "To be specific, header extensions
    using this specification MUST only be used for data that can safely
    be ignored by the recipient without affecting interoperability, and
    MUST NOT be used when the presence of the extension has changed the
    form or nature of the rest of the packet in a way that is not
    compatible with the way the stream is signalled (e.g., as defined by
    the payload type)."

Thus, I think further discussion of how RID interacts with RTP is 
necessary.


F. Section 8. Other methods of applying RID?

One could potentially make hard bindings with RID to a particular SSRC. 
I don't think that is a common case, but there might be usages for which 
that applies. Thus, the question becomes does such a usage needs to be 
considered or even defined? I personally don't see the need to define it.

I do raise this as it is an indicator if the definition of the RID 
mechanism is modularized in an appropriate way? I understand we don't 
want to blow this into a million different drafts, and it actually makes 
sense to keep this more generic piece of work outside of the simulcast 
draft. But, it still needs to have some consideration so that one can 
define a specific non RTP close aspect in another way when the 
signalling is different.

In regards to modularizing and components, on the signalling side, it 
looks likely that WebRTC will be a case where one will define another 
method for establishing the constraints related to RID. These will be 
set through an API, and I assume at least by WebRTC 2.0 that will not be 
SDP as control surface.

G. The constraints defined so far makes sense for video. I will look at 
the definitions closer at a later stage to ensure that they look well 
defined.

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