April 4, 2013

Joyn/RCS vs. webRTC: Solving Directory Services

The basic Session Initiation Protocol (SIP) doesn't anticipate the presence of Network Address Translation (NAT) between IP phones.  Fortunately, when IPv6 completely displaces IPv4, the need for NAT will be eliminated; however, today almost all sites remain behind NAT as part of firewall protection --which creates problems for inbound connection requests.

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:

  • ICE to penetrate firewalls that operate with NAT, and
  • Sharing port 80 with all media streams so only one pinhole is needed in the firewall.

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:

  1. A user clicks on a button in a web page to set up multimedia communications with the host server. This is similar to click-to-talk or -chat or -video conference with a sales agent.
  2. A special-interest web site (cars, construction, golf, etc.) that helps its members contact each other.
  3. Any visitor to the web site can request a connection to any browser on the Web.

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: 

  1. ENUM (Electronic NUmber Mapping), an extension of DNS, converts the E.164 address to a URL.
  2. Looking up that URL in a specialized DNS server finds the IP; for a PSTN phone the IP address would be on a gateway to perform media and signaling conversions.

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.

Search Webtorials

Get E-News and Notices via Email




I accept Webtorials' Terms and Conditions.

Trending Discussions

See more discussions...

Featured Sponsor Microsites



Please note: By downloading this information, you acknowledge that the sponsor(s) of this information may contact you, providing that they give you the option of opting out of further communications from them concerning this information.  Also, by your downloading this information, you agree that the information is for your personal use only and that this information may not be retransmitted to others or reposted on another web site.  Continuing past this point indicates your acceptance of our terms of use as specified at Terms of Use.

Webtorial® is a registered servicemark of Distributed Networking Associates. The Webtorial logo is a servicemark of Distributed Networking Associates. Copyright 1999-2018, Distributed Networking Associates, Inc.