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

Hi Magnus,
I will  try to summarize where we stand
1. For  a=extmap-allow-mixed is it normal or identical? Do we require all m-lines in a bundle group to specify this attribute or can it be per m-line

2. For  extmap, point 1 and 2 are no problem, I can add text for the bundle case.

3.  For point 3 do we want use same ID in multiple m-lines in the bundle group for same RTP header extension configuration or do we mandate unique IDs for extmap defined in the bundle group.

4. For point 4, not sure if this change any current behavior of directionality for extmap and need to be specfied, or am I missing something. Currently the directionality must comply with the carrying RTP stream directionality.

Thanks
Roni

> -----Original Message-----
> From: avt [mailto:avt-bounces@ietf.org] On Behalf Of Magnus Westerlund
> Sent: יום ד 03 מאי 2017 11:27
> To: avt@ietf.org; draft-ietf-avtcore-rfc5285-bis@ietf.org; 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.
> 
> 
> 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  +46 10 7148287
> Färögatan 6                 | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt

Re: [AVTCORE] I-D Action: draft-ietf-avtcore-rfc5285-bis-11.txt - open issues on bundle use