Crack the NAT

It is really hard to predict the future. The authors of SIP and SDP designed (1996) a great concept which really addressed the needs of not just real-time communication for the next two decades. But they also believed the the Network Address Translation (NAT) is only a temporary solution which will be obsolete once everyone will use IPv6. In 2015 we still use the NATs and I’d think (! the same mistake again) that we’ll use it for a couple more years.

NAT is technique  which became in conjunction with IP masquerading a popular as an essential tool in conserving global address space allocations in face of IPv4 address exhaustion. These days the NAT is used also for security reasons e.g. topology hiding, port and IP restrictions etc.

The basic functionality of NAT is to translate one IP into another. Typically we can found NATs which mask behind one public IP a whole private network (one-to-many NAT). The traffic then can originate only from the private network (private IP space is not directly addressable from the public network).

Why we care about the NAT anyway? And what’s wrong with the SIP?

Right. Let’s remind that the SIP+SDP are used to establish a media session. It means we’re exchanging IP addresses of the originator and recipient which will be then used for (e.g. RTP, MSRP) data stream. These IP addresses are in the SIP body in the SDP content.

SDP with IP behind NAT

The media communication is then established on these IP:ports. As the addresses and ports are private the other clients can’t use them as they don’t see each other.

Ut interface – what is it for?

VoLTE and RCS support plenty of services – e.g. Call Forwarding, Call Barring or Presence. Some of these services can’t be pre-configured for the subscribers as each of them wants to provision his/her own forwarding/barred numbers or maybe doesn’t want to use the functionality at all. That means we need to have a way how to do a self-provisioning. In IMS we have a dedicated interface and network functionalities which allow to modify the setting of Supplementary Services and Presence Information directly from client (UE) via http/XCAP protocol. For VoLTE this is defined in the GSMA IR.92 and 3GPP TS 24.623, TS 24.423 and 3GPP TS 33.222. GSMA IR.92 directly says:

For supplementary service configuration, the UE and IMS core network must support XCAP at the Ut reference point as defined in 3GPP TS 24.623.

Wow – this is very important! There is not only the SIP/RTP between UE and IMS network but there can be also http (xcap)! Unlike SIP, HTTP is designed as a general-purpose data transport protocol. The purpose of SIP is mainly to create, modify, or terminate multimedia sessions. But sometimes we want to work with other types of data (e.g. configuration data, presence data, ..) which could easily overwhelm intermediate SIP proxies. HTTP is a good choice how to solve this issue.

What is the network architecture then?

Ut Reference Point

As we can see the http traffic does’t go through the SBC but either directly or through an Authentication Proxy (AP) instead. The interface uses in cellular access the HOS APN (Home Operator Services) as defined in GSMA PRD IR.88 (in Wi-Fi either the HOS APN or a different APN as defined in of GSMA PRD IR.51). The usage of AP depends on the HOS APN (Home Operator Services) value. The Network Identifier (NI) part of the APN is undefined and must be set by the operator. The operators can choose to reuse an APN for already deployed services (e.g. Internet access, MMS, etc.) or choose a new, specific APN for the APN for Home Operator Services.

As the HOS APN is often using the standard Internet access, we’ll take a look at the flows with AP. The main purpose of AP is to authenticate user requests. It is also used to separate the authentication procedure and the Application Server (AS) specific logic (e.g. Supplementary Service provisioning) to different network entities.

(In case of presence and OMA XDMS architecture we talk about so-called Aggregation Proxy, which is described in its own post.)

At your service..

VoLTE in GSMA IR.92 is defining a set of standard Supplementary Services:

• Originating Identification Presentation 3GPP TS 24.607
• Terminating Identification Presentation 3GPP TS 24.608
• Originating Identification Restriction 3GPP TS 24.607
• Terminating Identification Restriction 3GPP TS 24.608
• Communication Forwarding Unconditional 3GPP TS 24.604
• Communication Forwarding on not Logged in 3GPP TS 24.604
• Communication Forwarding on Busy 3GPP TS 24.604
• Communication Forwarding on not Reachable 3GPP TS 24.604
• Communication Forwarding on No Reply 3GPP TS 24.604
• Barring of All Incoming Calls 3GPP TS 24.611
• Barring of All Outgoing Calls 3GPP TS 24.611
• Barring of Outgoing International Calls 3GPP TS 24.611
• Barring of Outgoing International Calls – ex Home Country 3GPP TS 24.611
• Barring of Incoming Calls – When Roaming 3GPP TS 24.611
• Communication Hold 3GPP TS 24.610
• Message Waiting Indication 3GPP TS 24.606
• Communication Waiting 3GPP TS 24.615
• Ad-Hoc Multi Party Conference 3GPP TS 24.605
• Explicit Communication Transfer – Consultative 3GPP TS 24.629 (5G)

Update:

There is not much different in VoNR (5G), the same 3GPP documents are referred by GSMA NG.114. Explicit Communication Transfer is explicitly listed as one of the services. 

IR.92 also says that for supplementary service configuration, the UE and IMS core network must support XCAP at the Ut reference point as defined in 3GPP TS 24.623.

The supplementary services are applied on the traffic by application server (MMTel) based on the information received from HSS/CNTDB (Sh/LDAP). Note we distinguish the originating and terminating services (based on presence of the ‘orig’ tag in the top-most Route header). We also distinguish weather or not is the user currently registered in the LTE network (based on the ‘regstate’ tag in the P-Served-User). E.g. some services are applied for recipients (terminating service) who are not present in the LTE (regstate=unreg) – as voice mail. More details can be found in the 3GPP TS 24.229.

Route: <sip:mmtel@mmtel01.operator.com;lr;orig>,sip:1.2.3.44.50678.0.9000.@10.22.1.2:5070;lr;OdiPsi=mmtel>

P-Served-User: <sip:+123456789123@operator.com>;sescase=orig;regstate=reg

VoLTE Supplementary Services