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

I didn't say anything about changing the PTs. 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.

On 24 May 2013 09:59, Emil Ivov <emcho@jitsi.org> wrote:

> On 24.05.13, 11:40, Kevin Dempsey wrote:
> > Isn't the onus on the answerer to ensure the demux is possible, since it
> > is accepting the bundle. Therefore if it doesn't support signalling
> > SSRCs or an offerred 'fancy-RFC m-line matching' method, it must only
> > send PTs that are tied to a single m-line.
>
> PTs are defined by the offerer. The answerer cannot change them for the
> offerer-bound direction (even if it could request different values for
> the packets that it, the answerer, is going to receive).
>
> Emil
>
>
> >
> >
> > On 24 May 2013 08:17, Emil Ivov <emcho@jitsi.org
> > <mailto:emcho@jitsi.org>> wrote:
> >
> >     On 24.05.13, 00:59, Paul Kyzivat wrote:
> >     > IMO the "before the O/A completes" issues are separate from the
> "after
> >     > the O/A completes" issues. I'm still not convinced that the
> >     "before the
> >     > O/A completes" issues are important. (We have reliable 183
> >     responses to
> >     > deal with it.) But I'm ok with Cullen using PT to solve that
> >     problem if
> >     > he thinks he needs to.
> >
> >     I wasn't referring to "before the O/A completes" situations. If your
> >     peer does not support fancy-RFC m-line matching nor does it provide
> >     SSRCs, you have to be able to fall back to PT demuxing.
> >
> >     Therefore, all your offers have to accommodate for that possibility
> >     unless you know that the offer is going to someone who also supports
> >     other mechanisms.
> >
> >     Emil
> >
> >     --
> >     https://jitsi.org
> >     _______________________________________________
> >     mmusic mailing list
> >     mmusic@ietf.org <mailto:mmusic@ietf.org>
> >     https://www.ietf.org/mailman/listinfo/mmusic
> >
> >
>
> --
> https://jitsi.org
>