WebRTC GW

In the WebRTC and IMS post we briefly described the IMS and WebRTC integration. We explained that the WebRTC allows a rapid development of clients. The clients still need some infrastructure for the signalling and services – that’s the IMS. The network element which is acting as an interface between these two worlds – the world of web and the world of IMS is called a WebRTC GW. The WebRTC GW is a collection of network functions which we need for the translation of protocols, interworking and authentication procedures. It can be implemented as an enhancement of already present elements (e.g. eP-CSCF) or we can have a new stand-alone entity.

As we said the flows and procedures are described in the reference architecture for WebRTC – IMS communication in 3GPP TR 23.701 and 3GPP TR 33.871. Some new information and experience can be also found in GSMA WebRTC to complement IP Communication Services.

WebRTC GW

WebRTC GW

From the high-level WebRTC GW does the translation between http/ws to SIP and vice versa. When we go a bit more in detail there are many issues which have to be addressed.

  • Authentication and Security Issues
  • Protocol Issues
  • Network Issues
  • Media Issues
  • Legal Issues

Continue reading

A magic box called SBC

It is a part of nearly each IMS deployment. Session Border Controller. As the name indicates it sits on a border. A border between two networks. SBC is a controller so it controls all the traffic (both signalling and media) going through.  So far so good. But what is really the SBC? What standards we can find? Where is some detail description of the SBC internal architecture? Sure, there are plenty of specs which are somehow describing the role of SBC. The basic one describing SBC is the RFC 5853.

SBC in VoLTE

SBC in VoLTE

The meaning of SBC has changed over the last 15 years significantly. We can say that SBCs are solving the problems which are not addressed by other IMS elements – problems with multiple access networks (e.g. IPv4 and IPv6, SIP normalization, VPNs..), security issues (DOS attacks, topology hiding, ..), legislative issues (emergency calls, legal intercept, interworking,..), media related problems (QoS, transcoding, media security,..). And of course, the number of these problems and issues which need to be solved is increasing. So what is the SBC now? As an SBC we understand a network element which is implementing following functionalities:

  • Security:
    • Malicious attacks such as a denial-of-service attack (DoS) or distributed DoS
    • Toll fraud via rogue media streams
    • Topology hiding
    • Malformed packet protection
    • Encryption of signaling (via TLS and IPSec) and media (SRTP)
  • Connectivity:
    • NAT traversal
    • SIP normalization via SIP message and header manipulation
    • IPv4 to IPv6 interworking
    • VPN connectivity
    • Protocol translations between SIP, SIP-I, H.323
    • Access Transfer
  • Quality of service – the QoS policy of a network and prioritization of flows is usually implemented by the SBC. It can include such functions as:
    • Traffic policing
    • Resource allocation
    • Rate limiting
    • Call admission control
    • ToS/DSCP bit setting
  • Regulatory – many times the SBC is expected to provide support for regulatory requirements such as:
  • Media services – many of the new generation of SBCs also provide built-in digital signal processors (DSPs) to enable them to offer border-based media control and services such as:
    • DTMF relay and interworking
    • Media transcoding
    • Tones and announcements
    • Data and fax interworking
    • Support for voice and video calls
  • Statistics and billing information
  •  WebRTC Gateway

(source Wikipedia)

Continue reading