Re: [MMUSIC] Unified Plan for SDP Handling - multiple media sources

[Jonathan Lennox <[e-mail]>]

On Jul 17, 2013, at 12:24 AM, Adam Roach <[e-mail]> wrote:

> What we need is a token chosen by the *receiver* representing what will be sent to the receiver. The crux of the matter is that the recipient may start receiving an RTP stream prior to receiving any signaling from the far end that can be used to correlate a token to the stream. We need to include something in an offer that allows us to correlate streams *before* the answer arrives.
> 
> That's not to say we couldn't add such functionality to this draft. But, unless I've completely misunderstood the meaning of the passage I quote above, the current application token proposal doesn't solve the clipping problem that we're trying to avoid.

Ah, interesting.  The problem case is an offerer offering a new bundled sendrecv or recvonly m-line, where the answerer can start sending media for it immediately, outracing the answer?

Yes, I see how a receiver-chosen correlator solves that case.

That said, what I still don't see is, if you have the correlator, why you then actually need to send the a=ssrc in the SDP at all? The correlator should be sufficient for disambiguation, and it lets the sender switch the ssrc it's sending for an m-line without needing a fresh offer/answer.

(The use case I'm thinking about here is something like the CLUE "dynamic capture" in the context of what Magnus named the "Source-projecting mixer" topology -- where the ssrc sent for a given m-line switches dynamically and quickly, e.g. with loudest-speaker switching.)

--
Jonathan Lennox
[e-mail]