Mats Stille

Introduction to IP-Based Real-Time Communications

This chapter introduces the reader to voice over IP (VoIP) and multimedia over IP. The “IP” in VoIP relates to the communication network through which the “V” (voice) is transported. Digital transmission of voice occurs in networks such as ISDN and GSM/UMTS, where the voice is transported, in digitized form, over digital circuits. A circuit is a virtual connection between two end-points. For human voice, where transmission is traditionally applied in the range 300–3400 Hz, the sampling frequency is set to 8 kHz. A code size of 8 bits/code yields an effective bit stream of 64 kb/s. The stream of PCM samples is then fed into the DA converter, which produces an analog signal. The analog signal, in turn, is applied to analog signal processing circuitry to produce audible sound. When the PCM bit stream is transported over a PS network, the PCM bit stream needs additional encapsulation in order to make it suitable for transmission. The details of this encapsulation are described in this chapter.

Introduction to Session Initiation Protocol

This chapter introduces the Session Initiation Protocol (SIP). SIP is the control-plane protocol used in the multimedia subsystem (IMS) network for registration, session establishment, message routing, terminal capability exchange, and presence services. One of the main tasks of SIP is to facilitate the establishment of a media session between two end-points. A media session typically consists of real-time person-to-person communication. The two end-points establish a SIP session by exchanging SIP messages. One entity may initiate a SIP session by sending a session establishment request message to the other entity; the other entity may accept or reject the SIP session establishment request and signal the acceptance or rejection to the initiator of the SIP session. The execution of a transaction between two UAs may result in the establishment of a SIP session between these UAs. This depends on the actual transaction that is applied and on the outcome of the transaction. A SIP transaction constitutes a request from one SIP entity to another SIP entity to execute a particular task. The establishment of the SIP session implies engagement in media transfer, in accordance with a set of codecs.

Rich Communication Suite

This chapter discusses the Rich Communication Suite (RCS) and how this consumer goods software is used by individual consumers on their handsets. Rich Communication Suite is an initiative run by the GSMA. It brings together the main actors from the telecommunications industry from network vendors, operators, handset manufacturers, and device client developers for the creation of an interoperable, convergent, access-technology-independent rich communication experience to end-users. The RCS specifications have been developed to facilitate the introduction of commercial, IMS-based communication services for 3G, LTE, CDMA, and fixed networks. As will be discussed in the following sections, functionality within RCS includes Network Address Book, Enhanced Call through image and video sharing, and also Rich Messaging for both mobile and PC/broadband clients. Enhanced Messaging allows end-users to have a “new” messaging experience based on SMS/MMS capabilities, and also provides File Transfer and Chat facilities. A File Transfer session allows end-users to share files with one another via an MSRP message and relies on the underlying OMA IM specifications.

Service Deployment Patterns

This chapter discusses how to deploy the multimedia subsystem (IMS) applications at different places to get maximum output. Client-side applications are deployed in user devices, possibly building on capabilities provided by standard services like 3GPP Multimedia Telephony (MMTel) and the Open Mobile Alliance (OMA) standard services such as chat, file transfer, presence, messaging, and GSMA streaming video and image transfer during a phone call. End-point services in the network are addressable by the end-user through a client application—for example, a timetable service responding by voice. Mid-point services in the network tend to be more about modifying the behavior of sessions. The client-side API will be either a native API if one is coding directly to a specific platform, or the JavaME JSR281 interface. If all one needs to support ones application is to be able to find and connect a session to another terminal equipped with ones application, then one really does not need to know anything except the client-side API. The IMS core will handle all the details around client registration, SIP signal routing, and so on so forth.

Business Modeling for a Digital Planet

This chapter covers a series of topics that are relevant to application developers wanting to understand the evolution of the global economy and the role that multimedia subsystem (IMS) may play in developing applications. The mobile broadband platform is in the process of becoming the nexus of contracts within the global economy, rather than just for the mobile industry. The traditional business case for IMS is often built around the need for globally interoperable standards. IMS is developed by 3GPP, a global standards organization dedicated to the development of different mobile technologies, from radio to core network. Without IMS and the global interoperability it provides between handsets, equipment manufacturers and operators, implementing an application on a mobile device is quite limited, even with a smartphone. There is no guarantee that the operator that different friends and colleagues are using supports the application in question. In addition, if anyone has a legacy device, the communication format is more than likely not possible.

Interworking with Legacy Networks

This chapter considers the impact of network interconnection—connecting multimedia subsystem (IMS) network to CS network—on the availability of services in the IMS network. The communication between the IMS network and the other networks runs via designated gateways and through a transit transmission network. Interconnection between the IMS network and Public Switched Telephony Network (PSTN) or Public Land Mobile Network (PLMN) may, alternatively, be realized without a transit network. A PLMN subscriber establishes a call to an IMS subscriber. The call is routed from the GSM network to the IMS network. This routing may be based on B-number analysis or on number portability information. Various other information elements from ISUP can be mapped to corresponding SIP headers. Support of these headers depends on, for example, support of supplementary service interworking by the MGCF. 3GPP TS 29.163 provides an extensive overview of parameter mapping between ISUP and SIP. When a SIP-AS is controlling a call for a service number, it may apply service logic that includes the playing of an announcement to the calling party prior to connecting the calling party to an available agent.

MMTel and Other IMS Enablers

This chapter briefly introduces two of the major services—Multimedia Telephony (MMTel) and Presence—built on multimedia subsystem (IMS). When devices happen to have incompatible codecs installed, the network can provide conversion services. If the device is a PC and the users are reasonably technically inclined, these issues are normally handled by downloading codecs. However, apart from the inconvenience factor, it is most likely not even possible for the majority of mobile phones. Northbound Interface is an explicit call-out to an external application, invoked as part of the call processing in the MMTel AS node itself. The Presence function in IMS is the result of cooperation between standards bodies, in this case Open Mobile Alliance (OMA), 3GPP and 3GPP2, and the Internet Engineering Task Force (IETF), in a pattern that is becoming common. Basic protocols are developed in IETF; core capabilities and the architecture supporting them is the job of 3GPP, and then organizations like OMA build end-user applications.

Evolved IP Multimedia Architecture and Services

This chapter aims to explain the new concepts and evolution of multimedia subsystem (IMS) supporting the mobile telephony evolution. The main driver of the IMS and IMS service standard since 3GPP Release 7 has been to enable and support the evolution and migration of mobile telephony. The IMS architecture and generic service concepts were finalized in 3GPP Release 7 and it coincided with the handover of the MMTel service developed in ETSI TISPAN into 3GPP. The profile mandates supplementary service self-management over the Ut reference point using XCAP procedures based on XML according to 3GPP TS 24.623. The use of Ut and XCAP enables the use of more complex and powerful expressions in the future than the legacy equivalent 3GPP TS 24.010 protocol, which is used today. The Single Radio Voice Call Continuity (SRVCC) architecture has been developed over a number of 3GPP releases. The Service Centralization and Continuity application server (SCC AS) is a new logical IMS application server that for SRVCC is used primarily as a call signaling anchor when switching between the access legs.

Introduction to the IMS Network

Publisher Summary This chapter provides a methodological description of the multimedia subsystem (IMS) network architecture. IMS service development requires thorough understanding of the principles and protocols of multimedia over IP and of the architecture of the IMS network. IMS is fully specified in 3GPP technical specifications (TSs). TSs may include reference to standard documents from other standardization organizations. Those other standard documents then become, in full or in part, an integral part of the IMS specification. The 3G (also HSPA, LTE) access network is fully specified by 3GPP. Other access networks use technology specified by other organizations, such as Ethernet, which is standardized by IEEE (IEEE standard 802.3), and ADSL, which is standardized by ITU. Session border controller (SBC) is the control-plane entity of the A-SBG. It is the “SIP entry” for the end-user terminal towards the IMS network. When A-SBG and P-CSCF are deployed as separate entities, this has impact on the ability to establish an IMS security association between UE and the IMS network.

Chapter 5 – Service Development

Publisher Summary This chapter presents the steps involved in implementing constituent service components in Java and how they are integrated into an overall application by means of service composition. The development of the core business logic may be achieved using traditional Java-based development. Such a composite application may indeed be an implementation of a custom application router as specified by JSR289. All XML web services components are implemented in Java by means of the JAX-RS API, which is a part of the Java EE specification. The business log of the virtual call center application is broken down into three phases. The first of these phases deals with interactive voice recognition system (IVR) interaction and blocking of direct calls to a specific agent. The JSR289 API is a low-level API that operates at the level of SIP packets and their headers and contents. Thus, even simple high-level actions like sending a SIP packet are actually implemented by a comparably long sequence of low-level API calls that first create a SIP packet with a required payload and then send it.