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

[Roni Even <[e-mail]>]

inline

> -----Original Message-----
> From: avt [mailto:[e-mail]] On Behalf Of Magnus Westerlund
> Sent: יום ד 03 מאי 2017 11:27
> To: [e-mail]; [e-mail]; Ben Campbell
> Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-rfc5285-bis-11.txt
> 
> 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.
> 

 [Roni Even] I am not sure, currently you can have some m-lines support mixed and some not (use session level for all). 
Why do you want to enforce identical for bundle. One can repeat the allowed mixed or use session level if this is what he wants.
By your logic why do we need to allow in the not bundles case to support some with allowed mixed and some without? We could have used only session level for not bundled case.
> 
> 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
> 
> 
> 

[Roni Even] I assumed that the behavior is similar to session level extmap except that the RTP extension is only for the m-line

> 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.
> 
 [Roni Even] this is like session level

> 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.
> 
 
[Roni Even] so you are saying that if you use media level, the support for this extensions are only for this specific m-line


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

[Roni Even] My suggestion is to not repeat ID in different m-lines even if use the same extension, one space with unique IDs. This will be simpler. I do not think we have a problem with the number of IDs.

> 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]
> ----------------------------------------------------------------------
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt