Call hold -- was: RE: Panic between createOffer() and setLocalDescription()

Hi,

I recall that one of the use cases for SDP mangling that was discussed some time ago was to put a call on hold. According to http://tools.ietf.org/html/rfc3264#section-8.4 this is done by setting the affected stream(s) to sendonly.

I have not found anything in the latest PeerConnection draft to do this via the API (in a way, this is the opposite of "offerToReceiveAudio / offerToReceiveVideo"), and it is also not listed in the wiki referenced by Stefan below. So it seems to me that currently this can only be done by SDP mangling - or did I overlook something?

In case we want to support common use cases by defining a tool in the API to achieve these, I believe that putting a call on hold should be part of these, as it is even part of the original SDP o/a mechanism which we reference as the basis of JSEP. I.e. we would need to have an API feature which allows to set the sendrecv/sendonly/recvonly field in a more generic way than the current offerToReceiveAudio / offerToReceiveVideo.

Kind regards,
Uwe 

> -----Original Message-----
> From: ext Stefan Håkansson LK [mailto:stefan.lk.hakansson@ericsson.com]
> Sent: Tuesday, February 18, 2014 7:21 PM
> To: Silvia Pfeiffer; piranna@gmail.com
> Cc: Iñaki Baz Castillo; public-webrtc
> Subject: 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 Wednesday, 19 February 2014 11:23:23 UTC