Re: Panic between createOffer() and setLocalDescription()

On 2014-02-18 01:12, Silvia Pfeiffer wrote:
> I've also found all sorts of weird things happening when mangling SDP.

I think Martin Thomson has proposed that we for the very first version 
should state that no modification between createOffer/Answer and 
setLocal is be supported (i.e. you are on your own if you do). Maybe 
that is not such a bad idea.

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

I agree, and we also had a discussion on what things that we initially 
need API for. The conclusion of that discussion is captured at
https://www.w3.org/2011/04/webrtc/wiki/Transport_Control

Stefan

>
> 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 18:21:01 UTC