Contributions of Quobis for the standardization of WebRTC

26 May 2021

WebRTC has finished the process to become a W3C and IETF standard. 

Some weeks ago it was announced that WebRTC has finished the process to become a W3C and IETF standard.

This has been a lengthy process that took over 10 years, since Google, together with Ericsson, started the idea to create a technology for managing real-time communication capabilities with browsers. Today, thanks to the pandemic, it is massively used worldwide as the enabler of video calling.

Quobis took an active role in defining signalling stacks for WebRTC 

Quobis started in 2012 as one of the first players to support WebRTC and create ad-hoc solutions based on this technology. During these first years, we got different awards, industry recognitions and were involved in some of the first proofs of concept with major vendors and telcos worldwide.

Over these years, many architectural discussions have been to agree with the main differences between interoperability and compatibility among different browsers. Quobis took an active role in defining signalling stacks for WebRTC, as interconnection with existing networks (IMS-based networks, softswitches or PBXs) was the target of the company.

Quobis background was related to SIP interconnection, as the main business line of the company was initially based on dealing with the SIP interworking challenges, using Session Border Controllers and other signalling engines and media elements. This means that defining the basic signalling stacks for WebRTC was natural for the company and Quobis decided to play an active role on these definitions.

The Internet Engineering Task Force more known as IETF, is the body in charge of discussing and publishing the standards which will be used in the Internet and networking in general on top of the physical layer. All the applications you use today run on top protocols which are defined in Request For Comments (RFCs). RFCs are a joint effort that follows a cooperative effort to produce standards as solid and reviewed as possible. This approach has given shape to the Internet in the last half-century. Quobis employees have modestly contributed to the development of three standards as co-authors in the last 7 years.

The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP)

Firstly, we participated in the definition of SIP version to be used over Websocket (RFC7118), with also two Spanish. Websocket enables bidirectional communication form the Web browser which makes it suitable for a protocol like SIP which requires bi-directional (client -> server, server -> client) and asynchronous communication. We initially developed a JS SIPoWS stack, QoffeeSIP, but we later decided to abandon and start using a fork of JSSIP, a project started and maintained by the other co-authors of RFC. 

As a corollary of this RFC, we also participated in RFC7355 which defines the format of SIP Common Log Format (CLF) (RFC6873) adapted to SIPoWS.

About SIPoWS: the WebSocket protocol enables two-way real-time communication between clients and servers in web-based applications.  This document specifies a WebSocket subprotocol as a reliable transport mechanism between Session Initiation Protocol (SIP) entities to enable use of SIP in web-oriented deployments.

Loop Detection Mechanisms for Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs)

Following the same line of adapting application layer protocols used in real-time communications to Websocket, we also participated in the definition of rfc7332 which defines how to implement the Binary Floor Control Protocol (BFCP) to be transported over Websocket. BFCP is used to control the access to shared resources in a multi-party conference.

About B2BUAs: SIP Back-to-Back User Agents (B2BUAs) can cause unending SIP request routing loops because, as User Agent Clients, they can generate SIP requests with new Max-Forwards values. This document discusses the difficulties associated with loop detection for B2BUAs and the requirements for them to prevent infinite loops.

The WebSocket Protocol as a Transport for the Binary Floor Control Protocol (BFCP)

Coming back to our initial battlefield, the SIP interconnection, Quobis also contributed to rfc8857 which defines a mechanism to detect loops in SIP calls exchanged between B2BUA (Back-2-Back User Agents) such as SBCs or some PBX. This RFC defined the use of the header Max-Breadth to prevent unbounded message loops from happening. Having faced the problem loops between B2BUAs in production deployments makes it easier to understand the relevance of this RFC. SIP loops are often the result of misconfigurations but can literally behave as powerful DoS attacks which can even cause service outages.

About BFCP: The WebSocket Protocol as a Transport for the Binary Floor Control Protocol (BFCP) enables two-way real-time communication between clients and servers. This document specifies the use of Binary Floor Control Protocol (BFCP) as a new WebSocket subprotocol enabling a reliable transport mechanism between BFCP entities in new scenarios.

Next article

SFUs vs MCUs: which is the best way to manage multi-conferencing?

MCU the veteran and the most efficient in terms of bandwidthMCUs have been used for a long time, since the former H.323 era[...]