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

[Emil Ivov <[e-mail]>]

Hey Cullen,

On 24.05.13, 01:22, Cullen Jennings (fluffy) wrote:
> 
> <snip>
> 
> What I had in mind was something along the lines of the following
> 
> A is sending an offer that forks to B and C. A and B support the new
> mechanisms but C does not. A has no idea if the things it is talking
> to support the new thing.

Exactly.

> A constructs an offer that in the SDP has an indication it can
> receive the header extension. Perhaps something like
> "a=new-hdr-ext=123456". The new header extension allows one to embed
> an identifer in the RTP packets and this SDP indicates that the
> identifier should be 123456 for RTP with this mapping.

OK.

> A sends the offer and it arrives at both B and C. C does not
> understand it and just ignores it. B understands it and inserts a TP
> header extension with the identifier 123456.
> 
> Imagine the RTP packets from B and C arrive at A before any SDP
> answer. A looks at the RTP packet from B, and see the header exertion
> and reads out the identifier 123456 and now knows the mapping. A
> looks at the RTP packet from C and does not see the RTP header
> extension so it carries on to try other things.

That's it. This is the point that I am talking about. In order for A to
be able to fall back to something, it needs to have attributed PTs such
that they could be used for demuxing.

So in other words: when constructing your offer, whatever you do, you
MUST make sure that your PTs would be enough for you to match to m=
lines, UNLESS you are certain that the other party would support some
other mechanism for doing the same.

Does this make sense?

> So yes, as you point out, for the packets from C where it can't use
> PT, it needs to fall back to SSRC 

SSRC is also a non-guaranteed approach because you don't know if C is
going to pre-announce them in SDP.

Emil

-- 
https://jitsi.org