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

[Magnus Westerlund <[e-mail]>]

Hi,

Follow up inline.

Den 2017-05-03 kl. 12:56, skrev Roni Even:
> 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.

So the extmap configuration for an RTP session has a common ID space. So 
for all RTP m= lines that ends up in the same bundle, needs to have a 
consistent space and thus, it becomes difficult for an answerer to 
create an answer to an offer where one m= line in a bundle allows mixed, 
and the other not as it affects how to assign IDs. It is the same RTP 
session those RTP streams are going into. The only approaches to handle 
this is to act as mixed being disallowed, or not bundle at all.

I might have missed how Identical is treated in bundles with different 
protocols (PROTO). Because this clearly only need to be identical for 
all m= blocks that are using the same PROTO. Is this a missing category 
in SDP mux attributes draft?

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

I wasn't actually thinking about session level, but from a treatment 
level it is what you would aggregate across all the m= lines in the bundle.

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

Yes, actual usage is only for RTP streams belonging to this m= block. An 
example of this would be this abbrevaited SDP

a=group BUNDLE a b c
m=audio RTP 97
a=mid:a
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
m=audio RTP 97
a=mid:b
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
m=video RTP 98
a=mid:c
a=extmap:2 urn:3gpp:video-orientation

This above shows an example using header extensions that makes no sense 
to actually use in the other m= in the bundle, but the configuration of 
the RTP header extension is something that happens on RTP session level 
and thus, they must have unique and different numbers.

Yes, one could have configure the two extmap on SDP session level and 
get the same configuration. But it would lack the indication on which 
one they are used. And in the above case, maybe mid b) would not include 
audio-level, and then one could exlude the examap attribute and indicate 
this.

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

Actually, we only have 14 short format IDs, so I disagree with you. Take 
a CLUE conferencing scenario where one uses BUNDLE, then each m= block 
for audio may have 5 configured IDs (ssrc-audio-level, encrypt, 
sdes:cname, sdes:CaptId, sdes:mid). Unless you resuse them across the m= 
lines it will not work.

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