Re: [AVTCORE] draft-ietf-avtcore-rfc5285-bis-11.txt - new text for bundle case

[Magnus Westerlund <[e-mail]>]

Hi Roni,

Thanks for drafting text. See below for my comments.

Den 2017-05-18 kl. 13:10, skrev Roni Even:
> Hi,
> 
> I suggest adding the following text to section 6
> 
> When used in [bundle] this attribute is specified as normal category
> for the [mux attribute]. This allows for only a subset of the m-lines
> in the bundle group to offer extmap-allow-mixed. When an answerer
> supporting the extmap-allow-mix attribute receives an offer where
> only some of the m-lines in the bundle group include the
> extmap-allow-mixed attribute, the answerer must receive this offer
> and support mixed one-byte and two-bytes only for those m-lines.

I think we should clarify what "support" means. I think the reasonable 
thing that this means is that one MUST only send RTP header extensions 
using mixed on those RTP streams originating from those media sources 
(m=) blocks that includes extmap-allow-mixed, and are RECOMMENDED to 
support receiving mixed on all RTP streams being received in an RTP 
session where at least one bundled m= block is indicating 
extmap-allow-mixed. This to maximize interoperability.

> 
> 
> 
> And the following text to section 7
> 
> When using [bundle] to bundle multiple m-lines the extmap attribute
> falls under the special category of [mux attribute]. All the m-lines
> in a bundle group are considered to be part of the same local
> identifier (ID) space.  If an extension URI is offered in multiple
> m-lines the same attributes as part of the same bundle group it MUST
> use the same ID in all this m-lines. Each m-line in a bundle group
> can include different extension URIs allowing for example audio and
> video sources to use different sets of RTP header extensions. The
> directionality of the RTP header extensions in each m-line of the
> bundle group are handled as the non-bundled case. This allows for
> specifying different directionality for each of the repteated
> extension URI in bundled group.

This is not discussing the <extensionattributes> that the extmap 
attribute may include.

https://tools.ietf.org/html/rfc5484 does actually define extension 
attributes. What I understand of these extension attributes, two extmaps 
with same URN but with different extensionattributes are not compatible, 
and need different IDs. I would suggest the following edits:

When using [bundle] to bundle multiple m-lines the extmap attribute 
falls under the special category of [mux attribute].
All the m-lines in a bundle group are considered to be part of the same 
local identifier (ID) space.  If an RTP header extension, i.e. an 
particular extension URI and configuration using <extensionattributes>, 
is offered in multiple m-lines that are part of the same bundle group it 
MUST use the same ID in all of these m-lines. Each m-line in a bundle 
group can include different RTP header extensions allowing for example 
audio and video sources to use different sets of RTP header extensions.
It SHALL be assumed that any difference in configuration using any 
<extensionattributes> has importance and need to be preserved to any 
receiver, and thus require assignment of different IDs. Any RTP header 
extension that do not match this assumption MUST explicitly indicate 
this provide rules for what are compatible configurations that can be 
sent with the same ID. The directionality of the RTP header extensions 
in each m-line of the bundle group are handled as the non-bundled case. 
This allows for specifying different directionality for each of the 
repteated extension URI in bundled group.

I note that the sentence:

Any RTP header extension that do not match this assumption MUST 
explicitly indicate this provide rules for what are compatible 
configurations that can be sent with the same ID.

Likely should be added to the registation checklist in 10.1.

Cheers

Magnus Westerlund

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