Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th)

[Emil Ivov <[e-mail]>]

On 19.06.13, 21:18, Harald Alvestrand wrote:
> On 06/19/2013 07:09 PM, Emil Ivov wrote:
>>
>>
>> On 19.06.13, 18:47, Christer Holmberg wrote:
>>> Hi,
>>>
>>>>> The question is whether we shall specify exactly how entities
>>>>> associate RTP packets with the correct m= lines, or whether we
>>>>> shall simply give some guidelines and hints.
>>>>>
>>>>> For example, a client can choose to use unique PT values per m-
>>>>> values, within a given BUNDLE group, and everything should work
>>>>> fine. And, if the endpoint runs out of PT values, the create a new
>>>>> BUNDLE group. Now, whether it's religiously correct, I don't know :)
>>>>>
>>>>> OR, if the endpoints are able to signal which SSRCs they are going
>>>>> to use, they can use that.
>>>>>
>>>>> OR, if the endpoints support some kind of RTP header extension for
>>>>> this purpose, they can use that.
>>>>>
>>>> OR, if they don't care which M-line the stream is associated with,
>>>> the question may be moot.
>>>
>>> Correct.
>>>
>>>> In all cases, the payload type MUST clearly identify the codec
>>>> configuration it's associated with.
>>>
>>> *IF* you have a way to find the right m= line, couldn't PT X have
>>> different codec configurations in different m= lines?
>>
>> Let's assume that it could ... but then how would you know that your
>> peer also supports the same demuxing technique as yourself?
>>
>> In SIP for example, when constructing a first offer, you may want to
>> map both Opus and VP8 to 96, then add SSRCs for demuxing. This means
>> that you expect your peer to support SSRC demuxing and you can't
>> expect that unless we mandate it.
>
> Using 96 for both Opus and VP8 is flat out illegal according to the RTP
> specs.

It somehow sounded to me that people decided this didn't matter. Crazy 
times :). I am glad to know I was wrong.

> The corner case where we're discussing whether one can use the same
> payload type is if you have two M-lines that both specify VP8, with the
> same codec parameters - whether they can both use 96, given that it's
> the same codec.

Well same question then: what would be the downside of only allowing 
that once support for a non-PT demuxing mechanism has been confirmed?

Emil



-- 
https://jitsi.org