Today's telecommunication arena is rapidly moving towards next-generation networks (NGNs) that offer ubiquitous, converged services over converged voice, video, data and mobile networks. Until very recently, the prevailing telecommunications paradigm was based on multiple types of networks, each serving different types of applications.
While IP-related technology holds the most promise for meeting the requirements of NGNs, the use of the global Internet is quite limiting. The IP Multimedia Subsystem (IMS) is an architecture that allows delivery of identical services to fixed and mobile customers - regardless of whether they are connected through the packet-switched (PS) or circuit-switched (CS) network. IMS-based services enable communication in a variety of modes - including voice, text, location, presence, messaging, pictures and video, or any combination of these.
In addition to service creation and delivery, IMS handles call control issues, and can easily be adapted to serve roaming subscribers. The IMS architecture is inherently capable of bridging between separate networks, and will ultimately be used for all types of networks, such as wireline Voice-over-IP (VoIP) networks, WiMax wireless networks and packet cable networks.
The expansion and acceptance of IMS is an indication of just how important this technology is to the future of unified communications. Many organizations which are responsible for network standardization are currently adopting IMS technology. The ramifications for the industry are significant, and the entire telecommunications industry is gearing up for the imminent widespread implementation of IMS.
Based on a Strong Signaling Foundation: Session Initiation Protocol (SIP)
IMS technology was originally developed for the cellular arena to define how to set up advanced services for 3G cellular networks and grew out of a group of standards created by the 3rd Generation Partnership Project (3GPP).
IMS is a Media-over-IP network and uses the Session Initiation Protocol (SIP), originally standardized by the IETF, as its base signaling protocol. The 3GPP chose SIP as its base protocol because previous telecom signaling protocols failed to comply with all IMS requirements. Because SIP is an Internet protocol, it can accommodate convergence, and has the potential to meet all the needs of the IMS architecture. For instance, SIP can signal between different network entities, including endpoints and servers. In IMS, each network server has its own role, in contrast to traditional networks where a central office switch does it all, including call control and service control. In addition, SIP uses Internet extensibility mechanisms. A service provider with IMS networks initially may only have a small number of subscribers. As the subscriber base grows, IMS networks must be easily scalable to add more subscribers. SIP is also very flexible, and uses standard extensions. SIP's flexibility enables IMS networks to adapt and change signaling protocols to meet dynamic market needs. Finally, SIP provides adequate security, with both internal and external security mechanisms.
IMS SIP: A Complex Challenge
While offering the right foundation, SIP in its IMS form has proven to be quite complex and presented many technological challenges. There were many gaps between the SIP initially defined by the IETF, and the features required for full IMS support. To solve this problem the 3GPP defined dozens of SIP extensions - additions that are specific to IMS networks. Collectively, these extensions comprise the IMS SIP protocol, which is defined in the 3GPP TS.24.229 standard. These extensions, such as extended call control, presence and instant messaging, extend the functionality of SIP on IMS networks. This new IMS SIP usage profile is perhaps the most important in the telecommunications industry, and is uniquely the most appropriate for NGN networks.
To illustrate the inherent complexity of IMS SIP and all its extensions, we will review the major extensions below:
SigComp (RFC 3320)
The SigComp extension defines how to compress SIP textual signaling data, which can be very large and problematic to transmit, causing delay. SigComp solves the challenges of roundtrip delays, as well as mobile user equipment battery life
P-headers (RFCs 3455 and 3325)
(P- Private) In addition to standard headers, the 3GPP defined additional headers targeted at solving specific IMS network problems, such as obtaining information about the access network (cell ID) and the visited network (roamed network), and determining caller identity.
Security Agreement (RFC 3329)
This IMS SIP extension specifies how to negotiate security capabilities for multiple types of endpoints.
AKA-MD5 (RFC 3310)
This IMS SIP extension determines how terminals and networks are authenticated using already defined mechanism (e.g. ISIM), as well as specific key exchange.
IPSec
IPSec is used on various IMS interfaces and between different IMS networks. IMS uses IPSec in the transport mode, as opposed to the standard used in VPN services.
Media Authorization (RFC 3313)
Ensures that only authorized media resources are used.
Mobile Registration (RFCs 3327 and 3608)
On IMS networks, the terminal registration process is more complicated, as it includes various security extensions and must deal with registration from a visited network. RFC 3608 and RFC 3327 define the syntax and SIP entity usage of the Service-route and Path headers.
Reg-event Package (RFC 3680)
Used by the terminal and the P-CSCF to know the terminal registration status on the network.
IPv6
IMS prefers IPv6 networks, which offers distinct advantages. It permits a larger set of addresses and contains embedded IPSec functionality that may eliminate the need for entities like NATs and firewalls.
Preconditions (RFC 4032)
Specifies method for negotiating QoS, security and other required call behavior between two terminals.
IMS Resource Reservation (RFC 3312)
Defines how to make resource reservations for phone calls or sessions.
Session Description Protocol (SDP)
SDP defines the basic negotiation process for the media streams, and includes the bit rate and codec to be used, as well as other media attributes. IMS extends SDP with even more extensions, such as grouping of media lines, QoS and preconditions attributes, supplemental codec support, and bandwidth modifiers.
XML Usage
IMS SIP signaling uses XML protocols extensively, including XCAP, to implement various kinds of SIP message contents, and to allow full function interfaces between IMS entities.
IMS Simple Extensions
The SIMPLE group is an IETF working group that defines presence and instant messaging signaling requirements. Basic SIMPLE definitions were inadequate for IMS applications because they were not efficient enough for use on the air link. IMS SIP extended this standard with the following:
. Partial Notifications / Publications
. Notifications filtering
. Resource list / SIP exploders
. Message Session Relay Protocol (MSRP)
IMS SIP Expertise: A Prerequisite for Success
The use of SIP in IMS networks requires a great deal of adaptation and extension of the original signaling protocol. Given the breadth, variety and complexity of IMS SIP, it is indeed an arduous task to develop new services and applications from scratch. A more reasonable approach is to use prepared toolkits and infrastructure products that encompass all the nuances of IMS SIP, and where much of the development effort and interoperability testing (IOT) have already been completed.
In order to execute IMS roadmaps and ensure on-time deployment, developers need solutions that are finely tuned to the unique characteristics of IMS SIP and that provide the extended SIP signaling infrastructure needed for IMS applications.
Author Bio
A longer 25 page version of this white paper is available at http://www.radvision.com/Resources/WhitePapers/ims_sip.htm
Adi Paz is a Senior Product Marketing Director at RADVISION, a leading provider of video network infrastructure and developer tools for unified visual communications over IP, 3G, and emerging next-generation networks.
source: http://www.articlegeek.com/computers/telecommunication_articles/3780-imssiprightsolu.htm | June 16, 2015, 23:49:14 Share on Tumblr