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

[Emil Ivov <[e-mail]>]

On 19.06.13, 20:01, 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 the PT case, he doesn't have to, because he is going to tell you
> what PT values he wants you to send him.

Yes but how do you know whether or not it is going to pre-announce SSRCs 
so that you could demux the payload types that you want to receive?

>> 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.
>>
>> Or am I missing something?
>
> No. In case of support of extensions (e.g. the SDP ssrc attribute),
> you either have to perform some kind of capability exchange before
> you send the initial Offer. Or, you will figure out in the response
> to the initial Offer, and then you can "fix" it in a new Offer (as
> BUNDLE is currently specified, you will have to send a second Offer
> anyway).

Exactly. So what bothers me is that without at least one default 
demuxing a bundle offer can be downgraded to non-bundle if

1. the answerer doesn't support bundle
2. the answerer doesn't support the demuxing mechanism the offerer would 
like to use.

Point 2 means that UAs would have to support as many demuxing mechanisms 
as possible, even if they don't actually need them, just so that they 
could have bundle. This doesn't sound like a great thing.

What would be the downside of mandating PT demuxing but allowing it to 
be overridden by other mechanisms when available?

Emil

> But, again, what I want to discuss now is whether/what we are going
> to specify regarding the usage of multiple m= lines with the same
> transport protocol (RTP, or whatever other there could be).
>
> Regards,
>
> Christer
>
>

-- 
https://jitsi.org