Web real-time communications (WebRTC) -- the technology that embeds audio and video clients directly into a Web...
browser -- is all the rage in the UC community these days. The open source project threatens to revolutionize and democratize real-time communication and collaboration by allowing anyone with a Web browser to talk or conduct a video conference with anyone else. WebRTC doesn't require any centralized infrastructure, control mechanisms, third-party service support or closed proprietary applications; all it needs is a directory to allow one client to find another or a bridge to support multiparty conferencing.
How WebRTC sessions connect
Like Session Initiation Protocol (SIP), WebRTC uses the Session Description Protocol (SDP) for clients to exchange information necessary to establish a call. SDP definitions may include voice and video codecs, user identification and potentially even requirements for encryption. Clients also use SDP to share IP addresses, which enables clients to initiate a real-time protocol (RTP) stream to exchange voice and video.
Again, like SIP, this is where it gets challenging. If one client is on a private IP subnet, it will transmit an address that is unreachable to anyone that's not on the same subnet. WebRTC developers solve this problem by leveraging a technique called ICE (Interactive Connectivity Establishment -- RFC5245). ICE allows a WebRTC client to identify and embed its public-facing address rather than its private IP address located within its SDP information. Once again, this is identical to the way that SIP clients figure out their public IP address. Thus, when a remote client receives SDP, it responds to the public-facing address. The NAT server receives this request, maps it back to the internal address and allows the endpoints to establish a session.
Does WebRTC support IPv6?
Introducing IPv6 into the mix creates additional complexity: An IPv4 client can't reach an IPv6 client without using some sort of translator. In the SIP world, RFC6157 recommends that SIP clients adopt a dual-stack approach, whereby each client has both an IPv4 and an IPv6 address. The clients then use SDP to transmit both their IPv4 and IPv6 addresses. The remote end client can then respond to either to establish the session. Alternatively, an IPv6 client could use ICE to identify its IPv4 address as its session request crosses a v6-to-v4 gateway, but this requires a secure RTP (SRTP)/RTP-aware gateway, proxy server or session-border controller. Finally, a WebRTC client could take advantage of existing IPv6 in v4 tunnels (or v4 in v6 tunnels) to establish end-to-end connectivity.
WebRTC session enablement in IPv6 environments
So where are we today with WebRTC support? If both sides are IPv4, even if using network address translation, ICE provides the mechanism to establish connectivity. If both sides are IPv4- or v6-capable, dual-stack can allow IPv4 session establishment (the default) or a client may request IPv6 via the "EnableIPv6" line in SDP. If one side is IPv4 and the other is IPv6, a v4-to-v6 gateway or proxy server is required to translate, but this gateway must support real-time protocols such as RTP and SRTP. As of the time of this writing, I'm not aware of any v4 to v6 proxy servers for WebRTC, though it's likely that this feature will become part of offerings from session border control companies including Acme Packet and Sonus.
Bottom line: If you are planning on supporting WebRTC across v4 and v6 hosts, implement a dual-stack IP-addressing approach to minimize potential obstacles to session establishment.
Why IPv6 won't rid the Internet of NAT
Avoid these IPv6 planning pitfalls
WebRTC brings communications to the next level
Video: How WebRTC will affect the enterprise