In this section:

Related articles:

Introduction

The Ribbon WebRTC Gateway (WRTC) technology enables web browsers to participate in audio, video, and data communications, without any kind of additional plug-in or application download. Using a WRTC-enabled browser, a user can place a call, participate in multi-party video and audio conferencing, and engage in screen sharing collaboration. The Ribbon Web Service Solution bridges the web and SIP worlds to facilitate the integration of communications (voice, video, and data) in applications.

The Ribbon SBC Core is a component of the Ribbon Web Service Solution. The SBC provides media service functionality when WRTC endpoints are behind a NAT device.

The SBC acts as a WRTC-to-SIP media gateway. It enables WRTC users to communicate to any back-end SIP system and the PSTN. The SBC also provides routing, security, transcoding, and interworking. It supports the following functionalities:

  • Relaying and monitoring of media streams

  • Inter-working between WRTC media DTLS/SRTP and traditional RTP/UDP

  • Relaying or transcoding Opus to G7xx voice codecs

  • Relaying VP8/VP9 and H.264 video codecs

  • Supporting ICE and STUN procedures for NAT traversal

ICE-Lite Support

Overview

Interactive Connectivity Establishment (ICE) is a protocol for Network Address Translator (NAT) traversal for multimedia sessions established with the offer/answer model. ICE uses the Session Traversal Utilities for NAT (STUN) protocol and its extension Traversal Using Relay NAT (TURN). ICE uses STUN and TURN servers to overcome network address translation issues that can occur when an endpoint is situated behind a NAT device. ICE solves the NAT issues for media streams. Support of the ICE specification is required by WebRTC (WRTC) endpoints.

The SBC is capable of acting as an ICE-Lite agent to allow the WRTC endpoints to connect to the existing VoIP network through the SBC using the DTLS-SRTP protocol. While acting as an ICE-Lite endpoint, the SBC interconnects with endpoints that have either ICE-Lite or full-ICE implementations. ICE-Lite is a lite version of the ICE protocol, which is defined to exchange media with each other. The interconnect with ICE-Lite end points is only for the purpose of IPv4 to IPv6 inter-working and no NAT traversal procedures are supported for ICE-Lite to ICE-Lite.

Note
Implement SBC for ICE with endpoints connected to the SBC through the Ribbon WRTC gateway, as well as WRTC endpoints connected from a third-party WRTC Gateway to present ICE in their SDP.
Note

 As SBC is not required to act as an ICE client (it is not located behind a NAT in current deployment models), the initial support for ICE is limited to the SBC acting as an ICE-Lite endpoint.

ICE-Lite key points:

STUN message processing:

    • Decoding received messages on media port
    • Validating the received messages
    • Authenticating the received messages
    • Encoding outgoing STUN Response messages and sending on allocated media port
    • Encrypting outgoing STUN as per the configured username/password

Reachable IP address:  an ICE-Lite agent has a reachable public IP address and can work with other agents that use ICE and are behind the NAT.

ICE-Lite Implementation

The ICE-Lite procedure starts with the offerer discovering all IP ports where it is reachable.These are known as local “candidates”. The “candidates” can be any or all of the following:

  • Host candidates (Local IP port)
  • Server Reflexive Candidates (External IP port allocated by NAT)
  • Relay candidates (IP port on a media relay)

Use STUN to discover the Server Reflexive and Peer reflexive addresses on the NAT. Use TURN to discover the Relay candidates on the TURN relay. After the local candidates are discovered, the offerer (Full ICE Agent) sends them in the session description protocol (SDP) offer to the remote endpoints. The remote end point (SBC) discovers its own local candidates (which are only host candidates) and sends in the answer SDP to the offerer.

Once the offer/answer exchange completes, the Full ICE Agent assumes the role of ICE controlling agent and performs connectivity check between the candidate pairs (from local candidate to remote candidate) by sending the STUN messages. The SBC acts as a controlled agent, and responds to the STUN requests. Based on the success/failure of the connectivity check, the controlling agent selects a candidate pair to exchange the media, and sends a connectivity check on the selected pair with USE-CANDIDATE attribute to let the controlled agent know about the selected pair. The connectivity check may lead to the discovery of new local candidates due to the presence of Restricted or Symmetric NAT. These local candidates are also included in the procedure and are known as “Peer Reflexive Addresses”. The SBC, as a controlled ICE-Lite agent, cuts through the media after receiving USE-CANDIDATE on all components of the media stream (for example, if RTP and RTCP are required for a stream, the media is only cut-through when USE-CANDIDATE is received for both RTP and RTCP).

The controlling agent sends an updated offer by using the selected local candidate in the default IP port of the media line, and the controlled agent (SBC) responds by sending its local candidate in the default IP port of the media line to complete the ICE-Lite procedure. Use the Full ICE agent (using the ICE Restart procedures) to restart the Ice-lite procedure if the Media ports change during a call.

The ICE-Lite procedure starts with the offerer discovering all IP ports where it is reachable

DTLS/SRTP Support

Similar to TLS, the Datagram Transport Layer Security (DTLS) protocol provides authentication, data integrity, and confidentiality for communications between two applications over an unreliable User Datagram Protocol (UDP) connection. The Secure Real-time Transport Protocol (SRTP) provides encryption, message authentication and integrity, and replay protection to the RTP data in both unicast and multicast applications. DTLS-SRTP is an extension to the DTLS protocol, where DTLS acts as the key management protocol. DTLS protocol is also extended to negotiate the SRTP crypto suites and parameters for use with those keys.

WebRTC is a signaling protocol defined for real-time communication between web browsers. WebRTC uses the DTLS-SRTP protocol for media exchange between browsers. The SBC includes the following functionality:

  • Real-time communication between web browsers using DTLS-SRTP while inter-working with SIP networks.
  • DTLS on the media path for key management for SRTP-based media.
  • Self-signed certificates to secure and authenticate DTLS associations. DTLS connections are secured by the two browsers sharing self-signed certificates as part of the media connection during a DTLS handshake between the browsers. The certificates are authenticated by checking a fingerprint which is passed in the signaling path as part of the Session Description Protocol (SDP) negotiation.

The SBC includes crypto suites that define a set of ciphers (algorithms used for encrypting data) which allow the selection of an appropriate level of security. When a DTLS connection is established, the client and server exchange information about which cipher suites they have in common.

For configuration details, see Configuring SBC for WRTC.

  • No labels