Re: Panic between createOffer() and setLocalDescription()

I've also found all sorts of weird things happening when mangling SDP.
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.

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 00:11:32 UTC