Joyn/RCS vs. webRTC: Solving Directory Services

To "punch a hole in the firewall" requires other protocols and a server or two on the public Internet. For example, ICE (Interactive Connectivity Establishment) may use both Session Traversal Utilities for NAT (STUN) and Traversals Using Relays Around NAT (TURN) servers on the Internet to provide the information needed by endpoints to set up connections through NAT devices. Done well, these solutions solve the issues of VoIP configuration.  (For a complete description of ICE, STUN, and TURN, please see my book:  VoIP and Unified Communications.)

The webRTC project intends to overcome the connectivity problems with:

Google put the source code for webRTC out for use with very liberal free licensing, including certain Google patents required by the webRTC javascript software.   The goal is to make browsers capable of real-time communications.  There are several use cases for connectivity, including:

Isn't that third item what the phone companies do for voice? Almost.  Telephones have a globally unique address space, defined by Recommendation E.164 of the International Telecommunications Union (ITU).   The telephone number includes country and area codes.  Every phone installed on the PSTN automatically has an address known to the network, the E.164 address.  Control of how the numbers are allocated--only by local exchange carriers--means the PSTN can find any called number.  

In contrast to the PSTN's address protocol, the average web server lacks complete knowledge of all computers on the Internet, but it can ask for help. The Domain Name Service (DNS) traditionally maps URLs and email addresses to IP addresses.  End users must ensure their domain names are entered in DNS, usually by their ISPs.  Users of VoIP can register a voice server or voice instrument (for example a SIP phone) in an additional DNS record--but it's not inherent or automatic as for PSTN phones.

Converting an E.164 phone number to an IP address requires two steps: 

It's possible, then, for a web server to connect any two hosts that log onto that server or are listed in the DNS.  

Five years ago a program called Rich Communication Suite (RCS) started to define multimedia communications as a way to add features and value to cellular voice calls.  The 3rd Generation Partnership Project (3GPP), a group of telecom associations, adopted the work and continues it, now marketed as Joyn.  The 3GPP has published a series of Joyn specifications, with version 5.1 as the most  current.

Each carrier that deploys Joyn operates an Internet-protocol Multimedia Subsystem (IMS). It controls the signaling that sets up each medium: voice, video, file transfer, presence, etc. Other servers can deliver information streams or they can come from subscriber equipment. Extending all services over IP anticipates the all-IP transport of 4G/LTE networks.

Joyn operates within (and among) cellular carriers. Joyn, developed for cellular phones, deals with known E.164 addresses. Each carrier's home registry tracks the location of every mobile device, so there there is no need for NAT.

Under RCS, it is the IMS server that coordinates signaling and call setup--the same functions performed by the web server in webRTC and by a softswitch or IP PBX.

Both Joyn and webRTC suffer when compared to the PSTN because of directory services. IP-based devices may register with a local server, a web site, or an IP PBX--but there is no universal VoIP directory until ENUM is completed. All E.164 telephone numbers are known to the network--that is, every phone is registered by default in a global arrangement. A SIP address (SIP:UserName@domain.TLD) also relies on a user to populate a record in DNS and faces those problems with NAT. That's why many IP to IP calls today route through the PSTN. 

Because voice and (to a lesser extent) video calls still rely on the PSTN for directory services, closing down the circuit-switched PSTN would create major problems until a modified DNS can enable webRTC, Joyn, and SIP/ to find everyone, anywhere.