Panic between createOffer() and setLocalDescription()

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>