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

[Paul Kyzivat <[e-mail]>]

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