Re: Panic between createOffer() and setLocalDescription()

On 19 Feb 2014 05:20, "Stefan Håkansson LK" <
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.
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 <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>
> >
> >
>