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

Panic between createOffer() and setLocalDescription()

From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Mon, 17 Feb 2014 21:38:06 +0100
Message-ID: <CALiegfme=8dRn-sM99LNQs1oCZizEtLoz4bt6pjYVffFp6EW_w@mail.gmail.com>
To: "public-webrtc@w3.org" <public-webrtc@w3.org>

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

- 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

- 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

JSEP 06 tries to document some of the above actions in section 6
"Configurable SDP Parameters":


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"

Best regards.

Iñaki Baz Castillo
Received on Monday, 17 February 2014 20:38:54 UTC

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