Re: Panic between createOffer() and setLocalDescription()

On 2014-02-18 23:46, Silvia Pfeiffer wrote:
>
> On 19 Feb 2014 05:20, "Stefan Håkansson LK"
> <stefan.lk.hakansson@ericsson.com
> <mailto:stefan.lk.hakansson@ericsson.com>> wrote:
>  >
>  > 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
>
> Thanks for digging this out.
>
> We should continue to update this list with use cases as they appear.

That was the intention, it should be a "live" document.

> There's one for controlling FEC activation on another thread right now.
>
> Cheers,
> Silvia.
>
>  > Stefan
>  >
>  > >
>  > > Silvia.
>  > >
>  > >
>  > > On Tue, Feb 18, 2014 at 8:12 AM, piranna@gmail.com
> <mailto:piranna@gmail.com> <piranna@gmail.com
> <mailto: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
> <mailto: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 <mailto:ibc@aliax.net>>
>  > >
>  > >
>  >
>

Received on Wednesday, 19 February 2014 07:06:58 UTC