W3C home > Mailing lists > Public > public-webrtc@w3.org > February 2014

Re: Panic between createOffer() and setLocalDescription()

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Tue, 18 Feb 2014 18:20:35 +0000
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, "piranna@gmail.com" <piranna@gmail.com>
CC: Iñaki Baz Castillo <ibc@aliax.net>, public-webrtc <public-webrtc@w3.org>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1CF6AAE2@ESESSMB209.ericsson.se>
On 2014-02-18 01:12, Silvia Pfeiffer wrote:
> I've also found all sorts of weird things happening when mangling SDP.

I think Martin Thomson has proposed that we for the very first version 
should state that no modification between createOffer/Answer and 
setLocal is be supported (i.e. you are on your own if you do). Maybe 
that is not such a bad idea.

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

I agree, and we also had a discussion on what things that we initially 
need API for. The conclusion of that discussion is captured at


> 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 18:21:01 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:38 UTC