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

[Magnus Westerlund <[e-mail]>]

Please see inline.



Den 2017-05-03 kl. 15:41, skrev Roni Even:
>
>
>> 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.
>
>
> [Roni Even] If I understand your point, I think that by not allowing the same ID in multiple m-lines even if the same header extension with the same values will work.
>

So under the restriction that no extmap lines in any bundled m= block 
can have the same ID, then different applications of 
a=extmap-allow-mixed would result in that some m= blocks only can use 
one number space. Considering the limited space for one-byte header 
compatible IDs, they will be difficult to apply. Especially considering 
like 8 concurrent audio sources with identical needs for CNAME, MID, 
RID. In that case one is forced to use 2-byte headers. This results in 
an unnecessary overhead.

To be clear I have no issue with keeping extmap-allowed-mixed to be 
normal. As long as you can write up an explanation for when it occurs. 
And your session levels vs media level may make sense. However, I do not 
like the limitation that one may not use the same ID in multiple m= 
block that are bundled in the same RTP session, assuming identical 
configuration.



>>>
>>>> 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.
>
> [Roni Even] The example does not have any attribute value, when
> there  is one and you want to change you will need to negotiate a new ID.

Yes, that is correct if one changes the attributes one would need to 
negotiate a new ID. I don't think that is different from what is 
required today if one want safe operations across a switch as signaling 
and RTP is not synchronized.

Is there even any header extensions that uses attributes in signaling?



>
>
>
>>
>>>
>>>
>>>> 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.
> [Roni Even] This is why we have the two byte header extensions, and I assume that if you support bundle you should support RFC5285-bis

That is still creating an very artificial limitation that is not needed. 
An ID is an RTP session level configuration. Forcing the signalling to 
create X*Y IDs instead of simple X appears very strange to me. I would 
note that for conferencing with many sources one would possibly run into 
the limitation. There are after all only 254  IDs that can be used by 
the implementation. If one uses 5 IDs per media source then the limit is 
50 sources, that isn't that high.

I fail to see any issues with allowing for a given header extension 
configuration to be re-used in multiple m= blocks with the same ID. This 
is the same as the RTP PT.

And, the Chrome WebRTC SDP examples I have seen do re-use extmap values 
across multiple m= blocks.

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