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

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