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

Re: Panic between createOffer() and setLocalDescription()

From: Ethan Hugg <ethanhugg@gmail.com>
Date: Mon, 17 Feb 2014 12:47:53 -0800
Message-ID: <CALQ_quiXjP5XYsF8aPy-aexG5K6c=p7Gxt92ZMkhqzsJNR3KXg@mail.gmail.com>
To: Iņaki Baz Castillo <ibc@aliax.net>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
In Firefox we simply do not allow changes to the SDP between CreateOffer
and SetLocal.  We should but it's a bug that has not yet been fixed -


On Mon, Feb 17, 2014 at 12:38 PM, Iņaki Baz Castillo <ibc@aliax.net> wrote:

> 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:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:54 UTC