-1-
IPv4/IPv6 Inter-working in IMS by using Session Border
Controller
Abstract
IP Multimedia Subsystem （IMS） is a new network architecture for providing multimedia service in
the next generation networks. The 3rd Generation Partnership Project (3GPP) R5 standards specified
the use of Internet Protocol version 6 (IPv6) for the IMS. However, early implementations of IMS
Core and IMS clients support Internet Protocol version 4 (IPv4)-only. As the transition and migration to
IPv6 of both the IMS Core and IMS clients, the interoperability between IPv4 and IPv6 in the Core
region and clients region must be addressed. These issues have the potential to impact the
access-independent nature of IMS specified by 3GPP. In this paper, we introduce a middleware which is
similar to traditional Session Border Controller(SBC) between Core and clients, which can handle the
inter-working well. And we introduce an Interconnect-SBC (I-SBC)-like middleware which can deal
with the cross-IMS Cores communications. In addition, it also can provide other novel features such as
ANAT, IPv6 promotion and make the implementation of User equipment mobility relatively easy.
Keywords：IMS，SBC，IPv6，SIP
1 Introduction
The evolutionary trend of the next generation mobile communication system is obviously towards IP-based
networks. 3GPP has defined and standardized a network infrastructure called the IP multimedia
subsystem (IMS) [1] for supporting a multitude of IP multimedia services. IMS adopts Session Initiated
Protocol (SIP) [2] as its signaling protocol and uses Session Description Protocol(SDP) [3][4] to negotiate
the multimedia data transfer. SIP is defined by IETF to provide signaling control for multimedia session
such as Internet telephone calls. It is designed for multimedia session control.
IPv6 has been specified by 3GPP R5 to be used in IMS. However, because IPv4 is used in the large scale of
the existing Internets, the early implemented IMS Core and IMS clients support IPv4-only. As both the
clients and Cores transiting to IPv6, there will be a long period of the co-existence of IPv4 and IPv6, and
this will lead to problem for introducing IPv6 clients into the existing IPv4 IMS Cores, and it is
impossible for an IPv6 Core to communicate with the IPv4 Cores. As IMS-based network architectures
evolve and become widely accepted as a standards based service creation and delivery framework, these
inter-working problems are urged to be solved. Figure 1 shows the challenge of the IPv6 transition in IMS:
Figure 1: The issues related to the inter-working
-2-
An candidate solution is to introduce an element typically referred to as “Session Border Controller” (SBC)
[5] between IMS Cores and clients. This element is now an important component of several VoIP solutions
in real world. The SBC acts as intermediate node in all signaling and media sessions of a user that wants to
access the public network through a private access network. From the media point of view the SBC acts as
“B2BUA” (Back to Back User Agent) while from the signaling point of view it can also act as a Sip Proxy.
In practice the SBC “represents” the user in the public network by providing him/her with a public routable
IP address (IPv4 or IPv6) through which the user can be reached even behind a NAT.
IMS is naturally access independent, so we also propose a solution to handle the wireless clients
mobility[8][9] for a smooth media handover.
The rest of this paper is organized as follows. In section II we discuss the related background
acknowledge. In section III the SBC-like middleware is described in detail. Finally, we conclude this paper
in section IV.
2 Background
IMS
IMS is specified in the 3rd Generation Partnership Project/3rd Generation Partnership Project
2(3GPP/3GPP2) standards. IMS is based upon Internet protocols to provide access to multimedia
services, converging delivery of voice and data. The IMS core network provides the functions at the
session management layer of the three-tiered IMS structure (., access network, session management,
and application services). In this paper, we just simply introduce the session management tier and the
related functionality.
Proxy CSCF (P-CSCF) - P-CSCF is the first point of contact for users with the IMS. The P-CSCF is
responsible for security of the messages between the network and the user and allocating resources for the
media flows.
Interrogating CSCF (I-CSCF) - I-CSCF is the first point of contact from peered networks. The I-CSCF is
responsible for querying the HSS to determine the S-CSCF for a user and may also hide the operator's
topology from peer networks (Topology Hiding Inter-network Gateway, or THIG).
Serving CSCF (S-CSCF) - S-CSCF is the central brain. The S-CSCF is responsible for processing
registrations to record the location of each user, user authentication, and call processing (including routing
of calls to applications). The operation of the S-CSCF is controlled by policy stored in the HSS.
DNS - The DNS server should support IPv6 features such as "AAAA" type records. The ability of
receiving/responding queries through IPv6 is preferred, but not mandatory required.
HSS - HSS should has the ability to store and return FQDNs, IPv4 addresses and IPv6 addresses
according to specific configurations. The actual implementation and interfaces with other entities do
not have influence to the solutions, hence are not necessary to conform to standards (DIAMETER, for
example).
-3-
IPv6
Adoption of IPv6 is viewed as the key to deploying next-generation fixed and mobile services. IPv6 is
the next-generation Internet protocol that succeeds IPv4. The evolution from IPv4 to IPv6 is primarily
intended to support the peer-to-peer model of Internet connectivity and network efficiency and to
encourage innovation. IPv6 supports these by incorporating the following enhancements to IPv4:
z Expanded IP addressing capabilities,
z Header format simplification,
z Stateless address auto-configuration,
z Improved support for extension headers,
z Flow labeling capability,
z Any-cast capability, and Inherent support for IPSec and Mobile IP (MobIP).
The greatly increased number of IPv6 globally routable addresses eliminates the need for private
addresses and middleboxes such as NATs and application-level gateways (ALGs).
SBC
The term SBC is relatively non-specific, since it is not standardized or defined anywhere. It usually
sits between two service provider networks in a peering environment, or between an access network
and a backbone network to provide service to residential and/or enterprise customers. They provide a
variety of functions to enable or enhance session-based multi-media services (., Voice over IP).
These functions include: a) perimeter defense (access control, topology hiding, DoS prevention,
and detection); b) functionality not available in the endpoints (NAT traversal, protocol inter-working
or repair); and c) network management (traffic monitoring, shaping, and QoS). Some of these
functions may also get integrated into other SIP elements (like pre-paid platforms, 3GPP P-CSCF,
3GPP I-CSCF etc).[1]
3. Implementation of SBC
In our implementation of SBC, it is the interface between UEs and IMS core. It forwards SIP
signals between access segment and core segment, and forwards media traffic between UEs. Both the
IMS core and the UEs may have different IP capabilities and running different IP versions.
I-SBC is very similar with SBC in functions, and is the interface between different IMS domains,
these domains may also be different IP realms and running different IP versions. It is commonly used
to interconnect different IMS operators.
SBC run as a as a Back-to-Back User Agents(B2BUA) . It typically handle both signaling and
media and can implement behavior which is equivalent to a "privacy service" (as described in[2])
performing both Header Privacy and Session Privacy. SBCs often modify certain SIP headers and
message bodies that proxies are not allowed to modify. For example, our SBCs modify the session
description carried in the message to control the media traffic, replace the value of the Contact header
field with the SBCs’ address to do registration for clients and make them routable, generate new To
and From tags, and remove Via header fields and Record Route header fields for acheve THIG
(Topology Hiding).
As a B2BUA, SBC receives Request from client’s UAC, at this time, SBC make the role of UAS
and may send a response back, then it may forward the modified Request using its UAC. In reverse,
-4-
SBC will play the role of UAC when receiving Response, and it may using its UAS to forward the
Response after modification. Our SBC starts to handle media stream after the session is established,
when it receiving media packet(eg, RTP stream), it will get to know where the packet comes from, and
check the “Media Address Mapping” table, then it is aware of where should to forward this packet.
Figure2 shows our SBC works as B2BUA.
Figure 2: The B2BUA model of SBC
Since our SBC can modify the header fields of SIP Request and Response, it also can perform the
following functions:
z NAT Traversal
z Access Scenario
z IPv4 and IPv6 Inter-Working
z Topology Hiding
z ANAT & IPv6 Promotion
z Traffic handover
NAT Traversal
Clients are usually located in the private networks, so they are not routable in the public networks.
After the introduction of SBC, the clients can be represented by it and the signals and media can be
routed to them through SBC. In this case, SBC has two interfaces, one connects to the private
networks, and the other connects the public networks.
Clients that set SBC as their outbound proxy will send Register to SBC’s private interface, SBC
replaces the value of the Contact header field with the SBC’s address and uses its public interface to
forward the Register to IMS Core. At the mean same, SBC will forward the consequent 200 OK
Response to clients to finish the registration.
After the registration, IMS Core will map the client’s address-of-record to the SBC’s address, thus,
the subsequent requests to the registered clients are routed to the SBC. From the aspect of IMS Core,
SBC’s public interface represents all the clients of the private networks.
Our SBC maintains a registration table, every registration will update this table. It can help to route
the incoming SIP message to the right client. In addition, SBC make clients to register with itself at a
smaller interval by decreasing the value the Expire header field of the 200 OK. For example, SBC will
make clients register every minute, but it only forwards the Register request to IMS Core every 10
minutes. This can help to enhance the performance of handling clients mobility and improve the user
access control and authentication/or authorization.
-5-
IPv4 and IPv6 Interworking
As the deployment rapid of IPv6 is not as our expectation, most of the existing access networks are
supporting IPv4 only. Thus, many early implementations of IMS Core are also supporting IPv4 only,
which makes IPv6 clients can’t access to these IMS Core directly. And after the some IMS Cores
upgrade, there will be IPv4 IMS Core co-exists with IPv6/Dualstack IMS Core. These different Cores
also can’t communicate with each other directly.
Since our SBC listens on both IPv4 and IPv6 interfaces, hence able to exchange signals and media
traffic data with IPv4 Clients, IPv6 Clients and Dual Stack ones, and able to interface with IMS core
using either IPv4 or IPv6, depends on IMS Core's IP capabilities. So, we can easily solve these two
problem by just modify the SIP signals. Figure 3 shows how an IPv4 client communicates with an
IPv6 client with the help of SBC, and Figure 4 shows how an IPv4 Core communicates with an IPv6
Core with the help of I-SBC:
Figure 3 Inter-working between IPv4 and IPv6 Clients
In Figure 3, there are two users, joey@ (joey) and
chandler@(chandler), which have registered with Core using IPv4 and IPv6 address,
respectively. When joey wants to chat with chandler, it will send an INVITE request to SBC1’s private
interface, , then SBC1 will forward this INVITE to Core using IPv4 after inserting its
public IPv4 address to the SDP. On receiving INVITE from Core side, SBC2 will query its registration
table and get chandler’s registered address, [2016::90], then it replaces the media address of the
session description in the INVITE with its IPv6 address, [2016::68] and forwards to chandler using its
private IPv6 address. The 183 Response will go back to joey according to Via header fields. During
these two steps, SBC1 and SBC2 will update their “Media Address Mapping” table for forwarding
media packets.
In Figure 4, there are two domains, one is , which represents the early
implemented IMS Core, the other is , which can support IPv6. If a cross domain call
session is wanted to established, the I-SBC is involved. When it receives INVITE from the S-CSCF of
, it will lookup E-DNS to get the IPv6 address of the I-CSCF of , then
it inserts its public IPv6 address into the SDP and forwards the INVITE to the I-CSCF using its public
-6-
IPv6 interface. In reverse, it will forwards 183 Response back to the S-CSCF of . This
can make the two tie operators to inter-work will each other.
Topology Hiding
Topology hiding consists of limiting the amount of topology information given to external parties.
Operators have a requirement for this functionality because they do not want the IP addresses of their
equipment (proxies, gateways, application servers, etc) to be exposed to outside parties. This may be
because they do not want to expose their equipment to DoS (Denial of Service) attacks, they may use
other carriers for certain traffic and do not want their customers to be aware of it or they may want to
hide their internal network architecture from competitors or partners. The most common form of
topology hiding is the application of header privacy (see Section of [2]), which involves stripping
Via and Record-Route headers and replacing the Contact header.
In Figure 4, when I-SBC receives SIP Request from S-CSCF of , it will remove the
Contact header field and all the Via header fields and Record-route header fields, and before sends out
the Request to I-CSCF of , it will insert itself into these three headers fields for called
party to generate the back routes of the Response. Thus, from the point of view, the
architecture of is totally transparent.
In some deployments which use IP addresses instead of domain names in From and To headers,
I-SBC will also replace these IP addresses with its own IP address or domain name.
Figure 4 Inter-working between IPv4 and IPv6 Domains
Media Traffic Shaping + IPv6 promotion
Since the media path is independent of the signaling path, the media may not traverse through the
operator's network unless the SBC modifies the session description. By modifying the session
description the SBC can force the media to be sent through a media relay which may be co-located
with the SBC. Or just only to monitor it for collecting statistics and making sure that they are able to
meet any business service level agreements with their subscribers and/or partners.
So as to accelerate the deployment of IPv6, our SBC should provide mechanism to promote the
usage of IPv6 whenever possible, especially in the media plane. We can achieve this IPv6 promotion
just by replace the media address in the session description with IPv6 address.
However, in the situation of the co-existence of IPv4 clients and Cores, IPv6 clients and Cores and
Dual-stack ones, SBC has no idea of the IP capability of next-hop, so as to guarantee the success of
-7-
the session establishment, the SBC will use ANAT(alternative network address types[6][7])
mechanism to discover the IP capability of each call leg and show all its IP capability in the session
description offer. The processing procedures relevant to ANAT are described as follows:
• When a client receiving INVITE with the “Require= sdp-anat”, it will send 420 Response if it
doesn’t support ANAT.
• When a client receiving INVITE without the “Require= sdp-anat”, it will check the session
description, if it doesn’t support the media address type, it will send back 606 Response
• When SBC/I-SBC receiving 420 Response, it will re-Send INVITE with only IPv6 media
address
• When SBC/I-SBC receiving 606 Response, it will re-Send INVITE with only IPv4 media
address.
• When I-SBC get both IPv4 and IPv6 address by looking up DNS, it will send INVITE with
ANAT session description. Otherwise, it will insert only one media address type which
consists with the DNS lookup result.
•
Figure 5 The ANAT feature of SBC
In Figure 5, there are two Dual-stack clients, ross@ (ross) and
phoebe@ (phoebe). When ross wants to chat with phoebe, it will sends an INVITE
with ANAT session description. SBC1 receives this INVITE will select the IPv6 for the media traffic
between itself and ross, then it will send insert its IPV6 and IPV4 address to the session description,
and make IPv6 preferred (appear before IPV4). SBC2 will do the same job as SBC1 when it receives
the INVITE. At last, phoebe receives the INVITE and finds that IPV6 is preferred, then it will select
IPv6 for the media traffic between itself and SBC2 by set the media port in the IPV4 media
description section to zero. After establishing this session, we can see that all the media traffic are
going through IPV6.
In addition, SBCs on the media path are also capable of dealing with the "lost BYE" issue if either
client dies in the middle of the session. The SBC can detect that the media has stopped flowing and
issue a BYE to the both sides to cleanup any state in other intermediate elements and the clients.
-8-
4 Conclusion and future works
IMS has been deployed by more and more tier operators. IPv6 is an important part of the evolution
to next generation telecommunications systems, and many companies are doing job to accelerate IPv6
deployment. However, it will take a long time to transit to IPv6 completely, so, there will be a long
period during which IPv4 and IPv6 will coexist. This paper proposed a solution to support the IPv6
transition and IPv4/IPv6 interoperability in IMS by introducing a SBC between clients and Cores and
placing an I-SBC between different Cores.
Our implemented SBC/I-SBC runs as an B2BUA and provides a solution supporting NAT and IMS
ALG, it will make the IPv4 and IPv6 inter-working between clients and Cores efficient. It can also
provide mechanisms to achieve Topology Hiding between different tier operators, Promotion of
IPv6 with the ANAT extension of SDP. Smooth handover of media traffic when an on-call client
change its IP address will be studied.
References
[1] 3GPP, TS , “IP Multimedia Subsystem (IMS); Stage 2 (Release 7),” June 2006.
[2] J. Rosenberg, H. Schulzrinne, G. Camarilloet, et al., “SIP: Session Initiation Protocol,” IETF RFC 3261, June
2002.
[3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)",
RFC 3264, June 2002.
[4] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[5] J. Hautakorpi, Ed. G. Camarillo Ericsson R. Penfield Acme Packet A. Hawrylyshen Ditech Networks Inc, M.
Bhatia NexTone Communications “Requirements from SIP (Session Initiation Protocol) Session Border Control
Deployments” November 24, 2006
[6] G. Camarillo, Ericsson J. Rosenberg Cisco Systems , "The Alternative Network Address Types (ANAT) Semantics
for the Session Description Protocol (SDP) Grouping Framework" RFC 4091 June 2005
[7] G. Camarillo, Ericsson J. Rosenberg Cisco Systems "Usage of the Session Description Protocol (SDP) Alternative
Network Address Types (ANAT) Semantics in the Session Initiation Protocol (SIP)" RFC 4092 June 2005
[8] C. Perkins, “IP Mobility Support for IPv4,” IETF RFC 3344, August 2002.
[9] D. Johnson, C. Perkins and J. Arkko, “Mobility Support in IPv6,” IETF RFC 3775, June 2004.
[10] Campbell et al., “Design, implementation and evaluation of cellular IP”, IEEE Personal Communications
Magazine, vol. 7, pp. 42-49, Aug 2000.
[11] Ashutosh Dutta, Sunil Madhani, Wai Chen, Onur Altintas, Henning Schulzrinne “Fast-handoff Schemes for
Application Layer Mobility Management”, PIMRC 2004, Spain.
[12] Q. Wang and M. Abu-Rgheff, “Integrated Mobile IP and SIP Approach for Advanced Location Management,” In
Proceeding of 4th IEEE International Conference on 3G Mobile Communication Technologies, pp. 205-209, June
2003.
[13] Q. Wang, M. Abu-Rgheff, “Interacting mobile IP and SIP for efficient mobility support in all IP wireless
networks,” In Proceeding of 5th IEE International Conference on 3G Mobile Communication Technologies, pp.
664-668, June 2004.
[14] M. Alam, Z. Wu, “Comparison of Session Establishment Schemes over IMS in Mobile Environment,” In
Proceeding of 5th IEEE International Conference on Information, Communications and Signal, pp. 638-642,
December 2005.
[15] H. Schulzrinne, E. Wedlund, “Application-layer mobility using SIP,” IEEE Service Portability and Virtual
Customer Environments, pp. 29-36, December 2000.
