Re: Panic between createOffer() and setLocalDescription()

I was kind of hoping that the IETF list, which seems to have been handed the bulk of ironing out the details, would provide some concrete examples (beyond a laundry lis0t of requriements) for it's existing use case document:

http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14

Does anyone know of successful and repeatable cross-browser tests for the use cases in the above document?  If this is off topic for the W3C discussion, what is the proper method for actually getting some concrete SDP examples defined?

Thanks
-jim spring



On Feb 17, 2014, at 4:10 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:

> I've also found all sorts of weird things happening when mangling SDP.
> I think we need to pull all the use cases and turn them into actual
> browser APIs. Such as: setting bandwidth limits, muting/unmuting/hold,
> codec change. Once we've done all those, we can cordon off SDP. Right
> now, though, that would inhibit a lot of useful things from being
> possible.
> 
> Silvia.
> 
> 
> On Tue, Feb 18, 2014 at 8:12 AM, piranna@gmail.com <piranna@gmail.com> wrote:
>> I totally agree, setLocalDescription() purpose seems extrange to me (don't
>> you know who you are?!?!), and I also think that SDP, if used, should be
>> considered a closed, cryptic and inmutable blob, not allowing modifications
>> (I don't find SDP bad for itself except for being too verbose, but I find
>> bad the fact thay you need to manipulate it).
>> 
>> Send from my Samsung Galaxy Note II
>> 
>> El 17/02/2014 21:40, "Iñaki Baz Castillo" <ibc@aliax.net> escribió:
>> 
>>> Hi,
>>> 
>>> I've spent some time playing with SDP mangling between createOffer() and
>>> setLocalDescription(). I won't give accurate details since I prefer not to
>>> remember them, but I hope the whole picture is correctly exposed.
>>> 
>>> Let's say sdp is the RTCSessionDescription.sdp retrieved via
>>> RTCPeerConnection.createOffer():
>>> 
>>> - In Chrome: I can remove some payloads from a m line in that sdp. Then I
>>> pass the modified SDP to setLocalDescription(). The resulting SDP (inspected
>>> via getLocalDescription) does not contain such a payload nor its related
>>> a=rtpmap attribute is also removed (OK).
>>> 
>>> - In Chrome: Instead of removing a payload, I replace its number (i.e.
>>> 125) with another one (i.e. 126) in both the m line and its associated
>>> a=rtpmap attribute. Result after getLocalDescription()? The payload is not
>>> present (opsss).
>>> 
>>> - In Firefox: not tested.
>>> 
>>> - In Chrome: Before setLocalDescription() I can replace a=setup:actpass
>>> with a=setup:passive (to force the remote peer to behave as a DTLS cient).
>>> It works.
>>> 
>>> - In Firefox: It produces a "parsing" error (so the only way is mangling
>>> the SDP *after* getLocalDescription).
>>> 
>>> - In Firefox: Before setLocalDescription() I can remove the a=fingerprint
>>> attribute, but setLocalDescription() will append it again. OK, this seems
>>> reasonable (somehow).
>>> 
>>> - In Chrome: the same action forces the browser to use SDES (deprecated
>>> a=crypto lines are untouched).
>>> 
>>> 
>>> Like those, there are tons of undocumented and unpredictable stuff. The
>>> above basically means that:
>>> 
>>> - The list of *valid* changes that can be performed to a SDP between
>>> createOffer() and setLocalDescription() are undocumented. Some browsers
>>> behave in some way and others in a different way.
>>> 
>>> - The SDP passed to setLocalDescription() could be internally modified by
>>> the browser, so it does not match the "effective" local SDP (which can be
>>> retrieved via getLocalDescription).
>>> 
>>> - I am also pretty sure that modifying the stream direction (i.e.
>>> replacing a=sendrecv with a=recvonly) has not the expectable behavior
>>> (hopefuly I'm wrong).
>>> 
>>> 
>>> JSEP 06 tries to document some of the above actions in section 6
>>> "Configurable SDP Parameters":
>>> 
>>> http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-06#section-6
>>> 
>>> But the door is still open to lot of undocumented possibilities (basically
>>> due to the usage of a blob instead of a real API).
>>> 
>>> 
>>> My conclusion is that the current API is unfortunate. IMHO there should
>>> not be "createOffer" and "setLocalDescription", but a single (or multiple)
>>> API call that, in the end, makes the browser to produce a final and
>>> untouchable SDP. But the current API forces the developer to retrieve an
>>> "initial" SDP offer from a RTCPeerConnection via createOffer() and then to
>>> pass it again to the RTCPeerConnection via setLocalDescription(), which
>>> opens the door to funny nightmares between those steps (100% error prune due
>>> to the specification and due to implementations based on that "too open"
>>> specification).
>>> 
>>> 
>>> Best regards.
>>> 
>>> 
>>> 
>>> --
>>> Iñaki Baz Castillo
>>> <ibc@aliax.net>
>

Received on Tuesday, 18 February 2014 09:16:26 UTC