Ever thought how to wakeup your WebRTC Web Application?
One of the IETF 92 meeting items we believe is very important for WebRTC is browser push notification. Here are details about this coming to you from Dan and Amir. It is important to note that this work has just started so this can be yet another reason for you to signup for updates.
Highlights
WebRTC on mobile is more complicated in almost every area you look at (media, device diversity, support on devices…), but since the majority of WebRTC use cases on mobile devices are for applications rather than browsers, when it comes to push notification life is easier on mobile.
The need is pretty simple; it should be possible to notify the WebRTC application about events even when that application is not running. The trivial use case is an incoming call.
On mobile this is done through push notification messages that are sent from an application to the Google/Apple notification servers and from there to the device.
On the web this capability is not possible yet and requirements are a bit more complicated. The need is to be able to:
- Notify a web app even if user doesn’t have it open
- Launch the required web app in the correct state
- If browser is not open, launch it
- Know in which browser to launch it (computer may have multiple browsers)
Being able to receive those notifications requires having a client running on the PC. This client would receive the notifications from the notification server and in turn, act upon them (open the web app in a new a browser window/tab with state information).
Given this, it doesn’t make sense to have a notification service per web application, but rather solve the problem in a way similar to how notifications are done on mobile, e.g., in the OS level or through a limited number of push notification servers that would consolidate all notifications.
The standards now being worked on at W3C and the IETF don’t directly address the points above, but they do standardize the implementation and use of Internet-based push notification services for both web browsers and web applications.
Impact on my application
A very important capability for almost anyone using WebRTC in the browser, this should finally provide a standard way to interact with and use push notification services from within the web application.
Standards status
Work at W3C and IETF has recently started.
Details
The charter of the working group includes creation of an HTTP based protocol that will allow applications to request delivery of data to applications through a consolidated service. The working group will work in cooperation with W3C’s Web Push API. The solution for notifying web apps should support many applications (User Agents), different browsers and OSs as well as cases where one application runs on multiple devices and all application instances need to be notified.
PUSH API (W3C)
In 2012 work began in the W3C Web Applications (WEBAPPS) Working Group on standardizing such an API for HTML-based applications, the timing driven in large part by the urgent WebRTC use case of waking up an application for a real-time incoming call. Thus the W3C Push API was born. The intent was to provide very simple JavaScript APIs for push client registering and message receipt. Although the use cases for and requirements on the API have grown substantially over the past few years, particularly the need to accommodate many-to-many relationships among notification servers, user agents, and the applications running on them, the API remains relatively simple.
The API has two logical pieces:
- a pushRegistrationManager that consults the user agent about which push service to use and returns information (a registration id and a URI) that can be sent to the application server for it to know how to reach the push service. The details of what goes into these two information slots are loosely specified, but in general the URI is where the application server can send push messages and the registration id is to be provided to the push service to indicate the delivery target for the messages.
- a Service Worker that is used to catch, store if necessary, and ultimately deliver push messages to the application.
It is important to note that this is a client API that does not provide any standard for how the application server sends messages to the push server. This part is covered by the IETF WEBPUSH protocol.
WEBPUSH protocol (IETF)
Several technologies have really come together at the right time. Mobile devices have had notification services for a while now because of the need to limit (or at least consolidate) use of the power-consuming mobile radio. HTTP 1.x, however, was never designed to provide either long-lived connections or server-to-client, aka push, capability.
HTTP version 2, on the other hand, does have this capability.
In order to provide a standard way for push notification to be used on the Internet, the IETF WEBPUSH working group was created in late 2014. As stated in the charter of this working group, the WEBPUSH WG is developing an HTTP2-based mechanism for applications “to request the delivery of data to a device using a consolidated push notification service. This protocol will include the ability to push the same message to multiple subscribed devices. The work may describe a protocol that allows a device to subscribe to a push service and receive pushed messages.”
As with other IETF work, the effort will also mandate the ability to have end-to-end security while considering privacy.
Expected clients are both web applications and field gateways that consolidate and forward messages to embedded devices. Work was well underway by IETF 92. Several models have been discussed, and there currently seems to be most interest in a publication-subscription model where each device subscribes individually, but with no requirement for a separate registration in advance. There do not appear to be any major blocking issues at this time.
Briefly, the protocol defines:
- How a user agent (browser or field gateway) contacts its configured push service for the subscription/registration information that the W3C Push API registration call returns
- How the application server sends the subscription info to the push service
- How the application server sends push messages to the push service
- How the user agent receives push messages from the push service
See the actual IETF Web Push protocol for details.
Naturally, these 2 working groups are required to cooperate so the APIs and protocol are consistent.
Want to know more about these topics and what went on at the IETF meeting? Make sure to subscribe for updates.
Leave a Reply