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

From: Roni Even <[email-masked]>
Date: Thu, 18 May 2017 11:10:42 +0000

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.  

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.

Roni Even

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 23 May 2017 14:57:31 +0200

Hi Roni,

Thanks for drafting text. See below for my comments.

Den 2017-05-18 kl. 13:10, skrev Roni Even:
> 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.

> 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  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Roni Even <[email-masked]>
Date: Wed, 24 May 2017 10:45:05 +0000

Hi Magnus,
Thanks,

So the new text based on Magnus comments will be:

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

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. a 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 for any RTP header extension, difference in configuration using any of the <extensionattributes> is important and need to be preserved to any receiver, thus requiring assignment of different IDs. Any RTP header extension that do not match this assumption MUST explicitly 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 repeated extension URI in bundled group.

In section 10.1 review process add a new bullet.

That for [bundle] multiplexed m-lines, any RTP header extension with difference in configurations of <extensionattributes> that do not require assignment of different IDs, MUST explicitly indicate this and provide rules for what are compatible configurations that can be sent with the same ID.

Please review and send comments.

Roni

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: יום ג 23 מאי 2017 15:58
> To: Roni Even; [email-masked]
> Subject: Re: draft-ietf-avtcore-rfc5285-bis-11.txt - new text for bundle case
> 
> Hi Roni,
> 
> > 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
> 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.
> 
> >
> >
> >
> > 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
> 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.
> 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
> 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.
>