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

[Paul Kyzivat <[e-mail]>]

On 5/24/13 11:03 AM, Emil Ivov wrote:
> 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.

Looking back, there is some similarity, but still some difference.

IIUC you are saying that the if the offerer doesn't know the 
capabilities of the answerer then it must construct the offer so that 
any possible answer that accepts the bundle will allow proper 
association to the correct m-line. And I am not saying that.

I am saying that the offer may indeed depend on the answer supporting 
some mechanism specified in the offer in order to make the association 
unique. If the answerer doesn't recognize that mechanism (and so ignores 
it) it should be able then to recognize that the answer it would 
construct will not provide uniqueness. It then needs to fix that, by 
refusing the bundle, or refusing some of the m-lines, or whatever.

	Thanks,
	Paul

> Emil
>
> --sent from my mobile
>
> On May 24, 2013 5:57 PM, "Paul Kyzivat" <[e-mail]
> <mailto:[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]>
>         <mailto:[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
>