3 g m gw

HELSINKI UNIVERSITY OF TECHNOLOGYDepartment of Computer Science and EngineeringTelecommunications Software and Multimedia Laboratory

Edgar J. Ramos

Analyzing the Media Control interfaces and

Mobile Media Gateway for the Ip Multimedia

Subsystem (IMS)

Master’s Thesis submitted in partial fulfillment of the requirements for the degreeof Master of Science in Technology.

Espoo, February 4, 2008

Supervisor: Professor Antti Yla-JaaskiInstructor: Gonzalo Camarillo, M.Sc.

HELSINKI UNIVERSITY ABSTRACT OF THE

OF TECHNOLOGY MASTER’S THESIS

Author: Edgar J. Ramos

Name of the thesis: Analyzing the Media Control interfaces andMobile Media Gateway for the Ip Multimedia Subsystem (IMS)Date: Feb 4, 2008 Number of pages: 100

Department: Department of Computer Science and EngineeringProfessorship: T-110

Supervisor: Professor Antti Yla-JaaskiInstructor: Gonzalo Camarillo, M.Sc.

The IMS as part of the 3G evolution networks involves costs and investments for thedevelopment of new systems and technologies. The Multimedia Resource Function Pro-cessor (MRFP) is an important component on the IMS to provide the operations overthe media in the packet-switched domain. Also it has been identified strong synergieswith the circuit-switched domain Media Gateway (MGW). This Thesis mainly analyzesthe Mp interface deployment, which is the one used to send the control messages tothe MRFP. Additionally several protocol alternatives are reviewed from the proposedMedia Control protocols defined in IETF together with the scenarios where a MRFP isneeded. At the moment of writing this work, the Mp interface has not been standard-ized fully. Therefore, the models and protocols reviewed and their impact are analyzedfor the Mobile Media Gateway’s User Plane Control Function (UPCF) application. Thefinal analysis lead to the selection of a media server control model including the proto-cols recommendation for each interface. At last, a prototype was developed to illustratethe possible adaptations from the Mobile Media Gateway. It was meant to handle theMp interface behaving as a MRFP and setup IMS IP calls. This final output provides acontribution to one possible transition path for the evolution from the circuit switcheddomain to the packet switched domain using the Mobile Media Gateway and the MediaServer Control model.

Keywords: Media, Control, IMS, Mp, Mr, MGW, MRFP, MRFC, MRF

i

Acknowledgements

I want to thanks the people who supported me to finish this work: my family inPanama and here in Finland, my friends and my colleagues in Ericsson. Their bestcontribution was to provide me with their precious time.

I would also like to thank Johan Torsner for his patience and advices.

Finally, my gratitude to Gonzalo Camarillo, who made and excellent work as a tutorbesides the difficulties found during this work development.

Otaniemi, February 4th, 2008

Edgar Ramos

ii

To my beloved ones, with whom I share my challenges and rewards.

Contents

Abbreviations ix

List of Figures xi

List of Tables xii

1 Introduction 1

1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Problem Description . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.4 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.5 Structure of the Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 IP Multimedia Subsystem 5

2.1 Overview of the IMS Architecture . . . . . . . . . . . . . . . . . . . 5

2.2 The IP Multimedia Core Network Subsystem . . . . . . . . . . . . . 6

2.3 Signaling plane interfaces . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4 IMS/CS relationship (3GPP view) . . . . . . . . . . . . . . . . . . . 11

2.5 Media Plane Considerations . . . . . . . . . . . . . . . . . . . . . . . 13

2.6 Application Plane Considerations . . . . . . . . . . . . . . . . . . . . 13

3 Multimedia Resource Function Processor 14

3.1 Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1.1 Media Encoding . . . . . . . . . . . . . . . . . . . . . . . . . 14

iv

3.1.2 Media Transport . . . . . . . . . . . . . . . . . . . . . . . . . 15

4 Media Gateway 17

4.1 Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.2 Transport and Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.3 The Mobile Media Gateway (M-MGW) . . . . . . . . . . . . . . . . 22

4.3.1 Connectivity Packet Platform . . . . . . . . . . . . . . . . . . 23

4.3.2 Hardware Structure Overview . . . . . . . . . . . . . . . . . . 24

4.3.3 Application Overview . . . . . . . . . . . . . . . . . . . . . . 25

5 Control Protocol for Media Servers 30

5.1 Multimedia Resource Function, Media Servers and Physical nodesImplementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

6 Media Server Control Interface Criteria 34

6.1 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6.2 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

6.3 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6.3.1 3GPP Requirements . . . . . . . . . . . . . . . . . . . . . . . 36

6.3.2 IETF requirements . . . . . . . . . . . . . . . . . . . . . . . . 38

7 Media Server Control Interface Analysis 41

7.1 3GPP Proposed Protocols for Control of Media Servers . . . . . . . 41

7.2 IETF Proposed Protocols for Control of Media Servers . . . . . . . . 42

7.3 Media Server Control Protocols . . . . . . . . . . . . . . . . . . . . . 43

7.3.1 ITU Recommendation H.248 (Megaco Protocol) . . . . . . . 43

7.3.2 Session Initiation Protocol (SIP) . . . . . . . . . . . . . . . . 53

7.3.3 Media Sessions Mark-up Language (MSML) . . . . . . . . . . 62

7.3.4 Media Server Control Mark-up Language (MSCML) . . . . . 68

7.4 Traffic Scenario Implications . . . . . . . . . . . . . . . . . . . . . . . 75

7.5 Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

v

7.6 Preferred model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

8 Prototype 82

8.1 Mobile-MGW VoIP prototype . . . . . . . . . . . . . . . . . . . . . . 82

8.2 M-MGW prototype considerations . . . . . . . . . . . . . . . . . . . 82

8.3 Affected User-Plane Control application subsystems . . . . . . . . . 83

8.3.1 Signalling Transport Converter (STC) . . . . . . . . . . . . . 83

8.3.2 GCP Termination (GCPT) . . . . . . . . . . . . . . . . . . . 83

8.3.3 Connection Coordinator . . . . . . . . . . . . . . . . . . . . . 84

8.4 M-MGW Prototype testing . . . . . . . . . . . . . . . . . . . . . . . 84

8.4.1 H.248 flows between M-MGW and SBC . . . . . . . . . . . . 85

8.4.2 Call setup procedure. . . . . . . . . . . . . . . . . . . . . . . 86

8.4.3 Call Release Procedure . . . . . . . . . . . . . . . . . . . . . 86

8.4.4 MGW Cold startup flow . . . . . . . . . . . . . . . . . . . . . 86

9 Conclusions and Future Work 89

9.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

vi

Abbreviations

(A-F)

3G 3rd Generation3GPP 3rd Generation Partnership ProjectAAL1 ATM Adaptation Layer - 1AAL2 ATM Adaptation Layer - 2AAL5 ATM Adaptation Layer - 5AMR Adaptive Multi-RateAS Application ServerATM Asynchronous Transfer ModeATIS Alliance for Telecommunications Industry SolutionsBGCF Breakout Gateway Controller FunctionBICC Bearer Independent Call ControlB-ISUP Broadband ISDN User PartBSC Base Station ControllerCAMEL Customized Applications for Mobile network Enhanced LogicCAP CAMEL Application PartCN Core NetworkCOPS Common Open Policy Service protocolCPP Connectivity Packet PlatformCS Circuit SwitchedCSCF Call Session Control FunctionDiffServ Differentiated ServicesDTMF Dual Tone Multi-FrequencyEDGE Enhanced Data Rates for GSM EvolutionFTP File Transfer Protocol

vii

(G-M)

GCP Gateway Control ProtocolGGSN Gateway GPRS Support NodeGPRS General Packet Radio ServiceGSM Global System for Mobile CommunicationGSM-FR GSM Full RateHSS Home Subscriber ServerHTTP Hypertext Transfer ProtocolIANA Internet Assigned Numbers AuthorityI-CSCF Interrogating - CSCFICP Internal Communication PathIETF Internet Engineering Task ForceIIOP Internet Inter-Object Request Broker ProtocolIMS IP Multimedia SubsystemIM-SSF IP Multimedia Service Switching FunctionIP Internet ProtocolIPsec IP securityISDN Integrated Services Digital NetworkISUP ISDN User PartITU International Telecommunication UnionIVR Interactive Voice ResponseMEGACO Media Gateway Control protocolMGC Media Gateway ControllerMGCF Media Gateway Control FunctionMGW Media GatewayMIME Multipurpose Internet Mail ExtensionsM-MGW (Ericsson) Mobile Media GatewayMRFC Multimedia Resource Function ControllerMRFP Multimedia Resource Function ProcessorMTP3 Message Transfer Part level-3MTP3b Message Transfer Part level-3 broadbandMSC Mobile-services Switching CentreMTP Message Transfer PartM3UA MTP3 User Adaptation Layer

viii

(O-Z)

OSA-CSC Open Service Access - Service Capability ServerO&M Operation and MaintenancePCM Pulse Code ModulationP-CSCF Proxy-CSCFPSTN Public Switched Telephone NetworkQoS Quality of ServiceRFC Request For CommentsRNC Radio Network ControllerRSVP Resource Reservation ProtocolRTP Real-Time Transport ProtocolSAAL Signaling ATM Adaptation LayerSCF Service Switching FunctionS-CSCF Serving-CSCFSCTP Stream Control Transmission ProtocolSGW Signalling GatewaySIP Session Initiation ProtocolSLF Subscription Locator FunctionSS7 Signalling System no. 7SSCF Service-Specific Coordination FunctionSSCOP Service-Specific Connection-Oriented ProtocolSRTP Secure RTPTCP Transmission Control ProtocolTDM Time Division MultiplexingTHIG Topology Hiding Inter-network GatewayTLS Transport Layer SecurityUDP User Datagram ProtocolUE User EquipmentUMTS Universal Mobile Telecommunications SystemVoIP Voice Over IPVPN Virtual Private NetworkXML Extensible Mark-up LanguageXCAP XML Configuration Protocol

ix

List of Figures

1.1 Example of MGWs controled by the MSC . . . . . . . . . . . . . . . 2

2.1 Simplified IMS architecture . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 IMS reference points . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.1 MGW reference points and interfaces . . . . . . . . . . . . . . . . . . 20

4.2 Mc Interface/Reference point protocol stacks . . . . . . . . . . . . . 21

4.3 Nb Interface/Reference point Protocol stacks [3] . . . . . . . . . . . 22

4.4 IPBCP Tunneling [3] . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.5 Control system structure of a CPP configuration with eight BoardProcessors (BP) and some Special Processors (SP) and a Main Pro-cessor Cluster (MPC) with three Main Processors (MP). [82] . . . . 24

4.6 M-MGW hardware structure. [33] . . . . . . . . . . . . . . . . . . . 26

4.7 M-MGW hardware structure. [33][41] . . . . . . . . . . . . . . . . . 27

4.8 Connection model in the Connection Coordinator. [41] . . . . . . . . 28

5.1 IMS Logical Nodes grouping used for the industry relative to theMedia Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

7.1 Example of a H.248 connection model. The asterisk box in each of theContexts represents the logical association of Terminations implied bythe Context[62]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

7.2 H.248 Message structure . . . . . . . . . . . . . . . . . . . . . . . . 46

7.3 H.248 Message size for a Representative Call Flow, based on a bench-mark test performed by the Erlang project in [81]. . . . . . . . . . . 49

x

7.4 Encoding and Decoding measurements for H.248 binary encoded mes-sages based on a benchmark test performed by OSS Nokalva in [76].(The message sizes are the same as for the corresponding messagesshown in figure 7.3 for binary encoding) . . . . . . . . . . . . . . . . 50

7.5 SIP Message processing delay of 4 Proxy implementations. Source:[28] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

7.6 MSML Object classes’ relationship . . . . . . . . . . . . . . . . . . . 64

7.7 MSML Core Package Hierarchy . . . . . . . . . . . . . . . . . . . . . 65

7.8 MSCML Advanced Conference Model . . . . . . . . . . . . . . . . . 70

7.9 MSCML Media Server Connection Model . . . . . . . . . . . . . . . 71

7.10 Possible deployment of the Analyzed Media Server Control Protocolson the 3GPP interfaces of IMS (The ISC interface is not present forsimplicity). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

7.11 Selected preferred Model for Media Server Control (The ISC interfaceis not present for simplicity) . . . . . . . . . . . . . . . . . . . . . . . 81

8.1 H.248 Context view targeted to the prototype connection model . . 83

8.2 H.248 Call setup flow used for the Prototype . . . . . . . . . . . . . 87

8.3 H.248 call release and cold start-up flows used for the prototype . . 88

xi

List of Tables

4.1 Example of MGW’s features [43] . . . . . . . . . . . . . . . . . . . . 18

7.1 H.248 Commands [62] . . . . . . . . . . . . . . . . . . . . . . . . . . 45

7.2 H.248 Descriptors [62] . . . . . . . . . . . . . . . . . . . . . . . . . . 47

7.3 SIP Request Methods from the core specification[23] . . . . . . . . . 55

7.4 SIP Request Methods from extensions to the Core specification [23] 56

7.5 SIP headers defined in the Core Protocol . . . . . . . . . . . . . . . 57

7.6 MSML object classes . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

7.7 MSML mandatory and conditional packages . . . . . . . . . . . . . . 66

7.8 MSCML Request Methods for advanced conference . . . . . . . . . . 72

7.9 MSCML Request Methods for IVR . . . . . . . . . . . . . . . . . . . 73

7.10 Comparison of the characteristics of the Analyzed Media Control Pro-tocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

7.11 Functionality comparison of the analyzed Media Server Control Pro-tocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

xii

Chapter 1

Introduction

1.1 Background

The IP Multimedia Subsystem (IMS)[14] has been seen as the clear evolution ofthe packet-switched domain in the cellular world, specifically for the 3G networks.The operators and manufacturers have mainly driven this evolution through thestandardization bodies. They have agreed on standards and technologies that shouldallow the shift from the old systems to the new ones. This involves costs andinvestments from both parties (operators and manufacturers) for the developmentand the deployment of such technologies and sometimes the process specified by therecommendations and agreements is not providing a smooth enough transition forthe real environments.

From now on, we will be referring to the 3G networks as the ones defined forUMTS (Universal Mobile Telecommunications Service) and driven by 3GPP (ThirdGeneration Partnership Project) recommendations and the IMS as associated withit.

The Mobile Softswitch has been defined as the architectural model for the mobilecore network where the call control and the switching functions are found in differentnodes. It is based in the 3G Partnership Project’s (3GPP) release 4. The MediaGateway (MGW) and the MSC Server (Mobile Switching Center) are the main play-ers for this concept, where the MSC works as a controller for the MGW (see figure1.1). The MGW handles: the media stream processing, switching, transcoding andthe resources for transport (the links of the connectivity layer) while the MSC isresponsible for the mobility management and the call control.

The IMS has been introduced in the 3GPP’s release 5, providing to the 3G net-works with an infrastructure to offer QoS (Quality of Service), charging, coordina-

1

CHAPTER 1. INTRODUCTION 2

Connectivity Layer

Control Layer

MGW

MGW

MGW

MGW

IP – ATM Backbone

MSC

Figure 1.1: Example of MGWs controled by the MSC

tion and integration of services and security for the packet switch domain. Part ofthe media plane is handled through the Media Resource Function (MRF), whichis divided in two functions or logical nodes: the MRFC (Media Resource FunctionController) that is in charge of interpreting the SIP (Session Initiated Protocol)messages from the AS (Application Server) and the S-CSCF (Serving Call/SessionControl Function), and the control of the other MRF function, the MRFP (MediaResource Function Processor). The last is in charge of the media stream processingand mixing, playing announcements and controlling bearers on the Mb referencepoint [13].

1.2 Problem Description

There are strong synergies between the functions performed by the MGW and thefunctions expected from the MRFP. Both are capable of doing media stream process-ing, transcoding and control of the media transport. Already it has been proposed


the possibility of merging these logical nodes in one physical node: the Mobile MediaGateway (M-MGW) [43]. The Mp interface that is used for the MRFC to controlthe MRFP has not been standardized at the moment of writing this work. TheMGW already uses the protocol H.248 (known by IETF as MEGACO) for the Mcinterface with the MSC. Therefore, this work will analyze the different existing pro-posals for the Mp interface and Media server control. Also it will consider how theycould impact the M-MGWSs User Plane Control Function (UPCF) Application andpropose an implementation based in the H.248 protocol for the Mp interface througha prototype.

1.3 Objectives

To provide a comparison between the proposed protocols and models for MediaServer control. Additionally, to explore the implementation synergies between theM-MGW and the MRFP by constructing a prototype. The intention is to providea better understanding of the integration of the IMS network as an evolution of the3G networks by the gradual introduction of the IMS functions in the core network.

1.4 Scope

The thesis is limited to the Media Gateway (MGW) and the Mp interface of theMRF (Media Resource Function) contained in the 3GGP’s Release 6 specifications.The H.248 version discussed is version 2 released by ITU and IETF.

In the MGW, the scope is limited to the application that handles the User PlaneControl Functions (UPCF) although some hardware specific details are mentioned.The outcomes and test environment are presented despite the prototype implemen-tation is not provided. The test environment is using an adaptation of a 3G networksuitable for our analysis purposes.

1.5 Structure of the Thesis

Following to the introduction chapter, the IMS is presented in chapter 2. There,important elements to the 3G’s Circuit Switched Network and IMS interactionsare reviewed; the media plane and the services using such interactions are alsosummarized. The access network and the terminals are irrelevant for our purposestherefore we will concentrate on the Core Network Subsytem of the IMS. Chapter 3introduces to the Multimedia Resource Function Processor (MRFP) tasks and the


signaling that goes through the node. On chapter 4, the Media Gateway (MGW)implementation is described, its functions over the media plane, media transportand signaling combined with hardware and software overview. Chapter 5 providesan overview of the control protocols for Media Servers and the different modelsassociated to media server control. Later, the criteria of evaluation for the analysisprovided by this work can be found in chapter 6. The analysis itself of the differentprotocols alternatives , final comparison and selection of the preferred model is inchapter 7. The practical implementation of the prototype is presented in the finalchapter 8. Then the conclusions and future work are provided.

Chapter 2

IP Multimedia Subsystem

The mobile networks have been traditionally built in the Circuit Switched (CS)domain copying the model from the Public Switched Telephone Networks (PSTN).After the GPRS (General Packet Radio Service) launch for GSM, the interest for thetransport of data using the mobile core network was evident. The packet switchingbecame then an important part of the Core Network specifications that can be fullyrealized in the 3GPP vision for the ”All IP Architecture” [11]. In this frame, theIP Multimedia Subsystem (IMS) was defined based in the provision of multimediaservices that are bound to the packet data transmission. It is conformed for all thenecessary elements on the Core Network (CN) using the Packet Switch (PS) domainto deliver the different types of multimedia [13] [71].

2.1 Overview of the IMS Architecture

The IMS follows a layered architecture consisting of three different layers or planes[78]: application, control and connectivity & user’s plane. An example of the IMSlayered architecture is provided by figure 2.1.

The application layer basically consists on the SIP Application Servers, whichprovide the content and value-added services to the users. The independence of thislayer with respect to the others allows the services being provided regardless of theaccess used.

The control layer handles the registration, setup and release of calls and ses-sions. It also supplies functional control of the user’s plane servers (like MGWsand MRFPs). A big part of the network signaling is produced and received by thislayer, including the O&M (Operation and Management), charging, and network’sinterworking support.

5

CHAPTER 2. IP MULTIMEDIA SUBSYSTEM 6

Finally, the connectivity & user’s plane manages and processes the media sentby the end-points. This layer is in charge of the media traffic transport, routing,switching and network translation (protocol conversions).

3GPP has standardized functions or what we could call logical nodes. This isdifferent from the physical nodes offered by the vendors, which can merge severalfunctions in a physical node or split them in several entities[24]. In essence, thearchitecture of the IMS is defined by the logical nodes and the standardized interfaceslinking them.

CSCF

HSS

MGCFMRFC

MRFP

BGCF

SGW

AS

MGW

CS Network

Access Network

UE Media TrafficSignalling Traffic

Figure 2.1: Simplified IMS architecture

2.2 The IP Multimedia Core Network Subsystem

The IP Multimedia Core Network Subsystem according to 3GPP ”comprises of allCN elements for the provision of IP multimedia applications over IP multimediasessions” [12].For this purpose the CN includes:

1. User data base(s): One or several HSS (Home Subscriber Server), which can beconsidered as the evolution of the GSM node HRL (Home Location Register).


It stores and handles the subscriber and services related information. Some ofthe information includes: security items, location data, profiles and S-CSCF(Serving Call Session Control Function) allocated to the subscribers. TheSLF (Subscriber Location Functions) is used in case of the need to split theinformation stored by the HSS into several of them. The function of the SLF isto map the addresses of the subscribers into the corresponding HSS containingthe information needed for the particular subscriber [24].

2. The CSCFs (Call/Session Control Functions). They are SIP servers in chargeof routing and session management. The entities grouped in this category are:

� P-CSCF (Proxy Call Session Control Function). It is the first signalingcontact point within the Core Network (CN) with the terminal. It takescare of accepting requests (SIP messages) and processing them itself orforwarding them into the CN depending on what is required. It mayinclude a PDF (Policy Decision Function) that could be implemented ina separated node [14].

� I-CSCF (Interrogating CSCF). It is a SIP proxy, serving as a contact pointwithin an operator’s network for all the connections from a subscriber ofthe network or a roaming subscriber located in the network operator’sservice area at the moment. It has an interface using the Diameter pro-tocol to the SLF and the HSS. It can hide some domain information byencrypting parts of the SIP message. This last feature is known as THIG(Topology Hiding Inter-Network Gateway) and it is optional [14].

� S-CSCF (Serving CSCF). It is the main control entity in the signalingplane. Basically, it executes the session control services for the UserEquipment and maintains the session’s states needed to support the op-erator’s services. The S-CSCF analyzes the terminal’s SIP messages anddecides to route them to the correct application servers that would beable to provide the service to the subscribers. Another function of theS-CSCF is the routing services, for example translations of telephonenumbers provided instead of SIP URIs (Universal Resource Identifier)asaddresses. The enforce of network’s policies to the users is also done bythe S-CSCF depending of the user service profile and operator’s policyconfiguration [14] [24].

3. The ASs (Application Servers), which provide and hosts the multimedia ser-vices and comprise the application plane. Three types of ASs have been de-


fined:

� SIP AS: It is a native Application Server that executes multimedia ser-vices based on SIP. It will become the most used type for the developmentof new IMS specific services [24].

� OSA-CSC (Open Service Access - Service Capability Server): This typeof application server supplies an interface for the OSA (Open ServiceAccess) framework Application Server and interfaces the S-CSCF withSIP at the same time. It is an important mechanism to provide securedand standardized access for a third party AS to the IMS.

� IM-SSF (IP Multimedia Service Switching Function): It is a specializedapplication server designed to support CAMEL (Customized Applicationsfor Mobile network Enhanced Logic) services for legacy reasons. It acts asa SCF (Service Switching Function) on one side, interfacing the gsmSCFby using CAP (CAMEL Application Part) and allowing it to handle anIMS session. On the other side, it behaves as a SIP server interfacing theS-CSCF.

4. BGCF (Breakout Gateway Control function). The network can have one ormore of them. It is a point for breakout to the Circuit Switched network fromthe IMS. It is used when an IMS subscriber is trying to access the CS network.Despite being a SIP server, it uses the phone number and routes the requestto the MGCF (Media Gateway Control Function) if the breakout takes placein the same network, or to one BGCF on the destination network [24][78].

5. PSTN (Public Switched Telephone Network) - CS (Circuit Switched) gate-ways. They are decomposed into:

� MGCF (Media Gateway Control Function). It is a control and signal-ing node. It maps the SIP protocol to ISUP (ISDN User Part) or BICC(Bearer Independent Call Control), both over IP. Also, the MGCF con-trols the MGW resources using the H.248 protocol.

� SGW (Signaling Gateway). Sometimes it is needed to transfer requests tothe CS networks from the IMS and vice versa. The SGW is in charge to dothe low-level protocol conversion to make compatible the transport andmutual understanding in the signaling network. Basically, it converts theMTP (Message Transfer Part) into SCTP (Stream Control TransmissionProtocol) over IP[24].


� MGW (Media Gateway). It does the media plane conversion betweenthe IMS and the CS networks. The conversion can include change oftransport protocol (for example, from RTP to AAL2), transcoding (i.e.,from AMR to G.711) or stream processing (echo cancellation, playing ofannouncements, DTMF, etc). It receives control instructions from theMGCF.

6. MRP (Multimedia Resource Function). It is divided into two logical nodes:

� The MRFP (Multimedia Resource Function Processor) provides the nec-essary resources to support the user-plane services requiring media pro-cessing in the IMS domain. It is capable of performing conference mixing,transcoding, media analysis, stream treatment, and providing the mediato play announcements, for example.

� The MRFC (Multimedia Resource Function Controller) controls the MRFPresources using H.248 and acts as a SIP User Agent [24]. It was designedto grant the separation between the control plane and the user plane forthe IMS’ media resources.

2.3 Signaling plane interfaces

The signaling in IMS takes place over the reference points (see figure 2.2). Theyare links between the different IMS logical nodes using protocols that 3GPP haschosen to standardize. The protocols deployed at the reference points have beenstandardized by IETF (Internet Engineering Task Force) and ITU (InternationalTelecommunication Union). The reference points (we will also call them interfaces)in IMS grouped by protocols are [13]:

1. Reference’s points using Diameter (specified in RFC 3588 [22]) :

� Cx Interface. It is implemented between the I-CSCF or S-CSCF and theHSS. Mainly, it is used to allocate the S-CSCF, retrieve user informationand for authentication purposes.

� Dx Interface. It is implemented between the I-CSCF or S-CSCF and theSLF. It is used to find the HSS where the user’s data is allocated.

� Dh Interface (Release 6). It is implemented between the AS and theSFL. It is used by the AS to find the right HSS to contact in a multi-HSSenvironment.


� Sh Interface. It is implemented between the AS and the HSS. It is usedby the AS to access the HSS records.

� Si Interface. It is implemented between the HSS and the IM-SSF. It isused by the AS to query CAMEL subscription information from the HSS.

� Gq Interface (Release 6). It is implemented between the P-CSCF andthe PDF. It is used to exchange policy decision and information betweenboth entities.

2. Reference points using SIP (specified in RFC 3261 [86]) :

� Mw Interface. It is implemented between two CSCFs. It is used as acommunication channel (SIP proxy) between the CSCFs.

� ISC Interface. It is implemented between the S-CSCF and an AS. ISCstands for IMS Service control and it is used to carry charging informa-tion.

� Mi Interface. It is implemented between the S-CSCF and the BGCF. Itis used by the CSCF to forward a session to the BGCF when the sessionneeds to be routed to the CS domain.

� Mj Interface. It is implemented between the MGCF and the BGCF.When the BGCF selects the CS network where the breakout will happen,if it is happening in the home network, the Mj interface is used to forwardthe session to the MGCF.

� Mk interface. It is implemented between two BGCFs. It is used whenthe CS breakout happens in a network different from the home network.Then the session is forwarded to the BGCF in that network.

� Mr Interface. It is implemented between the S-CSCF and a MRFC. It isused by the S-CSCF to activate bearer related services. The functionalityis not fully standardized.

� Mg Interface. It is implemented between the MGCF and a I-CSCF. TheMGCF uses this interface to forward CS sessions to the IMS domain afterconverting the ISUP signaling to SIP.

� Mm Interface. It is implemented between the I-CSCF and another SIPterminal or server. In general, it is used by the IMS (specifically by theI-CSCF) to communicate with another multimedia IP networks by usingSIP.


� Gm Interface. It is implemented between the UE (in reality the accessnetwork) and the P-CSCF. It is used as the connection between the UEand the IMS. The interface allows three type of procedures: registration,session control and transactions [78]. The UE registers to the P-CSCFsending information about the supported security mechanisms and ex-changing authentication data with the network. This procedure impliesthe registration of user identities and the set up of secure ways of com-munication between the UE and the IMS. Re-authentication requestsor network initiated de-registration are also handled by this interface.After this, a session can be established and handled using the Gm inter-face (UE terminated or originated) to forward the requests. And finally,stand-alone requests and responses are also sent into the interface by thetransaction procedures.

3. Reference points using MEGACO (ITU-T Recommendation H.248)[62]:

� Mp Interface. It is implemented between the MRFC and the MRFP. Itis used by the MRFC to control the resources and media streams in theMRFP.

� Mn Interface. It is implemented between the MGCF and an IMS-MGW.It is used by the MGCF to control the resources and MGW functions.

4. Reference point using COPS (Common Open Policy Service protocol specifiedin RFC 2748 [31]):

� Go Interface. It is implemented between the PDF (P-CSCF) and theGPRS network. It is used for QoS authorization and charging correlationbetween the IMS and the GPRS.

5. Reference point using HTTP (HyperText Transfer Protocol) and XCAP (XMLConfiguration Protocol):

� Ut Interface (Release 6). It is implemented between the UE (in realitythe access network) and one (or several) AS. It is used to allow datamanipulation for configuration purposes from the UE.

2.4 IMS/CS relationship (3GPP view)

Even when the IMS operates in the packet switch domain, it needs to keep a rela-tionship with the circuit switch domain for several reasons: backwards compatibility


Access Network

S-CSCF

HSS

MGCF

MRFC

SGW

AS

SLF

P-CSCF

MRFP

MGW

UE

I-CSCF

P-CSCF

IP Multimedia Network

CS Network

Home IMSHome IMSNetworkNetwork

VisitedVisitedIMSIMSNetworkNetwork

Mw

MwMw

Dx

Gm

Ut

Cx

Cx

Si

ISC

MiMj

Mg

Mr

Mp

Mb

MbMb

Nb

Mn

Mk

BGCF

GGSN

PDF

GoGi

Figure 2.2: IMS reference points

and legacy, interworking with other networks and UEs, and inability to provide sup-port for certain services (i.e. emergency calls in the earlier phases). Although suchcompatibility is not mandatory from the specifications point of view, it is clearly ofimportance for the operators to be able to interact between both domains [74].

As has been stated, the PSTN/CS Gateway is the one that provides the inter-face for IMS toward a CS network. It handles the calls terminated and originatedin the CS domain where the IMS takes part. This Gateway has its counterpartin the CS domain, which in practical terms can be the same entity. Concerningthis, the 3GPP’s Technical Specification TS 23.002 reminds that the packet switchdomain and the circuit switch domain ”...are overlapping, i.e. can contain some com-mon entities”[13]. Also in TS 23.228 ”The IP multimedia subsystem is independentof the CS domain although some network elements may be common with the CSdomain”[13].

The specifications make a difference between the IMS-MGW and the CS-MGW(Circuit Switch MGW) as the MGW operating on the packet switch domain orthe one from the circuit switch domain. The reason for such separation is mainly


based on the media processing done in the CS domain and the possibility of it beingperformed in the PS domain (to adapt media for the CS domain, i.e. echo canceling).The pure media processing for the IMS has been specified as a task of the MRFP anda media connection can be established between both entities (MGW and MRFP),allowing media processing in one and protocol transcoding in the other one. TheCS MSC (Mobile-services Switching Center) and the IMS MGCF have also commonfunctions when is about the MGW control. Excluding some particular things properof the network characteristics, the MGW handling and control could be consideredidentical.

2.5 Media Plane Considerations

The IMS follows the signaling and media separation model, being able to offer aguaranteed QoS (Quality of Service), media services, and flexible charging. Re-gardless, IMS is still an IP network and the transport and routing of the mediais done following the IP principles. Because the IMS is an interconnected networkinterworking with another networks (i.e. Internet), the mechanism established toprovide the expected features requires the special handling of the packages (usingRSVP or DiffServ for QoS) and even specialized protocols (RTP, SRTP, SCTP,IPsec, etc). The media transverses an IP network by following a channel set by asession control. The media may or may not transverse network nodes (for examplethe MRFP or the MGW) depending if it is necessary any treatment to adequate itfor the communications purposes. For our study, we will concentrate on the caseswhen it is necessary to use the MRFP and the MGW in the IMS.

2.6 Application Plane Considerations

The Application Servers (ASs) perform the storage and service provisioning func-tions. Sometimes this implies the processing and analysis of media. For that reasonit makes sense in practice to fusion the MRFC functionality with the specific ASthat needs to do the media processing. In this way the media processing is done bythe MRFP controlled by an AS. From this point of view, the MRFC could seem tobelong to the application plane, because the media processing is done as part of aservice provided by the IMS or as the service itself. But in the strict meaning of theMRFC’s function it acts as a controller for the MRFP and for that reason we willconsider it in the control plane.

Chapter 3

Multimedia Resource Function

Processor

The MRFP is a part of the general Multimedia Resource Function. It is controlledby the MRFC using the Mp reference point. By this interface it receives ordersfrom the Application Servers (AS) and indirectly through the S-CSCF. It is alsoconnected using the Mb interface with other MRFPs, MGWs, other IMS networksand the GGSN (Gateway GPRS Support Node) for the media processing.

3.1 Function

The 3GPP specifications [13, 14] define the task of the MRFP as follows:

� Bearer control on the Mb reference point.

� Mixing of media streams (video and audio, multiparties, etc).

� Source of media (i.e. announcements, tones, etc).

� Processing of media streams (e.g. transcoding, analysis of media)

� Resources provisioning for the MRFC control.

In practice the MRFP will be used as a support node for the provisioning ofmultimedia services. The implementation of the functions are very open for themanufacturers, as well as the capacity and service parameters.

3.1.1 Media Encoding

The media encoding is relative to the digital handling of media. Video and audioare digitalized with several technologies and their interworking has to be secured

14

CHAPTER 3. MULTIMEDIA RESOURCE FUNCTION PROCESSOR 15

by transcoding mechanisms and translating techniques. Also the media could needmanipulation to provide a service to the subscribers or the mixing of several mediatypes or media streams to achieve a simultaneous transmission-reception of mediafrom several sources at the same time. One example is provided when an AS willcontrol the MRFP to adapt the media sent to one subscriber from a media server byperforming transcoding and mixing of the streams in a conference call. In this case,the MRFP can produce the media or transcode the media from a media server some-where in the network (or other interconnected IP network). Then the mixing couldbe done for several subscribers sharing the session. 3GPP has specified which codecsmust be supported in their IMS terminals [5]. This are AMR (Adaptative Multi-Rate) speech codec and H.263 video codec. Those terminals that support real timetext conversational services must use T.140 (ITU-T Recommendation T.140 [53])and the ones providing wideband services support AMR-WB (AMR WideBand). Onthe other hand, some non-3G terminals could support different codecs. The morecommon ones for speech are G.711 [54], also known as PCM (Pulse Code Modula-tion) and GSM-FR (GSM Full Rate) [35] implemented in all the GSM terminals,and for video: MPEG (Motion Picture Experts Group) video standards (MPEG-1[45], MPEG-2 [46] and MPEG-4 [44]) and H.261[47] used by the H.320[55] video-teleconferencing framework as well [24].

3.1.2 Media Transport

The MRFP takes care of the congestion and QoS for the bearer control. It couldalso handle the security associations for the media transport and the establishmentand release of connections over IP. This is useful considering the Mb reference pointconnections to other IP networks, i.e. GPRS, to set VPN (Virtual Private Networks)relationships and other IP connection services. Because of the IP properties, otherprotocols are used on top of it to provide the services not available with pure IP.Themost important protocols used for the MRFP are : RTP, TCP, UDP and SCTP.

The RTP (Real-Time Transport Protocol) [88] is used to transmit digitalized me-dia that are sensitive to delay and time continuity [26]. For this purpose, it providessequence numbers in the packages and timestamps. The first lets the receiver findout when a loss of packages has happened and the correct order of the packages inthe receiving buffer. The second allows playback control and delay handling.

RTP is used over UDP (User Datagram Protocol) datagrams mainly for con-currence reasons, allowing one equipment to handle several RTP streams at thesame time. RTCP (RTP Control Protocol) is used together with RTP. RTCP com-plements the RTP’s real-time functions. It provides an out-band communication

CHAPTER 3. MULTIMEDIA RESOURCE FUNCTION PROCESSOR 16

between the sender and the receiver, with information about the performance of thenetwork and additional information about the media sent using the RTP packages.It is transported over UDP and uses the next port number following the port numberused by the RTP stream.

For specific messages, the SCTP (Stream Control Transmission Protocol) protocolspecified in RFC 2960 [90] is used. This protocol is connection-oriented, which meansthe establishment of startup associations between two end points that provide a setof transport addresses to send and receive the messages. The basic function ofSCTP is to offer a reliable transport for messages between the peers avoiding thedisadvantages of TCP and UDP. Mainly these are: the capacity of multihoming,better DoS protection than TCP, and handling of multiple streams. In our studythe use of SCTP will be mainly seen in the signaling plane, where it is used totransport the H.248 messages over the Mp reference point.

TCP (Transmission Control Protocol)[80] has been used traditionally for reliabletransport. It was created to provide IP with the possibility of transmitting data-grams to different processes in the same host with reliability. It is a connectionoriented protocol, by creating a virtual circuit connection reserving a port and au-thorizing the transmission from both parties with full duplex capabilities. It is astream-oriented protocol and is based in buffered transfer [26]. At the same time,UDP (User Datagram Protocol) [79] is a connectionless and unreliable protocol, butadds to IP the capacity of distinguishing among multiple processes in a destinationhost [26]. The application handling the UDP transmission have to take care of thedelays, loss and duplication of packages, sorting and reachability of the destination.In any case, UDP is used because of the low overhead and easy packets transmis-sion. UDP can cause network congestion when is used to transmit large quantitiesof data, because it lacks of congestion control. Other protocols like DCCP (Data-gram Congestion Control Protocol) [69] have been developed to handle the possiblenetwork congestion because of unreliable transport services.

Chapter 4

Media Gateway

Traditionally, Gateways have acted as translators between networks, allowing com-munication to be carried on even when the protocols, topologies and transmissionmedia are different. The Media Gateways also adapt the media transmitted in thepayload to be compatible with the different technologies used for digital transmis-sion and terminals communicating. 3GPP has included the Media Gateways as themain edges for connectivity in the Circuit Switched Core Network. They providethe access to the network backbone for the media (acting sometimes as a transitswitch), payload processing, media conversion and bearer control, to support theCircuit Switched services options [13]. This is especially important in the transi-tion of the GSM networks to the ”all-IP networks” vision, when there exists severalnetworks, which needs to communicate and interact between them. The MediaGateways realize this in the media plane and the evolution of the 3G networks willdefine the needs of this node depending on the development into the all IP-visionalready mentioned.

4.1 Function

The Media Gateway function specified by 3GPP is split in two: the Circuit SwitchedMedia Gateway function and the Packet Switch (or IMS) Media Gateway function.The functions might or might not be implemented in the same node or implementedjust partially for each function (not the complete set for each type). In practice,the IMS-MGW and the CS-MGW can differ just in the transport used for thepayload, although only that fact is motive of important implementation differences.3GPP just outlines the MGW’s functions without giving an exact definition of thefeatures needed to ”...support the Iu options for CS services” [13] for the CS-MGW

17

CHAPTER 4. MEDIA GATEWAY 18

and ”...will be provisioned with the necessary resources for supporting UMTS/GSMtransport media” [13] as is specified in the 3GPP’s Network Architecture TS 23.002.Then the specific features can be inferred from those requirements. Teemu Haresin his master thesis ”Adding multimedia resource function processor functionalityto Mobile Media Gateway” already identifies this and presents an example of MediaGateway features needed, which can be seeing in table 4.1.

Table 4.1: Example of MGW’s features [43]Functions FeaturesSwitching/routing ATM switch

Real-time IP router (support of IPv4 and IPv6)Signalling Signaling with H.248, SS7, BICCProtocol conversion Convert transport protocolsTranscoding AMR speech

Speech coded with other codecsMedia Processing Echo cancellationQuality QoS handling

Differentiated Services (DiffServ)Security IP Security (IPSec)Services Multiparty connections

Tone sending/detectionDTMF sending/detectionAnnouncement handlingModem services and digital data accessCs dataCharging information collection

As specified, the control layer through the Media Gateway Control Function(MGCF), the Mobile-services Switching Centre (MSC) server and the Gateway MSC(GMSC) controls the Media Gateway. The Media Gateway interacts with thoseentities to implementing a termination and context view provided by the H.248abstraction. This will be further explained in section 7.3.1.

Because the Media Gateway is at the border of the backbone and interacts withother networks, it needs to implement a dual routing/switching function. If thebackbone implements an ATM network, the MGW switches the cells originated bythe Radio Network to or from the backbone, and it even serves as a transit nodewhere the cells are routed to other MGW or ATM switches. In the case of the IPbackbone, the routing mechanism works different from ATM. The MGW processesthe packets only directed to itself, it does not acts as a transit node although is not


required by the topology of the network and a routing table includes such a MGWas a link to reach another MGW. Also, the MGWs must know where to send thepackets to reach the end destination, and maintain a QoS level by keeping an ownrouting table if necessary.

In the case of being connected to different networks (PSTN, UTRAN, UMTS,ISDN, etc), the MGW could need to implement translation mechanisms to be ableto send the media with the right protocol format, data encoding and media frame toeach of the networks interacting with it. On the data transmission level, the mostcommon conversions are from ATM to IP and vice-versa, and from ATM internallayers AAL1 to AAL2 and vice-versa (mainly in the cases of TDM data, used mainlyfor PSTN and in some cases for GSM).

4.2 Transport and Signaling

The Media Gateway has several interfaces and references points. From the circuitswitch domain: the Mc interface connecting to the GMSC and MSC server, andthe Nb interface connecting to other MGWs in the network. The Mc interface(reference point) also connects the MGCF from the IMS to the MGW, and theMb interface connects the MGW with the MRFP and the GGSN from the GPRSnetwork. The radio network is connected by the IuCS interface, and the BSC canuse the A interface directly to the MGW as well.This can be seen in figure 4.1.

The Mc interface transports the H.248 signaling messages to control the MGW.The rest of the protocol stack is mentioned in the 3GPP specification TS 29.232”Media Gateway Controller (MGC) - Media Gateway (MGW) interface” [4]. TheATM or IP transport is handled as a mix of both or in ”pure” mode. In the pureATM transport, the H.248 is transported on top of MTP3b (Message Transfer Partlevel-3 broadband)[51] that provides the point-to-point link communication and thecapacity of sharing load and changeover between a set of links. The rest of the stackis SSCF (Service-Specific Coordination Function)[50] and SSCOP (Service-SpecificConnection-Oriented Protocol)[48] conforming to the Signaling ATM AdaptationLayer (SAAL) [49] on top of AAL5 (ATM Adaptation Layer - 5). In the pureIP transport mode, the stack is simpler by having the H.248 on top of the SCTP(Stream Control Transmission Protocol)[90] over IP providing the connection ori-ented relation needed to compliant with the redundancy and load handling of thesignaling. The specification also warns about not to use IPsec for the Mc interfacebecause SCTP provides the necessary security. In the case when both signalings areused, the M3UA (MTP3 User Adaptation Layer) [6] shall be added to the SCTP


MSC

MSC +

VRL

MGW

PSTN

MGCF

MRFP

GGSN

RNC

BSC

MGW

Nb

Mb

IuCS

A

Mc

PSTN

Radio Network Nodes

IMS Nodes

CS Domain Nodes

GPRS Nodes

Figure 4.1: MGW reference points and interfaces

stack providing the necessary interworking with all the systems. It might also beadded in a pure IP network, looking for a more flexible implementation of the nodes.Figure 4.2 illustrates the possible stacks for the Mc interface.

The Iu-CS interface is connecting the Media Gateway with the Radio NetworkController (RNC) and the Base Station Controller (BSC). This interface is alsoconnecting the Radio Access Network (UTRAN) to the Core Network. ATM andIP can be used as a transport for this interface [7].

When the Iu-CS interface is not implemented for the BSC (Base Station Con-troller), the A-interface can be used instead [1]. It was designed for the EDGE(Enhanced Data Rates for GSM Evolution) Radio Access Network connection tothe MSC, and only the user’s data is routed to the MGW. The backwards com-patibility with GSM and the MSC split (MSC-Server/MGW) makes this interfaceappear into the 3G networks’ layout.

The Nb interface provides the transport for user plane data between MGWs and


IP ATMIP

SCTP

SCTP

AAL5SSCOPSSCF

MTP3bM3UA

H.248 H.248 H.248

IP-Transport ATM-TransportIP - ATM Transport

Figure 4.2: Mc Interface/Reference point protocol stacks

bearer control [3]. It can use ATM and IP transport, and the protocol stack variesfor the transport network user plane or the transport network control plane. Inthe first, the ATM case, the stack is AAL-2 SAR SSCS (AAL type 2 Segmenta-tion And Reassembly Service Specific Convergence Sublayer)[52]/AAL2 [57]/ATM.In the IP case, the stack is RTP/UDP/IPv4 or IPv6. The transport network con-trol plane for ATM uses AAL2 connection signaling (ITU-T Q.2630.2 [56])/AAL2Signaling Transport Converter for MTP3b (ITU-T Q.2150.1 [61])/MTP3b/SSCF-NNI/SSCOP/AAL5/ATM. The IPBCP (IP-Bearer Control Protocol)[60] shall betunneled as specified in 3GPP TS 23.205 ”Bearer-independent circuit-switched corenetwork” [2]. The figures 4.3 and 4.4 show the Nb stacks and the IPBCP tunnelingroute.

The Mb interface/reference point provides access for the IPv6 network servicesto transport user data[13]. According to the specification, the Mb interface can bethe same as the Gi interface from the GPRS network. Therefore, the MGW keeps atransport link with the GPRS network (specifically the GGSN) and with the MRFPfrom the IMS.

The PSTN interface connects the MGW to the PSTN network. The interface isused for the media gateway just to transport the user plane media. The controlsignaling goes to the MSC server or the GMSC. From the transport point of view,the MGW is considered to be one ISDN external exchange point for the PSTNnetwork.


IPv4 ATMATM

UDP AAL2

AAL5

SSCOP

SSCF-NNI

MTP3b

AAL-2 SAR SSCS

RTP

AAL2 STC for MTP3b

IP-Transport User Plane

ATM Transport Control Plane

ATM Transport User Plane

AAL2 connection signalling (Q.2630.2) RTCP

IPv6

Figure 4.3: Nb Interface/Reference point Protocol stacks [3]

4.3 The Mobile Media Gateway (M-MGW)

The specifications do not standardize the implementation of the different functions inthe networks (that we know as ”logic nodes”). Instead they give a set of requirementsand tasks that must be accomplished by the logical entities. The manufacturers andoperators can choose the way how these functions are implemented; i.e. severallogical nodes can be grouped into one physical node. The circuit-switched MGWfunctions are implemented in the Mobile Media Gateway (M-MGW) together withsome useful extra functionality. The M-MGW can be used as a Signaling Gateway(SGW), an ATM packages handler (in addition to the switching point), real-timeIP router and media stream handler.

The evolution of the 3G networks especially from operators within the ”incumbentGSM adding WCDMA” and ”greenfield” [34] scenarios, has given to the M-MGWthe opportunity to develop as an important part to be considered by the operatorsin their network planning. The flexibility and versatility of the node, which allowsto change or upgrade the capacity or functions implemented physically, even duringoperation (or short operation breakages), is an attractive feature in the competitivemarket. These facts make feasible the study of the node possibilities to include IMS


MGW MGW

MSC-Server MSC-ServerNc

Mc

Nb

Mc

TS 29.232

BICC: Q.765.5

Tunnel: Q.1990

IPBCP: Q.1970

Figure 4.4: IPBCP Tunneling [3]

functionalities into its features. Many of the M-MGW characteristics are possiblethanks to the ”Connectivity Packet Platform”(CPP), former ”Cello Packet Platform”[68].

4.3.1 Connectivity Packet Platform

The CPP is a proprietary platform for execution and transport, providing interfacesto be used by applications using its services and executing on top of it. CPP hasbeen designed to provide support for redundancy, scalability, distributed executionenvironment and transport services. It includes a real-time operative system, a dis-tributed real-time database and O&M (Operation and Maintenance) support. CPPis built up for software and hardware modules [82] and consist of two big parts: TheCPP platform and the CPP development environment. The first contains supportfor ATM switching, IP routing, SS7 (Signaling System no. 7), B-ISUP (BroadbandISDN User Part) and Q.2630 [56] for AAL2 connections. The second provides ap-plication interfaces, libraries and software execution control for the multiprocessorenvironment.


4.3.2 Hardware Structure Overview

In general, the CPP nodes are composed by a backplane acting as a bus wheredifferent processor boards are attached and communicating between them. Theprocessors follow a hierarchic model (figure 4.5 and are placed in specialized boardswith specific functions and purposes.

MP

MP

MP

ICP

ICP

ICP

SPSPSP

ICP

ICP

ICP

ICP

ICP

ICP

ICP

ICP

ICP

BP

BP

BP BP

BP

BP

BP

BP

BP

ICP

MPC

Figure 4.5: Control system structure of a CPP configuration with eight Board Pro-cessors (BP) and some Special Processors (SP) and a Main Processor Cluster (MPC)with three Main Processors (MP). [82]

The Main Processors (MPs) form a cluster (referred to the Main Processor Clus-ter) where several Board Processors (BPs) are attached using a star topology. Theyuse an Internal Communication Path (ICP) to communicate with the cluster andcan control several Special Purpose Processors (SPs). The MPs inside a clustercommunicate but the SPs only with the BP they are connected to. Although this ishierarchic system, there is not a master-slave relationship, since in case of MP restartor crash, another MP will take over the critical processes immediately. The proces-sors can find where the processes are executed, querying a name server provided byCPP that publishes the task and services running in the MPC [82].

The backplane of the M-MGW is able to switch up to 622Mps duplex non-blocking


between the boards attached to the backplane(figure 4.6. The boards have a specificfunction and purpose, and they contain the different processor types depending ontheir function. The different types of boards that can be found in the M-MGWstructure are [33]:

� General Purpose Boards (GPB). They have a hard disk and can be configuredas a Main Processor (MP) or to provide Interactive Messages (IM).

� Special Purpose Boards (SPB). The SPB has been provided with several pow-erful microprocessors and can be used to execute any application. One of itstypical task is the packet handling.

� Media Stream Boards (MSB). The MSBs are controlled by the applicationsand are composed of Digital Signal Processors (DSPs), memory, and controlprocessors.

� Exchange Terminals (ET-x). There exists different types of Exchange Termi-nals and then named depending on the transmission technology used. Theyare named ET-MC1, ET-M4, ET-C4, ET-FE1, ET-FE4 and ET-FET, andeach of them adapts to a different type of physical medium (i.e. Ethernet,ATM, TDM, SONET, SDH, etc).

� Switch Core Board (SCB). The SCB has three functions: it works as an ATMswitch core, it distributes the system clock and connects the subracks togetherusing the Inter-Subrack Link (ISL).

� Switch Extension Boards (SXB). They are used to expand the M-MGW ca-pacities. In large nodes, the SXB interconnects subracks where the use of aSCB is not enough.

� Timing Unit Board (TUB). It provides the clock reference for the M-MGW.Also it is synchronized with the public network and has long term stability.

� Pooled Forwarding Engine. Used to handle the packet IP traffic over ATM.

4.3.3 Application Overview

The M-MGW application is a software layer built on top of the CPP platform, usingits services to interact and communicate. The application is the one that instructsthe M-MGW hardware the task that must be done, and implements an abstractenviroment to handle call data, protocols, instructions and services. Part of this


SCB

BackplaneSXB

TUBSPB

GPBMSB

PFE

ET-MC1ET-MC41

ET-M4

ET-C4

ET-FE1

ET-FE4

ET-FET

ET-X Exchange Terminals

SCB Switch Core Board

SXB Switch Extension Board

TUB Timing Unit Board

SPB Special Purpose Board

GPB General Purpose Board

MSB Media Stream Board

PFE Pooled Forwarding Engine

Figure 4.6: M-MGW hardware structure. [33]

abstraction is the Virtual Media Gateway (VMGW). With the VMGW, the M-MGW node can serve several MGC (Media Gateway Controllers) making possiblethe sharing of the physical resources and services[41].

The application is structured in three big parts:

� User Plane Control Functions (UPCF). The User Plane Control Functionsconsist of Signaling Transport Converter (STC), GCP Termination (GCPT)and Connection Coordinators.

� User Plane Functions. It consist of the media stream and media framingresources software.

� Operation and Maintenance application (O&M). Provides the software inter-face for Operation and Maintenance of the node.

User Plane Control Functions

The User Plane Control Functions (UPCF) can be seen as the brain of the M-MGWnode. Its functions go from terminating the H.248 protocol, by interpreting and


MGWApplication

User Plane Control

FunctionsGCP Terminations

Media FramingFunction

Media Stream Function

User Plane Functions

Operationand

Maintenance

CPPBearer Termination External Bearer Control

Real-time Routing Switching Function Signalling Gateway

Physical Interfaces

API

H.248

Signaling Transport Converter

Connection Coordinators

Virtual MGWs

API

API

API

Figure 4.7: M-MGW hardware structure. [33][41]

replying the commands, administering the resources of the node, ordering connec-tions, selecting transport systems and controling stream functions. It is divided intothree subsystems:

1. Signaling Transport Converter. This subsystem handles the transport of H.248between the M-MGW and the MGC (any Media Gateway Controller; i.e. MSCserver, MGCF, etc) fulfilling the recommendation Q.2150 from ITU-T [61].It provides: Independence from the transmission media, service’s availabilityreports, and transparency of the information transferred [91].

2. GCP Termination. GCP stands for ”Gateway Control Protocol” and it is yetanother name for H.248 (or MEGACO). The GCPT subsystem is decodingand encoding the H.248 message in binary mode, using the ASN.1 (AbstractSyntax Notation One) [64] and encoding applying the Basic Encoding Rules(BER) [63]. It also handles the H.248 messages by breaking them into M-MGWinternal data and vice versa, checks the syntax of the messages and controls thetimers implemented for the H.248. Load balancing between several ConnectionCoordinators (CCs) following the H.248 rules and load balancing algorithmsis part of its functionality as well [91].


3. Connection Coordinator. The Connection Coordinator is responsible for map-ping the H.248 view to the user plane view. In other words, the CC interpretsthe H.248 instructions and maps them into device reservations, connections,stream processing commands for the platform and event monitoring. The re-sources database is also updated by the CC to keep control of the hardwareand software resources used in the different calls. Figure 4.8 illustrates anexample call where the CC has implemented a chain of reserved functions forstream processing and transport adaptation.

Logical View

Connection Chain

ATM AAL2 IuFHVoice Coder

Echo Canceller

RTP UDP IP

Connection Coordinator

ResourceComponent

Database

Media Framing Media FramingMedia Stream

Resource Component

Figure 4.8: Connection model in the Connection Coordinator. [41]

User Plane Functions

The User Plane Functions system can be divided into two parts: the media streamfunctions and the media frame functions. The media stream functions are relative tothe necessary media stream processing in the user plane. It can be a stream addition(tones, interactive messages, DTMF sender), stream modification (echo canceling,speech coders), media analysis (DTMF detector, tones detector) or data modula-tion (asynchronous non-transparent circuit switched data, etc). The media framefunctions does the work of adapting the media frames into the different transport


systems, by framing the media and fixing it into the adequate protocol stack forthe transmission. Basically, it packs and unpacks the media arriving as payload tothe node, facilitates the media stream processing if needed, and converts from onetransport system to another.

Operation and Maintenance application

The O&M application allows the administration of the M-MGW node and the con-figuration of many of their parameters. It provides support for upgrades and resourceadministration, keeps logs and informs about the status of the node. It can be op-erated remotely or locally using a Graphical User Interface (GUI). A web browserusing a Java Virtual Machine (JVM) can access the GUI and the client can com-municate with the node by HTTP (Hypertext Transfer Protocol), IIOP (InternetInter-Object Request Broker Protocol) and FTP (File Transfer Protocol).

Chapter 5

Control Protocol for Media

Servers

5.1 Multimedia Resource Function, Media Servers and

Physical nodes Implementation

Media Server is a term used by the industry for referring to the Multimedia Re-source Function as a physical node. The Media Servers could include several of thefunctionalities specified by 3GPP for the IMS logical nodes in one box and not onlythe MRF. Sometimes, the control part is totally split from the processing part, andsometimes is considered an integral part of it. The most common desired groupingsof functions are (see figure 5.1):

� MRFC-MRFP or MRF. Comprises the Media Resource Function in a physicalnode. The standardized communication interface in use by this node wouldbe the Mr interface, which according to the specification 3GPP TS 23.228[14]uses the SIP protocol specified by IETF RFC 3261[86]. In this case, the Mpinterface could be omitted, and one would use a proprietary interface to controlthe Media Resources available in the node.

� MRFC-MGC. Associating the MRFC with the MGC could be considered agood alternative in terms of stack reuse since both use H.248 to control theirslaves nodes as masters. Also, some of the state machinery and the control logichave strong synergies, and there exists similar points in their functionalities(see 2.1). One of the strongest arguments that could affect this association isthe difference in cardinality. Some experts believe that the cardinality betweenMRFC-MRFP is many-to-one, meanwhile, the MGC-MGW is one-to-many.

30

CHAPTER 5. CONTROL PROTOCOL FOR MEDIA SERVERS 31

This is a valid scenario if we compare with a CS-MGW to which every UEhas to get a connection. There is then a need for many MGWs for reasonsof capacity, load balancing and even geographic location for the user planeprocessing. Meanwhile only a MGC could be deployed to take care of thesignaling. In the IMS case where the MRFP is expected to be used, there isnot a need for each UE to access a MRFP. In this case, an architecture witha more centralized approach for a Media Processing Server is expected to bedeployed, at least in the initial IMS phases. Also several ASs will expect tohave access to control the MRFP resources to serve their clients.

� AS-MRFC. This kind of associations add an additional value to the previouspoint, where the AS is integrated and has direct access to the MRFP. Signalingreduction in the network, easier integration and clearer routing managementare some of the advantages brought by this association. On the other hand, thiskind of close architecture could represent a risk of inter-vendor compatibilityand interworking, i.e, for other AS accessing the MRFP or interworking withthe AS embedded in this entity.

� MRFP-MGW. The MGW and the MRFP have strong synergies in the mediaprocessing area. Integration studies have already been published for this asso-ciation [43] providing many arguments for the merging of the functionalities inone node. The control of both nodes is driven by H.248, and their associationswith the masters is very similar.

The merging of MRFC-CSCF means basically the addition of the MRFC func-tionality to the CSCF. The main concerns with respect to this type of associationare about the H.248 signaling that has to be generated to control the MRFP. TheCSCF and the MRFC deploy a SIP stack in their input interfaces, and the handlingof a H.248 stack for output might seem superfluous and therefore not practical.

The idea of grouping the functions has caused discussion in the industry forums(i.e., 3GPP and IETF ) to look into alternative interfaces to control the MediaServers. The 3GPP specifications [14] locate the media resources per se in theMRFP, and define the Mp interface as the control interface from the MRFC. Despiteof this, the utility and feasibility of the Mp interface has been questioned by somemanufacturers and developers in several forums (IETF, ATIS, 3GPP, etc) and whitepapers (i.e. Convedia [27]and Brooktrout [20]). The main arguments for those claimsare:

� Increasing of the network complexity by using the master-slave relationshipbetween MRFP and MRFC. The H.248 master-slave model forces the MFR


CSCF

HSS

BGCF

SGW

AS

CS Network

Access Network

UEMedia TrafficSignalling Traffic

MGCFMRFC

MRFP MGW MRFP

BGCF

SGW

AS

MGW

CS Network

Access Network


CSCF

HSS

MRFC MGCF

MRFP

AS

MGW

CS Network

Access Network


CSCF

HSS

MGCFMRFC

BGCF

SGW

BGCF

SGW

MGW

CS Network


MRFP

CSCF

HSS

MRFC

AS

Access Network

MGCF

CSCF

HSS

MRFC

BGCF

SGW

AS

CS Network

Access Network


MGCF

MRFP MGW

Figure 5.1: IMS Logical Nodes grouping used for the industry relative to the MediaServer


split and limits the possibility of direct control from the Application Serversto the MRFPs.

� Lack of flexibility for the implementation of the media services. Low level con-trol and direct processing commands are specified in H.248’s packages, makingthe realization of services and application level resources more restricted.

� Development redundancies for the node commercial releases. The limited useof H.248 for 3GPP networks for the specific cases of MRFPs and MGWs repre-sents an extra effort for support and maintenance and a waste of opportunitiesto converge protocols used commonly in different standardized media networks,specifically in the case of SIP. The production of commercial nodes mergingseveral capabilities and providing support for several network architectures islimited because of this aspect.

Chapter 6

Media Server Control Interface

Criteria

6.1 Methodology

The analysis of the protocols is based on the different scenarios implying the MRFCand the MRFP for IMS networks. As the aim of this thesis is to study the feasibilityof the implementation of the Mp interface for the M-MGW, the impacts that theprotocols have on the node are then considered as well.

The scenarios are used to provide some of the basic requirements. At the sametime, these provide the evaluation parameters for the comparison of the protocols.The comparisons are done on a theoretical level, since some of the protocols are stillin draft stage or not fully standardized. The criteria used to evaluate the protocolsare based on:

� Network specifications and standards (3GPP, IETF, ITU)

� Articles and technical reports

� Test results when available

These items provide the information to analyze the different aspects of the pro-tocols:

1. Functionality. Analyzes the different functions and services provided by theprotocols.

2. Architecture specifics. Looks at the different configurations details and theenvironment setup necessary for the protocols to workt’, and also into theassociated protocols and transport.

34

CHAPTER 6. MEDIA SERVER CONTROL INTERFACE CRITERIA 35

3. Performance. Evaluates different aspects inherent to this category: Bandwidthconsumptions, delays, processing power needed, load variation and error han-dling.

4. Extensibility. Reviews the possible extensions to be used with the protocolsto improve their capabilities and add functionality.

5. Scalability. Analyzes the handling of overload situations, connection associa-tions and deployment of several instances.

6. Security. Lists the security features of the protocol restricted by the securityneeds for the Mp interface.

7. Interoperability. Analyzes the possibility of deployment in several areas (otherthan the Mp interface), legacy and configuration compatibility.

8. Development. Presents the future trends and state of the protocols at thismoment.

6.2 Evaluation

The final result of the analysis is provided by the evaluation criteria. Even when it isdifficult to quantize the extent of the protocol’s commitment to every requirementfor the Mp interface and other analyzed aspects, several aspects can be defineddepending on the inherent characteristics. The aspects used for the study are:

1. Flexibility. It denotes the degree of adaptability for changing environments,different configurations or deployment extent.

2. Capacity. It ranges the capabilities measurement to equivalent categories forthe protocols.

3. Reliability. It measures the reliability of the protocols for the different analyzedaspects.

4. Complexity. It evaluates the level of complexity for the implementation ofeach protocol and necessary setup arrangements to make it work.

5. Abstraction level. This measurement shows the rank of abstract concepts usedby the commands in the protocols implementation. This gives an idea of thedegrees of freedom for the implementation of the protocol’s commands by thehandling applications.


6.3 Requirements

6.3.1 3GPP Requirements

According to the last published stage of the TS.23.333 “Multimedia Resource Func-tion Controller (MRFC) - Multimedia Resource Function Processor (MRFP) Mpinterface: Procedures Descriptions” [9] at the moment of writing this text, the MFRfunction has been split into MRFC and MRFP and their tasks defined as follows:

The tasks of the MRFC may consist of the following:

� Control the media stream resources in the MRFP.

� Interpret information coming from an AS and S-CSCF (e.g. session identifier)and control the MRFP accordingly.

� Generation of CDRs (Call Data Records).

Tasks of the MRFP may consist of the following:

� Control of the bearer on the Mb reference point.

� Provide resources to be controlled by the MRFC.

� Mixing of incoming media streams (e.g. for multiple parties).

� Media stream source (e.g. for multimedia announcements).

� Media stream processing (e.g. audio transcoding, media analysis).

� Floor Control (i.e. manage access rights to shared resources in a conferencingenvironment).

Also, the next functional requirements have been defined:

� Play Tones. The MRFP should be able to send specific tones upon requestof the MRFC. It shall be able to play the tone, continuously until a stoprequest is sent or for a requested length of time. Also, it shall be able tosend notifications and detect a DTMF with the possibility of triggering tonesactions.

� Play Announcement. The announcements shall be played with the same re-quirements as the tones, with the addition that requests of predefined fixedannouncements can also be received. Furthermore, several predefined vari-ables (such as date, time, currency, etc) could be provided by the MRFP inthe announcement under request.


� Text to Speech. To produce automatically generated speech from text inputis another of the functional requirements. Although the language type may beindicated, a translation function is not required.

� Audio Record. It basically consists of recording the audio media stream inthe user plane and storing to a file. The recording could include the mixing ofstreams from a multi-party call.

� DTMF Collection. The MRFP shall be able to detect and report DTMF digitsto the MRFC.

� Automatic Speech Recognition. This function is responsible for the processesimplying the matching of a user input voice against a target data producing arecognition result that represents the detected input.

� Play Multimedia. The function of the playing multimedia is to play the syn-chronized audio and video media stream to the user, including requests forplaying media to several parties connected to a call or session and transcodingif the codec of the media is different from that of the session codec.

� Multimedia Record. Storing the recorded synchronized audio and video mediastream(s) into a multimedia file is part of the MRFP functions. The recordingcan include one or several parties from a single or conference call.

� Audio Conference. The audio conference allows several subscribers participat-ing in the conference to communicate with each other. The way of communi-cation may be influenced by a floor control policy summarized in 3GPP TS24.147 [8]. Transcoding, DTMF detection, playing tones or announcements,recording of audio during the conference may be possible.

� Multimedia Conference. The multimedia conference adds the video stream tothe previous function and the respective video manipulation actions such asrecording and transcoding.

� Audio Transcoding. The MRFP shall support audio transcoding betweenstreams of two Terminations within the same context where the streams areencoded differently. As minimum requirement the MRFP shall support the de-fault 3GPP audio codec AMR (narrowband), and optionally any other codecs.

� Video Transcoding. The MRFP shall support video transcoding betweenstreams of two Terminations within the same context where the streams are


encoded differently. As a minimum requirement the MRFP shall support thedefault 3GPP video codec H.263, and optionally any other codecs.

6.3.2 IETF requirements

IETF has been one of the forums used by those opposing the deployment of H.248 tocontrol media servers. They have raised there proposals for media control protocols,and specially discussed the need of such a protocols to use SIP in some way (i.e. astransport, extending it, etc). The internet draft draft-even-media-server-req-01[36]tried to compile the general feeling from the discussion list of the requirements forsuch a protocol. The document also takes as a reference RFC 4553 “A Frameworkfor Conferencing with the Session Initiation Protocol (SIP)”[83] (at the time of thedocument writing it was an internet draft) to provide the requirements based in therequired functionality specified. At the moment of writing this work it is an expireddocument and has not been updated yet, but it gives a good view and understand-ing of the IETF discussion’s general opinion for the media server control protocolrequirements. The document by R. Even mentions textually in the requirementchapter (from page 6) the n points:

� General protocol

1. The Media server control messages shall be sent over a reliable connection.

2. The protocol shall enable one AS to work with multiple MS.

3. The protocol should enable many AS to work with the same MS

4. The AS should be able to find the MS and connect to it.

5. The MS shall be able to inform the AS about it status.

6. The protocol should be extendable.

7. The MS shall be able to tell the AS its capacities.

8. The MS shall be able to tell the AS its functionality (Mixing,IVR, An-nouncements).

9. The AS shall be able to request the MS to create, delete, and manipulatea mixing, IVR or announcement session.

10. The MS shall supply the media addresses (RTP transport address) to beused to the AS.

11. The MS should send a summary report when the session is terminatedby the AS.


12. The AS should be able to request call/session and conference state fromthe MS.

13. The MS should support DTMF detection (in band tones and RFC 2833[89])

14. The protocol shall include redundancy procedures.

15. The protocol shall include security mechanisms.

16. The AS should be able to reserve resources on the MS. The resourcesmodels should be simple. (This requirement needs more discussion)

17. The MS may support resource reservation and shall report the supportin the initial connection to the AS.

18. The MS shall inform the AS about any changes in it capacities. Thechanges may be due to reservation, internal usage or due to some mal-function.

19. The AS shall be able to tell the MS which stream parameters to use onincoming and out going streams. Stream parameters may be for examplecodec parameters (video codec features) or bit rates. This requirementwill help the MS to allocate the right resources.

20. The AS shall be able to define operations that the MS will perform onstreams like mute and gain control.

21. The MS shall supply the AS with sufficient information for the eventpackage.

� Announcements. Announcements may include voice, audio, slides or videoclips.

1. The AS shall be able to instruct the MS to play a specific announcement.

2. The MS shall be able to retrieve announcements from an external con-nection.

3. The AS shall be able to tell the MS if the message can be delayed if theMS cannot play it immediately.

4. The AS shall be able to instruct the MS to play announcements to asingle user or to a conference mix.

� Media mixing

1. The AS shall be able to define a conference mix.

2. The AS may be able to define a separate mix for each participant.


3. The AS shall be able to define the relationship between two mixes, forexample a pair of audio and video for lip-sync or for voice activated videoswitch

4. The AS may be able to define a custom video layout built of rectangularsub windows.

5. For video the AS shall be able to map a stream to a specific subwindowor to define to the MS how to decide which stream will go to each subwindow. The number of sub-windows will start from one.

6. The MS shall be able to inform the AS who is the active speaker.

7. The AS may be able to cascade mixers ( side bar with whisper mode)

8. The MS shall be able to inform the AS which layouts it supports.

� IVR

1. The AS shall be able to load an IVR script to the MS and receive theresult

2. The AS shall be able to mange the IVR session by sending announcementsand receiving the response (DTMF)

3. The AS should be able to instruct the MS to record a short participantstream and play it back to the conference. This is not a recording re-quirement.

Chapter 7

Media Server Control Interface

Analysis

7.1 3GPP Proposed Protocols for Control of Media Servers

The Media Server as such can be mapped to the MRF function from the 3GPP designof the IMS. The interfaces specified for the MRF have been already mentioned in2.3 and illustrated in 2.2. These interfaces are:

� Mb Reference Point. It is considered the user media transport interface. It isalso known as “Reference Point to IPv6 network services”. It is connecting theMRFP with other MRFPs, MGWs and IPv6 networks, such as GPRS. In thelast case, it can be the same reference point as the GPRS Gi reference point[13].

� Mr Reference Point. It is a SIP based interface. It is not totally specified atthis moment by 3GPP. It connects the MRFC to the CSCF, and it is meant totransport the necessary information to provide the media services requestedfrom the Media Servers. This information is expected to be provided by theApplication Servers.

� Mp Reference Point. It shall be based on the H.248 protocol and the respectivepacket extensions for the media control. It transports the control commandsfrom the MRFC to the MRFP. The work for the specification of this interface[9] is still in progress at the moment of writing this work.

Consequently, the control of the MRF is dependent of the Mr and Mp interfacesand their protocols SIP (specified in RFC 3261 [86]) and MEGACO (ITU-T Rec-ommendation H.248)[62].

41

CHAPTER 7. MEDIA SERVER CONTROL INTERFACE ANALYSIS 42

7.2 IETF Proposed Protocols for Control of Media Servers

As it was already mentioned in 6.3.2, there exists different attempts in IETF tostandardize a control protocol for Media Servers. Some of them have been submittedas internet drafts at the moment of writing this work, and therefore their currentstate of completeness and matureness are at different levels. We will focus later onthe set of protocols that provides Control features at least comparable with H.248.The proposed protocols to be use for media control in IETF are:

� Media Sessions Mark-up Language (MSML) [87]. This on going work is meantto provide a complete protocol for media control. The main aim is to replaceH.248 and reuse the SIP stack present in many IP network nodes. Furtherdetails are expanded in section 7.3.3.

� Media Server Control Mark-up Language (MSCML) and Protocol, RFC 4722[32]. Another alternative to H.248 for media server control. It provides a highdegree of implementation freedom by providing directives embedded in SIPbody messages. Further details are expanded in section 7.3.4.

� Basic Network Media Services with SIP (Netann), RFC 4240 [19]. Netann isconsidered to be an extension of SIP that provides announcements, scriptedIVR and conference mixing setup. We will not analyze deeper the possibilityof Netann deployment for media control, since the possible media control withNetann is quite limited especially after the establishment of the session, andit can be used to complement the services provided by MSCML and MSML.

� The Call Control XML (CCXML). Included in RFC 4267 [40]. CCXML pro-vides a XML syntax to provide telephony call support for dialog systems suchas VoiceXML. This protocol can be consider complementary to the VoiceXMLcompatible protocols (i.e. SIP, MSCML, MSML, etc).

� SIP Interface to VoiceXML Media Services [21]. This draft intends to providea SIP interface to VoiceXML media services provided by Media Servers andemployed commonly by Application Servers. This protocol could be consideredas complementary for SIP for providing VoiceXML interaction. Therefore wewill not analyze it further in this work.

� A Control Framework for the Session Initiation Protocol (SIP) [17]. This in-ternet draft intends to provide a framework and protocol based on SIP forapplication deployment where the application logic and processing are dis-tributed (i.e. Media Servers and Media Server Controllers) . It is meant to


be extended by defined “Control Packages” that provide a specific control fea-tures. The definition of this framework was not mature at the time of writingthis work, therefore it was left out of the scope of the analysis. However, inthe “Future Work” section 9.1 a small update of the current work done on thisprotocol is provided.

� VoiceXML Interactive Voice Response (IVR) Control Package for the SessionInitiation Protocol (SIP)[18].This internet draft defines a package for IVRfunctions using VoiceXML dialogs for the Control Framework for SIP [17].

� A Basic Interactive Voice Response (IVR) Control Package for the SessionInitiation Protocol (SIP) [16]. The scope of the package is control of mediaserver functions for basic interactive media, as well as notifications related tothese functions defined as XML messages. This internet draft defines a controlpackage for basic IVR functions for the Control Framework for SIP [17].

7.3 Media Server Control Protocols

7.3.1 ITU Recommendation H.248 (Megaco Protocol)

H.248[62] is a protocol developed as a joint effort between the International Telecom-munication Union (ITU) and the Internet Engineering Task Force (IETF)[42]. Thename Megaco is derived from the IETF workgroup where it was produced. It wasenvisioned as the substitute for all the control protocols deployed by different ven-dors and networks to control Media Gateways , such as the Media Gateway ControlProtocol (MGCP).

1. Architecture specifics. H.248 follows a transaction master-slave model, wherethe Media Gateway is the slave and the Media Gateway Controller is themaster. The protocol works in the application layer of the OSI model, whichmeans that it needs a suitable transport to establish the connections and toprovide redundancy, security and routing. For those task, some other transportprotocols are used to provide those services. They have even been standardizedfor ATM [58] (mainly deploying AAL5 and MTP3), SCTP [59], and IP (annexD of [62]) by means of UDP and TCP.

2. Functionality. H.248 was meant to be used for MGW control, although it hasbeen extended to be deployed also for advanced conferencing. A model for cre-ating advanced conferences is presented in [73]. It provides a transaction base


way of communication where every request should receive a reply. H.248 de-fines a “connection model” which defines two abstract entities: Terminationsand Context. A termination can be the source or/and the sink of a mediastream. It also encapsulates the media stream and bearer parameters. A Con-text defines the association between collections of terminations; there existsa special type of context named null context which represents the repositoryof all the terminations that do not have any association. Also a special typeof termination called root is defined, in order to address the whole gatewayinstead of one particular termination. An example of the connection model isshown in figure 7.1.

H.248.1V2 F01

TerminationTermination

RTP Stream

Termination

Media Gateway

TerminationTermination

RTP Stream

Context

Termination

Context

Termination

RTP Stream

Null Context

SCN BearerChannel

SCN BearerChannel

SCN BearerChannel

SCN BearerChannel

Context

Figure 7.1: Example of a H.248 connection model. The asterisk box in eachof the Contexts represents the logical association of Terminations implied by theContext[62].

The message structure of H.248 is shown in figure 7.2. A H.248 message isessentially a transport mechanism for transactions. It contains a header anda set of transactions which are processed independently of each other withoutany specific order. The H.248 messages are not acknowledged.

The H.248 commands are the basic orders from the MGC to the MGW. Theirtask is to manipulate the logical entities of the protocol connection model.Table 7.1 briefly describes the different commands available.

The commands contains several parameters called Descriptors. The Descrip-


Commands Description Direction

Add The Add commands adds a Termination to a Context. TheAdd command on the first Termination in a Context is usedto create a Context

MGC -> MGW

Modify The Modify command modifies the properties, events andsignals of a Termination.

MGC -> MGW

Subtract The Subtract command disconnects a Termination from itsContext and returns statistics on the Termination’s partici-pation in the Context. The Subtract command on the lastTermination in a Context deletes the Context.

MGC -> MGW

Move The Move command atomically moves a Termination to an-other Context.

MGC -> MGW

Audit Value The AuditValue command returns the current state of prop-erties, events, signals and statistics of Terminations.

MGC -> MGW

Notify The Notify command allows the Media Gateway to informthe Media Gateway Controller of the occurrence of events inthe Media Gateway.

MGW -> MGC

ServiceChange The ServiceChange command allows the Media Gateway tonotify the Media Gateway Controller that a Termination orgroup of Terminations is about to be taken out of service orhas just been returned to service. ServiceChange is also usedby the MGW to announce its availability to a MGC (regis-tration), and to notify the MGC of impending or completedrestart of the MG. The MGC may announce a handover tothe MGW by sending it a ServiceChange command. TheMGC may also use ServiceChange to instruct the MGW totake a Termination or group of Terminations in or out ofservice.

MGW -> MGC,MGC -> MGW

Table 7.1: H.248 Commands [62]


Transaction1

H.248 message

Action1 Command1 Command2

Action3 Command1 Command2

Command3 Command4

Action2

Transaction2

Action1 Command1

TopologyDescriptor

MediaDescriptor

Figure 7.2: H.248 Message structure

tors consist of a name and a list of items which may have values. Table 7.2describes all the possible descriptors and their purposes. Some of them cannot be present together in a command.

The Actions are in general a group of commands which are related to the sameContext. Exceptions to this are commands which refer to terminations thatare not in any context or when a new context is created.

Finally the Transactions are grouping of Actions and therefore Commandswhich can be grouped into two types: Transaction Requests and TransactionReplies. The Commands within a transaction are executed sequentially incontrast to the already mentioned non-sequence nature of the Transactionsin a H.248 message. The Transaction requests are basically acknowledged bythe Transaction replies. The applications handling the protocol implementstimers for either resending a transaction request or issuing Transaction Pend-ing, which is a type of message used by the receiver of a Transaction Requestto inform the sender of delays in the processing of a specific Transaction Re-


Descriptor Name Description

Modem Identifies modem type and properties when applica-ble.(ModemDescriptor has been deprecated in ITU-T Rec. H.248.1version 1 (03/2002)).

Mux Describes multiplex type for multimedia Terminations (e.g. H.221,H.223, H.225.0) and Terminations forming the input mux.

Media A list of media stream specifications

TerminationState Properties of a Termination (which can be defined in Packages) that arenot stream specific.

Stream A list of remote/local/localControl descriptors for a single stream.

Local Contains properties that specify the media flows that the MG receivesfrom the remote entity.

Remote Contains properties that specify the media flows that the MG sends tothe remote entity.

LocalControl Contains properties (which can be defined in packages) that are of in-terest between the MG and the MGC.

Events Describes events to be detected by the MG and what to do when anevent is detected.

EventBuffer Describes events to be detected by the MG when Event Buffering isactive.

Signals Describes signals applied to Terminations.

Audit In Audit commands, identifies which information is desired.

Packages In AuditValue, returns a list of Packages realized by Termination.

DigitMap Defines patterns against which sequences of a specified set of events areto be matched so they can be reported as a group rather than singly.

ServiceChange In ServiceChange, what, why service change occurred, etc.

ObservedEvents In Notify or AuditValue, report of events observed.

Statistics In Subtract and Audit, report of Statistics kept on a Termination.

Topology Specifies flow directions between Terminations in a Context.

Error Contains an error code and optionally error text; it may occur in com-mand replies and in Notify requests.

Table 7.2: H.248 Descriptors [62]


quest. A Transaction Reply should include the results for all the Commandsfound in the corresponding Transaction Request. This means that it shouldinclude the return values for the Commands executed successfully, and theerror descriptor for any Command that has failed.

The protocol allows to be extended by means of the Package Definitions. Theydefine optional Properties, Events, Signals and Statistics that may occur onTerminations. Packets defined by IETF appear in separate RFCs, the ones de-fined by ITU-T may appear in relevant Recommendations, and those definedby other organizations should be registered with IANA (Internet AssignedNumbers Authority). The definition of which Packages are supported is en-sured by the use of Profiles. A profile is identified by a name (IANA registered)and a Version. The profile is a document containing a description of the op-tions available for a particular application. The only mandatory elements arethe Name, Version and a summary of the profile. The profiles are negotiatedby the ServiceChange command.

3. Performance.

(a) Bandwidth consumptions. The H.248 specification supports binary andtext encoding. For the binary encoding BER (Basic Encoding Rules) andASN.1 (Abstract Syntax Notation number One) [63] format is used. Forthe text encoding the Augmented Baur-Nackus Form (ABNF)[29] in itsform verbose and compact. The message sizes can vary depending of thequantity of transactions, the number of contained commands per trans-action, the type of command and mentioned descriptors. For making anobjective measurement, we can base the measurements on a representa-tive call flow, such as the one provided by RFC 3525 [42]. The Erlangproject Megaco Benchmarking [81] is based on those messages and addedsome additional data. The results referring to the message size are sum-marized in Figure 7.3. There, we can see the difference between binaryencoding and text encoding size, and the dependency on verbose modeor compact. The size of the text encoded compact messages are simi-lar to the binary messages in size. The H.248 constructions will growproportionally to the number of Transactions and Commands in a sin-gle message, as well as with the number of descriptors deployed in theCommands. Logically the text verbose encoding will be larger, althoughthe compact mode could be even smaller than the binary counterpart inmany cases.


H.248 Messages Size

0

100

200

300

400

500

600

msg01a

msg01b

msg02

msg03

msg04

msg05

msg06a

msg06b

msg07

msg08a

msg08b

msg09

msg10

msg11

msg12

msg13

msg14

msg15

msg16

msg17

msg18

msg19

msg20

msg21

msg22a

msg23a

msg23b

msg23c

msg23d

msg24

msg25

msg30a

msg30b

msg30c

msg30d

msg51a

msg51b

msg51c

msg51d

msg51e

msg51f

msg51g

msg51h

msg52

msg53

msg54a

msg54b

msg54v

msg55

msg56

msg57

msg58a

msg58b

H.248 message identifier

Byt

es

Full Text Compact Text ASN.1 BER

Figure 7.3: H.248 Message size for a Representative Call Flow, based on a benchmarktest performed by the Erlang project in [81].

(b) Delays. As it was mentioned, H.248 implements several timers to beable to handle the processing and transmission delays. The transmissiondelays are influenced by the type of transport and protocols chosen tocarry the H.248 messages. These kind of delays are out of the scope ofthis work. The processing delays are the sum of all the delays from themoment when a node receive a message with a transaction request un-til it sends back another message replying to the transactions requested.Since the resource handling and switching in the nodes are also out ofthe scope of this work, we will concentrate on the encoding and decodingdelays. The encoding of the messages are strongly depending on the al-gorithm, libraries and hardware used to run the encoder/decoders. Thismakes it difficult to establish a comparison point between several proto-cols. Nevertheless, based on measurements done by a commercial H.248encoder manufacturer[76] some estimate can be assumed, based on themessage flow sequence already presented for message size. Figure 7.4 il-lustrates the encoding and decoding delays for different type of binaryH.248 messages provided by the tests performed using OSS Nokalva li-


braries. The average encoding time is 11.8 microseconds, meanwhile, thedecoding time was 13.4 microseconds [76].

H.248 Processing Delay for Binary Encoding

0,0

10,0

20,0

30,0

40,0

50,0

60,0

70,0

80,0

msg01a

msg01b

msg02

msg03

msg04

msg05

msg06a

msg06b

msg07

msg08a

msg08b

msg09

msg10

msg11

msg12

msg13

msg14

msg15

msg16

msg17

msg18

msg19

msg20

msg21

msg22a

msg23a

msg23d

msg24

H.248 message identifier

Mic

roS

eco

nd

s

Encode Decode Encoding-Decoding

Figure 7.4: Encoding and Decoding measurements for H.248 binary encoded mes-sages based on a benchmark test performed by OSS Nokalva in [76]. (The messagesizes are the same as for the corresponding messages shown in figure 7.3 for binaryencoding)

(c) Load Variation. The time deployed by a gateway to process the H.248messages depends on the message requirement from the gateway physicalresources. Normally, the processing of the messages is counted in hun-dreds of milliseconds, and the variations are according to the number ofconnection/disconnections needed, the type of stream functions requestedand the initialization of their hardware, the quantity of terminations in-volved in the messages and quantity of functions already reserved. Thosefigures have a direct relation to the quantity of PendingTransactions mes-sages sent (since the replies can be delayed) and the way how the repliesmay be grouped together creating bigger messages. Finally it is up to theapplication to decide if the replies are grouped into one message or sent


in separate ones, what kind of operations will be allowed and which oneswill be rejected as not supported, and to go on successfully with the callflow or report a failure. The entities handling the protocol must be readyto handle different types of loads. Whereas a message could be processedimmediately after it was received or empty fast overflowed queues threat-ening the system to collapse. Some already mention avalanche preventionmechanisms are part of the protocol itself but they are mainly targetingthe restart or the applications and not “in service” overload situations.One item worthy of mention is that the current traffic models used forH.248 may not be anymore valid in the case of using it for Media ServerControl. The reason is the different characteristics of the traffic deployingthe services of the node. For the MGW traffic, the burst of H.248 mes-sages happens at the beginning and at the end of the call session. The callsetup ensures to provide to the UE with all the functions needed from thebeginning and just ready to be activated/deactivated. This creates a firstburst of messages. Then later, in the call release phase, another burst ofmessages is created to release the resource and initialize the applicationentities. For media control, this might be still true, but one can expectmuch more interaction with the UE during the “established phase” thanbefore. The reason is that a UE can request services during this phase,for example: playback of different videos, recording of audio, switchingbetween video streams, switching between audio streams, etc.

(d) Error Handling. H.248 messages are not acknowledged. The nodes areaware of the message arrival when they receive messages referring to thetransactions contained in the sent message (replies or pending). The ap-plication handling the protocol has to be aware of the time elapsed sincean outgoing transaction took place and react accordingly if the trans-action is not acknowledged in any way. Basically, transactions whichare not replied to a certain period of time, are resent in another H.248Message. For this reason it is important for the protocol to keep synchro-nization between the two nodes, since they are highly coupled and theinterworking between the master and slave requires a precise and detailedknowledge of the capacity and capabilities of the controlled node. Whenthe synchronization between the nodes is lost, for example because wronghandling of unexpected events, a bug in the applications or overloads, theprotocol provides Audits for a re-sync on the termination level or for thewhole node. In case of major failures, restarts of the nodes can have sev-


eral levels (warm restart, cold restart, etc) or disabling of services whichare in failure. Rather, the protocol itself provides the tools to handle thistype of error, but not really an automatic way to detect them and to actaccordingly since those details are left to the handling application to takecare of. The protocol provides also an error descriptor which indicateswith a code (and even a text) the error risen during the processing ofa command. More errors could be defined for new packages and theyare part of the package definition. The H.248 specification also providesconsiderations to avoid restart avalanches when a master node or severalslaves restart. The re-registration of the nodes could cause an avalancheof initialization ServiceChanges that could cause message losses and net-work congestions during a critical time as it is the network restoring. Arandom value is used to activate a timer before sending the power-onindication when following a restart procedure already established.

4. Extensibility. The protocol was meant to be extended by the means of pack-age definitions. 3GPP has registered several packages to assure the inter-compatibility between vendors in the 3GPP networks. The packages have tobe registered with IANA, and there define extra properties, signals and errorcodes handled by the new package. Some issues related to encoding couldlimit the extensibility, such as the case of IPBCP tunneling, which can notbe encoded in text mode because of character incompatibility with the H.248text encoding.

5. Scalability. The ITU-T H.248 recommendation mentions the possibility ofdeployment of Virtual Media Gateways, each logically independent but maybesharing the same node resources. Each Virtual Media Gateway could receiveits own transactions and process them independently of the transactions sentto the other Virtual Media Gateways. The handling of resource overloadsare left to applications and pointed out by the deployment of the correcterror codes. The network congestions are not handled by the protocol itself,since it is expected to be part of the duties left to the transport layers andapplication congestion detection. The connection associations are assumed tobe directed only between the slave and the master node, which implies thatthe routing between the two nodes is also handled by the transport layers andthere is not done any type of load balancing, resource discovery or servicesreallocation other than those provided by audit means or ServiceChange. Themedia connections should not be related to the signaling connections since


the signaling establishes the media connection between different entities otherthan the master-slave. The avalanche restart effects are already mentioned inthe Error Handling bullet of this section.

6. Security. The protocol assumes a inclosed connection between the master andthe slave entity . Security is assumed to be provided by the lower layers andencryption. The recommendation just addresses the security for IP networksand specifies the deployment of IPsec to provide the connection protection.The recommendation also specifies the deployment of encryption and sourceIP header analysis of the media packages to avoid “uncontrolled barge-in”attacks and eavesdropping. Those mechanisms could delay the call set-up sincemore data needs to be available, such as encryption keys or media destinationaddress, before the security mechanism can be used. By itself, H.248 does notimplement any type of protection for eavesdropping, Denial of Service Attacksor spoofing.

7. Interoperability. H.248 has been openly criticized because its interoperabilityscope is limited to 3GPP networks and even in them it has shown some in-compatibility between vendors [70]. H.248 it is not used in other standardizednetworks other than 3GPP since its scope has been mainly in the Media Gate-way control. 3GPP is expecting to utilize the experience obtained from thedeployment of the protocol and apply the same principles used for the MediaGateways in the early stages of the 3GPP IMS networks. Besides, H.248 pro-vides with mechanisms during the initialization phase to agree on the protocolversion in use, the encoding type, and the profile supported (which basicallydefines the packages supported as well).

8. Development. H.248 has been extended to provide more services needed bythe media resource control. A third version of the protocol was already re-leased by ITU in September 2005 with several improvements to the core pro-tocol. H.248.19 “Decomposed multipoint control unit, audio, video and dataconferencing packages” [65] was also released. 3GPP has already started thespecification of the Mp interface based on H.248 [9] which was withdrawn onMarch 2007.

7.3.2 Session Initiation Protocol (SIP)

The Session Initiation Protocol was developed by the IETF as the result of merg-ing two IETF protocol proposals targeting session inviting. It has been defined


in RFC 3261 [86] and become a widely used standard in the multimedia productsthat handle conferences, multimedia resource sharing, presence, etc. 3GPP has alsotaken into use the protocol for several of the IMS interfaces (see section 2.3). Anintroduction to SIP is required, since some SIP extensions have been proposed forMedia Server control, and the other analyzed protocols deploy SIP for transport andsession initiation as well.

1. Architecture specifics. SIP operates in the application layer of the OSI model.The transport of SIP is meant to be UDP, TCP and SCTP, and it is basedon the Hypertext Transfer Protocol (HTTP) deploying the same client-servertransaction model. The client produces requests that are received, processedand replied to a server. In contrast with H.248 that uses a master-slave model,the client-server model allows a more free connection model, where the clientcould contact different servers depending of the request that wants to be ex-ecuted instead of addressing only one entity as is done in the master-slavemodel. SIP provide interoperability by incorporating methods for negotiatingthe extensions that will be used in a session.

SIP defines User Agents (UA) as entities that interacts with the users. TheUser Agents can be User Agent Client (UAC), which sends the requests to aUser Agent Server (UAS), which receives the requests and replies to it.

Other SIP entities are the proxy servers. They act as intermediaries behavingas server and client to execute a request on behalf of other clients. The typesof SIP proxies are:

� Call Stateful Proxies. This type of proxies keeps information of the sessionfrom the beginning until its end. They are always in the path used for theSIP message exchange between two users. They need to know all the SIPtransactions happening during the session. Normally this type of proxiesare found close to the edge of the core network.

� Stateful Proxies. Also called transaction stateful proxies since the trans-action is their only concern. Basically they store state related to a giventransaction until its ends.

� Stateless Proxies. They do not keep any state, by only forwarding therequest and replies to the next hop. They are found mostly close to thecore of the network.

2. Functionality. SIP was made to handle multimedia sessions and normally theparties participating in a SIP dialog keep a kind of peer-to-peer relationship.


In its basic operation SIP provides session establishment, session modificationand session termination. The sessions can be totally new or already createdsessions. The protocols allows the users to join or leave these sessions as wellas negotiate the operative parameters of the session. Based on the negotiationresult and the willingness of the invited party of participate in the session,a session is established. To negotiate the multimedia parameters used in thesession, some session description protocol might be needed to be distributed aswell. The Session Description Protocol (SDP) is usually taking this function,although a different protocol can deploy SIP to reach the interested parties.In that sense, SIP is used to distribute session descriptions among potentialparticipants [23]. During the session establishment SIP will keep the partiesinformed of the progress of the setup and allow them to request modificationsto an already established session. Finally, the protocol will provide a gracefulrelease sequence where the parties can be explicitly aware of session termina-tion. SIP provides the connectivity between the parties and in principle doesnot intervene once the session has been established.

Request method Description

INVITE Invites the parties to participate in a session. It also contains the de-scription of the session.

ACK It acknowledges the reception of the final response to an INVITE. Itfacilitates the three-way handshake implemented only for the INVITEmethod in part to avoid unsynchronized parties on session establishmentand enables the implementation of fork proxies. It might contain sessiondescriptors as well

OPTIONS It queries a server party about its capabilities, such as methods sup-ported, session description protocol, message encoding, etc.

CANCEL It requests a cancellation of a pending transaction

REGISTER It is used to inform a server (named Registrar when supported by thismethod) about the location of the client

BYE It indicates a user abandoning a session. In case of a two-party session italso terminates the session in contrast with a multi-party session wherethe session continues after the user has left

Table 7.3: SIP Request Methods from the core specification[23]

The request and reply together is known as a SIP transaction. In fact, onerequest can generate several replies and still be considered one transaction.


The reason is the existence of provisional responses and final responses. Theprovisional responses uses a status code in ranges from 100 to 199, whilethe status codes from 200 to 699 are final. Table 7.3 shows the SIP requestmethods and their functions from the core specification, and table 7.4 showsother methods defined in the extensions.

Request method Description

INFO It is used to transport mid-session information that does not affect thestate of the session (for example, billing information)

SUBSCRIBE It is used to declare the user interest in a particular event and the statusof a service session. The use of SUBSCRIBE will trigger the use ofNOTIFY

UNSUBSCRIBE It is used to terminate the monitored session started with SUBSCRIBE

NOTIFY It is used to provide information from a subscribed session

UPDATE Allows a user to update the parameters of a session without impactingthe state. The request can be sent even when an answer to an INVITEhas not being provided.

MESSAGE It is used to provide Instant Messaging (IM) between the parties of aninitiated SIP dialog. The body of the MESSAGE method has the formof MIME body parts

REFER Defined to provide session transfer functionality, by allowing one SIPentity to instruct another to perform an action

PRACK It plays the same role as ACK but for provisional responses, however ithas its own response in contrast to ACK

PUBLISH It indicates publication of any event state for which there exists an ap-propriate event package

Table 7.4: SIP Request Methods from extensions to the Core specification [23]

The general format for the SIP messages consists of:

(a) A start line. In the case of the request, the start line is a request linewhich contains three elements:

� Request method, that can be any of the ones already mentioned intables 7.3 and 7.4.

� Request-URI (Uniform Resource Identifier), indicating the next hopto which the request has to be routed.

� Protocol version, indicating the used version of the protocol (for thecurrent version: SIP/2.0)


In the case of replies, the start line is known as “status line”. The statusline contains also three elements:

� Protocol version, same as the requests.

� Status code, referring to the integer from 100 to 699 describing thestatus of the transaction.

� Reason phrase, which describes the status code in verbose stringmode.

(b) One or more header fields. It provides information about the requestor response and about the body if it contains it. The different headersdefined in the core SIP specification are contained in table 7.5.

Accept Content-encoding Max-forwards RouteAccept-encoding Content-language MIME-version ServerAccept-language Content-length Organization SubjectAlert-info Content-type Priority SupportedAllow Cseq Proxy-authenticate TimestampAlso Date Proxy-authorization ToAuthorization Encryption Proxy-require UnsupportedCall-ID Error-info Record-route User-agentCall-info Expires Require ViaContact From Response-key WarningContent-disposition In-reply-to Retry-after WWW-authenticate

Table 7.5: SIP headers defined in the Core Protocol

(c) An empty line. It separates the headers from the message body.

(d) A message body (optional). Usually the SIP bodies are session descrip-tions but it could be any other type of object as well. For SIP, the bodycontent is transparent and it is not examined. A SIP message can containseveral bodies as well.

Any SIP application will assume that another SIP application can at least com-municate by using the SIP core protocol. However, SIP is a flexible protocolable to be extended following the mechanism described in the protocol specifi-cation. Such extensions are then negotiated during the session establishmentby the means of the core protocol.

3. Performance


(a) Bandwidth consumptions. When SIP was designed, the bandwidth con-sumed by the SIP signaling was considered negligible, since the mediawas supposed to use the same link as the SIP signaling. But in the mediaservers case, the bandwidth is a resource that has to be taken care of.This might be a dimensioning issue that can affect the number of simulta-neous users that a node can serve. Relative to this, message compressionis a possible option but brings a trade-off with processing capacity, sincethe compressed messages need to be decompressed to be able to processthem. A study giving results about SIP compression can be found in [66].Since SIP deploys full verbose text messages, the messages can be fromhundred bytes to several kilobytes.

(b) Delays SIP performance has being evaluated in several studies. Eyersand Schulzrinne did it from the point of view of Internet telephony whilecomparing SIP with H.323 [37]. In the scope of this work, some resultsare available for delays and processing power needed from Cortes et al.[28]. Figure 7.5 is based on their measurements and shows the processingdelays for different proxy implementations. The proxies differ in the li-braries used for string processing and memory allocation, threading modeland data storage. They had also provided some measurements about thequantity of calls that every proxy can handle according to their model.Those results are not shown in this work because they are strongly hard-ware and traffic model dependent.

(c) Load Variation. The load characteristics expected for SIP in a mediaserver are very much similar to the ones explained for the H.248 protocol.Basically, the peaks in the signaling are present during the setup of thecall, since that is when the session parameter’s negotiation is taken place.The SIP dialogs are very simple to be terminated and they do not produceas much signaling as the H.248. Since SIP has being designed to workwith non-reliable protocols such as UDP, some retransmissions can beexpected if the responses are not delivered on time or if they are lost.Also, the SIP extension PRACK can be used for acknowledging non-finalresponses, which can increase the signaling load per user as well. Byimplementing a broker function node that works as intermediate betweenseveral media servers and several application servers, it is possible tocreate some kind of centralized control that balances the server loads andredirects the request to the appropriate servers according to their knowncapabilities [72]. The broker would then receive all the requests directed


to any media server from any application server, and since it is a non-standardized node some proprietary implementations and optimizationmay be deployed for load handling.

(d) Error Handling. SIP provides different responses which points to severalerrors depending of the nature of them. The application must processthem and act according to the error reported. The errors due to datatransmission are handled by the transport layer protocol in the case ofreliable transport or by timer based retransmissions from the User Agentin the case of unreliable. In the case of lost synchronization because ofnode restarts or link failures, SIP do not provide any recovery mechanism.The applications have to do the work of recover the call state or releasethe ongoing sessions. Also, there is not any protection against a possibleavalanche registration effect after a node restart.

SIP message processing delay for 4 Proxy implementations

0

200

400

600

800

1000

1200

1400

1600

1800

2000

327 389 423 467 499

SIP messages size

Mic

roS

eco

nd

s

Proxy A Proxy B Proxy C Proxy D

Figure 7.5: SIP Message processing delay of 4 Proxy implementations. Source: [28]

4. Extensibility. SIP is a modular and extensible protocol. Special needs aresolved by defining extensions. The extensions are negotiated between User


Agents using the “Require” and “Supported” headers. The extensions that arecommonly supported are possible to use, and the core protocol functionalityhas always to be supported by all the User Agents. This gives the possibilityof fall-back and ensures interoperability.

The RFC 4485 “Guidelines for Authors of Extensions to the Session InitiationProtocol (SIP)” [85] provides some design principles for the definition of SIPextensions. The extensions have to be registered with IANA and they mightrequire approval from the IETF, especially when broadly used. Several exten-sions have been defined already for SIP and are widely adopted in almost allSIP implementations.

5. Scalability. The connection model of SIP is client-server as was already men-tioned. The characteristics of the connection are very similar to a peer-to-peerconnection, but still with the client-server approach of transactions with re-quest and response. The connection between two or more User Agents isknown as the SIP dialog, since in general the User Agents exchange the rolesof server and client quite often. The nature of this connection depends onthe transport layer used for SIP, for example if it is possible to use encryp-tion, message retransmissions or congestion detection. By following the IETFInternet paradigm, SIP is meant to use other protocols to address needs dif-ferent that its main function of describing a session. And although it is notthe main responsibility of SIP to handle issues like security, or congestion, etc,it is affected by the performance of the lower layer protocols that take care ofthese.

One way used by the SIP server implementations to handle a high load ofsignaling in a node is to store sessions on disk to avoid that hardware problems(restarts, lost of connection, etc) cause loss of synchronization in the on-goingsession. This is a clear disadvantage for the call setup time, since the disk-based storage is slower than memory based storage.

The redirection of requests to SIP servers by broker functions and load bal-ancers is also becoming a solution that has gotten a lot of attention on net-works operating with SIP servers. These entities recognize the load in a poolof servers and knows also the different capabilities of each of them. In this way,they forward the session to the entity which they consider capable of handlingit in both terms: capabilities and/or load level.

6. Security. SIP is a protocol designed to be used over the Internet. It hasalso inherited the authentication mechanisms used by HTTP to authenticate


a user and S/MIME (Multipurpose Internet Mail Extensions) [39] to provideconfidentiality and message integrity. The end-to-end security is trusted tobe provided by lower layers with protocols like: IPsec [67] and TLS (Trans-port Layer Security) [30]. For IMS, an extra feature has been defined named“Topology Hiding”. Since some SIP messages contain sensitive informationfrom one operator such as the addresses of entities on the network or thenumber of entities, then an operator may choose to hide this information tominimize the risk of attacks. This is done by encrypting the headers of theSIP messages as they leave the network and to decrypt the messages whenthey enter the internal network. This practice is not supported by IETF butjudged necessary by 3GPP.

Without any other protocol support, SIP is vulnerable to man-in-the-middle,Denial-of-service and Eavesdropping attacks.

7. Interoperability. All the SIP User Agents have to be compliant with the coreSIP protocol. In this way, a basic level of interoperability is ensured. For moreadvanced features a mechanism to negotiate the different extensions that aresupported by the UA is provided. In that way the client and the server candecide the best way to negotiate their session. SIP is also text based andreuses many characteristics of well known Internet protocols: HTTP, SMTPand MIME. This characteristic makes it easy to share implementation codewith the code deployed to implement those protocols for other services (weband e-mail).

8. Development. Presents the future trends and state of the protocols at thismoment. A lot has been said about the SIP future and development direction.The protocol flexibility and the property of easily incorporating extensions hashelped SIP to gain momentum a reputation inside the packet based telecom-munications area. The direction of development in the beginning was to ensurethe harmonized coexistence of SIP and the rest of the IETF protocols. Partof the SIP development are also the different SIP extensions and the proposalof formal methods to use SIP in specific situations and even as transport forother protocols that use part of the SIP provided infrastructure.

The current development has started to get closer to the users, where theuse of SIP in P2P networks, quality-of-service assurance, lawful interceptionand emergency services (911-type) are subject to analysis. Other issues, suchas privacy, protection against DoS attacks, and network access handover arealways in consideration.


7.3.3 Media Sessions Mark-up Language (MSML)

At the moment of writing this work, MSML is being defined by an Internet draft[87] and therefore it is not finalized yet. However, the first version of the draft wasreleased in June 2003 and it actually is comprised of two separated drafts: one forMSML and another one for Media Object Markup Language (MOML). These twodrafts were merged in February 2006 into the current draft for MSML.

MSML was developed to provide a way to control media servers by using SIPas transport. Still, the latest versions of the MSML claim that it is a transportindependent protocol.

1. Architecture specifics. The MSML transactions are triggered by events in theapplication domain that are required by the services provided by the mediaservers. MSML provides an abstraction of the media server called Media ServerObject Model. This model assumes that there exists one single control contextwithin a media server. This control context is aware of the state of all mediaobjects and media streams within the media server. The objects are endpointsof one or more media streams. They are four types: network connections,conferences, dialogs and operators (see table 7.6).

The single control context receives and processes all MSML requests and allevents generated internally by media objects and sends them to the appro-priate SIP dialog. As was already mentioned, MSML claims to be transportindependent, although the only transport defined at the moment of writingthis work is SIP. SIP is deployed first to establish the session and also to pro-vide third party call [84] control to create sessions on behalf of end users. TheIETF draft presents two alternative ways to use SIP to transport MSML: oneis by deploying SIP INFO messages and the other is using the SIP ControlFramework [17]. VoiceXML can be deployed in MSML for the dialog descrip-tions as well.

2. Functionality. The MSML request may carry several actions (elements) tobe processed or a single command. The multiple elements request must beprocessed in the sequential order in which the elements are sent in the re-quest. Every request is treated as a simple transaction, and a media servershould make sure that it has enough resources to carry out the transaction be-fore executing the request. The execution is expected to happen immediately,meaning that often the execution of elements that can take long or unpre-dictable quantities of time are forked. When the fork is successful, the nextelement is processed. The transaction must be stopped when an error occurs


Object Description Example

Network connection Abstraction representing the media stream pro-cessing resources involved in a RTP terminationof a call. They are instantiated through SIP

Full duplex audiostream, Multimediaconnections

Conferences Represents the resources and state informationrequired for a single logical type of media mixin a conference. Conferences are instantiated bythe <createconference> element of MSML.

Audio , video

Dialogs Dialogs represent automated participants. Theyare very similar to network connections froma media flow perspective although they are in-stantiated by MSML instead of SIP by the <di-alogstart> element.

Interactive messages,tones, recorder

Operators They are functions used to process a mediastream (filtering, transforming, adapting, etc).They are divided into unidirectional or bidirec-tional, where the difference is in the number ofinput and output streams. They are instanti-ated implicitly when the streams are created ormodified by the elements <join> and <modifys-tream>

Unidirectional: gaincontrol, tone filtering.Bidirectional: Muxers,moderated muters

Table 7.6: MSML object classes

during the execution of an element. The processed elements are not rolled backand the client is responsible for taking the necessary actions according to thesituation. The value of the attribute of the last processed element must be re-turned with the error response. If the errors happens during a forked process,then an asynchronous event with an error should be issued. The transactionresults are returned as part of the SIP request response, indicating the successor failure of the transaction.

The objects are referenced by using identifiers. The identifiers are composed ofone or more terms which specify an object class and the names of a specific in-stance within that class. The objects are assigned to identifiers when they arecreated. Some classes of objects such as conference and network connectionscan exist independently on a media server to provide services that are goingto be used in future connections. The dialogs provide services to independent


objects, either by acting as participants of a conference or interacting with aconnection. Therefore the dialogs are depending upon the existence of inde-pendent objects, which is reflected in the composition of their identifiers. Theoperators on the other hand are also depending on other objects, but they arenot represented by any identifier, since they are used to modify the media flowbetween other objects. The relationship between MSML objects is presentedin the example of figure 7.6.

Network Connection

Dialog

Operator

Dialog

Conference

Media Server

RTP

Figure 7.6: MSML Object classes’ relationship

The identifiers allow every object in a media server to be uniquely addressed,but they can also be used to address multiple objects by using wildcards. TheMSML elements can restrict the class of objects which are valid in a givencontext, even when the identifiers share a common syntax.

The language structure of MSML is based on a package scheme and a profilescheme. “A package is an integrated set of one or more XML schemes thatdefines additional features and functions by new or extended use of elementsand attributes.”[87]. MSML consists of a core package that basically providesa structure skeleton and does not support any specific feature set. The func-


tionality is provided by additional packages that rely on the core package.Figure 7.7 shows the hierarchy between the MSML core packages, in additionthe description of the mandatory and conditional mandatory packages can beseen in table 7.7.

MSML Core

Dialog Core

Conf Core

Audit Core

Dialog Base Dialog Transform Dialog Group Dialog Speech Dialog Fax DetectDialog Fax

Send/Receive

Audit Conf Audit Conn Audit Dialog Audit Stream

Figure 7.7: MSML Core Package Hierarchy

Since the applications and devices might not support all the available function-ality of MSML, a description of the supported set is needed to easily identifythe supported features. This is provided by the profile scheme. With theprofiles it is possible to point to a subset of a package functionality that isrequired or supported by a party. For example, an audio only announcementsprofile that will not support video announcements.

The conferences using MSML have a mixer for every type of media that issupported in the conference. The mixer description elements are the onesdescribing how the multiple inputs are combined into a single logical output.The media streams are created when objects are connected together. Everyobject has at least one input and output for each type of media that it supports.Therefore the connections between the objects represent the media stream


Package Name Description Mandatory

MSML Core package Minimum framework which must be imple-mented to support additional core packages

Full mandatory

MSML ConferenceCore package

Basic and advanced multimedia and audio con-ference package. Used if conferencing is used.

Conditional

MSML Dialog Corepackage

Dialog core package implemented for any dialogservices. The systems supporting only confer-encing may omit support for MSML dialogs.

Conditional

MSML Dialog Basepackage

Used if the Dialog Core package is in use. Conditional

MSML Audit Corepackage

Specifies the framework within which additionalaudit packages are supported. It must be imple-mented to support auditing services.

Conditional

MSML Audit Con-ference package

For auditing Conference, Conference Dialog andConference Stream

Conditional

MSML Audit Con-nection package

For auditing Connection, Connection Dialog andConnection Stream

Conditional

MSML Audit Dialogpackage

For auditing Dialog. Must be used either withMSML Audit Conference Package or MSML Au-dit Connection Package

Conditional

MSML Audit Streampackage

For auditing Stream. Must be used either withMSML Audit Conference Package or MSML Au-dit Connection Package

Conditional

Table 7.7: MSML mandatory and conditional packages

connections.

3. Performance.

Since MSML is based in practice on SIP, its performance is not expected toovertake the SIP analyzed performance in terms of bandwidth deployment andprocessing delays. There can even be expected an increment of the processingtime and memory consumption, because the type of monolithic media servercontext additional to the MSML and voiceXML (in case of being used) extraparsing. The control plane of the server may become a limitation for themedia server sessions handling capacity in this case. The MSML Internetdraft does not mention any special load control features integrated into theprotocol, but relies on the lower layers to provide them. Some control could


be implemented by an application through inferring the load level on the errorcodes provided. The error handling is basically copied from SIP, adding thepossibility of reporting the errors produced by forked executions by the meansof asynchronous events.

4. Extensibility. The creation of new packages is the primary way of extendingMSML. Such package extensions should follow the presented hierarchy andfollow the core framework. MSML Packages are assembled together to forma specific MSML profile that is shared between different implementations.A MSML script must include references to all the schemes that define thepackages used by the script. According to the MSML internet draft, the MSMLpackage profiles must be published in standard documents dedicated to MSMLpackage profiles, which are different from the MSML specification. The profilesare not registered with IANA. On the other hand, the Control Package nameshave been planned to be registered, as well as the XML schema associated.It is intended the addition of future registration with IANA of the packages.Auditing of supported MSML packages and profiles is not specified at themoment.

5. Scalability. MSML does not have any special handling specified for overloadsituations. In case of connection congestions, they are either left to the appli-cation control or to the protocol transport to solve and recover from them.

Since MSML follows a client-server connection model, the implications is thatmany controllers could use the resources of one Media Server. This mightcomplicate the hardware allocation logic of the Media Server and some otherprotocols may need to be deployed to provide among others authentication,policing, capacity and capabilities handling.

The protocol assumes a monolithic context that handles all the pool of avail-able resources and the state of all the connections. This concept of a mono-lithic context might in practice limit the capacity and not be very scalable,if a modular and distributed implementation is not deployed. This kind ofimplementation for monolithic context is usually complex and might involveperformance issues on the process communication level.

6. Security. The Internet draft of MSML mentions a security consideration wherethe security is a function of the MSML invoking protocol or language. Thedefined security considerations for XML in RFC 3023 [75] are also consideredapplicable. This means that in the case of the SIP protocol transport, the


already mentioned security issues are valid for MSML as well. In addition tothat, the XML inherent security risk from the package dependency to fetchfrom sources with unknown security could increase the risk associated to ma-licious changes. For example, changes in the master templates can force theexecution of unintended commands or information exposure.

7. Interoperability. The advantage of deploying SIP as transport protocol givesMSML the flexibility of reusing the SIP stack to provide control of the con-nections to a certain extent. Also, the client-server architecture is very flexibleand present in many different type of networks. These two features mightgive some leverage to MSML to be deployed in different network contexts andnot only the IMS, where SIP has being deployed already. This is one of themain claims of the protocol inventors that see the widely deployment of SIPas an important trend to be follow and complemented with services providedby MSML for the media control.

8. Development. The protocol is still evolving and being specified in the IETF.Some products have been released incorporating early versions of the protocol,but in general the community has not given lot of attention regardless of beingopen and free of patent considerations. The main claim is the similarity toH.248 functionality, since it basically ports the main H.248 functionality intoa XML compatible format that can be easily transported over SIP.

7.3.4 Media Server Control Mark-up Language (MSCML)

The Media Server Control Mark-up Language has being specified in the informa-tional RFC 4722 [32] in IETF. It was driven together with the Network Announce-ment (NETANN) protocol specified by RFC 4240 [19] and called Basic NetworkMedia Services with SIP. Such services include network announcements, user in-teraction, and conferencing services. NETANN was found insufficient for advancedconferencing and IVR handling. Therefore, SnowShore (today Dialogic) authoredand drove MSCML in opposition to MSML driven by Convedia (nowadays Radisiys).MSCML is guaranteed to be royalty free although it is covered by patent protectionunder normal conditions.

1. Architecture specifics. SIP has been defined as the transport protocol forMSCML. The Media Servers get the MSCML command by the means of SIPINVITE and SIP INFO messages.

The abstraction level of MSCML is high enough to provide the application


layer with constructs and primitives which deal with the required conferenceservices with single commands with a semantics that translate the implemen-tation details to the Media server, in contrast to H.248 and MSML, since theykeep tight control over the Media Server actions. The connection model is apeer to peer relationship in a client-server association.

The deployment of SIP enables also the deployment of the native SIP servicelocation and load balancing. The Media Server must support SIP message bod-ies with the MIME type multipart/mixed. The MSCML response should beplaced in the final response to the SIP INVITE used to transport the MSCMLrequest. In the case of using SIP INFO, the only allowed final response isa 200 OK, consequently, the Media Server sends the MSCML response in aseparate SIP INFO request. Only one MSCML body must be present in aSIP message, and only one MSCML request or response may be contained ina MSCML body. Also, MSCML does not support provisional responses, onlyfinals. However, a request may end in multiple notifications. The request mayinclude uniquely defined client ID attribute to provide a mechanism to matchrequest and responses.

For basic conferences, the process is done following the procedure described byRFC 4240 [19] where the first INVITE to the media server with a unique clientID creates a conference and it is based on SDP. The advanced conference, onthe other hand, requires that the first INVITE contains a MSCML“<configureconference>” payload that extends the number of session parameters which isnot possible to express with SDP. The resulting SIP dialog created by theMedia Server Controller is called “Conference Control Leg” and the conferencewill exist during the lifetime of this leg. The Media Server does not expectany RTP stream associated with this leg. Figure 7.8 shows an example of aadvanced conference model, and figure 7.9 presents a graphical view of theMSCML connection model.

2. Functionality. Analyzes the different functions and services provided by theprotocols. There are two classes of MSCML functionality. The first includesprimitives for advanced conferencing (see table 7.8) and the second providesprimitives for IVR (presented in table 7.9 ).

The advanced conferencing is available when the Conference Control Leg hasbeen created. Once the conference has been created, it can be manipulatedby the “client” as a whole, a particular leg or a team by issuing commandson the associated SIP dialog. The support for video conferencing is implicitly


MRFAS

Private URIMSCML Session

UE

UE

UE

Public URISIP Session

RTP

RTP

RTP

Figure 7.8: MSCML Advanced Conference Model

supported in the form of video switching. The video of the loudest talker issent to the conference participants except to the talker. This at the same timegets the video of the immediately prior loudest talker. The transcoding ofthe media should be provided by the Media Servers, and also ensure that themedia sent is supported by the participants. The conference events are sentmainly to the Conference Control Leg, and the client can subscribe to activetalker event reports received in that leg. Finally, a conference is terminatedwhen the client issues a SIP BYE request in the dialog representing the ControlConference Leg. The media server replies with 200 OK and issues a SIP BYErequest to all the other legs in the conference.

The IVR services provided by MSCML are:

� Basic interactive voice response functions

� Playing of announcements

� Collecting of DTMF digits

� Recording


Conference Control Leg

SIP Conference Leg

Sip Conference Leg

Media Server

RTP

Sip Conference Leg

RTP

RTP

SIP-MSCML

MSCML Relationships

SIP-MSCML

SIP-MSCML

SIP-MSCML

Figure 7.9: MSCML Media Server Connection Model

The MSCML IVR request should be sent in a SIP INFO request, and theyare not allowed in INVITES. The participant leg that will receive the IVRcommands should be configured with a mixmode = “parked” (using <config-ure leg> for example) isolating the input and output of the participant fromthe rest of the conference. An exception of this is the digit collection andrecording. For this functions it is not necessary to configure the mixmodeas “parked”. The service indicator for IVR must be set to “ivr” in the de-ployed URI, in contrast to “dialog” used by VoiceXML. The media servers donot queue IVR requests. If a second IVR request is received when the MediaServer is processing the first, the first request has to be stopped and the secondrequest executed. The Media Server will reply with a response to the request,once it has been completed or stopped.

3. Performance. The MSCML performance will be very close to the analyzed SIPperformance. The reason is the total dependency of the protocol on SIP. Theprotocol goal is to provide an application interface, and therefore it does not


Request method Description Attributes

<configure conference> Used to create an ad-vanced conference whenthe control conferenceleg is created and toprovide new input for acreated conference.

reservedtalkers (optional if other than cre-ating the conference control leg): Providesthe maximum number of participant legs tobe allocated for the conference.reserveconfmedia (optional): To controlthe allocation of resources for playing to orrecording from the conference.

<configure leg> Provide properties forthe conference legs to bemodified by the client

type (optional): values are “listener” and“talker”, indicates to the server the inclusionof the leg in the output mix.dtmfclamp (optional), if yes, takes DTMFdigits from the input audio.toneclamp (optional), if yes, removes tonesfrom the input audio.mixmode (optional), valid inputs are: “full”,“parked”, “mute”, “preferred” and “private”

<configure team> Configures the partici-pants as members of ateam within a specificconference. It is a childof <configure leg>

id, it is the unique ID of the leg being modi-fiedaction, it can take the values “add”, “delete”,“query”, and “set”

Table 7.8: MSCML Request Methods for advanced conference

interact on the stream level for the media control. That could indeed bringsome improvements in the call setup times, resource reservation and modifi-cation and processing time. The high-level interface proposed by the protocolfoments the deployment of proprietary solutions that are driven by high-levelinstructions, giving large freedom to the implementation of the Media Serverto process the request in the preferred way, as long as the result provided is theexpected. There are not public available measurements of the MSCML com-mercial server performance, and as it has been stated they might be stronglydependent on the implementation. The error handling is rather simple also,because the high level of the requests and the architecture give enough flexi-bility to deploy the system in a distributed environment, where the processingload can be shared and controlled.


Request methodDescription Attributes

<play>

It is used to play an an-nouncement without in-terruption and with nodigit collection

id (optional), it is a client-defined idpromptencoding (optional), it specifies the non self-described contentencodingprompturl (optional), it provides the URL of the content to be played

<playcollect>It is used to play an an-nouncement and collectdigits. Share the samebasic attributes definedfor <play>

cleardigits(optional), specifies if previous user input should be consid-ered.barge (optional), it specifies if the user input will barge the prompt andforce transition to the collect phase.maskdigits, it controls if the DTMF inputs are logged in the mediaserver.maxdigits, specifies the maximum number of digits to be collected

<playrecord>

It indicates the needof convert and/ortranscode RTP streamsand store them in aURL using the specifiedcodec(s). Share thebasic attributes definedfor <play>, plus bargeand cleardigits from<playcollect>)

escapekey(optional), it specifies a DTMF key to indicate the termina-tion of the operation without saving any input recorded at that point.recurl, Specifies the URL for the record.recencoding(optional), it specifies the encoding of the recordingmode(optional), it specifies whether the recording should overwrite orbe appended to the target. Possible values are“overwrite”and“append”.duration(optional), Maximum allowable time for the recording. Ex-pressed as a time value from 1 onwards or the strings “immediate” and“infinite”.beep(optional), it specifies whether a beep should be played to thecaller. Valid values are “yes” and “no”initsilence (optional), it specifies how long to wait for initial inputbefore canceling the recording. Expressed as a time value from 1msonwards or the strings “immediate” and “infinite”.endsilence (optional), it indicates how long the media server waits

after speech has ended to stop the recording. Expressed in the sameway than previous.recstopmask(optional), it points to a list of individual DTMF charac-ters that, if detected, will cause the recording to be terminated.

<stop>

Used to stop a requestin progress and not toinitiate another opera-tion.

id (optional), it is a client-defined id

Table 7.9: MSCML Request Methods for IVR


4. Extensibility. MSCML’s RFC [32] does not provide any explicit extensionmechanism. The protocol is under a royalty-free license regime where theprotocol is free to be deployed but it provides barriers for further developmentdone by others than the current patent holders.

5. Scalability. The protocol does not provide other handling for overloads thanusing error codes in transaction responses. It also relies on the implementationof the handling application, the distribution of resources and the protocolflexibility to address those problems. They are considered to be out of scopeof the protocol.

6. Security. The responsibility of the session security is translated to the MediaServer and there is strong recommendation to implement “security measures”to provide integrity and confidentiality. The referenced security model is theone used by SIP to provide authentication, authorization and access control.Also the media server must support TLS and SIPS(SIP Secure) for the sig-naling and should support SRTP (Secure RTP) for the media plane. Alsothe relationships of the Media Servers with external entities such as HTTPservers must be secured and authenticated. The general considerations forXML markups are also applied to this protocol.

7. Interoperability. The target of MSCML is to operate in networks where SIP isthe dominant signaling protocol, also where the nodes are preferred to enclosea large quantity of functionality and provide simple and straightforward ser-vices. It can easily be adapted to systems which already have a SIP stack toextend the processing functionality to process the XML-based payload. Butthe high-level paradigm makes it very difficult to adapt it to systems thathave been operating with a tight control interface (like H.248). The protocolallows fall-back to the simple conferencing services provided by SIP and NE-TANN, but mainly translate the support responsibility to the Media Serverimplementation as well as other issues.

8. Development. MSCML has being specified in the IETF RFC 4722 [32]. Cur-rently the framework and paradigm supported by MSCML is being extended ina newly created workgroup in IETF “MEDIACTRL” and specially addressedby the workgroup draft “A Control Framework for the Session Initiation Pro-tocol (SIP)”[17] at the moment of writing this work.


7.4 Traffic Scenario Implications

The assumptions about the type of traffic that IMS media servers will face is stillquite unknown. The vendors are expecting the introduction of old and new servicesin the IMS especially powered from the Internet. For this study, the focus has beenin the advance conference services with video and audio,in addition to multimediaplayback and user interaction. This might not be the main application deployed bythe users, but the application will for sure make use of these capabilities to providemore functionality to the users. A good example is given today by Facebook [38].This web application gives the user the power to select the type of applicationsthat they want to have attached to their profiles and share with their friends. TheFacebook platform provides them with the tools to attach such applications to theirprofiles and make use of them. Meanwhile application developers provide the appli-cations and make them available for the users. The applications can be from textposting, picture sharing, to conferencing and instant messaging systems. The Face-book example gives us an analogy of what we can expect from Media Servers in theIMS, a platform that whould allow the users to process their application’s requestin an easy and transient way. The dilemma comes in the degree of control of thenetwork over what the users can request and how to process it. To give full accessto the users to the media processing capabilities of the network is something thatsimply is not going to happen for obvious reasons (security, resource administration,charging policies, etc), therefore the intermediate control is needed and desired bythe network operators. The other dimensions, users, vendors and service providersmight have a different view:

� A tighter control will give more power to the network operators to decidethe exact way how the resources are administrated. It will provide themwith a more granular detail of the operations performed in their network andflexibility to handle new services but it might at the same time increase thecomplexity with some impact in their OPEX. The complexity rises from thesecurity mechanism needed to be verify for the operations requested by theMedia Servers and the handling of the network traffic targeting the MediaServers (i.e. load control, QoS, etc). For the end user, the tight networkcontrol might be translated in bigger delays due to signaling, resource alloca-tion and security verifications. For the vendors, the provisioning control nodeswith a complex logic implementing the operators needs is a good business thatopens opportunities for proprietary optimizations and creates dependency onthe vendor’s equipment (if it provides a good performance). Finally, the ser-


vice providers do not have a transparent interface to deal with, but a networkprovided contact point and total dependency on the network policies, agree-ments and handling from the operators. This type of control will have a greaterdegree of deployment of the Mp interface. The Mr interface would handle lesssignaling comparatively.

� An application driven control (or loose control) will give to the Media Serverapplication the responsibility of serving the users application handlers requests.This means that the Media Servers optimize their operations by having ahigh level of knowledge of what the application needs to get from the MediaServer. The flexibility for operator control is diminished and the Media Serverbecomes dependent on the control protocol request capabilities and their ownresources availability. New services might needed to be introduced by changesin the control protocol. The operators could find this type of Media ServerControl difficult to steer from the point of view of the security, QoS and loadbalancing, since the granularity of the request commands is quite low andtheir direct source are the application servers (own and external). The usersmight experience shorter signaling gaps and higher service availability butmaybe more incompatibilities when accessing from different operators. Theservice providers would obtain more control over their applications and a directinterface to utilize the network resources. Finally, the vendors would haveto implement more complicated Media Servers instead of Media Controllers,which in practice would be simple proxies. The optimizations and servicesupports are then emphasized in the Media Servers, and several proprietarysolutions might compete in this area to provide the best performance andsupport for wider services.

7.5 Comparison

The analysis of the studied protocols for Media Server control provides us withseveral characteristics, capabilities and supported functionalities, which are possibleto group and compare. Table 7.10 collects the relevant characteristics from theanalyzed Media Server Control protocols in brief. From the general characteristicswe can first compare the fitting interface from the 3GPP point of view, according tothe already defined specifications. Since H.248 has been defined as the protocol forthe Mp interface [9], the SIP based protocols are only suitable for the Mr interfaceor a non-specified interface (may be proprietary highly application dependent) tocontrol the media servers. This is shown in figure 7.10.


MRFC MRFPAS Mr (MSML /SIP)

The functions are implemented in a combined MRF but the implementation divides the control part and the processing part similarly to the MRFC and MRFP but using a proprietary protocol to communicate between them

AS

MRFC MRFP

Possible deployment of the Analyzed Media Control Protocols in the IMS’ 3GPP interfaces

No 3GPPMRF Split

MRF

The functions (MRFC and MRFP) can be implemented in the same node. The combined node has to be more intelligent and complex to handle the high level commands. (i.e. More application implementation dependent)

Mr

(MSCML /SIP )

AS Mp (H.248)

Less participation of MRFC. Only Translation of SIP transported media control protocols to H.248

3GPPMRF Split

Mr

(MSML/SIP)

MRFC MRFPAS Mp (H.248)

High participation in control from MRFC. High-level commands from SIP transported Media Control Protocols to lower-level H.248 commands.

Mr

(MSCML/SIP, Netann-SIP)

Figure 7.10: Possible deployment of the Analyzed Media Server Control Protocolson the 3GPP interfaces of IMS (The ISC interface is not present for simplicity).

The MRF as specified by 3GPP provides the functions expected from the MediaServer. Its realization can be either a logical split in one physical node that containsboth the MRFP and the MRFC or non-split at all. The first option implies that theMp interface is deployed and therefore H.248. In the case of deploying an applicationhigh-level control protocol such as MSCML or even Netann-SIP, the MRFC wouldprovide a realization of the high-level commands into H.248 and commanding theMRFP through more device specific orders. The case of MSML would leave theMRFC in a mere translation function, where almost all the Mr commands can bemapped one-to-one to a H.248 order. On the other hand, when the split is noteffective, the node can leave the application to take care of the high-level commandsfrom MSCML without the need of 3GPP’s functional splitting (where the controllerpart is cleared divided from the processing part). MSML, meanwhile, can stillmake use of such a split because of the connection model and protocol frameworkdeployed, but there are not dependencies for the communication protocol betweenthe parts since they are realized in one node. In other words, the application split


is independent of the protocol specified for the 3GPP interface between them. Thelikelihood of deploying one or another model is truly an operator’s choice, whetherthey prefer to keep a firm and strict control of their network nodes, or providetrust handling of their equipment to third-parties that provide the services. Thefirst alternative favors the models where the 3GPP split is enforced, especially thecase where high level instructions are provided from the third-parts, meanwhile thesecond alternative requires more trust and confident in the third party control andprovisioning of knowledge about the physical node characteristics. This last casealso apply to the direct deployment of H.248 from the AP due to the tightly-coupledrelationship of the master-slave model deployed.

Another argument that can be used by the operators for a direct control of theirmedia servers is the lack of load control support from the SIP transported protocols,and they might argue in favor of deploying broker functions that balance and controlthe load and the access to the media server’s pool. From the vendors point ofview, additionally to the operators wishes are also the cost of implementing theapplication that handles the functions of the node. The complexity required bysome applications to handle a node might encourage implementations in which awell defined split can modularize the development of the products or let them deployas many available proprietary solutions as possible. This complexity might be ondifferent levels, in the controlling part or in the processing part. Big companies withaccess to hardware development facilities might prefer to implement the complexityin the processing part, while small companies handling mainly software might preferto handle the complexity in the controlling part.

The user that actually can be considered in two separate dimensions, dependingon their usage of the operators network, are the application provider and the finaluser. The application providers’ needs can be very different, depending on whatservice they are going to provide. But mainly they expect that the network cansatisfy efficiently their media processing requests, in a fast and reliable way. Thefinal users require similar treatment and have similar expectations on the network.Therefore, the largest number of available functionalities, the highest efficiency toprovide the services with the lowest quantity of transactions as possible and thelowest latency are highly desired by them. In this case, from the users’ perspective,the high-level protocols provide them with a simple interface without the need ofcomplex applications to handle the protocol requests. Even so, the networks arestill driven by the operators requirements. They consider the users’ requirementsto provide better service and to obtain an increasing deployment of the network.It is expected that the increase of the network utilization means an increase in the


ProtocolCharacteristics H.248 SIP/Netann MSML MSCML

General

ApplyingInterface Mp Mr Mr/Mp Mr

Connection model Master-Slave Client-Server Client-Server Client-Server

ATMStandardized TCP-UDP-SCTP,Transport over IP UDP-TCP/IP SIP SIP

LoadBalancing Some support No No No

Extendability Defined Possible Defined Not defined

Abstraction level

ApplicationFramework Distributed Monolithic DistributedDistribution control Peer-to-peer control control

Requests level Stream Session Stream Dialog

Complexity

Media ServerControllerlogic complexity High High High Low

Media Serverlogic complexity Medium Low Medium High

Commandslength Long Medium Long Short

Table 7.10: Comparison of the characteristics of the Analyzed Media Control Pro-tocols

revenue of the operators. In reality, this might depend on the operator’s chargingstrategy.

7.6 Preferred model

The analysis provides us with different options of protocols to be deployed for MediaServer Control. The alternatives were inspected over the light of their characteristics,functionality and final deployment. Balancing all the requirements from the different


Protocols H.248 SIP/Netann MSML MSCMLFunctionality

Basicconferencing Yes Yes Yes Yes

UnscriptedIVR Possible No Yes Yes

Scripted if adding if addingIVR Possible Yes VoiceXML VoiceXML

Fax handling Yes No Yes Yes

Audio if addingrecording & Play Yes VoiceXML Yes Yes

Videorecording & Play Possible No Yes Yes

Advancedconferencing Yes No Yes Yes

Statistics Yes No Yes No

Auditing Yes No Yes No, Only event report

Announcements Yes Yes Yes Yes

Video Announcements Yes No Yes Yes

Table 7.11: Functionality comparison of the analyzed Media Server Control Proto-cols

parts involved in the media server control protocols deployment (also indirectly byusing the media processing services), the model that presents us with the bets setof characteristics is the MRF split model with a high-level control protocol for theMr interface, such as MSCML, and keeping the Mp interface based on H.248. Themain reasons to select this alternative (see figure 7.11 ) are:

� H.248 is a well known and tested protocol, even in real networks because ofits deployment in Media Gateways. In addition, the strong synergies betweenMGW and Media Servers would facilitate the reuse of the application layersin the construction of the Media Server products. Operators also benefit fromthis, since the personnel providing support for their current MGW control caneasily provide the same type of services for the additional media server nodes.The other protocols do not provide better argument to substitute H.248 thanthe advantages provided by a SIP transport which is not enough from the3GPP perspective.


� The physical split will allow the operators to control and administrate theirpool of resources directly from their trusted nodes, which will interpret andserve the requests from their own and external application servers. This facil-itates load handling and balancing. The deployment of H.248 facilitates thestate alignment between the nodes thanks to the Audit commands, and alsosupports the control from multiple master to single slave physical entity byusing virtualization of the slave entity.

� A high-level protocol to provide instructions for the Media Control simplifythe application server interface and request of services from the Media Servers,although this could restrict the access to the full potential of utilization. How-ever, full access to the media server by external parties might be undesirablefor the operators, and in special cases some kind of tunneling of pseudo H.248commands (or MSML) could be allowed to be translated into the H.248 thatthe Media Server understands.

� This model is flexible enough to be extended and refined, and it is fully 3GPPcompliant.

MRFC MRFPAS Mp (H.248)

High participation in control from MRFC. High-level commands from SIP transported Media Control Protocols to lower-level H.248 commands.

Mr

(MSCML/SIP, Netann-SIP)

Figure 7.11: Selected preferred Model for Media Server Control (The ISC interfaceis not present for simplicity)

Chapter 8

Prototype

8.1 Mobile-MGW VoIP prototype

The objective of the prototype was to allow the M-MGW to be controlled by aMGCF (Media Gateway Control Function) using H.248 transported in text modewith a SCTP/IP stack. The MGCF needed to be able to set up a single or multi-party (conference) VoIP call using the MGW as a conference controller. The MGWwill be able to connect directly to the SIP Clients to send and receive audio mediaon top of RTP/UDP/IP (see figure 8.1 ).

8.2 M-MGW prototype considerations

The M-MGW prototype implementation work was meant:

� To deploy only IP terminations. Other types of transport were supported(ATM, TDM) but not tested.

� The H248 text parsing was handling only the commands from specific detailedcall flows. Other commands and parameter were recognized by the parser butnot processed.

� The implementation of the parser allowed to configure the VMGW to usebinary or text mode, although the new functionality was implemented onlyfor the text mode H.248.

� Binary mode H.248 operates with the M3UA transport.

82

CHAPTER 8. PROTOTYPE 83

IP

UDP

T2

AAL2

PCM

AAL2

PCM

Ctx1

T1

AAL2

PCM

IPB IPB

IP Client 1 RTP

PCM

IP

UDP

RTP

PCM

IP Client 2

Figure 8.1: H.248 Context view targeted to the prototype connection model

8.3 Affected User-Plane Control application subsystems

The prototype development affected only the application software of User PlaneControl Function application code. The following subsystems needed to be modified.

8.3.1 Signalling Transport Converter (STC)

The STC handles the transport of H.248 between the M-MGW and the MGC. Thechanges in the design of the STC were avoided by using a Linux box between theSBC and the MGW to terminate the M3UA layer and transfer the payload forSCTP. The bridge between the protocol stacks was possible by using an open sourcepackage (M3UA from sourceForge or OpenSS7).

8.3.2 GCP Termination (GCPT)

This subsystem is decoding and encoding the H.248 message in binary mode, usingthe ASN.1 and encoding applying the Basic Encoding Rules (BER). It also handles


the H.248 messages by breaking them into M-MGW internal data and vice-versa,checking the syntax of the messages and controling the timer implementations forH.248. The modification includes the implementation of the H.248 parser and textmode and handling for the SDP package (the package itself has to be defined). Thereexists some differences in how the parameters are transmitted between the binarymode and the text mode. GCPT has to decode the SDP descriptors instead oftunneling them as is done by the IPBC protocol. The generation and decoding ofthe protocol for text was affected as well. The prototype mapped the text H.248 tothe binary structures already handled by the MGW. This subsystem was the mostaffected.

8.3.3 Connection Coordinator

It is responsible for mapping the H.248 view to the user plane view. In other words,the CC interprets the H.248 instructions and maps them in to devices reservations,connections, stream processing commands for the platform and events monitor-ing. The prototype impacted several parts of the subsystem. The context handlinghad to be updated to accept the possible differences compared with the previousimplementation. The stream management was also updated to deploy the SDP de-scriptors instead of decoding the IPBCP. The interface used to transport the SDPdescriptor had to be updated accordingly. Also CC should not reserve the MFD(Multi-Function Device) that provides the Nb framing by default when the IP de-vice is requested to eliminate the Nb framing from the RTP/IP stack.

8.4 M-MGW Prototype testing

The testing environment for the applications was divided into three levels:

� Subsystem Test. It included the independent test of every modified subsystem:

– STC Subsystem test. It verifies the H.248 over SCTP transmission cor-rectness, including associations and connection issues.

– GCPT Subsystem test. It verified the right interpretation of the H.248and code execution.

– MeSC Subsystem test. With this test, the execution of the code and theresource reservation by the subsystem was checked.

� Load Module Test. It included the test of all the affected load modules con-nected between them and it tested only the signaling between the subsystems.


� Node Test. Testing of all the prototype functionality in a real M-MGW node.The media was also possible to process although this was not verified. TheH.248 was sent to the node using a traffic generator tool.

8.4.1 H.248 flows between M-MGW and SBC

The Session Border Controller (SBC) was acting as a Media Gateway Controller(MGC) from the point of view of H.248. The currently supported flows for bothnodes had some differences beyond the binary/text format of the protocol, whichneeded to be unified and adapted to make possible the interworking. For this proto-type it was only analyzed the successful cases needed to set-up and release a RTP/IPconference call and the start up of the MGW node. The Session Border ControllerH.248 call flows had some differences with respect to the MGW deployed call flows:

� Two commands per transaction

� Use of Session Description Protocol directly in the Local and Remote descrip-tors, and tunneling of IPBC is not used.

� Different packages are used, and some of the SDP MGW parameters are notsupported. The reporting of the local IP address is done in the ADD responsecommand, instead of being received in the NOTIFY request command.

� The SBC does not currently support a call setup with several terminations ina context.

Therefore the prototype used the following settings aiming for the minimal impactin each node:

� Use one H.248 command per transaction.

� The SDP was kept as in the SBC local and remote descriptors.

� Not supported packages were not sent or ignored.

� The M-MGW reporting of the local address was not done in the ADD responsecommand.

� NOTIFY commands were suppressed by the MGW and not sent to the SBC.

� The adding of further terminations (after two parties) to one context was alsoincluded in the flows (with the ”n” indicating a number up to the maximumnumber of terminations allowed in the context)


� Changes in the stream mode were not processed. The stream mode for IPBwas kept as SenderReceiver.

� Link restart needed a VMGW lock-unlock to get the signaling back.

� SBC must not send audit for terminations after the ServiceChange sequencewas done.

� Termination id mapping had to be realized and a hard coded terminationgroup was used in the SBC.

8.4.2 Call setup procedure.

The MGW is using Nb framing nowadays and IPBC tunneling for the IP calls. TheIPBC is used to notify a remote MGW of the local IP address of the terminationthat it will be connected to. This IP address and UDP port are tunneled (togetherwith the Session Descriptor Protocol parameters) in H.248 using IPBC (IP BearerControl Protocol) and it is forwarded by the MGC in the signal descriptor of anADD or MODIFY command. The MGW informs about the local IP address byNOTIFY command. The type of commands used or the sequence of the connectionis dependent on the parameter: type of tunneling (fast or delay connection). In thefast connection, the IP address of the remote site is known and provided in the ADDcommand descriptors, and the MGW returns the local IP address of the terminationin a NOTIFY command in the same transaction. Meanwhile, in the delay connectionthe IP address is sent later in a MODIFY command, and the local IP address is alsosent in the NOTIFY command but in a different H.248 transaction. The call flowis shown in figure 8.2.

8.4.3 Call Release Procedure

The release of terminations from the M-MGW point of view is simple and supportsdifferent combinations of wildcarding as well. The SBC requests some statistics notsupported by the M-MGW, and this was disabled for the prototype flows. Also, theone command per transaction encoding was used.

8.4.4 MGW Cold startup flow

The difference is only in the profile used by each node (EP1 and EP2 in the di-agrams). The other node profile is not supported currently by the nodes (In thiscase the MGW profile will not be supported by the SBC). For the purpose of this


M-MGW SBC

4.1.2: addRsp(Ctx=1 ,Term=T1,MediaDescriptor: LocalDes{SDP(v=0, c=IN IPv4 "T1 IP ADDRESS" , m=-"T1 UDP PORT" RTP/AVP-)})

4.1.1: addReq({Ctx=Choose, Term=Choose (IP Wildcard),MediaDescriptor: LocalCntrlDes {strmMode=SR}

LocalDes{SDP(v=0, c=IN IPv4 $, m=-$ RTP/AVP-)}RemoteDes{SDP(v=0, c=IN IPv4 "CLIENT1 IP", m=- "CLIENT1 PORT" RTP/AVP)}}})

4.2.2: addRsp(Ctx=1 ,Term=T2,MediaDescriptor: LocalDes{SDP(v=0, c=IN IPv4 "T2 IP ADDRESS" , m=-"T2 UDP PORT" RTP/AVP-)})

At this point the remote IP of the second termination is unknown by the MGC.The alternatives are to wait until the IP is known and follow the flow for Tnreservation or start the second termination reservation and modify it later with the remote IP address when is available as is done in the following sequence.

Creating T2 in Ctx 1

4.3.1: modifyReq({Ctx=1, Term= T2,MediaDescriptor: LocalCntrlDes {strmMode=SR}

RemoteDes{SDP(v=0, c=IN IPv4 "CLIENT2 IP", m=- "CLIENT2 PORT" RTP/AVP)}}})

4.3.2: modifyRsp(Ctx =1 , Term= T2)

IP address from Client2 is available

Abbreviations:Ctx: Context, Term: Termination, LocalCntrlDes: Local Control Descriptor, strmMode: Stream mode, SR: Sender Receiver, LocalDes: Local Descriptor,RemoteDes: Remote Descriptor, SDP: Session Descriptor Protocol, v: Version,c: Connection, m: Media.

4.4.2: addRsp(Ctx=1 ,Term=Tn,MediaDescriptor: LocalDes{SDP(v=0, c=IN IPv4 "Tn IP ADDRESS" , m=-"Tn UDP PORT" RTP/AVP-)})

Creating Tn in Ctx1

4.4.1: addReq({Ctx=1, Term=Choose (IP Wildcard),MediaDescriptor: LocalCntrlDes {strmMode=SR}

LocalDes{SDP(v=0, c=IN IPv4 $, m=-$ RTP/AVP-)}RemoteDes{SDP(v=0, c=IN IPv4 "CLIENTn IP", m=- "CLIENTn PORT" RTP/AVP)}}})

4.2.1: addReq({Ctx=1, Term=Choose (IP Wildcard),MediaDescriptor: LocalCntrlDes {strmMode=SR}

LocalDes{SDP(v=0, c=IN IPv4 $, m=-$ RTP/AVP-)}})

ModifyingT2 in Ctx 1

Figure 8.2: H.248 Call setup flow used for the Prototype


prototype, the profile was overridden in the H.248 text encoder from the MGW tomatch the currently accepted SBC profile (see figure 8.3).

M-MGW MGC

Releasing Ctx 1 T1 and T2

7.1.1: SubReq (Ctx=1, Term= ALL)

7.1.2: subRsp(Ctx= 1, Term= ALL)

M-MGW : MGW SBC : MGC

MGW Start up

1.1: serviceChangeReq( Ctx=NULL, Term=ROOT,scm=restart,scr=coldBoot, scp=EP2, scv=2)

1.2: ServiceChangeRsp(Ctx=NULL, Term=ROOT, scv=2)

MGW without TDM termination groups configured

: .Abbreviations:Ctx: ContextTerm: Terminationscm: Service Change Method scr: Service Change Reason scp: Service Change Profile EP2: Profile version

Figure 8.3: H.248 call release and cold start-up flows used for the prototype

Chapter 9

Conclusions and Future Work

Standardization in the Media Server Control area has received a great deal of atten-tion in the telecommunication industry. The 3G mobile telecommunication industryneeds a model to evolve from the current network architecture to the all IP vision.The road map of this evolution includes the definition of Media Server Controlprotocols and Media Control interfaces. This work is constantly evolving. Therequirements for this standardization are provided by the industry interests, theservice offerings, and the end-users demands.

Strong synergies exist between the already deployed Mobile Media Gateway (M-MGW) and the future Media Resource Function Processor (MRFP). These synergiesprovide a good starting point to analyze the issues that will be found in the deploy-ment of the MRFP. They point to the most important aspects to be consideredrelated to the control protocol and the required interfaces.

Based on the analysis of the mentioned factors, this work concludes that thepreferred model for media server control in 3G networks includes a high-level con-trol protocol for the Mr interface together with the already specified H.248-basedMp interface. The high-level control protocol could consist of the already specifiedMSCML or Netamm-SIP. H.248 is deployed to provide low-level and detailed controlof the MRFP by the MRFC.

The study of the alternative models and protocols was mainly based on the levelof complexity that was required to implement it on the different network elements.The study also took into account requirements coming from final users, operators,vendors, and service providers. The model chosen is believed to provide the lowestoverall level of complexity for all network elements while satisfying the requirementsof all the affected parties. Other models and protocols, in addition to the ones chosenin this study, also satisfied many of the requirements. However, their implementation

89

CHAPTER 9. CONCLUSIONS AND FUTURE WORK 90

seemed to involve an equal or a higher level of complexity than the suggested model.At equal complexity, priority was given to already deployed protocols, since theexperience gained during their deployment is considered to be a valuable additionaladvantage in their favor.

Finally, as the practical part of this thesis, a prototype of a MRFP was imple-mented by modifying the User Plane Control Function of a M-MGW. The experiencegained from this work provided valuable information to recognize the potential ofreuse of current implemented functions into the design of a MRFP. The prototypesuccessfully demonstrated the synergies between the M-MGW and a MRFP. Also, itprovided a glimpse of the services that can be deployed using an already functionalplatform.

9.1 Future Work

The development of multimedia technologies has increased at a high pace during thelast decade. The requirements for media processing are continuously changing withthe development of new technologies. New media contents and formats are beingcreated and made available all the time. The architecture of the media provisioningand processing functions in mobile networks is also likely to evolve according to theneeds that new developments bring. Some of these issues, such as the implemen-tation of MBMS (Multimedia Broadcast Multicast Service) [92], are already beinginvestigated. Also, increases in the demand for certain services could lead to theneed and research in the area of load distribution and efficient resource allocation.In [25], some steps in this area are already given by proposing specific optimizations.

3GPP has also felt the need of presenting solutions to the Media Server Control.In response to this need, the technical report TR.24-880 for Release 8 [10] is currentlyin its final state before being approved, at the time of writing. The recommendationprovided by the report is to support two models of Media Server Control, bothkeeping the Mp interface with the current H.248 specified protocol:

� A delegation model, where the MRFC fetches from the AS an indicated exe-cution script (based on XML), and by following the script, the MRFC controlsthe MRFP. The SCXML[15] or CCXML profile are recommended to be usedhere together with VoiceXML 2.1[77] or 3.0 depending on the availability ofthe later.

� A protocol model with dedicated control channel. It uses a transport channelto send media control messages from a high-level control protocol to the MRFC

CHAPTER 9. CONCLUSIONS AND FUTURE WORK 91

that interprets them in the correspondent H.248 transactions. The high-levelprotocol recommended by the report is the result of the IETF MEDIACTRLworking group (the current draft-ietf-mediactrl-sip-control-framework-00[17]).In case this IETF work is not available with in the 3GPP release 8 timeframe,the proposal is to use MSCML[32].

Both proposals require the creation of a new interface that will be named Cr or Sr.This interface would establish the direct connection between the AS and the MRFCthat this thesis assumed is done through the ISC and Mr interfaces. Additionally,the report recommends the support of Netamm-SIP[19] with the clarification de-fined in the draft-burke-vxml[21]. This provides a third way of supplying mediacontrol commands from the AS. Furthermore, the report explores the possibility ofintroducing broker functions to provide an improved connection between the MRFCand the AS. This possibility was briefly mentioned in this thesis (see section 7.3.2).The introduction of the same idea by the technical report highlights its importance.Work in this area will continue once the definitive model to be used is defined.

Bibliography

[1] 3GPP: Base Station System - Mobile-services Switching Centre (BSS - MSC)interface; General aspects. Ts 48.001, 3rd Generation Parnership Project(3GPP), February 2005. http://www.3gpp.org/ftp/Specs/html-info/

48001.htm.

[2] 3GPP: Bearer-independent circuit-switched core network; Stage 2. Ts 23.205,3rd Generation Parnership Project (3GPP), June 2005. http://www.3gpp.

org/ftp/Specs/html-info/23205.htm.

[3] 3GPP: Core network Nb data transport and transport signalling. Ts 29.414,3rd Generation Parnership Project (3GPP), January 2005. http://www.3gpp.org/ftp/Specs/html-info/29414.htm.

[4] 3GPP: Media Gateway Controller (MGC) - Media Gateway (MGW) interface;Stage 3. Ts 29.232, 3rd Generation Parnership Project (3GPP), June 2005.http://www.3gpp.org/ftp/Specs/html-info/29232.htm.

[5] 3GPP: Packet switched conversational multimedia applications; Default codecs.Ts 26.235, 3rd Generation Parnership Project (3GPP), April 2005. http://

www.3gpp.org/ftp/Specs/html-info/26235.htm.

[6] 3GPP: Signalling System No. 7 (SS7) signalling transport in core network;Stage 3. Ts 29.202, 3rd Generation Parnership Project (3GPP), January 2005.http://www.3gpp.org/ftp/Specs/html-info/29202.htm.

[7] 3GPP: UTRAN Iu interface data transport & transport signalling. Ts 25.414,3rd Generation Parnership Project (3GPP), June 2005. http://www.3gpp.

org/ftp/Specs/html-info/25414.htm.

[8] 3GPP: Conferencing using the IP Multimedia (IM) Core Network (CN) subsys-tem; Stage 3. Ts 24.147, 3rd Generation Parnership Project (3GPP), December2006. http://www.3gpp.org/ftp/Specs/html-info/24147.htm.

92

http://www.3gpp.org/ftp/Specs/html-info/48001.htm













BIBLIOGRAPHY 93

[9] 3GPP: Multimedia Resource Function Controller (MRFC) - Multimedia Re-source Function Processor (MRFP) Mp interface: Procedures Descriptions. Ts23.333, 3rd Generation Parnership Project (3GPP), December 2006. http:

//www.3gpp.org/ftp/Specs/html-info/23333.htm.

[10] 3GPP: Media server control using the IP Multimedia (IM) Core Network (CN)subsystem; Stage 3. Tr 24.880, 3rd Generation Parnership Project (3GPP),December 2007. http://www.3gpp.org/ftp/Specs/html-info/24880.htm.

[11] 3rd Generation Partnership Project (3GPP): Study on Release 2000 servicesand capabilities. TR 22.976 V2.0.0 , Technical Report, Technical SpecificationGroup Services and System Aspects, June 2000.

[12] 3rd Generation Partnership Project (3GPP): Service requirements for the IPMultimedia Core Network Subsystem (Stage 1). TR 22.228 V5.6.0 , TechnicalSpecification, Technical Specification Group Services and System Aspects, June2002.

[13] 3rd Generation Partnership Project (3GPP): Network architecture. TS 23.002V5.12.0 , Technical Specification, Technical Specification Group Services andSystems Aspects, September 2003.

[14] 3rd Generation Partnership Project (3GPP): IP Multimedia Subsystem(IMS)language = english ;stage 2. TR 23.228 V6.5.0 , Technical Specification,Technical Specification Group Services and System Aspects, March 2004.

[15] Barnett, Jim, Michael Bodell, Dan Burnettand Jerry Carter, and Rafah Hosn:State chart xml (scxml): State machine notation for control abstraction. Work-ing Draft, February 2007. http://www.w3.org/TR/2007/WD-scxml-20070221,Work in progress.

[16] Boulton, C., T. Melanchuk, S. McGlashan, and A. Shiratzky: A basic in-teractive voice response (ivr) control package for the session initiation pro-tocol (sip). Internet draft, May 2008. http://tools.ietf.org/html/

draft-boulton-ivr-control-package-05, Work in progress.

[17] Boulton, C., T. Melanchuk, S. McGlashan, and A. Shiratzky: Acontrol framework for the session initiation protocol (sip). In-ternet draft, February 2008. http://tools.ietf.org/html/

draft-ietf-mediactrl-sip-control-framework-00, Work in progress.




http://www.w3.org/TR/2007/WD-scxml-20070221

http://tools.ietf.org/html/draft-boulton-ivr-control-package-05

http://tools.ietf.org/html/draft-boulton-ivr-control-package-05

http://tools.ietf.org/html/draft-ietf-mediactrl-sip-control-framework-00

http://tools.ietf.org/html/draft-ietf-mediactrl-sip-control-framework-00

BIBLIOGRAPHY 94

[18] Boulton, C., T. Melanchuk, S. McGlashan, and A. Shiratzky: A voicexml in-teractive voice response (ivr) control package for the session initiation pro-tocol (sip). Internet draft, May 2008. http://tools.ietf.org/html/

draft-boulton-ivr-vxml-control-package-03, Work in progress.

[19] Burger, E., J. Van Dyke, and A. Spitzer: Basic Network Media Services withSIP. RFC 4240 (Informational), December 2005. http://www.ietf.org/rfc/rfc4240.txt.

[20] Burger, Eric and Greg Pisano: Mscml protocol: The key to unlocking a newgeneration of multimedia sip services. White Paper, July 2005. http://www.

cantata.com/whitepapers/pdf/mscml_protocol.pdf.

[21] Burke, D., M. Scott, J. Haynie, R. Auburn, and S. McGlashan: Sip interface tovoicexml media services. Internet draft, January 2008. http://tools.ietf.

org/html/draft-burke-vxml-03, Work in progress.

[22] Calhoun, P., J. Loughney, E. Guttman, G. Zorn, and J. Arkko: Diameter BaseProtocol. RFC 3588 (Proposed Standard), September 2003. http://www.ietf.org/rfc/rfc3588.txt.

[23] Camarillo, Gonzalo: SIP Demystified. McGraw-Hill Telecom, 1st edition, 2002,ISBN 0-07-137340-3.

[24] Camarillo, Gonzalo and Miguel Angel Garcia-Martin: The 3G IP MultimediaSubsystem (IMS) : Merging the Internet and the Cellular Worlds. John Wiley& Sons, 1st edition, 2004, ISBN 0470871563.

[25] Cao, Feng, J. Smith, and K. Takahashi: An architecture of distributed mediaservers for supporting guaranteed qos and media indexing. Multimedia Com-puting and Systems, 1999. IEEE International Conference on, 2:1–5 vol.2, Jul1999.

[26] Comer, Douglas E.: Internetworking with TCP/IP, volume 1. Prentice Hall,4th edition, 2000.

[27] Media services in the ims: Evolution for innovation. White Paper, June 2004.http://www.convedia.com/PDFs/WP_Media_Servers_and_SIP.pdf.

[28] Cortes, Mauricio, J. Robert Ensor, and Jairo O. Esteban: On sip performance.Bell Labs Technical Journal, 9(3), 2004. http://dx.doi.org/10.1002/bltj.

20048.

http://tools.ietf.org/html/draft-boulton-ivr-vxml-control-package-03

http://tools.ietf.org/html/draft-boulton-ivr-vxml-control-package-03

http://www.ietf.org/rfc/rfc4240.txt


http://www.cantata.com/whitepapers/pdf/mscml_protocol.pdf

http://www.cantata.com/whitepapers/pdf/mscml_protocol.pdf

http://tools.ietf.org/html/draft-burke-vxml-03

http://tools.ietf.org/html/draft-burke-vxml-03



http://www.convedia.com/PDFs/WP_Media_Servers_and_SIP.pdf

http://dx.doi.org/10.1002/bltj.20048

http://dx.doi.org/10.1002/bltj.20048

BIBLIOGRAPHY 95

[29] Crocker, D. and P. Overell: Augmented BNF for Syntax Specifications: ABNF.RFC 2234 (Proposed Standard), November 1997. http://www.ietf.org/rfc/rfc2234.txt, Obsoleted by RFC 4234.

[30] Dierks, T. and C. Allen: The TLS Protocol Version 1.0. RFC 2246 (ProposedStandard), January 1999. http://www.ietf.org/rfc/rfc2246.txt, Obso-leted by RFC 4346, updated by RFC 3546.

[31] Durham, D., J. Boyle, R. Cohen, S. Herzog, R. Rajan, and A. Sastry: TheCOPS (Common Open Policy Service) Protocol. RFC 2748 (Proposed Stan-dard), January 2000. http://www.ietf.org/rfc/rfc2748.txt.

[32] Dyke, J. Van, E. Burger, and A. Spitzer: Media Server Control Markup Lan-guage (MSCML) and Protocol. RFC 4722 (Informational), November 2006.http://www.ietf.org/rfc/rfc4722.txt.

[33] Media gateway. Technical description, May 2000.

[34] Softswitch in mobile networks. White Paper, April 2005. http:

//www.ericsson.com/products/white_papers_pdf/3025_softswitch_

mobile_A.pdf.

[35] ETSI: European digital cellular telecommunications system (Phase 1); GSM FullRate Speech Transcoding (GSM 06.10). Recommendation GTS 06.10, EuropeanTelecommunications Standards Institute (ETSI), Jan 1995.

[36] Even, R.: Requirements for a media server control protocol. In-ternet draft, June 2006. http://www.ietf.org/internet-drafts/

draft-even-media-server-req-01.txt, Expired.

[37] Eyers, Tony and Henning Schulzrinne: Predicting internet telephony call setupdelay. Proceedings of the 1st IP-Telephony Workshop, Berlin - Germany, 2000.http://www.cs.columbia.edu/~hgs/papers/Eyer0004_Predicting.pdf.

[38] Facebook: Facebook. http://www.facebook.com.

[39] Freed, N. and K. Moore: MIME Parameter Value and Encoded Word Exten-sions: Character Sets, Languages, and Continuations. RFC 2231 (ProposedStandard), November 1997. http://www.ietf.org/rfc/rfc2231.txt.

[40] Froumentin, M.: The W3C Speech Interface Framework Media Types:application/voicexml+xml, application/ssml+xml, application/srgs, applica-






http://www.ericsson.com/products/white_papers_pdf/3025_softswitch_mobile_A.pdf



http://www.ietf.org/internet-drafts/draft-even-media-server-req-01.txt

http://www.ietf.org/internet-drafts/draft-even-media-server-req-01.txt

http://www.cs.columbia.edu/~hgs/papers/Eyer0004_Predicting.pdf

http://www.facebook.com


BIBLIOGRAPHY 96

tion/srgs+xml, application/ccxml+xml, and application/pls+xml. RFC 4267(Informational), November 2005. http://www.ietf.org/rfc/rfc4267.txt.

[41] Fyro, Magnus, Kai Heikkinen, Lars Goran Petersen, and Patrik Wiss: Mediagateway for mobile networks. Ericsson Review, 2000. http://www.ericsson.

com/about/publications/review/2000_04/files/2000042.pdf.

[42] Groves, C., M. Pantaleo, T. Anderson, and T. Taylor: Gateway Control ProtocolVersion 1. RFC 3525 (Proposed Standard), June 2003. http://www.ietf.org/rfc/rfc3525.txt.

[43] Hares, Teemu: Adding multimedia resource function processor functionality toMobile Media Gateway. Master’s thesis, Helsinki University of Technology,Espoo, Finland, February 2003.

[44] International Organization for Standardization: ISO/IEC 14496-1:1999: In-formation technology — Coding of audio-visual objects — Part 1: Systems.International Organization for Standardization, Geneva, Switzerland, 1999.http://www.iso.ch/cate/d24462.html.

[45] ISO/IEC: MPEG-1 coding of moving pictures and associated audio for digitalstorage media at up to about 1,5 mbit/s. ISO/IEC 11172, 1993.

[46] ISO/IEC: MPEG-2 generic coding of moving pictures and associated audio in-formation. ISO/IEC 13818, 1996.

[47] ITU-T: Video codec for audiovisual services at px64 kbit/s. RecommendationH.261, International Telecommunication Union, Mar 1993.

[48] ITU-T: B-ISDN ATM adaptation layer - Service specific connection orientedprotocol (SSCOP). Recommendation Q.2110, International TelecommunicationUnion, Jul 1994.

[49] ITU-T: B-ISDN signalling ATM adaptation layer (SAAL) - Overview descrip-tion. Recommendation Q.2100, International Telecommunication Union, Jul1994.

[50] ITU-T: B-ISDN ATM Adaptation Layer; Service Specific Coordination Func-tion for Signaling at the Network Node Interface (SSCF at NNI). Recommen-dation Q.2140, International Telecommunication Union, Feb 1995.


http://www.ericsson.com/about/publications/review/2000_04/files/2000042.pdf




http://www.iso.ch/cate/d24462.html

BIBLIOGRAPHY 97

[51] ITU-T: Message transfer part level 3 functions and messages using the servicesof ITU-T Recommendation Q.2140. Recommendation Q.2210, InternationalTelecommunication Union, Jul 1998.

[52] ITU-T: Overall network aspects and functions. Protocol layer requirements. Rec-ommendation I.366.1, International Telecommunication Union, Jun 1998.

[53] ITU-T: Protocol for multimedia application text conversation. RecommendationT.140, International Telecommunication Union, Feb 1998.

[54] ITU-T: Pulse Code Modulation (PCM) of voice frequencies. RecommendationG.711, International Telecommunication Union, Nov 1998.

[55] ITU-T: Narrow-band visual telephone systems and terminal equipment. Recom-mendation H.320, International Telecommunication Union, May 1999.

[56] ITU-T: AAL type 2 signalling protocol - Capability Set 2 . RecommendationQ.2630.2, International Telecommunication Union, Dec 2000.

[57] ITU-T: B-ISDN ATM Adaptation Layer specification : Type 2 AAL . Recom-mendation I.363.2, International Telecommunication Union, Nov 2000.

[58] ITU-T: Gateway control protocol: Transport over ATM. RecommendationH.248.5, International Telecommunication Union, Nov 2000.

[59] ITU-T: Gateway control protocol: Transport over Stream Control TransmissionProtocol (SCTP). Recommendation H.248.4, International TelecommunicationUnion, Nov 2000.

[60] ITU-T: BICC IP Bearer control protocol. Recommendation Q.1970, Interna-tional Telecommunication Union, Jul 2001.

[61] ITU-T: Signalling Transport Converter on MTP3 and MTP3b . Recommenda-tion Q.2150.1, International Telecommunication Union, May 2001.

[62] ITU-T: Gateway control protocol: Version 2. Recommendation H.248.1, Inter-national Telecommunication Union, May 2002.

[63] ITU-T: Information technology - ASN.1 encoding rules: Specification of BasicEncoding Rules (BER), Canonical Encoding Rules (CER) and DistinguishedEncoding Rules (DER). Recommendation X.690, International Telecommuni-cation Union, Jul 2002.

BIBLIOGRAPHY 98

[64] ITU-T: OSI Networking and System Aspects. Abstract Syntax Notation One(ASN.1); Information Technology. Abstract Syntax Notation One (ASN.1):Specification of Basic Notation. Recommendation X.680, InternationalTelecommunication Union, Jul 2002.

[65] ITU-T: Gateway control protocol: Decomposed multipoint control unit, audio,video and data conferencing packages. Recommendation H.248.19, InternationalTelecommunication Union, Mar 2004.

[66] Jin, Haipeng and AC Mahendran: Using sigcomp to compress sip/sdp messages.ICC 2005. 2005 IEEE International Conference on Communications, 2005, May2005.

[67] Kent, S.: IP Authentication Header. RFC 4302 (Proposed Standard), December2005. http://www.ietf.org/rfc/rfc4302.txt.

[68] Kling, Lars Orjan, Ake Lindholm, Lars Marklund, and Gunnar B. Nilsson: Cppcello packet platform. Ericsson Review, 2002. http://www.ericsson.com/

about/publications/review/2002_02/files/2002023.pdf.

[69] Kohler, E., M. Handley, and S. Floyd: Datagram congestion control protocol(dccp). Internet draft, March 2005. http://www.ietf.org/internet-drafts/draft-ietf-dccp-spec-11.txt, Work in Progress.

[70] Kopajtic, Ozren and Riko LuSa: H.248 - implementation and interoperabilityissues. conTel 2003, 2003.

[71] Koukal, M. and R. Bestak: Architecture of ip multimedia subsystem. Multi-media Signal Processing and Communications, 48th International SymposiumELMAR-2006 focused on, June 2006.

[72] Lee, Yeong Hun Cho; Moon Sang Jeong; Jong Tae Park; Wee Hyuk: Distributedmanagement architecture for multimedia conferencing using sip. DistributedFrameworks for Multimedia Applications, 2005. DFMA ’05. First InternationalConference on, pages 98–105, 6-9 Feb. 2005.

[73] Liao, Wanjiun, Jen Chun Chang, and V.O.K. Li: Application-layer conferencetrees for multimedia multipoint conferences using megaco/h.248. Multimedia,IEEE Transactions on, 7(5):951–959, Oct. 2005, ISSN 1520-9210.

[74] Marsic, B., T. Borosa, and S. Pocuca: Ims to pstn/cs interworking. Telecom-munications, 2003. ConTEL 2003.Vol.2. Proceedings of the 7th InternationalConference on, June 2003.




http://www.ietf.org/internet-drafts/draft-ietf-dccp-spec-11.txt

http://www.ietf.org/internet-drafts/draft-ietf-dccp-spec-11.txt

BIBLIOGRAPHY 99

[75] Murata, M., S. St. Laurent, and D. Kohn: XML Media Types. RFC 3023 (Pro-posed Standard), January 2001. http://www.ietf.org/rfc/rfc3023.txt.

[76] Nokalva, OSS: Benchmark review : Comparison between binary encoder vs.textual encoder. Technical report, ASN.1 Consortium, 2002. http://www.

asn1.org/benchmark/benchmark1.htm.

[77] Oshry, Matt, R. J. Auburn, Paolo Baggia, Michael Bodell, David Burke, DanielC. Burnett, Emily Candell, Hakan Kilic, Jeff Kusnitz, Scott McGlashan, AlexLee, Brad Porter, and Kenneth G. Rehor: Voice extensible markup language(voicexml) 2.1. World Wide Web Consortium, Recommendation, June 2007.http://www.w3.org/TR/2007/REC-voicexml21-20070619.

[78] Poikselka, Miikka, Georg Mayer, Hisham Khartabil, and Aki Niemi: The IMS:IP Multimedia Concepts and Services in the Mobile Domain. John Wiley &Sons, 1st edition, 2004, ISBN 0-470-87113-X.

[79] Postel, J.: User Datagram Protocol. RFC 768 (Standard), August 1980. http://www.ietf.org/rfc/rfc768.txt.

[80] Postel, J.: Transmission Control Protocol. RFC 793 (Standard), September1981. http://www.ietf.org/rfc/rfc793.txt, Updated by RFC 3168.

[81] Project, Open Source Erlang Megaco/H.248: Performance comparison ofmegaco/h.248 encodings in erlang/otp. Technical report, Open Source Er-lang, December 2003. http://www.erlang.org/project/megaco/encoding_

comparison-v4/index.html.

[82] Reinius, Jonas: Cello an atm transport and control platform. Ericsson Re-view, 1999. http://www.ericsson.com/about/publications/review/1999_

02/files/1999021.pdf.

[83] Rosenberg, J.: A Framework for Conferencing with the Session Initiation Pro-tocol (SIP). RFC 4553 (Informational), February 2006. http://www.ietf.

org/rfc/rfc4553.txt.

[84] Rosenberg, J., J. Peterson, H. Schulzrinne, and G. Camarillo: Best CurrentPractices for Third Party Call Control (3pcc) in the Session Initiation Protocol(SIP). RFC 3725 (Best Current Practice), April 2004. http://www.ietf.org/rfc/rfc3725.txt.


http://www.asn1.org/benchmark/benchmark1.htm

http://www.asn1.org/benchmark/benchmark1.htm

http://www.w3.org/TR/2007/REC-voicexml21-20070619




http://www.erlang.org/project/megaco/encoding_comparison-v4/index.html

http://www.erlang.org/project/megaco/encoding_comparison-v4/index.html







BIBLIOGRAPHY 100

[85] Rosenberg, J. and H. Schulzrinne: Guidelines for Authors of Extensions to theSession Initiation Protocol (SIP). RFC 4485 (Informational), May 2006. http://www.ietf.org/rfc/rfc4485.txt.

[86] Rosenberg, J., H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R.Sparks, M. Handley, and E. Schooler: SIP: Session Initiation Protocol. RFC3261 (Proposed Standard), June 2002. http://www.ietf.org/rfc/rfc3261.

txt, Updated by RFCs 3265, 3853.

[87] Saleem, A., Y. Xin, and G. Sharratt: Media server markup language (msml).Internet draft, December 2005. http://www.ietf.org/internet-drafts/

draft-saleem-msml-02.txt, Work in progress.

[88] Schulzrinne, H., S. Casner, R. Frederick, and V. Jacobson: RTP: A TransportProtocol for Real-Time Applications. RFC 3550 (Standard), July 2003. http:

//www.ietf.org/rfc/rfc3550.txt.

[89] Schulzrinne, H. and S. Petrack: RTP Payload for DTMF Digits, TelephonyTones and Telephony Signals. RFC 2833 (Standard), May 2000. http://

www1.ietf.org/rfc/rfc2833.

[90] Stewart, R., Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor,I. Rytina, M. Kalla, L. Zhang, and V. Paxson: Stream Control TransmissionProtocol. RFC 2960 (Proposed Standard), October 2000. http://www.ietf.

org/rfc/rfc2960.txt, Updated by RFC 3309.

[91] Suominen, Mikko: Enhancing System Capacity and Robustness by OptimizingSoftware Architecture in a Real-time Multiprocessor Environment. Master’sthesis, Helsinki University of Technology, Espoo, Finland, May 2004.

[92] Zafar, Madiha, Nigel Baker, Meir Fuchs, Justino Santos, Ahsan Ikram, andSusana Sargento: Ims mbms integration: Functional analysis & architecturaldesign. Mobile and Wireless Communications Summit, 2007. 16th IST, pages1–5, 1-5 July 2007.





http://www.ietf.org/internet-drafts/draft-saleem-msml-02.txt

http://www.ietf.org/internet-drafts/draft-saleem-msml-02.txt



http://www1.ietf.org/rfc/rfc2833

http://www1.ietf.org/rfc/rfc2833



3 g m gw

Documents

media server control

domain media gateway

control messages tothe

mediaserver control

multimedia laboratoryedgar

gonzalo camarillo

setup ims ip calls

ims architecture