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
  • Demarkation
  •  WebRTC Gateway

(source Wikipedia)

Read More

VoLTE – close encounters

If you know a bit about SIP and IMS you are probably aware that they are quite flexible. There are many ways how to do some solution and different vendors can easily come up with different implementation for the same thing.

In trainings people are asking very often – is this SIP message mandatory, what will happen if our client will not support this feature, what header attribute is the right one to identify xyz?

Well we have a huge number of specifications (from different organizations and bodies as 3GPP, IETF, OMA, GSMA, …). To avoid the confusion for VoLTE service GSMA created (yes another) document called VoLTE Service Description and Implementation Guide. This is not a classical spec, rather a guide what are the exact call flows and what message fields are relevant for the VoLTE.

We already know the registration from other posts (Registration, How to read tcpdump – RegistrationThird party registration, Sh, ..). In the VoLTE the flow looks like this:

VoLTE registration
VoLTE registration

Read More

P-Early-Media – You are running low on credit!

Have you ever thought about how this simple announcement works? Most of the (IMS aware) people believe that in order to establish a media session an UAC (originator’s handset) has to send the SIP ACK. This is true as long as we don’t need to inform the originator before the real voice or video call is established – e.g. running low on credit, informing about calling into foreign network, playing customized ring back tones etc.

In order to achieve this functionality the RFC 3960 introduced a concept of Early Media. The basic call can look like this:

Early Media
Early Media

In general this early media can be generated by caller, callee or both. In case that B2BUA is present – which is the case of TAS in VoLTE, the B2BUA can establish the Early Media session too.

Read More

It is about quality!

One of the marketing reasons why one should prefer VoLTE instead of common VoIP is the Quality of Service. The framework for Policy and Charging Control is described in its own post. Here we’ll focus QoS support in SIP/SDP protocols. Note that this post goes in details and expects that you’re familiar with SIP/SDP session negotiation procedure. When we want to support QoS during the session negotiation we need to add so-called preconditions in the SIP INVITE:

Require: precondition

The details can be found in the RFC 4032 and RFC 3312. The preconditions can be of several types as  qos, connectivity or security. In order to support QoS there are dedicated fields in SDP:

 
      current-status     =  "a=curr:" precondition-type
                            SP status-type SP direction-tag
      desired-status     =  "a=des:" precondition-type
                            SP strength-tag SP status-type
                            SP direction-tag
      confirm-status     =  "a=conf:" precondition-type
                            SP status-type SP direction-tag
      precondition-type  =  "qos" | token
      strength-tag       =  ("mandatory" | "optional" | "none"
                         =  | "failure" | "unknown")
      status-type        =  ("e2e" | "local" | "remote")
      direction-tag      =  ("none" | "send" | "recv" | "sendrecv")

The logic is very simple. Each participant will define whether he/she has some desired status he/she wants to reach. Then during the SDP offer/answer negotiation they are simply checking if the current state >= desired state. Read More

VoLTE in IMS

The year 2015 is definitely a year of VoLTE. VoLTE is everywhere and operators are rolling out as crazy. There are plenty of articles describing how the LTE or LTE-A do work. We’ll put the LTE Packet Core part aside and take a look on the IMS related VoLTE architecture and VoLTE call flows.

Voice over LTE service specified in GSMA IR.92. If you think it seriously with VoLTE, don’t waste your time on any blog and read the VoLTE Service Description and Implementation Guide. On the other hand real beginners can try our VoLTE Illustrated: Beginners Guide.

The very basic architecture of IMS for VoLTE can look like this:

VoLTE network architecture – simplified

During the LTE attach procedure VoLTE client receives IP address of P-CSCF.

  • P-CSCF (Proxy Call Session Control Function)
    • An entry point for IMS signalling. It is directly connected to the VoLTE device (UE) over SIP protocol.
    • P-CSCF maintains the security associations between itself and the UE.

The P-CSCF is usually a part of A-SBC.

  • A-SBC (Access Session Border Controller)
    • Provides connectivity for two or more IP networks, including IPv4 and IPv6 interworking, NAT traversal, etc.
    • Implements Security features, e.g. DoS, DDoS attack prevention, Topology Hiding, Encryption, CAC, ..
    • Communicates with access network (e.g. LTE) and is responsible for QoS
    • Handles Media Services, provides transcoding if needed

For the end-2-end signalling (voice call setup) we use SIP protocol. The multimedia then goes out-of-band using RTP protocol.

The heart of IMS network is IMS Core. It consists of often collocated I/S-CSCF, which cares about authentication, session routing and management.

  • I-CSCF (Interrogating Call Session Control Function)
    • I-CSCF provides a Location service. That means that for each subscriber (or public service) I-CSCF is able to locate the right S-CSCF.
    • I-CSCF also represents IMS network to peers. E.g. for peer networks the I-CSCF is the first point of contact.
  • S-CSCF (Serving Call Session Control Function) 
    • The S-CSCF is responsible for basic IMS services.  It is a SIP server providing session set-up, session tear-down, session control and routing functions.
    • S-CSCF acts as SIP Registrar – stores the binding between Public User Identity (e.g. sip uri or tel uri) and its actual point of presence (Contact IP address) and maintains user registration status. During VoLTE registration procedure S-CSCF performs user authentication.
    • S-CSCF also invokes Application Servers (TAS, IPSMGW) based on rules (IFCs) received from the HSS.

The IMS Core however doesn’t know anything about Voice or SMS service. That is a task for Application servers. The Application Server for voice and video telephony is called TAS – Telephony Application Server or MMTel AS – Multimedia Telephony AS.

  • Telephony Application Server (TAS) 
    • The application server responsible for all the services as address normalization, call diverting, call forwarding, barring, etc.
    • In a nutshell TAS is what makes the VoLTE enhancements on top of the pure VoIP.

VoLTE specification also defines SMS interworking. To support SMS over SIP we have a dedicated Application Server called IPSMGW. In more detail it is described in IPSMGW – Transport Level Interworking post.

IMS Core and Application Servers don’t have any persistent storage. All the information about subscribers and their services is stored in HSS (Home Subscriber Server). The communication between HSS and I/S-CSCF or TAS makes use of Diameter protocol.

Other IMS elements are:

  • MRF – Media Resource Function
    • Can be used as a media mixer or as a media server for playing of tones and announcements.
  • MGCF – Media Gateway Control Function
    • MGCF is used for the breakout to and from CS network. Usually the MGCF and MGW – Media GW is a part of enhanced MSC.
  • BGCF – Breakout Gateway Control Function
    • BGCF might be used in case when S-CSCF is not able to find the routing based on ENUM/DNS (e.g. PSTN number). Usually it is a part of IMS Core (along with S-CSCF and I-CSCF).

The IMS definition is very broad and flexible. GSMA VoLTE standard restricts it and defines what services are mandatory and how we should implement them. E.g. it defines how to implement Emergency Services, SRVCC, Roaming, SMS interworking, etc. In our post we will go through the basic LTE to LTE callflow.

 

Read More

VoLTE or RCS Voice Call?

Update: The information in this post became obsolete over the time. Recently we’ve got RCS Universal Profile standard, which defines Green Button Promise for Voice and Green Button Promise for IP Video Call Services and Enriched Voice Calling. I’m working on an updated material, which will compare RCS IP Calls and VoLTE/VoWifi calling and describe RCS Network Architecture.

 

It is similar with many OTT applications for calls and massaging. Which one is the right or at least decent one? The big advantage is that usually we can try it for free.  Anyway what is the difference between a voice call performed as VoLTE (or VoWiFi) and voice call which is transmitted via RCS?

The 4G networks were originally designed for pure data traffic. But the voice service is a must have feature and right now it can’t be fully replaced by VoIP. The voice service has to be reliable and fully compatible with the service from 3G (Blacklisting, Call diverting, Lawful intercept, Emergency calls, DTFM, etc.) and has to allow seamless fallback in case the 4G coverage is lost (eSRVCC). This new service is called VoLTE.

Read More

What Are You Capable Of?

You have seen a couple of IMS flows. You know the registration, the 3rd party registration. Flows of SIP INVITE, SDP, SIP MESSAGE, RTP and RTCP, MSRP … do you think you know enough? For the core functionality this is nearly all we need. But for a real service there are many other things we have to learn. Yes in theory there is the Signaling and Media Plane. But there is also a parallel world of Presence and Capabilities. (And some other parallel worlds of billing, provisioning, monitoring, etc.)

The cornerstone mechanism for all the VoLTE/ViLTE, Instant Messaging and particularly for the RCS is a capability discovery. Users want to see their contacts with the RCS services that are available to communicate. This can be implemented either using the SIP OPTIONS or using a Presence-based solution defined in RCS Release 1 -4. Both will result in one of three types of response:

  1. The contact is registered for service resulting in the contacts current service capabilities
    being received and logged, or,
  2. the contact is not registered (they are provisioned but not registered),
  3. the contact is not found (they are not provisioned for service).

This discovery mechanism is important since it ensures that users can determine what services are available before the communication starts. The same mechanisms can be used to initially discover (and/or periodically check) the service capabilities of all the contacts within an address book when we first register for the service. For the Service Providers it is also very useful because they can add new types of communication channels without compatibility issues.

Capabilities of a device are shared during SIP Registration, over SIP OPTIONS and using the presence system.

SIP OPTIONS for VoLTE

In practice in VoLTE networks we can find the SIP OPTIONS messages to be used as application-layer pings or heart-beats. Via them we can monitor an availability of IMS network servers (instead of SNMP traps for example). E.g. S-CSCF monitors Applications Servers using SIP OPTIONS. If TAS is able to respond with 200 OK, it means it is up and running and not overloaded.

Moreover in VoLTE/ViLTE the SIP OTIONS can be also used for capabilities sharing. The IR.94 says that a Contact header field in a 200 OK response message to a SIP OPTIONS request must include the IMS Communication Service Identifier (ICSI) value of “urn:urn-7:3gppservice.ims.icsi.mmtel”, as defined in 3GPP TS 24.173. In addition for ViLTE, a contact header in a 200 OK response message to a SIP OPTIONS request must include a “video” media feature tag.

SIP OPTIONS for Presence and Capability Discovery

In this post we’ll address mainly the SIP OPTIONS presence/capabilities discovery and basic presence system.  The SIP OPTIONS method is send as end-to-end message. It is used both to query the capabilities (services which the other user has available) of the target contact and to pass the information about which capabilities are supported by the requester. Using this method, both users get updated information in a single transaction.

SIP OPTIONS
SIP OPTIONS

Read More

Sh Interface – What Is It Good for?

There are main principles and there are small technical details. People mostly understand how a petrol engine works. But that doesn’t mean they are able to fix one or even make it. No, it is a long way to understand how things really work. And it is a psychologically proven fact that we can’t really understand things until we will try to change them. Well, don’t try it at home with your petrol engine.

This time we will take a closer look on one of often omitted interfaces. You don’t need it in order to understand the general idea of IMS but when we go into a detail it can be very important.

Sh Interface
Sh Reference Point

The Sh interface is defined by 3GPP in TS 29.329 as a Diameter interface between an AS and HSS.

Read More

Much Ado about Registration

Registration is something what was missing in the times of wires. Ok, not completely but it was done more or less once when an MSISDN was assigned to some line.

IMS Registration
IMS Registration

In contrast to the previous types of the networks the 4G network is ‘user-centric’. It means the user can use multiple devices and identities and we have to deal with it. The main purpose of the registration is to create a binding between user (her public identity) and IP address of the device, so we know where we can send the data to. That’s why there is a Contact header in the SIP REGISTER message. The Contact header contains an address which identifies the current location of the user (Point-of-Presence – e.g. IP/FQDN of a particular client). During the registration is the Contact Address is linked to a Public Identity (IMPU, AOR in SIP terminology). The IMPU is an equivalent to MSISDN in GSM and has to be present in the To header of the SIP REGISTER. One identity can by used by more terminals and as each terminal can have different capabilities this has to be also taken into account. This information is part of the Contact header.

Contact: <sip:119560022547@152.67.235.234:49635;transport=tcp>;
   expires=3200;
   +g.oma.sip-im;
   language="en,fr";
   +u.asmc.apn="6a6044869e2aba3d23d4cfc0ef1384d00da28854c2408ddbbf";
   +sip.instance="<urn:uuid:D4196919-ED8A-4E00-9436-B9CDD1E76813>"

Read More