Re: Panic between createOffer() and setLocalDescription()

Hi,

If the user has enough power to specify how the SDP should look like (e.g. value of setup attribute) when calling createOffer(), there should be no need to modify the generated SDP, should there?

Regards,

Christer

Sent from Windows Mail

From: Stefan Håkansson LK<mailto:stefan.lk.hakansson@ericsson.com>
Sent: ‎Tuesday‎, ‎February‎ ‎18‎, ‎2014 ‎8‎:‎22‎ ‎PM
To: Silvia Pfeiffer<mailto:silviapfeiffer1@gmail.com>, piranna@gmail.com<mailto:piranna@gmail.com>
Cc: Iñaki Baz Castillo<mailto:ibc@aliax.net>, public-webrtc@w3.org<mailto:public-webrtc@w3.org>

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