Re: [AVTCORE] I-D Action: draft-ietf-avtcore-rfc5285-bis-11.txt

[Magnus Westerlund <[e-mail]>]

WG,

So this latest update was done, based on the IANA expert reviewer for 
the SDP registrations. Roni quickly updated the template to resolve 
contact and muxing category for the SDP attributes. However, I think we 
do need to do a bit more here, and I think the WG needs to review this. 
So below are my comments, and what I think need to be included.

First, is really "Normal" the mux category for a=extmap-allow-mixed?

To me "Identical" would make much more sense. Either you are capable of 
support mixed or one is not. Having some m= lines in a mux saying yes it 
is possible, and others saying no, I can't. That do not make any sense 
to me, at least across RTP m= lines.


Secondly, I wonder if there needs to be more discussion and spec text on 
muxing for extmap. So draft-ietf-mmusic-sdp-mux-attributes says on special:

4.8.  Category: SPECIAL

    For the attributes in the SPECIAL category, the text in the
    specification defining the attribute MUST be consulted for further
    handling when multiplexed.

    As an exampel, for the attribute extmap [RFC5285], the specification
    defining the extension needs to be referred to understand the
    multiplexing implications.

and

5.13.  RFC5285: RTP Header Extensions

    [RFC5285] provides a general mechanism to use the header extension
    feature of RTP.  It provides the option to use a small number of
    small extensions in each RTP packet, where the universe of possible
    extensions is large and registration is de-centralized.  The actual
    extensions in use in a session are signaled in the setup information
    for that session.

    +---------+--------------------------------------+-------+----------+
    | Name    | Notes                                | Level | Mux      |
    |         |                                      |       | Category |
    +---------+--------------------------------------+-------+----------+
    | extmap  | Refer to the document defining the   | B     | SPECIAL  |
    |         | specific RTP Extension               |       |          |
    |         |                                      |       |          |
    +---------+--------------------------------------+-------+----------+

                       5.13 RFC5285 Attribute Analysis



To my understanding the properties that applies to extmap when muxing a 
set of RTP m= lines are the following:

1. The ID space is common across all m= lines (using RTP) in a BUNDLE group.

2. Each m= block can define a subset of the total defined ID numbers 
indicating limits in use for a particular media source. This allows for 
example audio and video media sources to use different set of header 
extensions.

3. An ID number that is defined in multiple m= blocks MUST have 
identical extmap configuration, i.e. the same URL and any extension 
attributes that effect the usage or form of the RTP header extension.

4. The extmap direction setting for a particular ID number MAY be 
independently set per media source (m= block). This as some media source 
may be unidirectional and other bi-directional.

I think there is need that we actually document this in this level of 
detail so that we get consistent implementation support.

So, WG opinions, or comments on my proposal of how one needs to deal 
with extmap?

I have recommend to Ben that we don't put this document onto the IESG 
agenda until the above is resolved.

Cheers

Magnus Westerlund
Doc shepherd



-- 

Magnus Westerlund

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------