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

From: Magnus Westerlund <[email-masked]>
Date: Fri, 2 Jun 2017 09:57:17 +0200

Hi,

This works for me. I would really like some more people providing their 
views on this.

Cheers

Magnus Westerlund

Den 2017-05-24 kl. 12:45, skrev Roni Even:
> Hi Magnus, Thanks,
> 
> So the new text based on Magnus comments will be:
> 
> 
> 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.
> 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.
> 
> 
> 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 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.
> 

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