Intent to Implement and Ship: Promise-based RTCPeerConnection's createOffer and createAnswer methods.

2,621 views
Skip to first unread message

Guido Urdaneta

unread,
Feb 29, 2016, 9:27:58 AM2/29/16
to blink-dev

Contact emails

gui...@chromium.org, h...@chromium.org


Spec

https://w3c.github.io/webrtc-pc/

Tag review: https://github.com/w3ctag/spec-reviews/issues/14


Summary

The latest version of the WebRTC spec introduces five new promise-based versions of existing RTCPeerConnection methods.

This intent covers the addition of two three of these methods: createOffer() and createAnswer(). Promise-based versions of the other three methods (setLocalDescription(), setRemoteDescription() and addIceCandidate()) already exist in Blink. See related Intent to Ship thread.

Promise-based versions of createOffer() and createAnswer(), are being added one release after the other methods because there were overloading issues in the legacy versions of createOffer() and createAnswer() that required a stabilization period to be resolved (see related Intent to Remove thread).


Motivation

The WebRTC API, like many other JavaScript APIs, has been updated to support promises instead of callbacks as the preferred mechanism for asynchronous programming. This Intent to Ship is a step in that direction. Existing callback-based code will continue to be supported, though.


Interoperability and Compatibility Risk

The addition of these three new methods improves interoperability, as it makes Blink more compliant with the spec and more compatible with Firefox, which already supports these methods. In addition, the existing versions of the methods are still supported, so existing applications do not need to be rewritten.


The main compatibility issue this change introduces is that the return type of legacy methods will change from void to Promise<void>. In practice, this means that TypeErrors will not be thrown as usual, but will be reported to the returned Promise. This can happen when the methods are invoked with arguments of incorrect types. The current legacy implementations of createOffer() and createAnswer() also throw TypeErrors  when custom parsing of one of the arguments fails. This implementation detail will be changed so that some harmless errors (e.g., the presence of an unused field) do not result in a failure, or that parsing errors are reported via the failure callback.


Ongoing technical constraints

None.


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.


OWP launch tracking bug

crbug.com/582920.


Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5743313768415232


Requesting approval to ship?

Yes.


Philip Jägenstedt

unread,
Feb 29, 2016, 12:31:37 PM2/29/16
to Guido Urdaneta, blink-dev
LGTM1. Guido and I are discussing some of the details for errors in custom dictionary parsing in https://codereview.chromium.org/1713953002/, but that's all with the goal of enabling the promise-based methods.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Chris Harrelson

unread,
Mar 1, 2016, 11:29:03 AM3/1/16
to Philip Jägenstedt, Guido Urdaneta, blink-dev
LGTM2

TAMURA, Kent

unread,
Mar 1, 2016, 8:45:46 PM3/1/16
to Chris Harrelson, Philip Jägenstedt, Guido Urdaneta, blink-dev
LGTM3

--
TAMURA Kent
Software Engineer, Google


PhistucK

unread,
Jun 13, 2016, 11:45:47 AM6/13/16
to TAMURA, Kent, Chris Harrelson, Philip Jägenstedt, Guido Urdaneta, blink-dev
As it turns out, the new Promise based createOffer method comes with a new addTransceiver() method which was not implemented and thus creates some compatibility and/or interoperability issue.
See crbug.com/619289#c5 for details.

Harald says -
"the only question is how much pushback we get on adding non-standard options to the Web-exposed API"


PhistucK

PhistucK

unread,
Jul 8, 2017, 4:10:05 AM7/8/17
to Harald Alvestrand, Guido Urdaneta, blink-dev, Philip Jägenstedt
WebKit advocates addTransceiver as well now in their recently revealed implementation.

Are there any short-term plans to implement it before Safari 11 is released?
I see that no other browser implemented this API (except the upcoming Safari 11) -

If there are no plans to implement this method, perhaps WebKit/Safari 11 should remove it as well?




PhistucK



PhistucK

LGTM3


LGTM2


To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.



--
TAMURA Kent
Software Engineer, Google


--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.


Philip Jägenstedt

unread,
Jul 31, 2017, 5:45:16 AM7/31/17
to PhistucK, Harald Alvestrand, Guido Urdaneta, hb...@chromium.org, blink-dev
+Henrik Boström, can you take a look at this?



PhistucK

LGTM3


LGTM2


To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.



--
TAMURA Kent
Software Engineer, Google


--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.


Philipp Hancke

unread,
Jul 31, 2017, 6:32:17 AM7/31/17
to PhistucK, Harald Alvestrand, Guido Urdaneta, blink-dev, Philip Jägenstedt
addTransceiver is the alternative to the legacy offerOptions, it is not going to go away as it is an integral part of the transceiver evolution of the API as described in https://blog.mozilla.org/webrtc/the-evolution-of-webrtc/

Henrik Boström

unread,
Aug 14, 2017, 5:55:29 AM8/14/17
to blink-dev, phis...@gmail.com, h...@chromium.org, gui...@chromium.org, foo...@chromium.org
addTransceiver is part of the RTP Media API, there is consensus and this is being worked on. I am currently working on the essential addTrack and removeTrack parts of this API. addTransceiver in addition will allow receiving streams earlier and should be implemented as soon as we have lower-layer support and addTrack/removeTrack is shipped.

georg...@gmail.com

unread,
Sep 19, 2017, 12:09:22 AM9/19/17
to blink-dev

emmy...@gmail.com

unread,
Nov 13, 2017, 4:25:41 AM11/13/17
to blink-dev
internership
Reply all
Reply to author
Forward
0 new messages