Re: [MMUSIC] Proposal for what bundle should say about demux

[Emil Ivov <[e-mail]>]

Paul,

This looks very much like what I suggested initially in my response to
Cullen, so I am not sure why you sound as if you are disagreeing.

Emil

--sent from my mobile
On May 24, 2013 5:57 PM, "Paul Kyzivat" <[e-mail]> wrote:

> On 5/24/13 10:40 AM, Emil Ivov wrote:
>
>> On May 24, 2013 5:16 PM, "Paul Kyzivat" <[e-mail]
>> <mailto:[e-mail]>**> wrote:
>>  >
>>  > On 5/24/13 5:14 AM, Emil Ivov wrote:
>>  >>
>>  >> On 24.05.13, 12:02, Kevin Dempsey wrote:
>>  >>>
>>  >>> I didn't say anything about changing the PTs.
>>  >>
>>  >>
>>  >> Sorry, I misunderstood.
>>  >>
>>  >>> The answerer decides what
>>  >>> it codecs it will use from the ones listed in the offer. If it
>> doesn't
>>  >>> support any other mechanism to allow demux then it must choose codecs
>>  >>> that have PTs on only one m-line, or not accept the BUNDLE.
>>  >>
>>  >>
>>  >> Matching packets to m= lines is the concern of the receiving party. So
>>  >> is the mechanism that it uses. What you are suggesting is for the
>>  >> answerer to basically say: "It seems to me that you won't be able to
>>  >> demux these two payloads so I will not send them to you because I know
>>  >> better".
>>  >>
>>  >> In the same time the offerer may be planning on using a demux
>> technique
>>  >> that the answerer simply isn't aware of. For example (and this is
>> really
>>  >> just to make a point, so please don't assume I am suggesting something
>>  >> like this in general) if 101 is mapped to both telephone-event and
>> VP8,
>>  >> demuxing can be easily made without any other knowledge of SSRC or
>>  >> header extensions.
>>  >
>>  >
>>  > ISTM that after the O/A exchange both sides need to have a common
>>  > understanding that their communications will be understandable.
>>
>> I assume this means you agree that an offerer has to make sure at least
>> one of the demuxing mechanisms it supports will be understood by the
>> answerer.
>>
>
> No. But the offerer had better ensure that there is some way to answer
> that meets the requirements.
>
> Then it becomes a requirement on the answerer to answer in a way that
> makes the communication unambiguous. If it can't do that while bundling
> then it must remove the bundle, or remove some m-lines from the bundle, or
> reject some of the m-lines in the bundle, so that the resullting answer
> constructs an unambiguous communication.
>
> If the intent is to rely on "magic" then that can be achieved by using
> fewer m-lines in the bundle, in a way that dumps more streams/flows into
> the same m-line. So this is really only an issue for plan A.
>
>         Thanks,
>         Paul
>
>