Re: Panic between createOffer() and setLocalDescription()

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