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

[Bernard Aboba <[e-mail]>]

Indeed, unless the RTP extension is self-describing it has to be chosen by the receiver in order to provide guidance to the receiver before an answer arrives.  If it is opaque and chosen by the sender it isn't all that different from an SSRC chosen by the sender and potentially signalled in the answer.

Adam Roach <[e-mail]> wrote:

On 7/16/13 17:46, Jonathan Lennox wrote:
> Have you readhttp://tools.ietf.org/html/draft-even-mmusic-application-token-00.txt  ?  This is a more fleshed-out version of the same idea, as I understand the idea in Unified, written to be agnostic between Plans A / B / No Plan.

Thanks for the pointer -- I had missed this.

On a first read, this proposal seems to be backwards from what we need.
The token scoping appears to be summed up by the following passage:

    The token is chosen by the sender, and represents the RTP stream that
    will be sent to the receiver.


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.

/a

_______________________________________________
mmusic mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mmusic