Re: API scope

On 2/10/2012 4:19 PM, Timothy B. Terriberry wrote:
> 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.

Right.  If you're allowing the local app to change the local 
description, the app needs to know what changes are legal: codecs, 
parameters supported for those codecs, RFCs supported for things like 
mux and any other extensions to SDP.  We either need to specify possible 
changes, or you need to expose "SDP capabilities" in some manner, or the 
app may break the call and get an error from setLocalDescription(). 
Since SDP and all the ways it can be modified and extended by various 
RFCs and codecs is complex to say the least(!), it's tricky for an app 
to do a good job of safely doing more than small, focused mods to the SDP.

This isn't a low-level API, it's still specified in SDP, just not pure 
offer-answer SDP.

> 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.

I'd be a bit more worried about things like changing a=fmtp values for 
codecs - if you change the profile-level-id for H.264 for example, or 
the paramsets.  paramsets in particular are tricky items; they specify 
what you will send, not what you will receive, and they're densely 
encoded - typically you'd need to pass them to the codec to validate 
that they can be used to send.  Don't limit yourself in things to worry 
about to what's currently supported by libjingle.  Also, could the app 
add entire parameter variants for H.264 on new, different payload 
values? (packetization mode, level, etc)  I'd assume yes.

Maybe this is all ok, and works for all the codecs we do (might in the 
future?) support.  It's just hard for me to say that for certain.  For 
example, there's lots of text about how fmtp params are handled in RFC 
3984/6184 for offer-answer, and for declarative - which applies to JSEP? 
  Offer-answer semantics, I assume?

Of course, the answer to OFFER modifications may simply be that the 
browser must do complete validity checking of the local description, and 
kick out an error if the description includes anything it can't support. 
  The addition/modification might not be understood (at all) by the 
local browser, and so ignored, but may be understood and acted on by the 
far side, which assumes our local side is ready to handle it.  This I 
suppose is no different than the current case - the app or anything else 
in the signaling path could add stuff our browser doesn't understand to 
the offer.  (*Why* it would do so is another question.)

>> 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).

Yes, since this is a primary point of difference for JSEP from ROAP, 
it's important to know exactly how different OFFERs can be related, and 
what changes would require tearing down the state and generating a new 
offer (and how you'd get the browser to generate the offer you want).


-- 
Randell Jesup
randell-ietf@jesup.org

Received on Friday, 10 February 2012 23:10:55 UTC