Re: API scope

Justin Uberti wrote:
> To be fair, this is a general problem that affects any signaling API; we
> haven't stipulated what can be changed in the remote SDP either, and the
> app will always be able to touch that. In the end, we're going to have
> to document this regardless.

I'm not sure that's strictly a fair comparison. What you actually need 
to specify is what internal browser state the remote SDP can control 
(regardless of where it came from... anyone in the signaling chain can 
lie to you about anything). But having to specify this for both 
setLocalDescription() and setRemoteDescription() still seems like twice 
the work of just having to do the latter. I'm trying to help you out here.

The use cases for being able to change things like the payload type and 
SSRC in setLocalDescription() seem pretty marginal, and even modifying 
the receive codecs doesn't actually seem that critical (you can't add 
codecs the browser doesn't know about, and even if you remove them 
before forwarding the SDP to the other side and don't tell the local 
browser about it, it shouldn't actually matter that the browser is still 
prepared to receive them: the other side won't know to send them). Which 
leaves, among the things that my brief perusal of the code suggests 
libjingle supports changing, RTCP mux, RTP header extensions, and SRTP 
parameters. I'm not sure why the normal offer-answer process isn't good 
enough for controlling the first two (i.e., if you want to disable RTCP 
mux, it's your job to get an ANSWER back from the remote side that tells 
the browser not to use it), and I suspect we want to be _really_ careful 
about what we allow the app to control for the last one (I admit I 
haven't read enough of the code yet to know exactly what is allowed 
here). If I'm missing something here (entirely likely!) please help me 
understand what it is.

> be handled simply though; if you send multiple OFFERs, you have to be
> ready to receive media for any of them, which simply places constraints
> on what the OFFERs can contain. Adding a source, for example, would not
> cause a complication here, whereas changing recv codecs would.

I'd like to see that example fleshed out into a more complete list of 
what is and is not allowed ("not allowed" in the sense that the browser 
is required to detect and reject such an OFFER).

Received on Friday, 10 February 2012 21:20:12 UTC