LTU-EX-08210-SE

2008:210 CIV

M A S T E R ' S T H E S I S

IMS platform prototype

Leonard Broman

Luleå University of Technology

MSc Programmes in Engineering Computer Science and Engineering

Department of Computer Science and Electrical EngineeringDivision of Computer Engineering

2008:210 CIV - ISSN: 1402-1617 - ISRN: LTU-EX--08/210--SE

Abstract

The future in telecommunication systems goes towards a split between the networkprovider and the service provider, and a convergence of media distribution andcommunication networks. This has caused the 3GPP to develop an open specifi-cation for the future communication system, IP Multimedia Subsystem, providingreal-time multimedia services. The system is designed is a modular and flexiblecommunication platform running on top of any transport medium providing IPtransport capabilities. It is also designed to be to interface towards other networkssuch as the PSTN.

This report covers research and analysis of deploying a demonstration prototypeof the IMS platform. Using present open source solution and developing miss-ing components to enable services and solve network-topological problems such asNATs.

Contents

1 Introduction 9

1.1 IP Multimedia Subsystem . . . . . . . . . . . . . . . . . . . . . . . . 9

1.2 Assignment background . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.3 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.3.1 Prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.3.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.3.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.4 Emphasis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.5 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.5.1 General abbreviations . . . . . . . . . . . . . . . . . . . . . . 12

1.5.2 IMS abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 12

1.5.3 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 IP Multimedia Subsystem 14

2.1 IMS signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.1.1 SIP - Session Initiation Protocol . . . . . . . . . . . . . . . . 15

2.1.2 Diameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.1.3 Quality of Service . . . . . . . . . . . . . . . . . . . . . . . . 15

2.1.4 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1

Lulea university of technologyOctober 11, 2008

Leonard BromanCONTENTS

2.2 Single client services . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2.1 Client configuration data . . . . . . . . . . . . . . . . . . . . 16

2.2.2 Presence service . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.3 Text services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.3.1 Pager-mode instant messaging . . . . . . . . . . . . . . . . . 17

2.3.2 Session-mode one-to-one instant messaging . . . . . . . . . . 18

2.3.3 Session-mode instant message conferencing . . . . . . . . . . 18

2.3.4 Single-client text services . . . . . . . . . . . . . . . . . . . . 19

2.4 Audio and video services . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.4.1 Single client media service . . . . . . . . . . . . . . . . . . . . 19

2.4.2 Multimedia conversation session . . . . . . . . . . . . . . . . 19

2.4.3 Multimedia conference . . . . . . . . . . . . . . . . . . . . . . 20

2.5 System topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.5.1 Call/Session Control Function . . . . . . . . . . . . . . . . . 20

2.5.2 Home Subscriber Server . . . . . . . . . . . . . . . . . . . . . 22

2.5.3 Media Resource Function . . . . . . . . . . . . . . . . . . . . 22

2.5.4 Application Server . . . . . . . . . . . . . . . . . . . . . . . . 22

2.5.5 Media Gateway Function . . . . . . . . . . . . . . . . . . . . 23

3 Technical aspects and solutions 25

3.1 Network restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2 Network Address Translation . . . . . . . . . . . . . . . . . . . . . . 26

3.2.1 NAT and UDP . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.2.2 NAT and TCP . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.3 General requirements in restricted networks . . . . . . . . . . . . . . 27

3.4 Generic solution to IMS on restricted networks . . . . . . . . . . . . 28

3.4.1 Session border controller system topology . . . . . . . . . . . 28

2



3.4.2 SBC as NAT/Proxy . . . . . . . . . . . . . . . . . . . . . . . 28

3.4.3 SBC for QoS and network resource monitoring . . . . . . . . 29

3.5 Volatile networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.5.1 Signaling connection instability . . . . . . . . . . . . . . . . . 30

3.5.2 Media connection instability . . . . . . . . . . . . . . . . . . . 30

3.6 Conference sessions in SIP . . . . . . . . . . . . . . . . . . . . . . . . 31

3.6.1 Creating the focus/session . . . . . . . . . . . . . . . . . . . . 31

3.6.2 Subscribing to session changes . . . . . . . . . . . . . . . . . 32

3.6.3 Inviting new participants . . . . . . . . . . . . . . . . . . . . 32

3.7 MSRP conferencing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.7.1 Connecting to the session . . . . . . . . . . . . . . . . . . . . 32

3.7.2 Authentication mechanisms . . . . . . . . . . . . . . . . . . . 33

3.8 Audio and Video conferencing . . . . . . . . . . . . . . . . . . . . . . 34

3.8.1 RTP media and conferences . . . . . . . . . . . . . . . . . . . 35

3.9 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4 System design 36

4.1 Topological solution, DMZ to Private network border controllers . . 36

4.1.1 Multi-host systems . . . . . . . . . . . . . . . . . . . . . . . . 36

4.1.2 TCP initiation from private network . . . . . . . . . . . . . . 38

4.1.3 TCP tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.2 Topological solution, everything in DMZ . . . . . . . . . . . . . . . . 38

4.2.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.3 Network deployment solution . . . . . . . . . . . . . . . . . . . . . . 39

4.3.1 Software components . . . . . . . . . . . . . . . . . . . . . . . 39

5 Implementation 42

3



5.1 Client software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.1.1 Target platform . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.1.2 MSRP Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.1.3 IMS Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.1.4 Java client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.2 Server software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.2.1 SIP focus for MSRP sessions . . . . . . . . . . . . . . . . . . 51

5.2.2 Billing proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.3 Client based test bots . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.3.1 MSRP echo bot . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.3.2 Eliza bot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.3.3 Inviter bot . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.3.4 Conference bot . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.3.5 Conference inviter bot . . . . . . . . . . . . . . . . . . . . . . 53

6 Summary and future work 54

6.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

6.1.1 Present status . . . . . . . . . . . . . . . . . . . . . . . . . . 54

6.1.2 Technologies used . . . . . . . . . . . . . . . . . . . . . . . . 54

6.2 Future integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6.3 Future development . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

6.3.1 MSRP Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

6.3.2 IMS Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

6.3.3 Java Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

7 Results 60

7.1 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4



7.2 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Bibliography 62

A Links 65

B Establishing SIP focus session 66

B.1 Alice creates the session . . . . . . . . . . . . . . . . . . . . . . . . . 66

B.2 Alice creates a state subscription to the session . . . . . . . . . . . . 70

B.3 Alice invites Bob . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

B.4 Bob invites himself and joins . . . . . . . . . . . . . . . . . . . . . . 71

C Class diagrams 73

C.1 MSRP stack API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

C.2 MSRP stack implementation . . . . . . . . . . . . . . . . . . . . . . 73

C.3 IMS stack API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

C.4 IMS stack implementation . . . . . . . . . . . . . . . . . . . . . . . . 73

C.5 Java client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

D Activity diagrams 87

E State diagrams 91

E.1 MSRP stack API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

E.2 IMS stack API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

F Sequence diagrams 94

5

List of Figures

2.1 IMS functions overview . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.2 Different modes of operation for the SIP-AS . . . . . . . . . . . . . . 24

3.1 SBC on private/public network border . . . . . . . . . . . . . . . . . 29

3.2 The SIP-AS function with MRFC and MRFP . . . . . . . . . . . . . 33

3.3 RTP mixer in a 3-part conference . . . . . . . . . . . . . . . . . . . . 34

4.1 Network with SBCs . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.2 Network with multi-host components . . . . . . . . . . . . . . . . . . 37

4.3 Deployment example . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.1 Model-view-controller architecture behind the java client . . . . . . . 50

6.1 Present deployed network . . . . . . . . . . . . . . . . . . . . . . . . 55

6.2 Future extension examples . . . . . . . . . . . . . . . . . . . . . . . . 56

6.3 Client screen shot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

C.1 MSRP base class diagram . . . . . . . . . . . . . . . . . . . . . . . . 74

C.2 MSRP header class diagram . . . . . . . . . . . . . . . . . . . . . . . 75

C.3 MSRP packet class diagram . . . . . . . . . . . . . . . . . . . . . . . 75

C.4 com.atosorigin.msrp package class diagram . . . . . . . . . . . . . . . 76

C.5 com.atosorigin.msrp.data package class diagram . . . . . . . . . . . . 77

6


Leonard BromanLIST OF FIGURES

C.6 MSRP header implementation classes . . . . . . . . . . . . . . . . . 78

C.7 MSRP packet implementation classes . . . . . . . . . . . . . . . . . . 79

C.8 javax.ims package classes . . . . . . . . . . . . . . . . . . . . . . . . . 80

C.9 javax.ims.core package classes . . . . . . . . . . . . . . . . . . . . . . 81

C.10 javax.ims.core.media package classes . . . . . . . . . . . . . . . . . . 82

C.11 javax.ims.resource package classes . . . . . . . . . . . . . . . . . . . . 82

C.12 SipServlet API classes . . . . . . . . . . . . . . . . . . . . . . . . . . 83

C.13 SipServlet focus for MSRP conference sessions class diagram. . . . . 84

C.14 Java client controller classes . . . . . . . . . . . . . . . . . . . . . . . 85

C.15 Java client view classes . . . . . . . . . . . . . . . . . . . . . . . . . . 86

D.1 Message handling of the MSRP/SIP focus server . . . . . . . . . . . 88

D.2 Client initiating the MSRP stack . . . . . . . . . . . . . . . . . . . . 89

D.3 Client subscribing to focus state information . . . . . . . . . . . . . . 90

D.4 Client joining an SIP focus and an MSRP session . . . . . . . . . . . 90

E.1 MSRP Channel (TCP connection) state diagram. . . . . . . . . . . . 91

E.2 Originating UE state diagram . . . . . . . . . . . . . . . . . . . . . . 92

E.3 Terminating UE state diagram . . . . . . . . . . . . . . . . . . . . . 92

E.4 Publication state diagram . . . . . . . . . . . . . . . . . . . . . . . . 93

E.5 Subscription state diagram . . . . . . . . . . . . . . . . . . . . . . . 93

E.6 State diagram for the life cycle of a Media . . . . . . . . . . . . . . . 93

F.1 Network level session sequence . . . . . . . . . . . . . . . . . . . . . 95

F.2 Software level session sequence . . . . . . . . . . . . . . . . . . . . . 96

7


Leonard BromanLIST OF FIGURES

Acknowledgments

I would like to thank Regis de la Broise for supervising my project at Atos Origin,helping me with guidance, discussions and proofreading.

My internship supervisor at the University of Rennes, Professor Cesar Viho whomade my internship and thesis work possible in France by accepting me as a studentat his institution.

My thesis supervisor at Lulea University of Technology, Kare Synnes.

My family and the family of my beloved girlfriend for supporting me during mytime in France.

Celine Schmidt for receiving me with open arms and taking care of me during myfirst trembling steps on French soil.

My collective friends and their friends for accepting me and helping me during mytime of integration into the French society.

8

Chapter 1

Introduction

1.1 IP Multimedia Subsystem

The IMS architecture provides a multi-service, multi-access and multi-session IPnetwork which offers enablers to real-time, pseudo real-time and reliable-transmissionapplication servers. The architecture also allows IT actors to take a more importantplace than before in the development of the communication services.

1.2 Assignment background

A large part of the capital expenditures (CAPEX) of the telecom operators in theIMS architecture takes place in the application services and in the integration ofsupplies from multiple providers. The related activities are Atos Origin’s strengths.

In order to be prepared for this new evolution of the communication networks, Atoschose in 2006 to develop strong SIP-IMS expertise by creating a pre-IMS platformwithin its French labs. This platform is used to develop and demonstrate severalValue Added Services based on SIP-IMS capability. Some Added Value partnersand Open Source projects are integrated in some prototypes realized.

The goal is to have a better knowledge of the corresponding technology, a betteranswer to customer expectations and a better understanding of operators businessto help them anticipate the next generation services. Currently an Atos Origincommunication prototype using a soft-phone (standalone VoIP capable application)and an instant messaging application running in a browser exists. This prototypeis based on the following technologies: SIP (using BEA WLSS), Java, Ajax, JSP,Struts, Spring, Hibernate, PostgreSQL. Within this prototype, some IMS functionshave been simulated.

9


Leonard BromanCHAPTER 1. INTRODUCTION

1.3 Problem

The subject of the thesis is to study, identify and test new innovating services takingadvantage of the new capabilities of the IMS architecture. The way to test thesenew services will need to be defined and an IMS platform allowing running thesenew services will have to be built.

1.3.1 Prototype

This platform could be resulting from evolutions of the existing prototype makingit more IMS compliant by replacing some simulated IMS functions by componentsthat will make the prototype interact with a core via the standardized interfaces.These IMS components could consist of Open Source software components actingas IMS components, such as the CSCF (Call/Session control function) and the HSS(Home Subscriber Server).

Additional basic services could be added such as the integration of a presence serverand/or an XCAP server provided by an editor (an Atos partner) or coming froman Open Source project.

1.3.2 Requirements

In order to facilitate demonstrations on the Internet, NAT traversal solutions isalso to be studied. The different ways to achieve this feature should be studied andthe selected solution will have to be integrated with the prototype.

For the prototype platform to be useful in demonstration purposes an importantrequirement is that demonstrations of applications can be performed at locationswhich are not completely bound to geographical locations. At least the aim is tohave a goal where two clients on visited network may communicate. In this case,between a local private network and the public routable network.

This means that one private network should host the IMS home network, whereuser profiles are stored and the IMS mechanisms come in action. The only SIPinterfaces outside the home network is via the I-CSCF and media via the MRFP.

Network restrictions

The two networks involved in this case are the local private network and a remoteprivate network. They both reside behind NAT and has a DMZ (DeMilitarizedZone). However, a host in the DMZ may not connect to a host in the privatenetwork. In this case even the DMZ is behind a NAT, although the address spacebehind the NAT is not in the private range and potentially routable, they havehowever an external representation.

10



1.3.3 Summary

To summarize, the objectives of the thesis is to

• Analyze the present demonstration platform to determine its re-usability andextensibility.

• Integrate a prototype platform providing the CSCF and HSS IMS functions.

• Enable IMS instant messaging services on the IMS platform.

• Propose a solution reducing or eliminating connection issues concerning net-works behind NAT.

• Design and implement necessary missing software components to enable in-stant messaging services.

• Add, or suggest possibilities to add, additional services to the IMS platform.Most notably presence services and group management.

1.4 Emphasis

The subject of IMS is very vast and in term of research, design and development,it covers an area which is beyond the scope of this thesis. Therefore the emphasisof this work will be limited to certain aspects in IMS, summarized as

• The study of the core IMS system and services

• The study and deployment of instant messaging services in IMS

• Theoretical study and solutions of network topology issues for IMS deploy-ment on unmanaged networks.

1.5 Definitions

The base of this work is mainly specifications and proposals from organisations likeIEEE, IETF, 3GPP and ETSI. They are not only very dubbed in using acronymsand abbreviations aggressively (perhaps due to necessity) but they also tend todiffer in vocabulary between the organizations. I therefore see a great need of prepending this report with a list of definitions of words, expressions, acronyms andabbreviations. The ETSI also has its own vocabulary list [18].

11



1.5.1 General abbreviations

ETSI European Telecommunications Standards Institute

3GPP 3:rd Generation Partnership Project

TS 3GPP Technical Specification

IETF Internet Engineering Task Force

RFC Request For Comments

IMS IP Multimedia Subsystem

QoS Quality of Service

1.5.2 IMS abbreviations

CSCF Call/Session Control Function, SIP routing network routing component.

P-CSCF Proxy CSCF, IMS network entry point

I-CSCF Interrogating CSCF, inter-network routing component

S-CSCF Serving CSCF, service aware router and registrar

HSS Home Subscriber Server, subscriber information database

SLF Server Locator Function, registered user to S-CSCF mapping

MRFC Media Resource Function Controller, signaling layer media server

MRFP Media Resource Function Processor, media layer media server

MGCF Media Gateway Control Function, inter-network media gateway

MGW Media Gateway

UAC User Agent Client, originating user agent

UAS User Agent Server, terminating user agent

UE User Equipment, the end terminal where a client interacts with the IMS

UMTS Universal Mobile Telecommunication System (3G)

GGSN Gateway GPRS Support Node

OSA-CSC Open Service Access – Service Capability Server

IM-SSF IP Multimedia Service Switching Function

TP Trigger Point, logic expression identifying SIP packets

iFC Initial Filter Criteria, pairs binding trigger points to application servers

12



1.5.3 Protocols

SDP Session Description Protocol [21]

SIP Session Initiation Protocol [10]

MSRP Message Session Relay Protocol [6]

Diameter Authentication, authorization and accounting protocol [14] [24]

RTP Real-time Transport Protocol [8]

UDP User Datagram Protocol [30]

PIDF Presence Information Data Format [9]

RPID Rich Presence Information Data format for presence [38]

XCAP XML Configuration Access Protocol [36]

AKA Authentication and Key Agreement [4]

13

Chapter 2

IP Multimedia Subsystem

IMS is the response by 3GPP (3:rd Generation Partnership Project) to the clearcommunication evolution where data transport and communication services aregoing to separate. IMS provides a flexible and modular way of controlling andproviding services to the clients. The IMS network lives on top of a general datatransport network, either IPv4 or IPv6. The network is defined as functional nodes,gateways and interconnects and the actual specification does not require functionsto be implemented in particular fashions, only which protocols they follow.

The IMS is specified within numerous documents by ETSI (European Telecommu-nications Standards Institute) and IETF (Internet Engineering Task Force). Thisbecause IMS provides a way to use existing open technologies and ties them alltogether, to answer needs of service providers and for the flexibility of User Equip-ment.

IMS is usually said to consist of a signaling plane and a media plane. They bothreside on the general network and they are not depending on each other. Theyare however both necessary to provide IMS services (with the special exception ofservices using only the signaling plane).

This chapter roughly presents the general functionality and technologies involved.

2.1 IMS signaling

Two main protocols are used for the signaling part of IMS. SIP for the interconnectof UE (User Equipement) and management of communication. Diameter is used forAAA (Authentication, Authorization and Accounting) in the network to supportthe network functions with user information and billing capabilities.

14


Leonard BromanCHAPTER 2. IP MULTIMEDIA SUBSYSTEM

2.1.1 SIP - Session Initiation Protocol

SIP has become very popular for VoIP (Voice over IP) services since it is an openprotocol which has reached broad recognition and many free and open source soft-ware solutions exists (see Appendix A). SIP provides the functionality of settingup, managing and tearing down sessions between clients in the network and is gen-erally transport protocol agnostic. The main functionalities in SIP are specified inRFC 3261 [10].

Within IMS, SIP has extensions to provide signaling for the QoS functionality.For the UE the SIP part strictly follows the specification and theoretically themechanisms of IMS is transparent for the terminal application. But within theIMS network, the SIP signaling is managed to adapt the client communication tothe underlying network, to control subscriptions and billing functions.

2.1.2 Diameter

For the service and/or network operator to control the usage of services and theconnectivity of users the network uses the functionality of Diameter. Diameter is aAAA protocol defined in RFC 3588 [14]. It is a successor to RADIUS (RFC 2865[31]).

It is used in a number of forms, named interfaces, between the different functionsof the IMS network. This to provide the specific information at the points wherethey are needed. This report covers Diameter very lightly since it focuses on serviceenabling, signaling and media transports.

2.1.3 Quality of Service

QoS is provided by interfacing the IMS components towards components in the dif-ferent network architectures which provides QoS functionality. This is mainly doneby P-CSCF which has the knowledge of the local network and a policy descriptionfunction attached to regulate the use of QoS. One example of this is a P-CSCFproviding IMS connection in a UMTS network. The P-CSCF tracks establishmentof session to terminals in the network and controls the UMTS GGSN to open andclose streaming channels to the clients.

To provide easier QoS setup in networks SIP session negotiations in IMS usesPRACK (PRovisional ACKnoledgment) to separate session acceptation and codecagreement from network specific negotiation.

15



2.1.4 Security

For clients registering its location to the “registrar” (the S-CSCF in IMS) a chal-lenge authentication is of course required. This is done with the HTTP digestfunction to avoid sending the shared secret over the public network [19]. Specifi-cation for sending clear-text passwords exists but is strongly discouraged and mostSIP software suites does not allow it.

Network authentication is done using the AKA [4] protocol. This way the clientcan authenticate the connection to the home network when in a visited network.This is done using a shared secret and a sequence number.

To encrypt inter IMS traffic TLS can be used. TLS is depending on certificateswhich makes it more powerful between stationary units such as proxies. TLS canhowever still be used as a SIP encryption method for clients, although it does noteasily permit the use of certificates to authenticate clients.

For an even higher degree of encryption, provided by network borders (perhapsregulated by an SBC, see Section 3.4) provides a more general encryption of allUE traffic between networks. This is transparent but requires a more complexconfiguration and maintenance between each interconnected network.

2.2 Single client services

The different services in the IMS network can roughly be categorized as single- andmulti-client services. In the case of single client services we have all those that atthe point of service access only involve one user. These are functions like centralizedconfiguration information, presence monitoring and call forwarding.

2.2.1 Client configuration data

The client will most probably need and want to store data on the network insteadof its (many) devices. This can for example be contact and group lists, chat andcall history. Maybe even personalized themes and media.

This together with information which controls network behavior towards otherclients, such as call forwarding, availability and preferred terminals for certain typescommunication medium is all stored on an XDM (Xml Document Management)server and configured from the client via the XCAP (XML Configuration AccessProtocol) protocol, defined in RFC 4835 [36].

16



2.2.2 Presence service

Presence information is being regarded as vital information in today’s communica-tion systems. The presence handling in IMS is defined in TS 23 141 [15]. It is mainlybased in Application Servers handling PUBLISH (RFC 3903 [27]) , SUBSCRIBE andNOTIFY (RFC 3265 [32]) requests from user agents, however an important featureis the ability to subscribe to a resource list in an RLS (Resource List Server). Theresource list is manipulated by the client via XCAP. The XCAP server may thenprovide the resource list via a URI to the presence server.

Presence servers normally operate using internal presence documents [9]. The pres-ence document contains the presence information for a certain presentity, the UA(User Agent) publishing presence information. The document is updated by thepresentity using the PUBLISH SIP method [27], containing the presence documentfor the presentity. When the presence server receives this update it sends out notifi-cations, using the NOTIFY [32] method, to all UAs which have previously subscribedto the presentity using the SUBSCRIBE SIP method [32]. The NOTIFY may containeither the entire presence document or an update (diff) from the previous version.

In IMS many different type of notification services is provided, not only presence.For each such service an “event package” is defined, which specifies which infor-mation is provided. For user presence, using RPID or PIDF presence documents,the “presence” package is used (RFC 3865 [33]). The S-CSCF holds a specialpackage, “reg” (RFC 3680 [34]), to which P-CSCF subscribes to be able to refuseclient packages if the client is not registered. The registration state may also beused by registered clients to monitor their own registration, in the same manner asportable devices today monitor signal strength and roaming network. For focuses,the package “conference” (RFC 4575 [12]) is provided as mentioned in Section 3.6.2.

Application servers holding pager-mode messages for offline clients can also choseto subscribe to notifications when that users comes on line. In this case the MessageApplication Server acts as a User Agent in the presence system.

2.3 Text services

Instant message service mechanism in IMS is covered in TS 124 247 [16]. Thiscontains the methods and actions taken by the functions in the IMS system tohandle pager-mode, session-mode and session-mode conference instant messaging.

2.3.1 Pager-mode instant messaging

This is like good old way of sending messages like SMS. You send one and (maybe)get a delivery report when the destination has received it. This is generally calledpager-mode messaging and is deemed to be session-agnostic unless some client de-veloper intends to build a client handled and dependent session based messaging

17



on it. This is generally a bad idea.

This is done using the SIP MESSAGE request. The S-CSCF should deliver theMESSAGE request to an AS for handling. The AS determines the current state of therecipient. It should determine whether the message can be delivered at the momentand to which terminals which the user is registered to it should be delivered. Thereceiving terminal(s) must have registered support for MESSAGE in the HSS. If themessage cannot be delivered at the moment, action will be taken later when thereis a terminal capable of receiving it. Failure should be reported when the messageexpires, this is set by headers by the sending client (and might be moderated bythe AS). Delivery report of page messages is done using the default SIP responsecodes, i.e. 200 OK for successful delivery. The SIP MESSAGE method is an initialSIP request and thus subject to SIP proxy forking. If the AS chooses to fork themessage to multiple receiving terminals, it will still only report one SIP responseto the sending UA. (RFC 3428 [5]).

2.3.2 Session-mode one-to-one instant messaging

This is, with today’s aspects, the general way of doing instant message textualcommunication. Using a chat session with exactly two participants. This is donein IMS by setting up a SIP session between the terminals and using a direct mediaconnection or connecting directly via UE chosen by the terminals.

In IMS the media layer for session based instant messaging is MSRP [6] runningon TCP.

2.3.3 Session-mode instant message conferencing

A conference session is a session based textual communication where the numberof participants are two or more. One-to-one can because of this be considered aspecial case of conferencing and considered to be the general future form to use.However, for interoperability reasons we must assume that other terminals may notcompletely support the one form or the other.

Using a MRFC (Media Resource Function Controller) and a MRFP (Media Re-source Function Processor) as relays and session managers to establish connections.In this case, the MRFC is an AS which handles and manipulates invites to directUE to the MSRP MGCF instead of to the end clients.

Camarillo suggest in chapter 19.2 [3] that it is for each UE to perform SIP INVITE

to the MRFC and for the MGCF in turn to perform the MSRP connection to eachUE. Poikselka [28] extends this idea briefly in chapter 8 by introducing the conceptof tightly coupled conferences using a focus session concept. Requirements of thefocus is defined in RFC 4245 [23].

Section 8 and 9 in TS 124 247 [16] covers the specification of SDP session creationand MSRP session progress, respectively. This specification must be followed for

18



any IMS terminal supporting the feature.

2.3.4 Single-client text services

Text services such as searching for train departures or having asynchronous informa-tion sent to your device can be implemented using either session based connectionsto information “bots” or as pager-mode messages for requests and responses.

2.4 Audio and video services

Audio and video conversation is the classic way of human interaction. Audio has fora long time formed the very foundation of human interaction over distances sincethe telephone was invented. We will without any doubt continue with this. To addto this the communication industry has for a long time been trying to introducevideo services. This has never reached any broad use, although most clients are notopposed to using it.

2.4.1 Single client media service

In IMS there is nothing limiting the client from receiving audio and video mediawhich does not originate from a conversation. Music, pictures and movies can bedelivered from the IMS system, just as an ordinary media stream. For this servicethe SIP-AS will act as a UA see Section 2.5.4. The system will provide a MRFCand a MRFP, where the MRFC is the actual AS. The client establishes a sessionto the UA, which then would have a SIP-URI, like perhaps sip:[email protected], andthrough the media connection have access to media content by the service provider.

2.4.2 Multimedia conversation session

Today, the most common way of telecommunication is in one-to-one conversations.This is most likely due to traditional services supplied by the telecom serviceproviders. This is also one of the simplest services to provide in the IMS net-work. In this case the SIP-AS works as a proxy, see Section 2.5.4, transparent tothe UE which setup their media connection as a usual SIP initiated media streamsession. The AS main function is to provide billing functions to the sessions. TheAS can also provide, by SDP manipulation, transparent RTP proxy incorporationsolving issues with UE on NAT networks. Using a B2BUA (Back-to-Back UserAgent) AS is also a solution where separate session are maintained between thetwo participating UA.

19

mailto:@ims.net



2.4.3 Multimedia conference

The conference perspective of media services is a much more complex situationthan for textual conferences. The AS operates as a B2BUA (see Section 2.5.4)providing a focus session in the signalling layer and an RTP mixer in the mediaplane. Real-time media will not be covered in more detail as it is out of scope forthis thesis.

2.5 System topology

Figure 2.1 shows a general overview of some of the functional nodes in the IMS net-work. It is important to understand that there is a big difference between a networkfunction and an actual piece of software or machine running and performing it. Oneserver, in the aspect of machine or software, can perform many functions or onefunction can be spread over multiple machines with any non-defined interconnectin between them. As long as the function rest atomic in the network view, this isvery possible. Later on, the network functions will be put onto pieces of softwareperforming them, which somewhat will change the view of the system. Here, thetasks of certain functions are presented.

P - C S C F

I - C S C F S - C S C F

P - C S C F

S B C

S L F H S S

S I P - A S

M R F C

M R F P

T e r m i n a l /U s e r E q u i p m e n ti n h o m e n e t w o r k

T e r m i n a l /U s e r E q u i p m e n ti n v i s i t e d n e t w o r k

M G C F

M G W

P S T N /O t h e r n e t w o r k

S G W

D i a m e t e r s i g n a l i n g p l a n e

S I P s i g n a l i n g p l a n e

M e d i a p l a n e

Figure 2.1: Overview of the basic functions in the IMS network

2.5.1 Call/Session Control Function

The CSCFs provide the main signaling functions for the UE. From the UE per-spective it is just a set of SIP proxies and registrars and provides for the UE the

20



possibility to locate and set up session to other UE. The CSCF are split into threefunctions, P, I and S. For proxy, interrogation and serving, respectively.

Proxy - CSCF

For each IMS network, the proxy is the entry-point for the UE. Its function isobviously just a proxy for the UE but within the IMS network it carries manymore functions. For a visited network, its service provider has the chance to keepcontrol over its network resources and traffic thanks to the mandatory traversal ofthe proxy. One might think that in a free IP network the proxy in visited networksis useless, which is right, but the service provider has the possibility to enforce itdue to this network topology.

To provide the control over network resources, we might assume that some clientis connected to IMS via a proxy in a visited network (or maybe even the homenetwork). This network may be behind a NAT or heavily filtered to enforce P-CSCFtraversal. When setting up sessions, the P-CSCF provides two major mechanisms.It lets the network service provider have control over network resources used byclients of the service providers. It also gives the ability to proper control of theSBC (Session Border Controller), see Section 3.4, component and other networkspecific gateways during session negotiation. The SBC serves a purpose of mediaproxy where it lets packages traverse NAT obstacles, it opens channels in otherwisefiltered firewalls and foremost it provides the mechanisms of QoS on the medialayer. Other components can be support nodes which enables IP traffic with QoSin cellular networks.

Interrogating - CSCF

The I-CSCF provides the entry point to a home IMS network. For any P-CSCFresiding in visited networks, they will forward request to the UE home network viathe I-CSCF. The I-CSCF is located via DNS and has to be on the public routablenetwork. The I-CSCF has information about S-CSCF in the home network andalso knows how to contact UE residing in visited networks. It is also capable ofauthenticating incoming requests, and deny them if the client is not welcome.

Up to 3GPP release 6 the I-CSCF also provided topology hiding and the maingateway control functions at the entry point of the Home IMS system. In release7 this function has been separated from the I-CSCF and has been assigned to aparticular function namely the I-BCF (Interconnection Border Control Function),which provides similar functionality as the SBC, see Section 3.4.

Serving - CSCF

In the home network the S-CSCF is the main manager of SIP-signaling betweenUAs. The S-CSCF provides all the filtering need for propagating SIP-messages

21



their respective application servers and it also holds information about clients invisited network. All SIP traffic related to a certain client passes the S-CSCF in thehome network.

For all initial SIP requests the S-CSCF applies a set of routing rules provided by theHSS for each subscriber. This rules-set is called a subscriber profile and containsan order lists of Initial Filter Criteria (iFC). Each iFC contains one trigger pointand one application server. The trigger point contains a set of logical expressionswhich is used to analyze the request, looking at request method, URI, headers andcontent. If the logical expression matches the request it is routed via the applicationserver attached. After the request has been processed by the application server theS-CSCF continues processing the IFC list.

2.5.2 Home Subscriber Server

The HSS is basically a database storing user-related data. If a network has multipleHSS a SLF (Subscriber Locator Function) is required to locate the necessary dataand preferred S-CSCF.

2.5.3 Media Resource Function

The MRF provides media resource services in the network. Examples of such ser-vices may be streaming media and conference sessions. Common for those servicesare that the UE sets up a SIP session to an AS and accesses the media resource onthe media plane.

The MRF is split into two parts, MRFC (MRF Controller) and MRFP (MRFProcessor). The MRFC resides in the SIP signaling plane and has also access tothe HSS. The MRFC can be implemented directly as a SIP application server. Thesecond part, the MRFP resides in the media plane and serves the client/UE withthe media content. The interconnect between MRFC and MRFP is undefined andthey may be implemented as one piece of software fulfilling the functionality of SIP-AS, MRFC and MRFP. There exists however a IETF draft (now expired) proposinga protocol MSCP (Media Server Control Protocol) [25] to provided a standard forthe MRFC-MRFP interface.

2.5.4 Application Server

There are three types of application servers; SIP-AS, OSA-SCS, IM-SSF. Only theSIP-AS will be covered here since it is the most flexible and least complex. TheApplication server provides for the service mechanisms in the IMS network. EachSIP-message traversing the S-CSCF is subject to a filter-set which may reroute themessages to one or many AS serving different services. The SIP-AS may operatein three different roles; user agent, proxy and Back-to-Back user agent. Figure 2.2shows a simple view of the three roles.

22



User Agent mode

For services where the a session is established between the UE and the AS the ASacts as an UA towards the UE and is also viewed as one from the UE point of view.This is useful for services involving only one client. For example a film-streamingservice might be addressed with sip:[email protected] to which the UE establishes aSIP session to access media streams (on the media layer) on an MRFP.

Proxy mode

For services which take form of one-to-one sessions between end-clients, the AS isoften an interceptor and manager of the SIP-sessions. Upon session setup, the ASwill handle the Authentication, Authority and Accounting for the clients involved.The AS of course has the possibility to deny services, and to interrupt them. Ifan AS decides to interact as proxy in the SIP Dialog it must add itself to theRecord-Route header of the initial request. This way clients are aware of thetraversal but not of its effects.

An example application for proxy AS is a billing proxy. It keeps track of conver-sations and reports, via the Diameter interface, call starts, destination, ends andother interesting information (geographical information, identity usage, etc). Forthe online charging case it may refuse a call and end it prematurely when the callerhas no more credit.

Back To Back user agent mode (B2BUA)

In services involving two or more UE this model is used to manage for exampleconferences. In this case each UE has one established SIP-session towards the ASwhich acts as a UA to each. The AS then has abilities such as inviting more UE,disconnecting UE and charging for service usage.

An important ability for a B2BUA is also to be able to redirect calls in a clienttransparent way. This is useful for call-centers where a calling party may firstperform certain choices via DTMF, then be in a waiting line with some fancy musicand finally arrive at an operator. For the UE this is only one SIP session but theB2BUA may jump between many on the other side.

2.5.5 Media Gateway Function

For interfacing IMS with other communication networks there is a need for gate-ways. In the case if IMS the media gateway is split into three parts; media gatewayfunction controller (MGFC), media gateway (MGW), signaling gateway (SGW).Those three components provide the signaling and media interworking between thenetworks.

23

mailto:@ims.net



U A

U A

U A

U A

B 2 B U A

U E

U E U E

U E

U E

U E

U E

U A

P r o x y

Figure 2.2: Different modes of operation for the SIP-AS

The perhaps most common usage of this is the interconnect between IMS and PSTNallowing IMS client to make calls to the old telephone system, and vice versa. Asa possible example for instant messaging emphasis such a gateway may providepresence, contacts and chat-rooms between IMS and other IM protocols such asXMPP/Jabber and Oscar/ICQ.

24

Chapter 3

Technical aspects andsolutions

This chapter covers the technical solutions and considerations which have to betaken into account; on the basis of today’s structure of the Internet and entitiestying it together, serving and restricting it.

3.1 Network restrictions

IMS was in its early stages supposed to run on IPv6 networks, where UE addressingdoes not pose a problem as in IPv4, where address space has forced the Internetsystems into radical measures. The delayed adoption of IPv6 has forced the IMSwork groups to adapt IMS to work with IPv4 systems as well. The main issue isnetwork topolygies containing NATs. IMS does not present any soutions on howsuch networks restrictions should be handled, it has however been considered andis mentioned very briefly in Annex G of TS 23.228 [17].

It has to be mentioned that at a grand deployment stage, most IMS networks willrun on transport networks restricted to such a degree that it can be considered tonot be apart of the general Internet but built exclusively for IMS. This is mainlydue to the willingness to be able to control services on the network and to keepcontrol over complex mechanisms such as QoS and priority. It must also be assumedthat IMS network providers does have control over the transport network they arerunning on.

25


Leonard BromanCHAPTER 3. TECHNICAL ASPECTS AND SOLUTIONS

3.2 Network Address Translation

Currently most mobile networks providing Internet connections do so by usingNATs (network address translation) [39]. Those provide extended address spaceswithin private networks who are not routable from the public Internet.

Generally, the types of NAT that exists impose a certain level of restriction. Thecone NAT maintains a mapping based on previous traffic from a source on theprivate network to an address and port on the public network. The mapping isinitiated when a packet passes the NAT to the public network and is dropped aftera certain timeout. Any packet arriving from the public network on that port willbe translated and sent to the host on the private network, thus allowing traversal ofthe NAT if the host in the private network knows its public IP, there are multipletechnologies to solve this, using STUN, ICE, TURN or information in SIP messages.

The “worst” kind of NAT is the symmetric NAT. This type of NAT saves additionalinformation in the mapping and filters out packages which do not have the samesource address and port (public) as the destination of the originating packet. Thisrestricts the host on the private network to only being able to communicate tohosts it can establish a connection to. Thus, the private host can only connect to aroutable address on the public address space and two private hosts can never reacheach other.

3.2.1 NAT and UDP

There exists multiple protocols for providing traversal over NAT. Mainly, this is animportant feature for audio and video media using RTP [8] when providing suchservices over Internet. RTP over IP is a user-space extension to UDP. It addsframing mechanisms where sequence and timestamp information is incorporated(this does not exist in UDP). The protocol permits for many media streams tobe transmitted over one RTP stream and to send data stream information andfeedback in a separate stream (RTCP, RTP control protocol).

STUN is defined in RFC 3489 [11] and provides functions such as determining aclient connection to the public IP address space. The protocol helps determiningproperties of the connection, such as filtering and presence of NATs and theirproperties. It also provides information to the client of its public address. Thispermits a client behind a NAT to offer its routable address during SDP negotiatingand may thus permit UDP hole punching attempts.

TURN is still an “internet-draft” currently documented in [13]. It provides means ofallowing any client to connect to any host, even on a private network, independentof protocol or NAT type. The main principle is to provide a dynamic way of settingup a relay on a public routable address. This is of course costly for the provider ofthe TURN server and may cause longer propagation delays.

ICE, just as TURN is also still in drafting, see [37]. ICE is a protocol defining aprocess to use STUN and TURN to provide NAT traversal for offer/answer session

26



initiation. The method is fairly complex and there is nothing in IMS that specifiessupporting it (as with STUN and TURN) and the IMS network has to be ICE-awarenot to start billing users for calls not made etc.

Many proprietary solutions use hole-punching to ease up NAT traversal. The tech-nique is very simple. Both endpoints perform multiple re-sends and accepts initialfailures to establish the association in the NAT. This method is however completelyclient specific.

RTP proxy

Providers of SIP based VoIP services use a fairly simple solution to avoid NATissues. This solution is provided by two open source community products, RTPProxy and Media Proxy (see Appendix A). Their function is very simple. Theyintegrate with an outbound SIP proxy which performs SDP manipulation to routeUDP traffic via the proxies. This is completely transparent to the client and theyalways send their media to and from the public routable proxy.

Extreme case: asymmetric client

There is yet one even worse case where not even the proxy based systems helps;asymmetric clients behind NATs. An asymmetric client is a client which sends andreceives UDP data on different ports, for a certain session. This is possible sinceUDP does not create any connection state but just sends datagrams and lets theclient handle the datastream. Due to this the outgoing connection does not createany associations related to the incoming stream, independent of the NAT type.Thus the incoming packet stream cannot be mapped back to the proper UA. Thiscase is out of scope of this thesis and will not be covered any further.

3.2.2 NAT and TCP

Since TCP is connection oriented (as opposed to UDP which uses datagrams) itcan not easily trick NATs to let it traverse. Hole punching is something that issometimes used but rarely works. Any type of state-full TCP information in theNAT router causes TCP hole punching to fail. TURN is of course a general solutionto this, but as mentioned in the previous section, it is bandwidth and time costly. Italso adds yet another layer that clients and network has to be aware of and support.

3.3 General requirements in restricted networks

Restricted networks containing IMS entry-points have to provide for their visitingclients to utilize IMS services. For general network access it is simply required thatthe UE is on a network that “supports” IMS. Either a restricted network with an

27



P-CSCF and SBC, covered in Section 3.4, or on the public Internet with knowledgeof at least one public P-CSCF.

As a general point of view this is of course a network requirement but it might notsuffice in our case where we have limited control over the network due to policies.

3.4 Generic solution to IMS on restricted networks

As an IMS network provider normally has control over the underlying transportlayer network, it can, and should, deploy network mechanisms which lets a clientinterface transparently over the IMS network without the need to use methods likeSTUN, TURN and ICE. This general system is called the Session Border Controller,SBC.

3.4.1 Session border controller system topology

The main ability of the SBC is that it has information about both the private andthe public network. This provides the ability for the SBC to act as what could becalled a layer 5 NAT. This is covered more in detail in Section 3.4.2. The SBCmight also have functionality providing QoS and network usage monitoring andrestrictions. Figure 3.1 shows a typical visited network. It has a P-CSCF, which isreachable and the only IMS point that the UE sees. The UE finds the P-CSCF viaDHCP information or DNS resolve. In the figure both a GGSN and a general SBCis shown. The P-CSCF provides information to the SBC and GGSN by relayingSIP messages via them. The normal SIP communication traverses the NAT, tocorresponding I-CSCF, as usual.

Since release 7 a function of the I-CSCF have had one function separated from itwhich is now called IBCF (Interconnect Border Control Function). It has similarfunctionality as the SBC but mainly provides inter-IMS-network encryption andnetwork resource policy enforcement.

3.4.2 SBC as NAT/Proxy

To provide a transparent network for the UE in the IMS the SBC monitors andmanipulates the SDP information for session establishment. In this way it willtransparently place itself as a media proxy between the two participating parties.When a UE on the private network sends an INVITE the SIP messages traversesthe SBC. The SBC stores the given data reception information for the UE andreplaces it with an assigned public address, of the SBC itself. When the OK fromthe opposing party arrives it may also, if it is necessary, make the same mappingfor outgoing data. Finally, when the ACK passes the SBC it opens the necessaryports for the media.

28



P r i v a t e I P n e t w o r k

P u b l i c I P n e t w o r k

P - C S C F

S B C

N A T

G G S N

S I P

I - C S C F

G e n e r i c m e d i a s t r e a m

Q o S d e p e n d i n g m e d i a s t r e a m

Figure 3.1: SBC on private/public network border

Generally, the SBC may be incorporated into any CSCF and thus reduce SIPmessage processing and provide a dynamic flow control for security purposes.

3.4.3 SBC for QoS and network resource monitoring

Since QoS may be critical for real-time applications on highly loaded networks,the GGSN provides this functionality in a similar fashion as an SBC. Althoughthe GGSN provides a more particular functionality. This component interfacestowards the local networks QoS enabling facilities and provides a means for thenetwork provider to monitor and regulate network usage.

The major extension to SIP to provide QoS support and resource reservations arethe extended form of session establishment using provisional responses. This splitsthe session establishment into two phases. First the initial INVITE is sent. Theresponse to this invite determines whether the peer accepts the session and whichcommon codec’s to use. The response is a PRACK (PRovisional ACKnowledge-ment). In the next phase the originating UE sends an UPDATE which is, if neces-sary, manipulated by SBC and Gateways to provide correct IP and port mappingsfor network resources. This determines the media path.

3.5 Volatile networks

Future IMS clients will live in IP networks connected to the Internet using cellu-lar networks (beginning with 3G). Those networks are subject of being extremelyunstable and unreliable. At any point a connections might be lost (i.e. passingthrough a tunnel) or the host IP and network route may change (i.e. networkroaming access).

29



3.5.1 Signaling connection instability

Today SIP applications are used on stable networks connections. The IETF RFCsoften suggest default timeout constants in their standardization documents. Thosenumbers are often in the order of hours. This is of course not applicable to IP incellular networks, where the connection is subject of changes as soon as the clientis changing location. For those networks the timeout should be in the ranges lessthan a minute. The client is then required to refresh their registration and theirpublished presence information constantly.

3.5.2 Media connection instability

The SIP UPDATE method provides the signaling means to change media connectiv-ity as the IMS devices traverses networks. It requires high awareness of possiblenetworks changes in the IMS device to be able to predict and prevent connectionloss.

Real-time media

RTP transmission carrying audio and video must function seamless in roamingsituations. This is a known problem since the very first packet switched cellularnetworks. Since IMS operates in the application layer of the IP stack it increases thecomplexity of media reliability in roaming situation. This increases the demandsboth for the transport network as well as the IMS media and signaling networks.

In many cases the real-time media does not suffer from the same restraints asreliable media. When passing through short tunnels or losing the stream for shortermoments it does not impact the user more than today’s GSM systems does.

Reliable media

Reliable media, transmitted over TCP streams can not easily be reestablished andcontinued upon changes in network and any type of connection loss. Using directTCP transmissions in highly mobile IMS clients is most likely an issue to be avoided.

MSRP may be a solution to this. There is no proposed standard for this fromthe IETF but, one might ponder, that letting relays offer buffers for packets beingretransmitted and delivered later when connection is dropped.

These issues may form the subject for a Master Thesis themselves and are somewhatout-of-scope here. The matter will not be covered any further.

30



3.6 Conference sessions in SIP

Extensions to SIP to support conference sessions are in the works, but they are stillon the working table and it might take a long time before we start seeing standardsand implementations supporting it. The IETF MMUSIC working group is lookinginto this. Therefore, were not going to get involved into this at the moment.

At present, many proprietary solutions has been developed for providing conferencesessions within SIP, such as Genesys ACD and Streamwide SVI (see Appendix A).This is done using the focus session concept where one client, be it a participatoror a server acts as a focus, letting many connect to it and informing the others.The focus session is just what SIP-AS B2BUA is all about, see Section 2.5.4.

SIP focus conferencing has been so widespread that IETF issued RFC 4245 [23]to define requirements of this model. This to regulate future implementations andpermit higher degree of interoperability. Later IETF specified the conferencingin SIP in detail in RFC 4353 [35]. However none of these RFC’s are standardstrack and does not actually specify in detail how focus mechanisms should work inpractice.

Although very shallow, Both Camarillo (chapter 19.2 [3]) and Poikselka (chapter 7[28]) touches this concept in IMS. Camarillo only discusses the SIP-AS as an entityto where clients invites themselves but Poikselka touches the concept of a focus andsuggests an IMS compliant SIP aspect. He does however not go into depth coveringsession information exchange or authorization.

3.6.1 Creating the focus/session

The actual traffic sent is covered in detail in Appendix B.

The session is initiated by a UE which wishes to participate in a conference with oneor more other participants. The UE generates a conference URI via a conferencefactory. The conference factory may have a sip uri like sip:[email protected]. Thisprocess is done by sending an invite to this address. At this point, the S-CSCFmust determine which SIP-AS should handle this request, depending on the URIand the media suggested in the SDP offer.

The conference factory in this case is the application server. It will respond to theINVITE with an OK with a Contact header which is the URI of the session. TheURI should contain the parameter isfocus to indicate that it is a focus. At thispoint the application server also takes measures needed to set up media resources,such as for MSRP, see Section 3.7.

In Section 5.2.1 a very critical limitation in SipServlet is presented which makesthe use of Contact header for focus URI information impossible.

31

mailto:@ims.net



3.6.2 Subscribing to session changes

To receive notifications about state changes (joins/leaves etc.) in the session eachparticipant must send a SUBSCRIBE. The subscribe should be to the conference URIand the event package “conference”. The focus notifies subscribed clients when theconference state changes according to RFC 4575 [12]. The notifications provideinformation about the conference itself, such as textual information, connectionURIs and media. It also provides information about the current participants, suchas names, contact information and connection status.

3.6.3 Inviting new participants

Inviting other clients to the session can be done in two ways. Either by sending aREFER to the focus, which in turn will invite the URI suggested. Or by sending aREFER to the client, with enough information for the client to invite himself to thesession.

The REFER method is very complex and contains mechanisms to inform the origi-nator of the session progress of the referee. This is not very useful since the focusprovides this information using presence information. An alternative would be toexchange the focus information in a MESSAGE request or using SIP INVITE to thefocus sip-uri.

3.7 MSRP conferencing

Where the SIP focus provides conference management on the signaling plane, thereis a corresponding communication in the media plane. This can be provided in aseries of ways using a distributed relays or central relays. Only the central solutionis covered here since it does not pose any problems whatsoever for hosts behindNATs.

The MSRP session is handled in an MSRP session server. In the IMS system it fallsunder the function of a MRFP (Media Resource Function Processor). To providesecurity mechanisms and not just free-for-all access it may be tightly coupled withits signaling counterpart MRFC (MRF Controller). If implemented as one piecetogether they provide the functions SIP-AS, MRFC and MRFP.

Using the SIP session state information the MRFP can create and destroy sessionsand control who may SEND and VISIT MSRP sessions.

3.7.1 Connecting to the session

From the client side the process of connecting to the MSRP is fairly simple. The UEis responsible for establishing a TCP connection to the MSRP, defined in section

32



M e d i a

M R F C

M R F P

S I P - A S

S I P

Figure 3.2: The SIP-AS function with MRFC and MRFP

8.5 in RFC 4975 [6], since it is the sending the initial offer. This means simply thatthe one sending the initial INVITE, that is, the originating client is the one thatshould provide the MSRP path between the endpoints. The MMUSIC group didpropose methods for negotiating connection direction for TCP session but it wasdiscarded due to complexity.

When the TCP connection is established, the UE sends either a SEND or a VISIT. AVISIT is like a SEND but without content. The VISIT request is not specified in theMSRP standards, however it is commonly used in discussions and Poikselka [28]also mentions it as a method for client to confirm there presence in the media.The message contains a To-Path header containing the MSRP URI sent by theSDP answer from the SIP focus. The From-Path header contains a the MSRPURI sent in the SDP offer, by the UE. This way the two parts can identify theTCP connection as bearer of the messages to that those recipients, using only atemporary credential.

The base MSRP as defined does not contain any extensions for session state moni-toring. The only requests are SEND and AUTH. SEND is replied to with an OK, or anerror response. The MSRP session server only manages the session and relays allincoming SENDs to participators.

3.7.2 Authentication mechanisms

As a MSRP session server can be either central or distributed in the network itdoes not serve well for authentication purposes. If a client uses an MSRP server

33



not on the home network, the session server does not have access to the sharedsecret required for authentication.

Instead, MSRP relays can provide authentication using the AUTH method definedin RFC 4976 [7]. This would require all clients to establish connection and authen-ticate towards the relay in the home network. This would be a potential solutionto one-to-one MSRP around NATs but since we already have a potential solutionno more elaboration is put into this case.

3.8 Audio and Video conferencing

Just as the case with MSRP there are a multitude of solution for providing the mediaplane communication in a multimedia conference. Using many of the decentralizedsolutions such as meshes, multiple point-to-point or decentralized bridging posesgreat requirements on the underlying network structure.

Therefore a centralized bridge is preferred, since it helps avoiding the NAT prob-lem. The centralized bridge is often called an RTP mixer and like the MSRPsession server it keeps track of members in a focus based conference. It providesboth direction of the RTP data flow and transmits all incoming data to the otherparticipating parties. Mixers are covered in the definition documents of RTP, seeRFC 3550 [8].

A B

C

A

B

C

B + C

A + C

A + B

Figure 3.3: RTP mixer in a 3-part conference

34



3.8.1 RTP media and conferences

One issue with RTP and NAT traversal is the requirement of sending and receivingtowards one host on the same port to achieve traversal of symmetric NATs. Thisworks fine for any one-to-one stream where one side is public (i.e. proxy or mixer).RTP media is however streamed on separate UDP port pairs (one port media, oneport control) for different streams, and they cannot easily be combined. Participat-ing in a conference where media is separated which needs NAT traversal on portswhere the client is not sending is not possible.

One solution would be that the client does a NAT hole punching by sending somebogus data on the ports it wants to open. The proxy might need to be aware ofthis and it is client specific. It results in an unorthodox (in the IMS sense) way ofsolving this problem.

Another solution would be that the RTP mixer joins the all streams too one image,one stream. This would simplify for clients having possibility of handling only oneimage, such as a small device. Combining this by sending dimension information inthe SDP offer to the focus would enable the mixer to adapt the image size or videoencoding for each client and enable the NAT traversal as usual. This however posesgreat complexity and processing power requirements on the mixer. Developing anRTP mixer is not in the scope of this assignment but a deployment of presentsoftware is still possible if suitable software is to be found.

3.9 Conclusions

For a prototype system, a general solution to the NAT problem would be to simplynot use the peer-to-peer method for any conversation. Instead always treat one-to-one communication as a conference with only two participants. In this case it wouldsimply utilize the MSRP session server for all instant messaging services (exceptpager-mode) and require a RTP mixer only supporting two participants, thus actas RTP Proxy but comply better with the IMS since it avoids the insertion of ahidden RTP Proxy in the network. Of course; such a system would not support aclient attempting to perform a regular peer-to-peer connection.

Developing a limited RTP mixer for this purpose would enable a future upgrade ofthe mixer without actually changing the IMS network structure. Such an upgradecould contain many features such as image resizing, bandwidth adaption, imagemerging (many sources in one stream/image), audio mixing, etc.

35

Chapter 4

System design

In this chapter, the functional model of IMS (see Section 2.1) will be converted intoa practical and technical model based on networks, machines and server software.Later on, specific software will be deployed to the technical model. The practicalmodel considers requested capabilities of the platform as well as known networkrestrictions. The requirements and restrictions are covered in Section 1.3.2.

4.1 Topological solution, DMZ to Private networkborder controllers

Figure 4.1 depicts a possible practical solution that avoids putting the entire IMShome system in the DMZ, instead some of the functions must act as border con-trollers. The main issue here is the security level in the border controllers. Byenterprise security policies a non-validated software can never be put to provideaccess to the private network of the enterprise. Most open source software (suchas the I-CSCF) and software developed in the time-frame of this thesis fall underthis category. Hence this is not a good solution. This is however how a true IMSsystem for full deployment purposes would have to be designed.

4.1.1 Multi-host systems

Putting certain functions on system having two IP-addresses lets the software actas a border controller. One address is public and routable, residing in the DMZ,perhaps also behind a NAT in which case the software has to be aware of its IPor its DNS name. The private address allows the software to connect to serversresiding in the private, otherwise, unreachable domain. One must of course takecare that the machine does not route unhandled packages and such to the privatenetwork. If the border machine is compromised, the private network is as well.

36


Leonard BromanCHAPTER 4. SYSTEM DESIGN

Public IP UE

S-CSCF

I-CSCF

P-CSCF

Local private network

HSS

P-CSCF

P-CSCF

MSRPMRF

SBC

DMZ

DMZ

Private IP UE@Remote

Private IP UE@Local

Figure 4.1: Network topology for the network using SBCs as entry-points

Figure 4.2 explains this, where the I-CSCF, MRF and a dedicated SBC acts asborder controllers.

P-CSCF

I-CSCF

MRFC

MRFP

S-CSCF

SBC

HSS UE

Private

DMZ NAT

Public

Figure 4.2: Network topology for the network with software components residingin multiple networks

37



4.1.2 TCP initiation from private network

In this case the host residing on the private network must establish and maintainTCP connections to servers in the DMZ. This is fairly feasible concerning the IMSsystem, but for the UE it is much less practical. They must employ some form ofdiscovery to use proxies/SBCs available. It is not flexible and does not fall underthe specifications of IMS and is therefore discouraged.

4.1.3 TCP tunneling

By setting up SSH (or similar) tunnels from hosts on the private network to hostsin the DMZ connections are allowed to be initiated from the DMZ to the privatenetwork. This features the same security risks as with multi-host systems. Gener-ally the only gain of using this method is to bypass network security policies andis therefore strongly discouraged. Concerning UE side, it poses of course the sameproblems as TCP initiation and is therefore not applicable to the general case.

Tunneling RTP traffic over TCP also have the effect the RT (Real-Time) propertyof the protocol is completely lost. The RTP stream will suffer under congestioneffects (RFC 2581 [1]) in TCP which will increase propagation delays. Also, thephenomena called “TCP slow start” (RFC 3390 [2]) causes inconvenient problemswhen establishing sessions. Sharing TCP connection for multiple UDP protocolswill have side-effects like SIP traffic being queued behind RTP streams on congestedTCP connections.

4.2 Topological solution, everything in DMZ

Placing the entire IMS network in the public routable address space solves all thecentral problems. It is however not recommended for security reasons. Using anMSRP relay to provide a MSRP entry-point in the public address space and anRTP Proxy (see Section 3.2.1) for RTP streams gives a system which will work forUE on private NAT systems.

4.2.1 Conclusion

If we want to follow the specification of IMS and allow any generic IMS UE toconnect to the network, we are forced to use SBC solutions in NAT-ed networks.This is also the general solution in IMS. However, from network restrictions andpolicies for this particular case it is not possible. Both UDP and TCP proxies mustbe integrated into the network to completely bypass the problem.

38



4.3 Network deployment solution

For the deployment, the system will have to be built on a machine connected onthe DMZ. This is not completely recommended but internal functions will be alittle more protected in the sense that only the P-CSCF, I-CSCF, MRFP and RTPProxy will be connectable from the outside.

To build this simple system; the only thing needed is a machine hosting the system,connected to the DMZ which must be configured to not to filter the protocols weare going to use. In this case; UDP port 5060 for SIP and TCP port 2855 forMSRP.

W o r l d P u b l i c

D M Z

A n y w h e r e P r i v a t e

U E

U E

S I P - A S D N S

P - C S C F R T P P r o x y

s e r v e r 2

s e r v e r 1

H S S

S - C S C F

I - C S C FP r e s e n c eS e r v e r

X C A PS e r v e r

Figure 4.3: A deployment example for the IMS system, still in functional notation

4.3.1 Software components

The main IMS system will consist of a number of different software componentsinter-operating to provide services and management to the network. It should asfar as possible be built on preexisting software from the free software community.

The IMS core

The FOKUS work group at TU Berlin has developed an IMS testing playground.For the CSCF and HSS they have used and extended SER. Since SER is free andopen software FOKUS are redistributing their software for free use and modifica-tion. They do however not distribute other pieces of their IMS system which theyhave produced.

39



Presence and contact service

The OpenSER community provides a solution for SIP/SIMPLE presence services.They use OpenSER in conjunction with OpenXCAP to provide this, using OpenSERfor monitoring services and OpenXCAP as a database back-end. This same XCAPserver can later be reused for other services depending on XCAP capabilities, suchas contact list management. In the IMS system OpenSER will act as a SIP-AS.

This solution is actually not IMS compliant. The OpenXCAP server does notsupport Diameter for authentication. Also the documents are strictly bound to asip-URI witch results in issues when one private identity (which may be in anyformat) has multiple public identities.

The OpenSER community provides a SIP server core and a multitude of exten-sion modules. It can be used as SIP proxy, registrar, presence. It can be configuredto provide user agent services, supporting SDP manipulation, different databaseback-ends and direct XCAP integration. The OpenXCAP + OpenSER suite is avery interesting combination where the two servers shared database tables, this isalso the variant promoted by the OpenSER community. Together they provideresource-list manipulation and subscription, group management and presence-rulesfor privacy policies.

OpenXCAP is an HTTP server providing GET and PUT methods to manipulateXML documents stored in a MySQL database, where it may share its table with anOpenSER presence module. It was originally developed as a graduation thesis whichis obvious when you start working with it. The server is written in Python and ismore or less just a combination of Python frameworks; twisted web2, gnuTLS andMySQL. It is developed under Debian and does not work properly on other systems.In my case, CentOS, the server crashes due to run-time linking errors during startup. This is fixed by removing the TLS support in the source code. The server doesnot refresh the MySQL connection and stops working when the connection timesout due to inactivity. The development of the server is tracking the very latest of itsdependencies which makes maintenance difficult. Unfortunately due to time-framereasons the OpenXCAP + OpenSER solution is kept, but one must be aware ofthe daily need to restart the XCAP server. A future option would be to replace theOpenXCAP with the java.net project OpenXDM, which also provides a frameworkfor client development.

Audio and video conversations, with NAT solution

OpenSER in conjunction with MediaProxy solves the issue with clients behindNATs in a transparent way. OpenSER provides the mediaproxy module whichtransparently modifies the SDP in a SIP offer/answer to direct the media-streamvia a RTP proxy. This is completely transparent to the UE and solves the NATissue for UDP media in one-to-one conversations. However, it is somewhat of an

40



unorthodox solution for an IMS system. Section 3.9 suggest a possible alternativeto this.

The MediaProxy does however only support UDP streams is thus not a solutionfor MSRP one-to-one conversations. If using the media proxy from OpenSER thisSIP server must be the one that the UE is connecting to (the P-CSCF) to be ableto detect the originating address.

Textual messaging

For each type of textual (see Section 2.3) messaging services we need one applicationserver.

Pager-mode messaging is supported by an OpenSER server configured to providelong-time delays and delivery reports. The AS intercept and treats MESSAGE’ssent.

One-to-one session messaging is supported by a SIP-AS working in proxy mode.This can most probably be solved using an OpenSER server but since the function-ality in it is simple, it could be a good opportunity to develop the functionality in aSIP-supporting framework, like BEA. It should be noted that it might be necessaryto develop a TCP TURN proxy, similar to media-proxy but for MSRP connections.

Textual conferencing is supported by a SIP-AS acting in B2BUA mode. If OpenSERrequires to much modification it could also be deployed on the BEA server. Thisdoes however have much higher complexity than the one-to-one messaging SIP-AS.

The MSRP session manager (MRFP) need to be developed entirely. But the devel-opment of the MRFP should directly provide the MSRP stack which will also beused when developing the client.

Textual messaging history is a function controlled by the client, if it supports it,and is implemented as a service towards the XCAP server.

41

Chapter 5

Implementation

42


Leonard BromanCHAPTER 5. IMPLEMENTATION

5.1 Client software

The client should provide a flexible way of demonstrating the system. It is devel-oped in Java which provides a multitude of possibilities concerning platforms andenvironments.

This chapter covers the choice of target platform. It covers the design considerationsfor the implementation of the communication stacks and specifies which existingframeworks and libraries are used within the implementation.

5.1.1 Target platform

There already exists a demonstration client for the system simulating IMS services.This client is a web-based solution to provide the flexibility of running the applica-tion independent of platform or location. The system consists of an AJAX interfacecontaining

• Contact list, providing presence information via SIP/SIMPLE

• Chat window, enabling SIP/SIMPLE based textual messaging

• Shared white-board for Internet collaboration

• Java application (soft-phone), running as an applet, to provide audio andvideo communication. This is the only way for the application to interfacewith the system microphone and camera using Java media framework.

AJAX Client

At this point, an embedded java applet will not be considered as an AJAX compo-nent, since it is just a program running in a browser.

The most particular point in using an AJAX client is the fact that all communi-cation between the client and IMS will not traverse the Internet, if the client ishosted on the same machine as the IMS system. This is a most likely case here.Since the communication runs via servlets on the website host it is independent ofthe location of the user.

A web-client is limited in the sense that it cannot communicate with a web-cam ora microphone of the host system, and therefore can only support textual services.

Web embedded applet

As the case with the soft-phone a single fully featured client can be embedded as anapplet on a website. This does however put certain restraints on the client. It must

43



all be implemented as one “window”. This will not solve any problems concerningfirewalls or NATs. To be able to connect to network services the applet has to besigned and the user must accept the certificate.

Standalone Java application

The main advantage of a standalone client, compared to an applet, is the flexibilityof the UI design. The interface can be split up into multiple windows. The maindrawback of this is that the user must download and run the application locally.This does however not require any signature and may be considered less secure.

Java ME application for mobile devices

The last and most complex aspect of the client software is the possible requirementthat is should be able to run on a mobile device. Mobile devices, like smart-phonesand most newer cell-phones, mostly support only Java Micro Edition. Java MEonly contains a subset of the Java Standard Edition API. This puts restraints oncomponents shared among software components, like the MSRP stack (see Section5.1.2).

The Java ME client most likely have to developed separately since it has a com-pletely different screen and input aspects to be considered.

Issues with Java ME There are a number of serious issues which have to beconsidered before the decision to develop Java ME versions of the shared softwarecomponents, which are mainly the network protocol stacks and the client core.

The Java ME API has much fewer classes. For example there is only one Listimplementation, the Vector, and it does not inherit List but Object. This poseslimitations on the choice of data structure to use. This is an important aspectin designing software that is also going to run on servers, possibly handling greatdatasets.

The set of methods for classes are also reduced. For example the String.split()method which provides powerful parsing capabilities is missing.

The language support is also limited. Generics, annotations and enumerations areabsent. This does not impact on the programming capacity of java but does makeit more error prone and will cause an increase in time spent on bug searching.

5.1.2 MSRP Stack

The MSRP is a component in the system which is going to be used both by theserver and client software. A stack is not available in an open-source form or as

44



a Java API at the moment, therefore it will have to be designed and developed.Important is that the stack may function both for clients and servers (clients mayalso serve in peer-to-peer) and that it must also respect the limited API of JavaME if the choice to develop such a client is taken.

Statefullness hierarchy

Three levels of statefullness is provided by the stack. Channel, connection andtransmission. Those levels are directly related to how the MSRP specificationssuggest that MSRP data transfers are performed.

The Channel The TCP socket is wrapped into a Channel. The channel sym-bolized the peer-to-peer relation between two IP hosts. The channel contains astatefull, non-locking parser and enforces rules upon the TCP connection to pro-vide fault-condition handling. If the stack is running as Channel-statefull the chan-nel accepts MSRP packets directly and which are sent to the underlying socket.Incoming packets are only parsed and delivered the channel listener.

The Connection Each channel may (and should preferably) carry many MSRPconnections for which the next hop is the same host. The Connection interfacesmodels this mechanism and provides a means of sending packets over the next,without knowledge directly of the next hop. The channel maps the destinationURI to a connection and packets are delivered via the connection.

The Transmission Transmissions are pieces of data which should be transmit-ted and presented at the peer as an entity. Small (¡ 2048Kb) transmissions areperformed using only one MSRP packet. Larger transmissions are chunked intomultiple transactions, MSRP packets. The transmission contains the mechanismsto provide transmission progress reporting. This is also the main model for thestack listener to receive data from connections.

The Transaction This interface exists only to provide a complete model of theMSRP mechanisms to the implementer. The implementer may, using it, inspecttransaction information (mainly packets transmitted and progress). No practicalinterests exists for not having this layer stateless if the transmission is statefull.

Threaded model

The stack is implemented using two threads. One working thread which performsall operations such as queue flushing and data buffer checking, in a round-robinfashion with limitations for each step. It is the provider of execution time for

45



parsing incoming messaging and encoding messages sent. The second thread servesonly as the waiting thread for listening to and handling incoming TCP connections.

The listener thread is separated from worker thread using a thread-safe queue,where sockets for new connections are left for the worker to handle.

To provide locking avoidance for the parser a statefull parser is implemented. Aunique parser is assigned to each stream. The parser can be called to performparsing of present data in the incoming buffers, to a certain limit, or to parse untilthe buffer is empty. For large incoming packets, the latter will block all otheroperations in the stack until the buffer is empty.

Encoding data works similarly. All packets requested to be sent are put in a send-queue by the software using the stack. The send-queue is emptied when the workerarrives at this operation and messages are moved to the send-queue for there TCPconnection. Those queues are then emptied either fully or partially. At this pointpackets are also subject to fragmentation, or chunking as expressed in section 5.1in RFC 4975 [6].

Configuration and logging interfaces

The MSRP stack is configured using the Properties class. Properties can be hardcoded on in the application or loaded from an XML or Properties (key=value)formatted stream. The properties are fed to the stack upon instantiation and arenot subject to change in the present implementation.

Commons Logging by the Apache Commons community is used for logging. Itprovides a convenient interface for libraries and components used by applications.The logging facility itself does not provide a connection to logging output but mustbe used together with a “native” logging facility, in our case Apache Log4j managedby either the client or the SipServlet applications.

TCP connection direction and usage

RFC 4975 [6] slightly covers certain aspects of the problems posed by peer-to-peerprotocols over persistent channels. In contrast to other TCP driven protocols likeHTTP, MSRP maintains persistent TCP connection with request in both directions.This requires reactivity at both endpoints, as well as all relays on the path, asdefined by the MSRP relay extension RFC 4976 [7].

Where both peers are servers, the first issue is which endpoint should establish theTCP connection. This part is clearly specified in RFC 4975 is being the originatingclient, i.e. the client sending the INVITE.

RFC 4975 implies the preferred usage of shared TCP connections where manyMSRP connections are handled with the same TCP peer. The mechanism providingthis capability in the stack is covered in detail in Section 5.1.2

46



The problem arises upon session negotiation. The persistent MSRP relay scenariowill not be covered in this report. To keep the scenario understandable for thereader I will cover only the most simple scenario where client incompatibility mayoccur. Assume Alice and Bob have established an MSRP peer-to-peer channel andconnection. They are transmitting text messages in a session. For some reason theyare negotiating a new connection to transmit a file. By RFC 4975 [6] recommenda-tions they should reuse the existing channel, however this is only recommended andif the two clients make different choices the connection will fail. Alice will offer apath and await packages on the present channel and Bob may attempt to establisha new channel, which is not expected by Alice and thus denied.

At this point a scheme for determining form of connection establishment at sessionnegotiation should be required. This is however undefined and subject of clientincompatibility. This issue is very probable to arise for any type of TCP protocolsunder SIP. In our case, since the same stack is running is all clients, we enforcethe reuse of channels since it is more “sexy” (common expression in EuropeanIT development projects). The reuse is determined by maintaining a mapping ofdestination hosts for both incoming and outgoing connections.

5.1.3 IMS Stack

The Java Community Process JSR 281 [20] is a draft of a Java Micro Edition APIfor IMS application development on JME ready devices. The present public draftwas approved as late as October 29 2007. The purpose of the JSR is to specifyan API which enables non-IMS-experts to develop cross-device IMS applications.The interface abstracts the SIP and SDP layers for session negotiation with a setof interfaces.

A very important note is that JSR 281 is merely an interface an underlying IMSlayer. This layer is most probably (on a portable device) a native implementation.The interface specifies the java application view and is thus very limited and is notaware of the IMS layer implementation and mechanics.

This interface model, even if not targeted for the JSE platform, is chosen as thebase of the standalone application development. A few extensions and limitationsare made in the implementation to create a stack adapted for the JSE platform.

JSR 281 shortcomings

Here are issues and proposals to adapt and extend the JSR 281 interface for JSEusage.

TCP connection state For reliable media transmissions, modeled as interfacesBasicReliableMedia for pure TCP and FramedMedia for MSRP over TCP con-nection are missing information for connection state. In contrast to RTP/UDP

47



where data is sent without confirmation to a supposedly reachable address theTCP transmission are dependent on a confirmed transmission channel.

For BasicReliableMedia the Listener should be extended to be notified of suchchanges. As of the current JSR 281 draft [20] is only notified of failure in establish-ment and never alerted of successful connection.

MSRP transmissions are dependent of several TCP connections as its path to thepeer may be relayed. It is therefore important to have state information where thepath to the peer is in a functional state. At MSRP connection establishment theMSRP stack is implemented to send a VISIT package to confirm the connection.After such a successful transmission, the Listener should be alerted of the statechange in the FramedMedia.

Session/focus model Sessions are modeled by the Session interface. Implemen-tations are instantiated using a CoreService which in turn originates from the Stack.The sessions are created using a from-user to-user aspect suitable for one-to-oneconversations. It is of course also applicable to focus sessions (Section 3.6) sincethe actual sip session is established between the UE and the SIP focus.

Conference sessions are going to become much more usual as they are more easilybuilt using IMS than older more rigid communication systems. I think it is thereforeimportant to make difference in the API between sessions and focuses. The focuscontains much more dynamics than the session, foremost the state subscription andparticipant management. A session is merely a point-to-point connection and hasgenerally only on/off state. A focus has many users, they may join or leave orpublish presence information to the focus. Creating a focus model in the API willsimplify the view of the application developer.

Engine control The IMS engine of a portable device is a native managementlayer on the device which handles network connections for the subscriber. It usessubscriber information from the ISIM and not from user-space. The engine is ofcourse always running on the device, similar to the GSM connection managementof 2G devices.

This layer does not exist for the JSE platform. Therefore a tiny extension tobootstrap the engine is done. This is with the Manager.loadProperties(Propertiesp) method. It will start the “background” engine with the given properties. Theclient can after that use the JSR 281 interfaces as specified. Manager creationand engine init can be done manually but also with the ImsFactory which permitsimplementation selection.

This solution leaves a lot of space for improvements since the Manager is staticand jvm global and multiple jvm may have port clashes. Ericsson offers a productcontaining what they call a ICP (IMS Client Platform). This is a backgroundprocess in the machine which provides the IMS connection. Applications thenconnect to it to use the IMS core. The API for programming with the ICP is notrelated to JSR 281.

48



Group management What is often mentioned as group management can gen-erally be referred to as non-client bound information such as contacts and groups.The OMA (Open Mobile Alliance) refers to this as XDM (XML Document Man-agement) which is related to the IMS way of doing this.

For group management in IMS the XCAP protocol is used to manage central con-figuration files in XML format. The JSR 281 does not handle this issue, mostprobably because of the native device function which does this and later offer aseparate interface to device contact lists to the application.

For a standalone applications this is however highly interesting and a particularityis the fact that user presence is offered in the interface, but not the user accountinformation itself, whereas they are actually related.

An interface providing a high level of abstraction for this is provided in the resourcepackage extension detailed in Figure C.11.

Symmetric client enforcement Due to all the network [39] issues (Section 3.1)over non-manageable networks (Section 3.4) and to simply avoid stumbling over aclients wishing to run asymmetrical (Section 3.2.1) data streams the stack enforcessymmetrical communication.

Rich presence information The JSR 281 [20] interface for event subscription isextremely limited. The only information notification information that the interfaceprovides is a raw String provided via the SubscriptionListener when a notificationarrives. This leaves all the data treatment to the client and somewhat loses someof the purpose of the abstraction layer which is supposed to hide the IMS specificparts to the implementer.

This is more of a general issue for subscription information. Since subscriptionscan be done to various different event packages one might consider designing oneparticular interface for each one which belongs to the IMS standard. The threemost interesting would probably be “presence”, “reg-state” and “conference”. Forany other extension, the present, general, interface would be used.

SessionDescriptor interfaces For session negotiation, the java community pro-cess defined JSR 141 [29] clearly defining an interface for SDP programming. Read-ing the specification of JSR 281 you get the impression that the working group gottire when arriving at session descriptor. JSR 141 offers an easy to use interfaceto SDP whereas JSR 281 only has a number of getters giving raw Strings. Thisleaves much of the work to the implementer, which is perhaps not the purpose ofthe JSRs.

49



5.1.4 Java client

The main purpose of the java client is the ability to demonstrate the capabilities ofthe network and the implemented software components. Since the IMS stack hideseverything concerning SIP, MSRP and other protocols used for the IMS connectionthe implementation of the client is quite straight forward. The class diagrams ofthe client is presented in Appendix C.5.

Model, view, controller

The model-view-controller development pattern is popular when developing appli-cations with human interfaces. The main principle of the model is to separate thevisual and IO components, the view, from the data delivering back-end, the model.This is done by introducing a new intermediate part, the controller.

Figure 5.1 shows the principles used for the implementation. The view, what theusers see, is implemented in Java Swing. Swing is the second generation of GUI(Graphical User Interface) libraries provided with J2SE. It provides all the mecha-nisms and widgets to build just about any application.

For all components in Swing, callbacks can be registered. Callbacks are listeners,triggered when actions are performed on the GUI. Example of such are when keysare pressed or when the mouse pointer enters or leaves areas. The callbacks are theway that the controller is alerted of changes in the view. The controller then takesnecessary actions. When user inputs actions the main work done by the controlleris to send commands to the model, to request changes in the stack.

The IMS stack also works with callbacks. Mostly upon state changes for the dif-ferent components in the stack the listener is notified. Such events occur wheninvitations arrive, media is transmitted or when services requested are successfulor fails. At this point the controller notifies the user by changing the view.

Model View

Controller

SwingIMS Stack

IMS Stack callback Swing callback

Figure 5.1: Model-view-controller architecture behind the java client

50



5.2 Server software

On the server side, most components are already available. The CSCF and HSS areprovided from the OpenIMSCore project at FOKUS Berlin (see Appendix A. It usesSER and FHoSS for these functions. The presence server is deployed with OpenSERand OpenXCAP. OpenXCAP can also be used for the general XCAP access. Theparts that are missing are SIP-AS for focus and media resource management. Thoseparts will have to be designed and developed. For SIP-AS development a server witha servlet container [26] supporting the JSR 116 SipServlet API [22] is suitable. Inthis case the BEA SIP server is chosen, the main reason for this is that it is alreadyused and the company has licenses for it.

5.2.1 SIP focus for MSRP sessions

The SIP-AS providing instant messaging conference capabilities is developed as onepiece of software working as SIP-AS, MRFC and MRFP. The activities that shouldprovide are described in Figure D.1. The server is implemented as a servlet inthe BEA servlet container. The container provides a SIP interface where the BEASIP Server provide most of the SIP functionality leaving only small pieces requiredto develop for the servlet. The BEA server also provides the necessary Diametercomponents needed by the MRFC.

The MSRP stack must however be completely developed. The MSRP stack is sharedamong many platforms requiring it to provide a flexible interface for usage, but alsoa flexible interface towards external facilities such as logging and configuration. Itloads configuration in the form of Properties and uses commons-logging as loggingfacility. The stack is covered more in detail in Section 5.1.2. The MSRP stackprovides the media layer interface for the part of the server which in IMS would becalled MRFP (Media Resource Function Processor).

Limitations

The current SipServlet specification reserves headers such as From, To and Contactas so called system headers. This means that the possibilities to modify them isreserved for the servlet container. For the focus model described in Section 3.6where the Contact header provides the means to communicate the focus URI toa client creating it this is an issue. The Contact header may only be set by theservlet for initial REGISTER requests and 3xx and 4xx responses.

For this reason, implementing the focus mechanisms like this is simply impossible.Instead the focus is implemented to transmit this information in the Reply-To

header.

The BEA SipServlet container does not implement all Privacy header extensions inIMS. In this case the P-Asserted-Identity set by the P-CSCF is not implementedand thus cannot be used for client identification. Instead the public user identity

51



must be taken from the From header. This is much less secure since it is may beforged by the client and manipulated.

Focus model

The focus is modeled according to class Diagram C.13. This first version of themodel does invite for some future extensions. It manages focuses. Each focusmay have one or more users. An empty focus may be considered dead. Each usermay be connected to the focus using one or more sessions. The model suggests apossible extension for SMS. In a next-generation model the session can be mademore generic, supporting back-to-back sessions to provide RTP media conferences(in combination with MSRP).

In the focus. Each message arriving to the focus is retransmitted to all other Users.It is up to the implementation for each sessions which messages to transmit and howto provide status notifications. This permits a simple and powerful differentiationbetween SMS and MSRP messaging.

5.2.2 Billing proxy

Simple peer-to-peer session does not need the support of an application server inthe bare IMS core network. However in a deployment situation the billing proxyprovides a monitoring role to provide tracking of calls and reporting of billinginformation to the HSS.

The proxy is implemented in one single servlet listening for new INVITE requeston the network. When an initial request arrive, the AS may determine whetherthe call may continue, depending on user credits or permissions. The proxy alwaysrecords its route for initial request to be able to follow the entire SIP dialog.

52



5.3 Client based test bots

For testing purposes a simple bot framework is developed to quickly be able to im-plement autonomous clients imitating particular behaviour. These simple bots letsthe implementor and integrator to easily test basic functions and client behaviour.

5.3.1 MSRP echo bot

Simple bot accepting all MSRP connections and echoing all messages sent to it. Asan extension it may also accept invitation to focus sessions.

5.3.2 Eliza bot

Eliza is computer program imitating a therapist by replying to questions and posingfollow-ups, imitating artificial intelligence in a simple way. The Eliza bot providesa connection between an MSRP session to a Java implementation of the Elizaprogram.

5.3.3 Inviter bot

The inviter bot sends an invitation every 30 seconds to sip:[email protected] (or anyother configured public identity). It sets up an MSRP connection, transmits a fewmessages (echos messages received) and then disconnects. This enables some clienttesting of session management.

5.3.4 Conference bot

The conference bot provides a network user which always accepts invitations toMSRP conference sessions, chat rooms. When in the chat room. The bot replies toall messages received with an echo. Also some additional info is added to the echoto notify participants, via the media, of the information that the bot has about thesession.

5.3.5 Conference inviter bot

This is similar to the inviter bot. But instead of inviting the peer to a session itinvites to a conference focus using a REFER request. This gives an opportunity totest the stack and client reactions to arriving invitations. After the invitation isdone, the bot echos messages received.

53

mailto:[email protected]

Chapter 6

Summary and future work

6.1 Summary

6.1.1 Present status

As of finalizing this document, the deployed system and the implemented softwarecomponents supports the main core features specified in the initial project de-scription; instant messaging with MSRP, presence and central contact lists (groupmanagement). The system also supports IMS compliant clients to establish ses-sion of other media types (such as audio/video) which do not require any networkspecific handling. This is however not implemented in the IMS stack.

6.1.2 Technologies used

The components of the system relies on different technologies enabling their com-munication frameworks and run-time environments.

IMS Core: OpenSER, FHoSS, OpenIMSCore, OpenXCAP, Tomcat,MySQL, Named, Python, J2EE

IMS Stack: Apache Commons-Logging, Apache HttpClient, JAXB, JAIN-SIP,J2SE

jClient: J2SE, Apache Log4j, Swing

54


Leonard BromanCHAPTER 6. SUMMARY AND FUTURE WORK

SIP port 5060

TCP port 2855

SIP port 5070

SIP port 5080

SIP port 5090

SIP-ASBEA SipServer

MRFC/MRFPSipServlet

I-CSCFSER

S-CSCFSER

P-CSFCFSER

Diameter Diameter

server1

server3

NAT/FIREWALL

Public IP

SIP Presence serverOpenSER

XCAP ServerOpenXCAP

SIP port 5095

DBMySQL

HSSFHoSS

Figure 6.1: The present deployed network structure.

6.2 Future integration

Now that the core services of the IMS system is in place it is fairly easy to extendit with new services and interfaces towards other networks. The most interestingextension as a continuation to this project is the implementation of conferenceservices for MSRP. Also the development of an MSRP relay for a consistent NATtraversal solution is of high interest.

Adding an RTP proxy to help NAT traversal for real-time media is an extensionwhich already exists and should not be to hard to add. For RTP media conferencesthere exists numerous enterprise solutions. Examples of those are the MRF servers

55



from Comverse and Streamwide. They provide both multimedia conferencing aswell as B2BUA capabilities and VoiceXML controlled services.

An interesting subject for future thesis work is to implement ultra-multimedia ses-sion supporting both real-time and reliable media. For example sessions supportingaudio, video, textual messaging, central file transfers/storage and co-editing.

BEA WLSS/Sailfin SipServlet AS

Pager-mode message

Bill ing proxy

Conference

IMS Stack

P-CSCFSER

I-CSCFSER

S-CSCFSER

Presence ASOpenSER

XDMopenXCAPopenXDM

SMS GatewayKannel

RTP MRFStreamwideComverse

Media GatewayAsterisk

HSSFHoSS

JDiameterPeer

MSRP Stack

Java Media FrameworkJAIN SIP

MSRP Relay

RTP Proxy

Media (TCP/RTP)

SIP

Diameter

Other

PSTN

SMSMMS

Other IMS domain

DNS

JAXB HttpClient

Figure 6.2: Example future extension possibilities to the presently integrated com-ponents. Components named with software suggestions.

6.3 Future development

The software components implemented has been designed with concern to futureimplementation interests. Due to time and subject limitation only a small subsetof the functionality has been implemented to support the required functions.

This section does only cover the currently most interesting features which may servewell for developing new services.

56



6.3.1 MSRP Stack

The statefullness hierarchy

The stack is designed to provide statefullness on different levels depending on thewishes of the developer. The present implementation only provides complete state-fullness which in most cases is a good option as it completely hides the MSRPmechanisms to the implementer.

Supporting stateless connections and transmission would allow implementers tocontrol connections and easy up implementation of very specific extensions.

Relay support

One of the most central important design concepts of MSRP is the possibility toconnect via relays. In fact MSRP offers a TCP-like transmission scheme where anapplication layer supporting authentication, relaying and multi-leg progress report-ing is added.

This is not implemented into the stack but would be vital for many applicationsrunning behind strict network policies.

Connection reestablishment support

On cellular networks, where the network connection is not reliable and subjectof disconnections and IP reassignments there is a true issue with reliable mediatransmissions. MSRP has not specifications (yet) how to handle this issue whichmay become an outstanding issue in future implementations.

6.3.2 IMS Stack

As a starting point the JSR 281 [20] specification for IMS services in java microedition was chosen. The base interfaces have been changed to provide a “stack”instead of of a “manager” interface towards the native implementation. Also, somefunctionalities have been added to support more features in reliable communication.A service have been added to provide XCAP support directly in the stack.

Present implemented features

The current implementation supports:

• Session (SIP peer-to-peer sessions)

57



• Publication (presence package)

• Subscription (presence package)

• FramedMedia (MSRP)

• Resource lists (group management) for a single contact list

• Multiple public identities per private identity

Focus support

An initial draft interface has been added for supporting focus sessions in SIP. Thisprovides an abstraction of the otherwise complex mechanisms of invitations, refer-rals and event subscriptions present in focus session. It is partially implemented.

Page messages

SMS has for the last 10 years been the most widespread of instant messaging onmobile devices. This way of communicating wont go away tomorrow and demon-strating this is interesting maybe most importantly to make the distinction frombetween session-based massaging and pager-mode messaging.

Capabilities

In the extension, the IMS system will provide all communication methods for it’ssubscriber. Be it instant messaging, voice calls or video-on-demand. Capabilitiesannouncement is critical to enable the IMS network to be aware of which media isaccepted/supported at user endpoints.

6.3.3 Java Client

The Java client has been implemented fairly fast to make use and visualize theimplemented features of the IMS stack. Today it provides a login window, centralcontact list (with manipulation of course) and the possibility to participate in peer-to-peer message session. The interface has been designed with the addition of morebasic media and services in mind. When those have been implemented in the IMSstack the step to usage in the client is not far away.

58



Figure 6.3: Screen shot from the Java Client version 0.1 running with a chat sessionto the Eliza chatterbot open.

59

Chapter 7

Results

7.1 Discussion

This thesis provides the standing ground for developing IMS services beginning ata knowledge base limited to basic IP networking knowledge. By starting at zeroand working the way towards the goal, instant messaging in IMS, covering all steps,the basis is given for understanding of the IMS network, how it works, and how itprovides services.

Obviously, the work done follows certain predefined milestones. There is a needfor the protoype to work under certain network conditions. Certain services shouldbe provided, namely instant messaging, which should be demonstrateble. Theplatform should be extensible for future use and general service deployment shouldbe possible. These issues are all covered and an implementor of other services thaninstant messaging can draw experience from the results presented by this thesis.

With the evolution and convergence of network societies on the internet instantmessaging is now at an interesting point. Jabber/XMPP has been embraced by theopen source community as a protocol which is simple yet powerful and has an openspecification with a clear evolutionary process. On the proprietary side we haveMicrosoft, which with their protocol for instant messaging are offering integration of“Live Messaging” in the service platforms of their clients. This is something FranceTelecom (Orange) is offering at the moment. The third protocol is that specified inIMS. IMS uses the combination of SIP and MSRP separating singaling and media,just as real-time media streams. But yet, IMS has no client deployement and thespecification lies dormant until the day it arrives. The question is only, will thetelecom operators chose to use the instant messaging in IMS?

60


Leonard BromanCHAPTER 7. RESULTS

7.2 Conclusions

The direct results of these thesis work is based on the problem definition. Thereforethe summary of problem definitions is repeated here.

• Analyze the present demonstration platform to determine its re-usability andextensibility.

• Integrate a prototype platform providing the CSCF and HSS IMS functions.

• Enable IMS instant messaging services on the IMS platform.

• Propose a solution reducing or eliminating connection issues concerning net-works behind NAT.

• Design and implement necessary missing software components to enable in-stant messaging services.

• Add, or suggest possibilities to add, additional services to the IMS platform.Most notably presence services and group management.

The present demonstration platform is a hybrid solution where one applicationserver drives all IMS services and the web client itself. The web client also containsa java applet. The java applet provides advantages in the audio video interface,but also brings along disadvantages in terms of NAT issues. This previous demon-stration prototype was not used in the developed platform.

The new IMS prototype platform was based on the open source project OpenIM-SCore by TU Berlin. It provides the SIP routing elements (P/I/S-CSCF ) andthe HSS. The presence service was added using the OpenSER presence module,not being targeted for IMS systems, proving the possibility to integrate presentSIP services in IMS networks. An XCAP server (OpenXCAP) was also added toprovide group management capabilities.

Concerning network restrictions, focused on NAT (Network Address Translation),the best way to deploy the core network is in the DMZ (DeMilatarized Zone). Thisis mainly due to company security policies and the absence of suitable SBC (SessionBorder Controller) software.

Since no MSRP java component is available in the open source community, thispart has to be developed. An MSRP stack is developed in two seperate components;API and implementation. It is designed to be used both in clients and servers.

The IMS instant messaging server is developed in a SipServlet (see Section 5.2.1)container, providing the SIP interface, and with the instant messaging session/chat-room manager using the MSRP stack.

61

Bibliography

[1] M. Allman and et al. TCP congestion control. IETF RFC 2581, IETF,http://tools.ietf.org/html/rfc2581, April 1999.

[2] M. Allman and et al. Increasing TCP’s initial window. IETF RFC 3390, IETF,http://tools.ietf.org/html/rfc3390, October 2002.

[3] G. Camarillo and M. A. Garcia-Martin. The 3G IP Multimedia Subsystem(IMS). Wiley, second edition, 2006.

[4] A. Niemi et al. HTTP digest authentication using authentication and keyagreement. IETF RFC 3310, IETF, http://tools.ietf.org/html/rfc3310,September 2002.

[5] B. Campbell et al. SIP extension for instant messaging. IETF RFC 3428,IETF, http://tools.ietf.org/html/rfc3428, December 2002.

[6] B. Campbell et al. The message session relay protocol (MSRP). IETF RFC4975, IETF, http://tools.ietf.org/html/rfc4975, September 2007.

[7] C. Jennings et al. Relay extensions for the message session relay protocol(MSRP). IETF RFC 4976, IETF, http://tools.ietf.org/html/rfc4976,September 2007.

[8] H. Schulzrinne et al. RTP: A transport protocol for real-time applications.IETF RFC 3550, IETF, http://tools.ietf.org/html/rfc3550, July 2003.

[9] H. Sugano et al. Presence information data format (PIDF). IETF RFC 3863,IETF, http://tools.ietf.org/html/rfc3863, August 2004.

[10] J. Rosenberg et al. SIP: Session initiation protocol. IETF RFC 3261, IETF,http://tools.ietf.org/html/rfc3261, June 2002.

[11] J. Rosenberg et al. STUN - simple traversal of UDP through NATs. IETFRFC 3489, IETF, http://tools.ietf.org/html/rfc3489, March 2003.

[12] J. Rosenberg et al. SIP event package for conference state. IETF RFC 4575,IETF, http://tools.ietf.org/html/rfc4575, August 2006.

[13] J. Rosenberg et al. Traversal using relays around NAT (TURN). Internet-draft, IETF, http://tools.ietf.org/html/draft-ietf-behave-turn-04,July 2007.

62

http://tools.ietf.org/html/rfc2581











http://tools.ietf.org/html/draft-ietf-behave-turn-04


Leonard BromanBIBLIOGRAPHY

[14] P. Calhoun et al. Diameter base protocol. IETF RFC 3588, IETF,http://tools.ietf.org/html/rfc3588, September 2003.

[15] ETSI. Presence service; architecture and functional description. 3GPP TS 23141, ETSI, http://www.3gpp.org/ftp/Specs/html-info/23141.htm, Octo-ber 2006.

[16] ETSI. Messaging service using the IP multimedia (IM)core network (CN) subsystem. 3GPP TS 24 247, ETSI,http://www.3gpp.org/ftp/Specs/html-info/24247.htm, jun 2007.

[17] ETSI. Presence service; architecture and functional description. 3GPPTS 23 228, ETSI, http://www.3gpp.org/ftp/Specs/html-info/23228.htm,September 2007.

[18] ETSI. Vocabulary for 3GPP specifications. 3GPP TR 21 905, ETSI,http://www.3gpp.org/ftp/Specs/html-info/21905.htm, jun 2007.

[19] S. Glassman, M. Manasse, and J. Mogul. Y10k and beyond. IETF RFC 2550,IETF, http://tools.ietf.org/html/rfc2550, April 1999.

[20] JSR 281 Expert Group. IMS services API. Java Specification Request 000281,Java Community Process, http://jcp.org/en/jsr/detail?id=281, Septem-ber 2007.

[21] M. Handley and V. Jacobson. Session description protocol. IETF RFC 4566,IETF, http://tools.ietf.org/html/rfc4566, July 2006.

[22] Anders Kristensen. SIP servlet API. Java Specification Request 000116,Java Community Process, http://jcp.org/en/jsr/detail?id=116, Febru-ary 2003.

[23] O. Levin and R. Even. High-level requirements for tightly coupled SIP con-ferencing. IETF RFC 4245, IETF, http://tools.ietf.org/html/rfc4245,November 2005.

[24] J. Loughney. Diameter command codes for third generationpartnership project (3GPP) release 5. IETF RFC 3589, IETF,http://tools.ietf.org/html/rfc3589, September 2003.

[25] S. McGlashan and et al. Media server control protocol (MSCP). Internet-draft,IETF, http://tools.ietf.org/html/draft-mcglashan-mscp-03, March2007.

[26] Rajiv Mordani and et al. Java servlet 2.4 specification.Java Specification Request 000154, Java Community Process,http://jcp.org/en/jsr/detail?id=154, September 2007.

[27] A. Niemi. SIP extension for event state publication. IETF RFC 3903, IETF,http://tools.ietf.org/html/rfc3903, October 2004.

[28] Miikka Poikselka, Georg Mayer, Hisham Khartabil, and Aki Niemi. The IMSIP Multimedia Concepts and Services. Whiley, second edition, 2006.

63


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





http://jcp.org/en/jsr/detail?id=281





http://tools.ietf.org/html/draft-mcglashan-mscp-03




Leonard BromanBIBLIOGRAPHY

[29] Kelvin R Porter. SDP API. Java Specification Request 000141, Java Commu-nity Process, http://jcp.org/en/jsr/detail?id=141, July 2004.

[30] J. Postel. User datagram protocol. IETF RFC 768, IETF,http://tools.ietf.org/html/rfc768, August 1980.

[31] C. Rigney and et al. Remote authentication dial in user service (RADIUS).IETF RFC 2865, IETF, http://tools.ietf.org/html/rfc2865, June 2000.

[32] A. B. Roach. SIP - specific event notification. IETF RFC 3265, IETF,http://tools.ietf.org/html/rfc3265, June 2002.

[33] J. Rosenberg. A presence event package for SIP. IETF RFC 3865, IETF,http://tools.ietf.org/html/rfc3865, August 2004.

[34] J. Rosenberg. SIP event package for registrations. IETF RFC 3680, IETF,http://tools.ietf.org/html/rfc3680, March 2004.

[35] J. Rosenberg. A framework for conferencing with SIP. IETF RFC 4353, IETF,http://tools.ietf.org/html/rfc4353, February 2006.

[36] J. Rosenberg. The extensible markup language (XML) con-figuration access protocol (XCAP). IETF RFC 3588, IETF,http://tools.ietf.org/html/rfc4835, May 2007.

[37] J. Rosenberg. Interactive connectivity establishment (ICE). Internet-draft, IETF, http://tools.ietf.org/html/draft-ietf-mmusic-ice-18,September 2007.

[38] H. Schulzrinne and et al. RPID: Rich presence extensions to thepresence information data format (PIDF). IETF RFC 4480, IETF,http://tools.ietf.org/html/rfc4480, July 2006.

[39] P. Srisuresh and K. Egevang. Traditional NAT. IETF RFC 3022, IETF,http://tools.ietf.org/html/rfc3022, January 2001.

64









http://tools.ietf.org/html/draft-ietf-mmusic-ice-18



Appendix A

Links

This is a collection of Internet links which does not qualify as formal references.Here you can find resources for software downloads and project information.

• http://www.openxcap.org/

• http://openser.org/

• http://www.openimscore.org/

• http://www.asterisk.org/

• http://www.mobicents.org/

• http://www.rtpproxy.org/

• http://www.ag-projects.com/MediaProxy.html

• http://commons.apache.org/logging/

• http://maven.apache.org/

• http://hc.apache.org/httpclient-3.x/

• https://jaxb.dev.java.net/

• https://openxdm.dev.java.net/

• http://www.bea.com/sip/

• https://jain-sip.dev.java.net/

• http://junit.sourceforge.net/

• http://www.genesyslab.com/

• http://www.comverse.com/

• http://www.streamwide.com/

65

http://www.openxcap.org/

http://openser.org/

http://www.openimscore.org/

http://www.asterisk.org/

http://www.mobicents.org/

http://www.rtpproxy.org/

http://www.ag-projects.com/MediaProxy.html

http://commons.apache.org/logging/

http://maven.apache.org/

http://hc.apache.org/httpclient-3.x/

https://jaxb.dev.java.net/

https://openxdm.dev.java.net/

http://www.bea.com/sip/

https://jain-sip.dev.java.net/

http://junit.sourceforge.net/

http://www.genesyslab.com/

http://www.comverse.com/

http://www.streamwide.com/

Appendix B

Establishing SIP focussession

This document describes in detail SIP and MSRP messages passed over the IMS net-work when establishing, participating in, and leaving an MSRP conference, drivenby a SIP focus.

In this case the system contains a P, I and S-CSCF. Both participants are separateprivate networks behind NAT routers. Their UE are unaware of any particularmethods of NAT traversal, they dint even know their public IP.

• P-CSCF proxy.ims.net : 192.168.5.1 @Public 5.5.5.1

• I-CSCF inter.ims.net : 192.168.5.2 @Public 5.5.5.2

• S-CSCF server.ims.net : 192.168.5.3

• SIP-AS/MRFC mrfc.ims.net [email protected] : 192.168.5.4

• MRFP-MSRP msrp.ims.net : 192.168.5.5 @Public 5.5.5.5

• Alice [email protected] alice.athome.net : 192.168.1.1 @Public 1.1.1.1

• Bob [email protected] bob.athome.net : 192.168.2.1 @Public 2.2.2.1

B.1 Alice creates the session

Alice starts by sending an INVITE to the conference factory. In this case it is the SIP-AS that handles this. She knows the URI of the conference factory [email protected] UE configuration. In this first step every jump in the IMS network traversal isincluded, later it will be omitted.

66




mailto:@ims.net


Leonard BromanAPPENDIX B. ESTABLISHING SIP FOCUS SESSION

INVITE sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP alice.athome.net

To: IMSChat <sip:[email protected]>

From: Alice <sip:[email protected]>;tag=2345

Call-ID: [email protected]

CSeq: 1 INVITE

Route: proxy.ims.net inter.ims.net server.ims.net

Contact: <sip:192.168.1.1:5060>

Content-Type: application/sdp

Content-Length: ?

v=0

o=- 9876 1 IN IP4 alice.athome.net

s=Our chatroom

c=IN IP4 alice.athome.net

t=0 0

m=message 7394 TCP/MSRP *

a=accept-types:text/plain

a=path:msrp://alice.athome.net:7394/2s93i9ek2a;tcp

The P-CSCF records the route and forwards it to Alice’s home network ims.net:


Via: SIP/2.0/UDP proxy.ims.net

Via: SIP/2.0/UDP alice.athome.net;received=1.1.1.1




CSeq: 1 INVITE

Route: inter.ims.net server.ims.net

Record-Route: <sip:[email protected]:5060>

Contact: <sip:192.168.1.1:5060>


Content-Length: ?

v=0


s=Our chatroom


t=0 0




The I-CSCF can now determine if Alice is a valid user in ims.net and which S-CSCFto use, if more than one exists. It records the route and forwards:


Via: SIP/2.0/UDP inter.ims.net

Via: SIP/2.0/UDP proxy.ims.net;received=192.168.5.1

67





msrp://alice.athome.net:7394/2s93i9ek2a





mailto:[email protected]:5060









CSeq: 1 INVITE

Route: server.ims.net



Contact: <sip:192.168.1.1:5060>


Content-Length: ?

v=0


s=Our chatroom


t=0 0




The S-CSCF uses its internal filtering condition(s) to determine if and which AS(Application Server) should process this Request. It records the route and forwards:


Via: SIP/2.0/UDP server.ims.net

Via: SIP/2.0/UDP inter.ims.net;received=192.168.5.2






CSeq: 1 INVITE




Contact: <sip:192.168.1.1:5060>


Content-Length: ?

v=0


s=Our chatroom


t=0 0




The request now arrives at the SIP-AS serving SIP focuses and MSRP sessions. Itwill create an MSRP session, identified by “abcd”, and a SIP focus, identified the

68

















same way, this is not necessary. The SIP-AS responds with an OK containing theSIP focus address in the Contact header and the connection information for theMSRP session in the SDP answer. Note also how session-version in the “o=” fieldis incremented.

SIP/2.0 200 OK

Via: SIP/2.0/UDP server.ims.net;received=192.168.5.3

Via: SIP/2.0/UDP inter.ims.net;received=192.168.5.2



To: IMSChat <sip:[email protected]>;tag=3456



CSeq: 1 INVITE




Contact: <sip:[email protected]>;isfocus


Content-Length: ?

v=0

o=- 9876 2 IN IP4 msrp.ims.net

s=Our chatroom

c=IN IP4 msrp.ims.net

t=0 0



a=path:msrp://msrp.ims.net:2588/abcd;tcp

Alice must now only connect to the MSRP server and VISIT or SEND to the sessionto be a part of it. RFC 4975 section 8.5 specifies that the inviter is responsible forcreating the connection and thus Alice can connect as long as the MSRP server isreachable from the outside, she may also use an already present connection to thatMSRP server. Her next step is joining the MSRP session.

MSRP dkei38sd VISIT

To-Path: msrp://msrp.ims.net:2588/abcd;tcp

From-Path: msrp://alice.athome.net:7394/2s93i9ek2a;tcp

Message-ID: 456s9wlk3

-------dkei38sd$

The MRFP replies

MSRP dkei38sd 200 OK

To-Path: msrp://alice.athome.net:7394/2s93i9ek2a;tcp

From-Path: msrp://msrp.ims.net:2588/abcd;tcp

-------dkei38sd$

69








msrp://msrp.ims.net:2588/abcd







B.2 Alice creates a state subscription to the ses-sion

Subscribing to events in a focus does not function in the same way as subscribingto user events in IMS. In the IMS system user events are handled by presenceservers and not by subscribing directly to the users themselves. In focus sessions,the presence is handled internally in the focus, but with the same protocol as anormal subscription.

SUBSCRIBE sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP alice.athome.net

To: IMSChat <sip:[email protected];session=abcd;isfocus>


Call-ID: aq528f

CSeq: 1 SUBSCRIBE

Event: ?

Contact: <sip:192.168.1.1:5060>

She then gets two replies. One notification and one OK

SIP/2.0 200 OK

To: Alice <sip:[email protected]>;tag=76283

From: IMSChat <sip:[email protected];session=abcd;isfocus>

Call-ID: aq528f

CSeq: 2 SUBSCRIBE


NOTIFY sip:[email protected] SIP/2.0


;tag=893790

To: Alice <sip:[email protected]>

Call-ID: aqsd38907

CSeq: 1 NOTIFY


Content-Type: application/pidf+xml

Content-Length: ?

<?xml version="1.0" encoding="UTF-8"?>

<conference-info

xmlns="urn:ietf:params:xml:ns:conference-info"

entity="sip:[email protected]"

state="full" version="1">

<conference-description>

<subject>Just another chat room</subject>

</conference-description>

<conference-state>

70














<user-count>1</user-count>

</conference-state>

<users>

<user entity="sip:[email protected]" state="full">

<display-text>Alice</display-text>

</user>

</users>

</conference-info>

Yes, she got her own information. . . NOTIFY is a request and is therefore answeredwith an OK.

B.3 Alice invites Bob

Alice doesn’t really feel like chatting for herself, therefore she invite Bob as well.This is done using the REFER SIP method which is sent to Bob. It contains the URIof the SIP focus which lets Bob invite himself. The REFER will itself result in a setof messages exchanged between Alice and Bob but they’re not really interesting atthis point.

REFER sip:[email protected] SIP/2.0

From: Alice <[email protected]>;tag=9289

To: Bob <[email protected]>

Refer-To: IMSChat <sip:[email protected]>;isfocus

B.4 Bob invites himself and joins


From: Bob <[email protected]>;tag=8927208

To: IMSChat <sip:[email protected]>;isfocus

Call-ID: 987097865

CSeq: 1 INVITE


Content-Length: ?

v=0


s=Our chatroom


t=0 0



a=path:msrp://bob.home.net:2588/572424;tcp

The MRFC replies

71









msrp://bob.home.net:2588/572424



SIP/2.0 200 OK


;tag=976367891912

To: Bob <[email protected]>;tag=8927208

Call-ID: 987097865

CSeq: 2 INVITE


Content-Length: ?

v=0


s=Our chatroom


t=0 0



a=path:msrp://msrp.ims.net:2588/abcd;tcp

Bob sends an ACK back and is ready to VISIT or SEND to the MSRP conversation.As mentioned, since he is the inviter in this case he is also responsible for theconnection. This avoids the NAT problem he might have been posed to at thistime.

At this time a notification will go out to Alice about Bob joining. She will alsoreceive information in the REFER dialog about the success for Bob. The focus stateinformation may reveal differences between the MSRP and the SIP session if Bobhas not joined the MSRP session yet. This may be discussed at a later time.

72




Appendix C

Class diagrams

C.1 MSRP stack API

C.2 MSRP stack implementation

C.3 IMS stack API

C.4 IMS stack implementation

C.5 Java client

73


Leonard BromanAPPENDIX C. CLASS DIAGRAMS

javax.msrp

javax.msrp.data

MsrpFactory

+setPath(path:String): void

+createStack(): MsrpStack

MsrpStack

+PROP_STACK_URI: String

+PROP_STACK_PORT: String

+PROP_STACK_MAX_PACKETS_PER_FLUSH: String

+PROP_STACK_MAX_RESPONSE_QUEUE_LENGTH: String

+PROP_STACK_NAME: String

+setListener(listener:MsrpStackListener): void

+setProperties(configuration:Properties): void

+getProperties(): Properties

+getHeaderFactory(): HeaderFactory

+getFromPath(): FromPathHeader

+createChannel(host:InetAddress,port:int): Channel

+createConnection(direction:int): Connection

+start()

+stop()

MsrpStackListener

+msrpStackStarted(stack:MsrpStack)

+msrpStackStartedFailed(stack:MsrpStack)

+msrpStackInternalFailure(stack:MsrpStack, cause:Throwable)

HeaderFactory

+createMsrpURI(uri:String): MsrpURI

+createOfferPath(path:URI): OfferPath

Connect ion

+State: enum = INITIAL,PROPOSAL,READY,CONNECTED,CLOSING,CLOSED

+Direction: enum = OUTGOING,INCOMING

+setListener(listener:ConnectionListener): void

+getOfferPath(): OfferPath

+getToPath(): ToPathHeader

+getFromPath(): FromPathHeader

+prepare(peerPath:OfferPath): void

+getState(): State

+close(): void

+getId(): String

+createTransmission(text:String): Transmission

+createTransmission(file:File): Transmission

+visit()

Connect ionListener

+connectionReady(conn:Connection): void

+connectionConnected(conn:Connection): void

+connectionClosed(conn:Connection): void

+receive(conn:Connection,t:Transmission): void

MsrpURI

+parse(s:String): void

+getHost(): String

+getPort(): int

+getScheme(): String

+getTransport(): String

+getUserInfo(): String

+toString(): String

+setResource(resource:String): void

+getResource(): String

+clone(): MsrpURI

Transmission

+State: enum = INCOMPLETE,COMPLETE,FAILED

+send(): void

+stop(): void

+pause(): void

+resume(): void

+percentTransmitted(): float

+getSize(): Long

+getState(): State

+setListener(listener:TransmissionListener): void

+getContentType(): ContentTypeHeader

+getEncoding(): String

+getContent(): byte[]

+getId(): String

+getType(): PacketType

Transaction

+isOk(): Boolean

+isSent(): Boolean

+getId(): String

+setListener(listener:TransactionListener): void

+getPacketToSend(): MsrpPacket

Transact ionListener

+transactionTimeout(transaction:Transaction): void

+transactionReplied(transaction:Transaction): void

Encodab le<T>

+encode(): T

<<Encodable<String>>>

OfferPath

+getURIList(): List<? extends MsrpURI>

TransmissionListener

+transmissionComplete(t:Transmission): void

+transmissionFailed(t:Transmission): void

+transmissionTimeout(t:Transmission): void

Channel

+State: enum = UNDETERMINED,DETERMINED,ASSOCIATED,CLOSED,STATELESS

+Direction: enum = INBOUND,OUTBOUND

+send(packet:MsrpPacket): void

+setListener(listener:ChannelLister): void

+getState(): State

+visit()

ChannelListener

+receive(packet:MsrpPacket): void

+channelClosedInactive(channel:Channel)

+channelClosedFailure(channel:Channel)

+channelConnected(channel:Channel)

Figure C.1: javax.msrp and javax.msrp.data package class diagram

74



javax.msrp.data.header

Encodab le<T>

+encode(): T

<<Encodable<String>>>

MsrpHeader

+getKey(): String

+getValue(): String

+clone(): MsrpHeader

+getType(): HeaderType

PathHeader

+makeTo(): ToPathHeader

+makeFrom(): FromPathHeader

FromPathHeader

+key: String = From-Path:

+getLastHop(): MsrpURI

+getOrigin(): MsrpURI

+addHop(uri:MsrpURI): void

ToPathHeader

+key: String = To-Path:

+getNextHop(): MsrpURI

+getDestination(): MsrpURI

+removeHop(uri:MsrpURI): MsrpURI

UsePathHeader

+key: String = Use-Path:

+getEntryPoint(): MsrpURI

ByteRangeHeader

+key: String = Byte-Range:

+getStart(): long

+getEnd(): long

+getTotal(): long

ContentTypeHeader

+key: String = Content-Type:

+getContentType(): String

+getContentSubType(): String

+getParameter(name:String): String

Fai lureReportHeader

+key: String = Failure-Report:

Sta tusHeader

+key: String = Status:

+getCode(): Integer

+getNameSpace(): Integer

+getComment(): String

SuccessReportHeader

+key: String = Success-Report:

Message IDHeader

+key: String = Message-ID:

<<enum>>

HeaderType

-key: String

+getKey(): String

+byString(key:String): HeaderType

Figure C.2: javax.msrp.data.header package class diagram

javax.msrp.data.packet

MsrpPacket

+getHeader(type:HeaderType): MsrpHeader

+getFrom(): FromPathHeader

+getTo(): ToPathHeader

+getId(): String

+getType(): PacketType

+clone(): MsrpPacket

Request

+getMessageID(): String

+createResponse(type:PacketType): Response

Response

+getCode(): int

+getMessage(): String

OK

Unauthor ized

+authorize(username:String,secret:String): Auth

N o t I m p l e m e n t e d

NotFound BadRequest

Auth

+verify(Unauthorized:auth,String:secret): Boolean

Visit

Send

+getContent(): byte[]

+getContentString(): String

+getContentType(): String

+getByteRange(): ByteRangeHeader

<<enum>>

PacketType

-key: String

-comment: String

+getComment(): String

+toString(): String

+byString(key:String): PacketType

Figure C.3: javax.msrp.data.packet package class diagram

75



m s r p

< < C o n n e c t i o n > >

C o n n e c t i o n I m p l

- d i r e c t i o n : i n t

- f r o m P a t h H e a d e r : F r o m P a t h H e a d e r I m p l

- t o P a t h H e a d e r : T o P a t h H e a d e r I m p l

- u s e P a t h H e a d e r : U s e P a t h H e a d e r I m p l

- o f f e r P a t h : O f f e r P a t h I m p l

- t r a n s i d 2 T r a n s m i s s i o n : H a s h M a p < S t r i n g , O u t g o i n g T r a n s m i s s i o n I m p l >

- m e s s i d 2 T r a n s m i s s i o n : H a s h M a p < S t r i n g , I n c o m i n g T r a n s m i s s i o n I m p l >

- t r a n s m i s s i o n s : Q u e u e < T r a n s m i s s i o n I m p l >

- i d : l o n g

- l i s t e n e r : C o n n e c t i o n L i s t e n e r

+ C o n n e c t i o n I m p l ( s t a c k : M s r p S t a c k I m p l )

+ r e c e i v e ( p a c k e t : M s r p P a c k e t I m p l ) : v o i d

+ v i s i t ( ) : v o i d

+ g e t ( ) : M s r p P a c k e t I m p l

+ t r a n s m i s s i o n C o m p l e t e ( t : I n c o m i n g T r a n s m i s s i o n I m p l ) : v o i d

+ t r a n s m i s s i o n C o m p l e t e ( t : O u t g o i n g T r a n s m i s s i o n I m p l ) : v o i d

M a p p i n g Q u e u e < K , V >

# m a p p i n g : H a s h M a p < S t r i n g , V >

# r o b b e r Q u e u e : Q u e u e < S t r i n g >

# s e m a : S e m a p h o r e

# c o u n t : i n t

# r e s o l v e ( k e y : K ) : S t r i n g

+ g e t ( k e y : K ) : V

+ r e m o v e ( k e y : K ) : V

+ h a s ( k e y : K ) : b o o l e a n

+ a d d ( k e y : K , v a l u e : V ) : v o i d

+ r e m o v e A l l ( l i s t : L i s t < K > ) : v o i d

+ r e s e t ( ) : v o i d

+ n e x t ( ) : V

+ i s D o n e ( ) : b o o l e a n

H e a d e r F a c t o r y I m p l

+ c r e a t e M s r p U R I ( o r i g : M s r p U R I ) : M s r p U R I I m p l

+ c r e a t e C o n t e n t T y p e H e a d e r ( t y p e : S t r i n g , s u b t y p e : S t r i n g ) : C o n t e n t T y p e H e a d e r

+ c r e a t e T o P a t h H e a d e r ( u s e P a t h : U s e P a t h H e a d e r , o f f e r e d : O f f e r e d P a t h ) : T o P a t h H e a d e r I m p l

+ c r e a t e O f f e r P a t h ( u s e P a t h : U s e P a t h H e a d e r , f r o m P a t h : F r o m P a t h H e a d e r ) : O f f e r P a t h I m p l

< < C h a n n e l > >

C h a n n e l I m p l

- o u t p u t : O u t p u t S t r e a m

- s o c k e t : S o c k e t

- h o s t A s s o c i a t i o n : M s r p U R I I m p l

- s t a c k : M s r p S t a c k I m p l

- c o n n e c t i o n s : C o n n e c t i o n M a p p e r

- p a r s e r : M s r p P a r s e r

+ M s r p C h a n n e l ( s o c k e t : S o c k e t , s t a c k : M s r p S t a c k I m p l )

+ r e c e i v e ( p a c k e t : M s r p P a c k e t I m p l ) : v o i d

+ f l u s h ( ) : v o i d

- w r i t e ( d a t a : b y t e [ ] ) : v o i d

- f l u s h O u t p u t Q u e u e ( ) : b o o l e a n

+ c l o s e ( ) : v o i d

+ h a s W o r k ( ) : b o o l e a n

+ s e t H o s t A s s o c i a t i o n ( u r i : M s r p U R I I m p l ) : v o i d

+ a d d C o n n e c t i o n ( c o n n : C o n n e c t i o n I m p l ) : v o i d

< < M a p p i n g Q u e u e < M s r p U R I I m p l , C h a n n e l > > >

C h a n n e l M a p p e r

# r e s o l v e ( k e y : M s r p U R I I m p l ) : S t r i n g

< < M a p p i n g Q u e u e < M s r p U R I I m p l , C o n n e c t i o n I m p l > > >

C o n n e c t i o n M a p p e r

# r e s o l v e ( u r i : M s r p U R I I m p l ) : S t r i n g



M s r p P a r s e r

- p a c k s : i n t

- m a x P a c k e t s P a r s e d : i n t

- i s : I n p u t S t r e a m

- c o n n e c t i o n : C h a n n e l

- d e l i m i t e r : P a c k e t D e l i m i t e r


+ h e a d e r T y p e s : M a p < S t r i n g , < C l a s s < ? e x t e n d s M s r p H e a d e r I m p l > >

+ p a c k e t T y p e s : M a p < S t r i n g , < C l a s s < ? e x t e n d s M s r p P a c k e t I m p l > >

+ M s r p P a r s e r ( s t r e a m : I n p u t S t r e a m , c o n : C h a n n e l , s t a c k : M s r p S t a c k I m p l )

+ f l u s h ( ) : v o i d


< < M s r p S t a c k , R u n n a b l e > >

M s r p S t a c k I m p l

- o u t p u t L i s t e n e r : R a w S t r e a m C h u n k L i s t e n e r

- i n p u t L i s t e n e r : R a w S t r e a m C h u n k L i s t e n e r

- c o n f : P r o p e r t i e s

- c h a n n e l M a p p i n g : C h a n n e l M a p p e r

- p e n d i n g C o n n e c t i o n s : C o n n e c t i o n M a p p e r

- i n c o m i n g S o c k e t s : Q u e u e >

- r u n : b o o l e a n = t r u e

- n a m e : S t r i n g

- f r o m P a t h : F r o m P a t h H e a d e r I m p l

- u s e P a t h : U s e P a t h H e a d e r I m p l

- s e t N a m e ( n a m e : S t r i n g ) : v o i d

- c r e a t e O u t g o i n g C o n n e c t i o n ( ) : C o n n e c t i o n I m p l

- c r e a t e I n c o m i n g C o n n e c t i o n ( ) : C o n n e c t i o n I m p l

+ M s r p S t a c k I m p l ( )

+ s i g n a l S t o p ( ) : v o i d

+ a d d U R I A s s o c i a t i o n ( u r i : M s r p U R I I m p l , c o n n e c t i o n : C h a n n e l ) : v o i d

+ s t a r t ( n a m e : S t r i n g ) : v o i d

+ g e t P r o p e r t y ( k e y : S t r i n g ) : S t r i n g

+ g e t I n t P r o p e r t y ( k e y : S t r i n g ) : i n t

+ g e t U s e P a t h ( ) : U s e P a t h H e a d e r I m p l

+ e n q u e u e F o r C o n n e c t i o n ( C o n n e c t i o n I m p l : c o n n ) : v o i d

+ c o n n e c t ( u r i : M s r p U R I I m p l ) : S o c k e t

+ g e t P e n d i n g C o n n e c t i o n ( o r i g i n : M s r p U R I I m p l ) : C o n n e c t i o n I m p l

S o c k e t L i s t e n e r L i s t e n e r

+ r e c e i v e ( u r i : M s r p U R I I m p l , s : S o c k e t ) : v o i d

< < R u n n a b l e > >

S o c k e t L i s t e n e r

+ S T A T E _ P A S S I V E : i n t = 1

+ S T A T E _ A C T I V E : i n t = 2

- l i s t e n e r s : H a s h M a p < S t r i n g , S o c k e t L i s t e n e r >

- l i s t e n e r : S o c k e t L i s t e n e r L i s t e n e r

- u r i : M s r p U R I I m p l

- s e m a : S e m a p h o r e = S e m a p h o r e ( 1 )

- r u n : b o o l e a n = t r u e

- h o s t : I n e t A d d r e s s

- p o r t : i n t

- c o u n t : i n t

- s e r v S o c k : S e r v e r S o c k e t

- S o c k e t L i s t e n e r ( u r i : M s r p U R I I m p l , l i s t e n e r : S o c k e t L i s t e n e r L i s t e n e r )

- s t o p ( ) : v o i d

+ g e t L i s t e n e r ( u r i : M s r p U R I I m p l , l i s t e n e r : S o c k e t L i s t e n e r L i s t e n e r ) : S o c k e t L i s t e n e r

+ s t o p L i s t e n e r ( u r i : M s r p U R I I m p l ) : v o i d

P a c k e t D e l i m i t e r

+ m a x S i z e : i n t = 1 0 2 4 * 2 * 2

- b u f f e r : b y t e [ ]

- s t a r t : i n t

- s i z e : i n t

- i s : I n p u t S t r e a m


- r e B u f f e r ( ) : b o o l e a n

- e x t r a c t P a c k e t ( ) : b y t e [ ]

+ P a c k e t D e l i m i t e r ( i s : I n p u t S t r e a m , s t a c k : M s r p S t a c k I m p l )

+ g e t ( ) : R a w M s r p P a c k e t

+ d u m p B u f f e r ( ) : S t r i n g


Figure C.4: com.atosorigin.msrp package class diagram

76



c o m . a t o s o r i g i n . m s r p . d a t a

B y t e A r r a y B u i l d e r

- c h u n k s : L i s t 

- l e n g t h : i n t

+ a p p e n d ( d a t a : b y t e [ ] ) : v o i d

+ a p p e n d ( d a t a : b y t e [ ] , s t a r t : i n t , e n d : i n t ) : v o i d

+ g e t B y t e s ( ) : b y t e [ ]

B y t e A r r a y s

+ e q u a l s S u b R a n g e ( a : b y t e [ ] , a S t a r t : i n t , b : b y t e [ ] , b S t a r t : i n t , l e n : i n t ) : b o o l e a n

+ c o p y S u b R a n g e ( f r o m : b y t e [ ] , f r o m S t a r t : i n t , t o : b y t e [ ] , t o S t a r t : i n t , l e n : i n t ) : v o i d

+ a p p e n d ( f i r s t : b y t e [ ] , s e c o n d : b y t e [ ] ) : b y t e [ ]

+ r a n d o m ( l e n g t h : i n t ) : b y t e [ ]

+ s u b R a n g e ( s o u r c e : b y t e [ ] , f r o m : i n t , s i z e : i n t ) : b y t e [ ]

< < T r a n s a c t i o n I m p l > >

I n c o m i n g T r a n s a c t i o n I m p l

+ I n c o m i n g T r a n s a c t i o n I m p l ( p a c k e t : R e q u e s t I m p l )

+ i s O k ( ) : b o o l e a n

< < T r a n s m i s s i o n I m p l > >

I n c o m i n g T r a n s m i s s i o n I m p l

+ o s t r e a m : B u f f e r e d O u t p u t S t r e a m

+ o b y t e s : B y t e A r r a y O u t p u t S t r e a m

+ c o n t e n t S i z e : l o n g

+ p o s i t i o n : l o n g

+ m a x P o s i t i o n R e c e i v e d : l o n g

+ r e s p o n s e Q u e u e : Q u e u e < R e s p o n s e I m p l >

+ n o n C o m m i t t e d C h u n k s : S o r t e d M a p < L o n g , S e n d I m p l >

+ a l l R e c e i v e d : b o o l e a n

+ I n c o m i n g T r a n s m i s s i o n I m p l ( r e q : R e q u e s t I m p l , c o n n e c t i o n : C o n n e c t i o n I m p l )

- a p p e n d C o n t e n t ( s : S e n d I m p l ) : v o i d

- s e t C o m p l e t e ( ) : v o i d

< < M s r p U R I , E n c o d a b l e < S t r i n g > , C o p y a b l e < M s r p U R I I m p l > > >

M s r p U R I I m p l

- s c h e m e : S t r i n g = m s r p

- u s e r i n f o : S t r i n g

- h o s t : S t r i n g

- p o r t : i n t = 2 8 5 5

- r e s o u r c e : S t r i n g

- t r a n s p o r t : S t r i n g = t c p

- p a r a m e t e r s : L i s t 

+ M s r p U R I I m p l ( U R I : S t r i n g )

+ M s r p U R I I m p l ( o r i g : M s r p U R I I m p l )

+ M s r p U R I I m p l ( o r i g : M s r p U R I )

+ M s r p U R I I m p l ( s c h e m e : S t r i n g , u s e r i n f o : S t r i n g , h o s t : S t r i n g , i n t : p o r t , s e s s i o n I D : S t r i n g , t r a n s p o r t : S t r i n g , p a r a m e t e r s : L i s t )

< < O f f e r P a t h > >

O f f e r P a t h I m p l

- l i s t : L i s t < M s r p U R I I m p l >

+ O f f e r P a t h I m p l ( l i s t : S t r i n g )

+ O f f e r P a t h I m p l ( l i s t : L i n k e d L i s t < M s r p U R I I m p l > )

< < T r a n s a c t i o n I m p l > >

O u t g o i n g T r a n s a c t i o n I m p l

< < T r a n s a c t i o n > >

T r a n s a c t i o n I m p l

- i d : S t r i n g

- l i s t e n e r : T r a n s a c t i o n L i s t e n e r

- r e q : R e q u e s t I m p l

- r e s p : R e s p o n s e I m p l

< < T r a n s m i s s i o n > >

T r a n s m i s s i o n I m p l

+ i d : S t r i n g

+ l i s t e n e r : T r a n s m i s s i o n L i s t e n e r

+ c o n n e c t i o n : C o n n e c t i o n I m p l

+ t y p e : S t r i n g

+ c o n t e n t T y p e : C o n t e n t T y p e H e a d e r

+ h a s Q u e u e ( ) : b o o l e a n


+ r e c e i v e ( r e s p o n s e : R e s p o n s e I m p l ) : v o i d

+ r e c e i v e ( r e q u e s t : R e q u e s t I m p l ) : v o i d

< , E n c o d a b l e < S t r i n g > , C o p y a b l e > >

P a r a m e t e r

+ P a r a m e t e r ( k e y : S t r i n g )

+ P a r a m e t e r ( k e y : S t r i n g , v a l u e : S t r i n g )

+ p a r s e ( d a t a : S t r i n g ) : P a r a m e t e r

O u t g o i n g T r a n s m i s s i o n I m p l

- i s t r e a m : B u f f e r e d I n p u t S t r e a m

- p o s i t i o n : l o n g = 1

- s i z e : l o n g

- s e n d Q u e u e : Q u e u e < O u t g o i n g T r a n s a c t i o n I m p l >

- s e t C o m p l e t e ( )

+ O u t g o i n g T r a n s m i s s i o n I m p l ( c o n n e c t i o n : C o n n e c t i o n I m p l )

+ O u t g o i n g T r a n s m i s s i o n I m p l ( t e x t : S t r i n g , c o n n e c t i o n : C o n n e c t i o n I m p l )

+ O u t g o i n g T r a n s m i s s i o n I m p l ( f i l e : F i l e , c o n n e c t i o n : C o n n e c t i o n I m p l )

+ r e f i l l Q u e u e ( ) : v o i d

Figure C.5: com.atosorigin.msrp.data package class diagram

77



com.atosorigin.msrp.data.header

R a w M s r p H e a d e r

-key: String

-content: String

+RawMsrpHeader(line:String)

+getKey(): String

+getContent(): String

<<MsrpHeader>>

MsrpHeader Imp l

+parse(String:data): void

+getKey(): String

+getValue(): String

+encode(): String

<<PathHeader>>

PathHeader Impl

#URIList: LinkedList<MsrpURIImpl>

#PathHeaderImpl(list:LinkedList<MsrpURIImpl>)

#PathHeaderImpl(uri:MsrpURIImpl)

#PathHeaderImpl(original:PathHeaderImpl)

#parseUriList(data:String): LinkedList<MsrpURIImpl>

+PathHeaderImpl()

+getURIList(): LinkedList<MsrpURIImpl>

+makeTo(): ToPathHeaderImpl

+makeFrom(): FromPathHeaderImpl

<<ToPathHeader>>

ToPathHeader Impl

<<FromPathHeader>>

FromPathHeader Impl<<UsePathHeader>>

UsePathHeader Impl

<<MessageIDHeader>>

Message IDHeader Impl

<<SuccessReportHeader>>

SuccessReportHeader Impl

<<StatusHeader>>

Sta tusHeader Impl

-namespace: int = 000

-code: int

-comment: String

+StatusHeaderImpl(code:int)

+StatusHeaderImpl(code:int,comment:String)

<<FailureReportHeader>>

Fai lureRepor tHeader Impl

<<ContentTypeHeader>>

ContentTypeHeader Impl

-type: String

-subType: String

-params: List<Parameter>

+ContentTypeHeaderImpl(type:String,subType:String)

+ContentTypeHeaderImpl(type:String,subType:String, params:List<Parameter>)

+getType(): String

+getSubType(): String

<<ByteRangeHeader>>

ByteRangeHeader Impl

-start: long

-end: long

-total: long

+ByteRangeHeaderImpl(start:long,end:long, total:long)

Figure C.6: com.atosorigin.msrp.data.header package class diagram, only imple-mented classes included

78



c o m . a t o s o r i g i n . m s r p . d a t a . p a c k e t

R a w M s r p P a c k e t

+ t y p e : S t r i n g

+ t r a n s a c t i o n I D : S t r i n g

+ c o n t F l a g : b y t e

+ h e a d e r s : L i s t < R a w M s r p H e a d e r >

+ c o n t e n t : b y t e [ ]

+ p a c k e t : b y t e [ ]

+ p o s : i n t = 0

+ R a w M s r p P a c k e t ( d a t a : b y t e [ ] )

+ g e t T y p e ( ) : S t r i n g

+ g e t T r a n s a c t i o n I D ( ) : S t r i n g

+ g e t C o n t F l a y ( ) : b y t e

+ g e t H e a d e r s ( ) : L i s t < R a w M s r p H e a d e r >

+ g e t C o n t e n t ( ) : b y t e [ ]

+ g e t L i n e ( ) : b y t e [ ]

< < M s r p P a c k e t , E n c o d a b l e , P a r s a b l e < R a w M s r p P a c k e t > > >

M s r p P a c k e t I m p l

+ r : R a n d o m

# f r o m : F r o m P a t h H e a d e r I m p l

# t o : T o P a t h H e a d e r I m p l

# i d : S t r i n g

# e x t r a H e a d e r s : V e c t o r < M s r p H e a d e r I m p l >

+ s e t H e a d e r ( h : M s r p H e a d e r I m p l ) : b o o l e a n

+ g e t F r o m ( ) : F r o m P a t h H e a d e r I m p l

+ g e t H e a d e r ( h e a d e r : S t r i n g ) : M s r p H e a d e r I m p l

+ g e t T o ( ) : T o P a t h H e a d e r I m p l

+ g e t I d ( ) : S t r i n g

+ s e t I d ( i d : S t r i n g ) : v o i d

+ e n c o d e ( ) : b y t e [ ]

+ g e t T y p e ( ) : S t r i n g

+ p a r s e ( p a c k e t : R a w M s r p P a c k e t ) : v o i d

# e n c o d e E x t r a H e a d e r s ( ) : b y t e [ ]

# e n c o d e F r o m T o ( ) : b y t e [ ]

# e n c o d e E n d L i n e ( ) : b y t e [ ]

< < R e q u e s t > >

R e q u e s t I m p l

# m e s s a g e I D : M e s s a g e I D H e a d e r I m p l

+ c r e a t e O K ( ) : O K I m p l

+ g e t M e s s a g e I D ( ) : S t r i n g

+ s e t M e s s a g e I D ( i d : S t r i n g ) : v o i d

R e s p o n s e I m p l

+ g e t C o d e ( ) : i n t

+ g e t M e s s a g e ( ) : S t r i n g

< < S e n d > >

S e n d I m p l

- c o n t e n t : b y t e [ ]

- c o n t e n t T y p e : C o n t e n t T y p e H e a d e r I m p l

- b y t e R a n g e : B y t e R a n g e H e a d e r I m p l

- l a s t P a c k e t : b o o l e a n

+ S e n d I m p l ( f r o m H : F r o m P a t h H e a d e r I m p l , t o H : T o P a t h H e a d e r I m p l , c o n t e n t T y p e H : C o n t e n t T y p e H e a d e r I m p l , s t a r t : l o n g , e n d : l o n g , t o t a l : l o n g , c o n t e n t : b y t e [ ] )

+ S e n d I m p l ( f r o m : F r o m P a t h H e a d e r I m p l , t o : T o P a t h H e a d e r I m p l , t y p e : C o n t e n t T y p e H e a d e r I m p l , c o n t e n t : b y t e [ ] )

+ S e n d I m p l ( o r i g i n a l : S e n d I m p l )

+ g e t B y t e R a n g e ( ) : B y t e R a n g e H e a d e r I m p l

+ i s L a s t P a c k e t ( ) : b o o l e a n

+ i s P r o p e r ( ) : b o o l e a n

+ g e t C o n t e n t T y p e ( ) : S t r i n g

- e n c o d e H e a d e r ( ) : b y t e [ ]

< < O K > >

O K I m p l

+ O K I m p l ( f r o m : F r o m P a t h H e a d e r I m p l , t o : T o P a t h H e a d e r I m p l , i d : S t r i n g )

< < V i s i t > >

V i s i t I m p l

+ V i s i t I m p l ( f r o m : F r o m P a t h H e a d e r I m p l , t o : T o P a t h H e a d e r I m p l )

< >

B a d R e q u e s t I m p l

Figure C.7: com.atosorigin.msrp.data.packet package class diagram, only imple-mented classes included

79



j a v a x . i m s

S e r v i c e

+ S T A T E _ C L O S E D : i n t

+ S T A T E _ C L O S I N G : i n t

+ S T A T E _ I N I T : i n t

+ S T A T E _ O P E N : i n t

+ S T A T E _ O P E N I N G : i n t

+ c l o s e ( ) : v o i d

+ g e t A c c e s s N e t w o r k ( ) : A c c e s s N e t w o r k

+ g e t A p p I d ( ) : S t r i n g

+ g e t S t a t e ( ) : i n t

+ g e t T y p e ( ) : S t r i n g

+ o p e n ( ) : v o i d

S e r v i c e L i s t e n e r

+ s e r v i c e C l o s e d ( s e r v i c e : S e r v i c e ) : v o i d

+ s e r v i c e O p e n ( s e r v i c e : S e r v i c e , s t a t u s : b o o l e a n ) : v o i d

A c c e s s N e t w o r k

+ A C C E S S _ N E T W O R K _ C A B L E : i n t

+ A C C E S S _ N E T W O R K _ C D M A 2 0 0 0 : i n t

+ A C C E S S _ N E T W O R K _ D S L : i n t

+ A C C E S S _ N E T W O R K _ G P R S : i n t

+ A C C E S S _ N E T W O R K _ N O T _ A P P L I C A B L E : i n t

+ A C C E S S _ N E T W O R K _ O T H E R : i n t

+ A C C E S S _ N E T W O R K _ U M T S : i n t

+ A C C E S S _ N E T W O R K _ U N K N O W N : i n t

+ A C C E S S _ N E T W O R K _ W L A N : i n t

+ A C C E S S _ N E T W O R K _ E T H E R N E T : i n t

+ g e t I n f o ( ) : S t r i n g

+ g e t T y p e ( ) : i n t

< < E x c e p t i o n > >

I m s E x c e p t i o n

I m s F a c t o r y

+ s e t P a t h ( p a t h : S t r i n g ) : v o i d

+ c r e a t e S t a c k ( p r o p e r t i e s : P r o p e r t i e s ) : I m s S t a c k

I m s S t a c k

+ g e t S e r v i c e ( a p p I d : S t r i n g , s e r v i c e N a m e : S t r i n g ) : S e r v i c e

+ d e s t r o y ( ) : v o i d

Figure C.8: javax.ims package classes

80



j a v a x . i m s . c o r e

< < j a v a x . i m s . S e r v i c e > >

C o r e S e r v i c e

+ c r e a t e C a p a b l i t i e s ( f r o m : S t r i n g , t o : S t r i n g ) : C a p a b i l i t i e s

+ c r e a t e P a g e M e s s a g e ( f r o m : S t r i n g , t o : S t r i n g , c o n t e n t : b y t e [ ] , c o n t e n t T y p e : S t r i n g ) : P a g e M e s s a g e

+ c r e a t e P u b l i c a t i o n ( t o : S t r i n g , e v e n t : S t r i n g ) : P u b l i c a t i o n

+ c r e a t e R e f e r e n c e ( f r o m : S t r i n g , t o : S t r i n g , r e f e r T o : S t r i n g , r e f e r M e t h o d : S t r i n g ) : R e f e r e n c e

+ c r e a t e S e s s i o n ( f r o m : S t r i n g , t o : S t r i n g ) : S e s s i o n

+ c r e a t e S u b s c r i p t i o n ( f r o m : S t r i n g , t o : S t r i n g , e v e n t : S t r i n g ) : S u b s c r i p t i o n

+ g e t L o c a l U s e r I d ( ) : S t r i n g

+ s e t L i s t e n e r ( C o r e S e r v i c e L i s t e n e r : l i s t e n e r ) : v o i d

+ s e t L o c a l U s e r I d ( u s e r I d : S t r i n g ) : v o i d

S e r v i c e M e t h o d

+ a d d H e a d e r ( k e y : S t r i n g , v a l u e : S t r i n g ) : v o i d

+ c r e a t e B o d y P a r t ( ) : M e s s a g e B o d y P a r t

+ g e t R e m o t e U s e r I d ( ) : S t r i n g

+ g e t R e q u e s t ( m e t h o d : i n t ) : M e s s a g e

+ g e t R e s p o n s e s ( m e t h o d : i n t ) : M e s s a g e [ ]

S e s s i o n

+ S T A T E _ E S T A B L I S H E D : i n t

+ S T A T E _ I N I T I A T E D : i n t

+ S T A T E _ N E G O T I A T I N G : i n t

+ S T A T E _ P R O C E E D I N G : i t n

+ S T A T E _ T E R M I N A T E D : i n t

+ S T A T E _ T E R M I N A T I N G : i n t

+ a c c e p t ( ) : v o i d

+ c a n c e l U p d a t e ( ) : v o i d

+ c r e a t e C a p a b i l i t i e s ( ) : C a p a b i l i t i e s

+ c r e a t e M e d i a ( t y p e : S t r i n g , d i r e c t i o n : i n t ) : M e d i a

+ c r e a t e R e f e r e n c e ( r e f e r T o : S t r i n g , r e f e r M e t h o d : S t r i n g ) : R e f e r e n c e

+ g e t M e d i a ( ) : V e c t o r < M e d i a >

+ g e t S e s s i o n D e s c r i p t o r ( ) : S e s s i o n D e s c r i p t o r

+ g e t S t a t e ( ) : i n t

+ h a s P e n d i n g U p d a t e s ( ) : b o o l e a n

+ r e j e c t ( ) : v o i d

+ r e m o v e M e d i a ( m e d i a : M e d i a ) : v o i d

+ s t a r t ( ) : v o i d

+ s e t L i s t e n e r ( l i s t e n e r : S e s s i o n L i s t e n e r ) : v o i d

+ s t a r t ( ) : v o i d

+ t e r m i n a t e ( ) : v o i d

+ u p d a t e ( ) : v o i d

S u b s c r i p t i o n L i s t e n e r

+ s u b s c r i p t i o n N o t i f y ( s u b s c r i p t i o n : S u b s c r i p t i o n , s t a t e : S t r i n g ) : v o i d

+ s u b s c r i p t i o n S t a r t e d ( s u b s c r i p t i o n : S u b s c r i p t i o n ) : v o i d

+ s u b s c r i p t i o n S t a r t e d F a i l e d ( s u b s c r i p t i o n : S u b s c r i p t i o n ) : v o i d

+ s u b s c r i p t i o n T e r m i n a t e d ( s u b s c r i p t i o n : S u b s c r i p t i o n , s t a t e : S t r i n g ) : v o i d

S u b s c r i p t i o n

+ S T A T E _ A C T I V E : i n t

+ S T A T E _ I N A C T I V E : i n t

+ S T A T E _ P E N D I N G : i n t

+ g e t E v e n t ( ) : S t r i n g

+ g e t S t a t e ( ) : i n t

+ s e t L i s t e n e r ( l i s t e n e r : S u b s c r i p t i o n L i s t e n e r ) : v o i d

+ s u b s c r i b e ( ) : v o i d

+ u n s u b s c r i b e ( ) : v o i d

S e s s i o n L i s t e n e r

+ s e s s i o n A l e r t i n g ( s e s s i o n : S e s s i o n ) : v o i d

+ s e s s i o n R e f e r e n c e R e q u e s t ( s e s s i o n : S e s s i o n , r e f e r e n c e : R e f e r e n c e ) : v o i d

+ s e s s i o n S t a r t e d ( s e s s i o n : S e s s i o n ) : v o i d

+ s e s s i o n S t a r t e d F a i l e d ( s e s s i o n : S e s s i o n ) : v o i d

+ s e s s i o n T e r m i n a t e d ( s e s s i o n : S e s s i o n ) : v o i d

+ s e s s i o n U p d a t e A c c e p t e d ( s e s s i o n : S e s s i o n ) : v o i d

+ s e s s i o n U p d a t e F a i l e d ( s e s s i o n : S e s s i o n ) : v o i d

+ s e s s i o n U p d a t e R e q u e s t ( s e s s i o n : S e s s i o n ) : v o i d

S e s s i o n D e s c r i p t o r

+ a d d A t t r i b u t e ( a t t r i b u t e : S t r i n g ) : v o i d

+ g e t A t t r i b u t e s ( ) : V e c t o r < S t r i n g >

+ g e t B a n d w i d t h I n f o ( ) : S t r i n g

+ g e t C o n n e c t i o n I n f o ( ) : S t r i n g

+ g e t E m a i l A d d r ( ) : S t r i n g

+ g e t P h o n e N u m b e r ( ) : S t r i n g

+ g e t P r o t o c o l V e r s i o n ( ) : S t r i n g

+ g e t R e p e a t T i m e s ( ) : S t r i n g

+ g e t S e s s i o n I d ( ) : S t r i n g

+ g e t S e s s i o n I n f o ( ) : S t r i n g

+ g e t S e s s i o n N a m e ( ) : S t r i n g

+ g e t S e s s i o n U R I ( ) : S t r i n g

+ g e t T i m e S e s s i o n ( ) : S t r i n g

+ g e t T i m e z o n e C o r r e c t i o n ( ) : S t r i n g

+ r e m o v e A t t r i b u t e ( a t t r i b u t e : S t r i n g ) : v o i d

+ s e t E m a i l A d d r ( e m a i l : S t r i n g ) : v o i d

+ s e t P h o n e N u m b e r ( n u m b e r : S t r i n g ) : v o i d

+ s e t S e s s i o n I n f o ( i n f o : S t r i n g ) : v o i d

+ s e t S e s s i o n N a m e ( n a m e : S t r i n g ) : v o i d

+ s e t S e s s i o n U R I ( u r i : S t r i n g ) : v o i d

< < j a v a x . i m s . S e r v i c e L i s t e n e r > >

C o r e S e r v i c e L i s t e n e r

+ p a g e M e s s a g e R e c e i v e d ( s e r v i c e : C o r e S e r v i c e , m e s s a g e : P a g e M e s s a g e ) : v o i d

+ r e f e r e n c e R e c e i v e d ( s e r v i c e : C o r e S e r v i c e , r e f e r e n c e : R e f e r e n c e ) : v o i d

+ s e s s i o n I n v i t a t i o n R e c e i v e d ( s e r v i c e : C o r e S e r v i c e , s e s s i o n : S e s s i o n ) : v o i d

+ u n s o l i c i t e d N o t i f y R e c e i v e d ( s e r v i c e : C o r e S e r v i c e , n o t i f y : S t r i n g ) : v o i d

P u b l i c a t i o n L i s t e n e r

+ p u b l i s h D e l i v e r e d ( p u b l i c a t i o n : P u b l i c a t i o n ) : v o i d

+ p u b l i s h D e l i v e r e d F a i l e d ( p u b l i c a t i o n : P u b l i c a t i o n ) : v o i d

+ u n p u b l i s h D e l i v e r e d ( p u b l i c a t i o n : P u b l i c a t i o n ) : v o i d

+ u n p u b l i s h D e l i v e r e d F a i l e d ( p u b l i c a t i o n : P u b l i c a t i o n ) : v o i d

P u b l i c a t i o n




+ g e t E v e n t ( ) : S t r i n g

+ g e t S t a t e ( ) : i n t

+ p u b l i s h ( s t a t e : S t r i n g ) : v o i d

+ s e t L i s t e n e r ( l i s t e n e r : P u b l i c a t i o n L i s t e n e r ) : v o i d

+ u n p u b l i s h ( ) : v o i d

P a g e M e s s a g e L i s t e n e r

+ p a g e M e s s a g e D e l i v e r e d ( m e s s a g e : P a g e M e s s a g e ) : v o i d

+ p a g e M e s s a g e D e l i v e r e d F a i l e d ( m e s s a g e : P a g e M e s s a g e ) : v o i d

P a g e M e s s a g e

+ S T A T E _ R E C E I V E D : i n t

+ S T A T E _ S E N T : i n t

+ S T A T E _ U N S E N T : i n t

+ g e t C o n t e n t ( ) : b y t e [ ]

+ g e t C o n t e n t T y p e ( ) : S t r i n g

+ g e t S t a t e ( ) : i n t

+ s e n d ( ) : v o i d

+ s e t L i s t e n e r ( l i s t e n e r : P a g e M e s s a g e L i s t e n e r ) : v o i d

M e s s a g e B o d y P a r t

+ g e t C o n t e n t ( ) : b y t e [ ]

+ g e t H e a d e r ( k e y : S t r i n g ) : S t r i n g

+ g e t L e n g t h ( ) : i n t

+ s e t C o n t e n t ( c o n t e n t : b y t e [ ] ) : v o i d

+ s e t H e a d e r ( k e y : S t r i n g , v a l u e : S t r i n g ) : v o i d

M e s s a g e

+ M E T H O D _ A C K : i n t

+ M E T H O D _ B Y E : i n t

+ M E T H O D _ C A N C E L : i n t

+ M E T H O D _ I N F O : i n t

+ M E T H O D _ I N V I T E : i n t

+ M E T H O D _ M E S S A G E : i n t

+ M E T H O D _ N O T I F Y : i n t

+ M E T H O D _ O P T I O N S : i n t

+ M E T H O D _ P R A C K : i n t

+ M E T H O D _ P U B L I S H : i n t

+ M E T H O D _ R E F E R : i n t

+ M E T H O D _ R E G I S T E R : i n t

+ M E T H O D _ S U B S C R I B E : i n t

+ M E T H O D _ U P D A T E : i n t

+ g e t B o d y P a r t s ( ) : M e s s a g e B o d y P a r t [ ]

+ g e t H e a d e r ( k e y : S t r i n g ) : S t r i n g [ ]

+ g e t R e a s o n P h r a s e ( ) : S t r i n g

+ g e t S t a t u s C o d e ( ) : i n t

Figure C.9: javax.ims.core package classes

81



j a v a x . i m s . c o r e . m e d i a

M e d i a

+ D I R E C T I O N _ I N A C T I V E : i n t

+ D I R E C T I O N _ R E C E I V E : i n t

+ D I R E C T I O N _ S E N D : i n t

+ D I R E C T I O N _ S E N D _ R E C E I V E : i n t


+ S T A T E _ D E L E T E D : i n t



+ S T A T E _ P R O P O S A L : i n t

+ U P D A T E _ M O D I F I E D : i n t

+ U D P A T E _ N E W : i n t

+ U P D A T E _ R E M O V E D : i n t

+ U P D A T E _ U N C H A N G E D : i n t

+ g e t D i r e c t i o n ( ) : i n t

+ g e t P r o p o s a l ( ) : M e d i a

+ g e t M e d i a D e s c r i p t o r ( ) : M e d i a D e s c r i p t o r

+ g e t S t a t e ( ) : i n t

+ g e t U p d a t e S t a t e ( ) : i n t

+ s e t D i r e c t i o n ( d i r e c t i o n : i n t ) : v o i d

F r a m e d M e d i a

+ c a n c e l ( m e s s a g e I d : S t r i n g ) : v o i d

+ c r e a t e F l o w S p e c ( ) : F r a m e d M e d i a F l o w S p e c

+ g e t A c c e p t e d C o n t e n t T y p e s ( ) : S t r i n g [ ]

+ g e t C o n t e n t T y p e ( m e s s a g e I d : S t r i n g ) : S t r i n g

+ g e t H e a d e r ( m e s s a g e I d : S t r i n g , h e a d e r : S t r i n g ) : S t r i n g [ ]

+ r e c e i v e B y t e s ( m e s s a g e I d : S t r i n g ) : b y t e [ ]

+ r e c e i v e F i l e ( m e s s a g e I d : S t r i n g , l o c a t o r : S t r i n g ) : v o i d

+ s e n d B y t e s ( c o n t e n t : b y t e [ ] , c o n t e n t T y p e : S t r i n g , h e a d e r s : S t r i n g [ ] [ ] ) : S t r i n g

+ s e n d F i l e ( l o c a t o r : S t r i n g , c o n t e n t T y p e : S t r i n g , h e a d e r s : S t r i n g [ ] [ ] ) : S t r i n g

+ s e t A c c e p t e d C o n t e n t T y p e s ( a c c e p t e d C o n t e n t T y p e s : S t r i n g [ ] ) : v o i d

+ s e t L i s t e n e r ( l i s t e n e r : F r a m e d M e d i a L i s t e n e r ) : v o i d

F r a m e d M e d i a L i s t e n e r

+ c o n n e c t i o n A c t i v e ( m e d i a : F r a m e d M e d i a ) : v o i d

+ c o n n e c t i o n C l o s e d ( m e d i a : F r a m e d M e d i a ) : v o i d

+ c o n n e c t i o n E r r o r ( m e d i a : F r a m e d M e d i a ) : v o i d

+ d e l i v e r y F a i l u r e ( m e d i a : F r a m e d M e d i a , m e s s a g e I d : S t r i n g , s t a t u s C o d e : i n t , r e a s o n P h r a s e : S t r i n g ) : v o i d

+ d e l i v e r y S u c c e s s ( m e d i a : F r a m e d M e d i a , m e s s a g e I d : S t r i n g ) : F r a m e d M e d i a

+ r e c e i v e d C o m p l e t e ( m e d i a : F r a m e d M e d i a , m e s s a g e I d : S t r i n g , s i z e : i n t ) : v o i d

+ s e n d C o m p l e t e ( m e d i a : F r a m e d M e d i a , m e s s a g e I d : S t r i n g ) : v o i d

+ t r a n s f e r P r o g r e s s ( m e d i a : F r a m e d M e d i a , m e s s a g e I d : S t r i n g , b y t e s T r a n s f e r r e d : i n t , b y t e s T o t a l : i n t ) : v o i d

M e d i a D e s c r i p t o r

+ a d d A t t r i b u t e ( a t t r i b u t e : S t r i n g ) : v o i d

+ g e t A t t r i b u t e s ( ) : V e c t o r < S t r i n g >

+ g e t M e d i a D e s c r i p t i o n ( ) : S t r i n g

+ g e t M e d i a T i t l e ( ) : S t r i n g

+ r e m o v e A t t r i b u t e ( a t t r i b u t e : S t r i n g ) : v o i d

+ s e t M e d i a T i t l e ( t i t l e : S t r i n g ) : v o i d

F r a m e d M e d i a F l o w S p e c

+ M O D E _ I N S T A N T : i n t

+ M D O E _ P R O G R E S S I V E : i n t

+ g e t I n s t a n t D e l a y ( ) : i n t

+ g e t M o d e ( ) : i n t

+ g e t P r o g r e s s i v e B a n d w i d t h ( ) : i n t

+ s e t I n s t a n t D e l a y ( d e l a y : i n t ) : v o i d

+ s e t M o d e ( m o d e : i n t ) : v o i d

+ s e t P r o g r e s s i v e B a n d w i d t h ( b a n d w i d t h : i n t )

Figure C.10: javax.ims.core.media package classes

j a v a x . i m s . r e s o u r c e . d i a

C o n t a c t

+ g e t I d ( ) : S t r i n g

+ g e t D i s p l a y N a m e ( ) : S t r i n g

+ s e t D i s p l a y N a m e ( n a m e : S t r i n g ) : v o i d

+ s e t B l o c k e d ( b l o c k e d : b o o l e a n ) : v o i d

+ i s B l o c k e d ( ) : b o o l e a n

C o n t a c t L i s t

+ g e t C o n t a c t s ( ) : L i s t < C o n t a c t >

+ a d d C o n t a c t ( c o n t a c t : C o n t a c t ) : v o i d

+ r e m o v e C o n t a c t ( c o n t a c t : C o n t a c t ) : v o i d

< < S e r v i c e > >

R e s o u r c e S e r v i c e

+ X C A P _ H O S T : S t r i n g = j a v a x . i m s . r e s o u c r e . X C A P _ H O S T

+ X C A P _ P O R T : S t r i n g = j a v a x . i m s . r e s o u r c e . X C A P _ P O R T

+ g e t C o n t a c t ( i d : S t r i n g ) : C o n t a c t

+ c r e a t e C o n t a c t ( i d : S t r i n g , d i s p l a y N a m e : n a m e ) : C o n t a c t

+ g e t C o n t a c t L i s t ( i d : S t r i n g ) : C o n t a c t L i s t

+ c r e a t e C o n t a c t L i s t ( i d : S t r i n g ) : C o n t a c t L i s t

+ a d d C o n t a c t L i s t ( c o n t a c t L i s t : C o n t a c t L i s t ) : v o i d

+ r e m o v e C o n t a c t L i s t ( c o n t a c t L i s t : C o n t a c t L i s t ) : v o i d

+ s e t L i s t e n e r ( l i s t e n e r : R e s o u r c e S e r v i c e L i s t e n e r ) : v o i d

< < S e r v i c e L i s t e n e r > >

R e s o u r c e S e r v i c e L i s t e n e r

+ r e s o u r c e S e r v i c e O p e n F a i l e d ( s e r v i c e : R e s o u r c e S e r v i c e ) : v o i d

Figure C.11: javax.ims.resource package classes

82



j a v a x . s e r v l e t

< >

S e r v l e t

+ d e s t r o y ( )

+ g e t S e r v l e t C o n f i g ( ) : S e r v l e t C o n f i g

+ g e t S e r v l e t I n f o ( ) : S t r i n g

+ i n i t ( c o n f i g : S e r v l e t C o n f i g )

+ s e r v i c e ( r e q : S e r v l e t R e q u e s t , r e s p : S e r v l e t R e s p o n s e )

< >

S e r v l e t C o n f i g

+ g e t I n i t P a r a m e t e r ( n a m e : S t r i n g ) : S t r i n g

+ g e t I n i t P a r a m e t N a m e s ( ) : E n u m e r a t i o n < S t r i n g >

+ g e t S e r v l e t C o n t e x t ( ) : S e r v l e t C o n t e x t

+ g e t S e r v l e t N a m e ( ) : S t r i n g

j a v a x . s e r v l e t . s i p

S i p S e r v l e t

# d o A c k ( r e q : S i p S e r v l e t R e q u e s t )

# d o B y e ( r e q : S i p S e r v l e t R e q u e s t )

# d o C a n c e l ( r e q : S i p S e r v l e t R e q u e s t )

# d o E r r o r R e s p o n s e ( r e s p : S i p S e r v l e t R e s p o n s e )

# d o I n v i t e ( r e q : S i p S e r v l e t R e q u e s t )

# d o S u b s c r i b e ( r e q : S i p S e r v l e t R e q u e s t )

# d o S u c c e s s R e s p o n s e ( r e s p : S i p S e r v l e t R e s p o n s e )

S i p S e r v l e t R e q u e s t S i p S e r v l e t R e s p o n s e

S i p S e s s i o nS i p S e r v l e t M e s s a g e

+ g e t S e s s i o n ( ) : S i p S e s s i o n

< >

G e n e r i c S e r v l e t

+ i n i t ( )

+ l o g ( m e s s a g e : S t r i n g )

+ l o g ( m e s s a g e : S t r i n g , t : T h r o w a b l e )

Figure C.12: The SipServlet API. Taken directly from the API specification. Thisis just for clarification.

83



com.atosorigin.ims.as.msrpfocus

Focus

-id: String

-users: Map<String,User>

+receive(from:User,message:String): String

+addUser(user:User): void

+getUser(id:String): User

+removeUser(user:User): void

<<Comparable<Session>>>

Session

-focus: Focus

-user: User

-id: String

+send(message:String): String

+send(InputStream:stream): String

+setUser(user:User): void

SmsSession MsrpSession

-connection: javax.msrp.Connection

User

-sessions: Map<String,Session>

-id: String

-focus: Focus

+send(message:String): String

+send(stream:InputStream): String

+setFocus(focus:Focus): void

+addSession(session:Session): void

+removeSession(session:Session): void

<<SipServlet>>

FocusServlet

-msrpStack

-focuses: Set<Focus>

javax.msrp.Connect ionListener

javax.msrp.data .TransmissionListener

Figure C.13: SipServlet focus for MSRP conference sessions class diagram.

84



com.atosorigin.ims.jclient.data

<<ActionListener, SubscriptionListener>>

Contact

-nickname: String

-impu: String

-popup: ContactPopupMenu

-subscription: Subscription

-contact: javax.ims.resource.Contact

-state: int

+Contact(mediator:ControllerMediator,contact:javax.ims.resource.Contact)

+getState(): int

+activate(): Contact

+getImsContact(): javax.ims.resource.Contact

ContactList

-mediator: ControllerMediator

-listModel: DefaultListModel

-contacts: Map<String,Contact>

-list: javax.ims.resource.ContactList

+createContact(id:String,name:String): Contact

+addContact(con:Contact): void

+setContactList(list:javax.ims.resource.ContactList): void

ContactListLoader

-list: ContactList

-service: ResourceService

+ContactListLoader(stack:ImsStack,ContactList:list)

+flush(): void

<<FocusSessionListener>>

ConferenceSession

-participantList: ListModel

-focus: FocusSession

-waitingInvites: Queue<Contact>

<<javax.ims.core.SessionListener>>

DirectSession

-session: javax.ims.core.Session


-peer: Contact

+DirectSession(peer:Contact,mediator:ControllerMediator)

+DirectSession(peer:String,mediator:ControllerMediator, session:Session)

+addMedia(media:Media): void

+createMedia(type:String): void

+start()

ClientSession

#media: Vector<Media>

M e d i a M a n a g e r

+sessionAlerting()

+sessionStarted()

+sessionTerminated()

<<ActionListener, FramedMediaListener>>

C h a t M a n a g e r

#chatPanel: ChatPanel

#media: FramedMedia

+connectionError(media:FramedMedia): void

+actionPerformed(e:ActionEvent): void

+terminate()

+close()

SimpleChatManager

-chatPanel: SimpleChatPanel

-peer: Contact

-session: DirectSession

+SimpleChatManager(peer:Contact,mediator:ControllerMediator, media:FramedMedia)

<<CoreServiceListener>>

JClient

-stack: ImsStack

-guiMediator: GuiMediator

-controllerMediator: ControllerMediator

-contactLoader: ContactListLoader

+main(args:String[]): void

<<CoreServiceListener>>

Contro l lerMediator

-client: JClient

-guiMediator: GuiMediator

-statusManager: StatusManager

-coreService: javax.ims.core.CoreService

-resourceService: javax.ims.resource.ResourceService

-imsStack: ImsStack

-contacts: ContactList

-sessions: List<ClientSession>

+ControllerMediator(client:JClient)

+start(stack:ImsStack): void

+quit(): void

<<ItemListener, PublicationListener>>

S t a t u s M a n a g e r


-publication: Publication

Mul t iCha tManager

-session: ConferenceSession

-chatPanel: MultiChatPanel

+MultiChatManager(focus:FocusSession,mediator:ControllerMediator, conferenceSession:ConferenceSession, media:FramedMedia)

Figure C.14: Java client controller classes

85



com.atosorigin.ims.jclient.gui

com.atosorigin.ims.jclient.gui.chat

<<JLabel, ListCellRenderer>>

ContactCel lRenderer

-online: ImageIcon

-offline: ImageIcon

-unknown: ImageIcon

<<JList>>

ContactListPane

+ContactListPane(contacts:ContactList)

M a i n W i n d o w

-statusBox: StatusBox

-contactList: ContactListPane

+MainWindow(mediator:GuiMediator)

+getStatusFieldArea(): JTextField

+getContactListPane(): JList

Mult iChatPanel

-participants: ParticipantList

-inviteButton: JButton

+MultiChatPanel(mediator:GuiMediator,manager:MultiChatManager)

SimpleChatPanel

+SimpleChatPanel(mediator:GuiMediator,manager:SimpleChatManager)

<<JList>>

Part ic ipantList

ChatPanel

-inputField: JTextField

-textArea: JTextArea

-statusField: JTextField

+appendMessage(message:String): void

+disableInput(): void

+enableInput(): void

+getTabIndex(): int

+close()

<<ActionListener>>

GuiMedia tor


-mainWindow: MainWindow

-chatWindow: ChatWindow

+start()

<<JPopupMenu>>

ContactPopupMenu

+ContactPopupMenu(contact:Contact)

<<JFrame, ActionListener>>

ChatWindow

-tabPane: JTabbedPane

+createSimpleChat(manager:SimpleChatManager, name:String): SimpleChatPanel

+createMultiChat(manager:MultiChatManager, name:String): MultiChatPanel

+close(): void

+getTabIndex(component:Component): int

+removeTabAt(i:int): void

<<JFrame, ActionListener>>

AddContactWindow

+ContactWindow(mediator:GuiMediator)

<<JFrame>>

LoginDialog

+LoginDialog(client:JClient)

+setStatusText(text:String): void

+setPercent(int:percent): void

+getImpi(): String

+getSecret(): String

+getImpu(): String

+getDisplayName(): String

<<JComboBox>>

StatusBox

Figure C.15: Java client view classes

86

Appendix D

Activity diagrams

87


Leonard BromanAPPENDIX D. ACTIVITY DIAGRAMS

C l i e n t s e n d s I N V I T Et o f o c u s m a n a g e r

F i l t e r w h e r et o p r o c e s s

U E S I P - A S M R F C M R F P

C r e a t e s e s s i o n C r e a t e s t a c kb i n d i n g

M o d i f y S D P - a n s w e r

S e n d O K

S e n d A C K

C o n n e c t

S e n d S E N D

T r a n s m i t t os e s s i o n

S e n d O K

R e c e i v e O K

C r e a t e c o n n e c t i o nb i n d i n g

Figure D.1: Message handling of the MSRP/SIP focus server

88



C l i e n t c o n s t r u c t sM s r p S t a c k

C l i en t ca l l ss ta r t ( )

C l i en t ca l l sc o n n e c t ( )

S t a c k f o r k sa w o r k e r t h r e a d

S t a c k c o n n e c t s

R e t u r n f a i l u r e

F a i l u r e

S t a c k c r e a t e sM s r p C o n n e c t i o n

S u c c e s s

H a n d l e i n c o m i n gp a c k e t s

S e n d p a c k e t s

P u s h / p o l lb u f f e r s

c o n t i n u e

F i r s t p a c k e t a r r i v e s

C o n n e c t i o n i d e n t i f i e r s e t

C l i en t ca l l ss i g n a l S t o p ( )

c l i en t ca l l sjo in ( )

s t o p

Figure D.2: Client initiating the MSRP stack

89



U A s e n d sS U B S C R I B E

R e p l yF a i l u r e

N o t i n s e s s i o n A d d u s e r t os u b s c r i p t i o n

l is t

R e p l y O K

Figure D.3: Client subscribing to focus state information

C l i e n t s e n d s I N V I T Et o f o c u s

F i l t e r w h e r et o p r o c e s s

U E S I P - A S M R F C M R F P

C r e a t e s t a c kb i n d i n g

M o d i f y S D P - a n s w e r

S e n d O K

S e n d A C K

C o n n e c t

S e n d S E N D

T r a n s m i t t os e s s i o n

S e n d O K

R e c e i v e O K

C r e a t e c o n n e c t i o nb i n d i n g

S e n d N O T I F Yt o s u b s c r i b e d c l i e n t s

Figure D.4: Client joining an SIP focus and an MSRP session

90

Appendix E

State diagrams

E.1 MSRP stack API

C O N N E C T I N G

E S T A B L I S H E DO U T G O I N G

T E R M I N A T E D

R E C O N N E C T I N G

I N I T

W A I T I N GC O N N E C T

E S T A B L I S H E DI N C O M I N G

W A I T I N GR E C O N N E C T

T I M E O U TW A I T I N G

F A I LT E R M I N A T I N G

T I M E O U TI N A C T I V I T Y

P A S S I V E

Figure E.1: MSRP Channel (TCP connection) state diagram.

E.2 IMS stack API

91


Leonard BromanAPPENDIX E. STATE DIAGRAMS

S T A T E _ E S T A B L I S H E D

S T A T E _ I N I T I A T E D

S T A T E _ N E G O T I A T I N G

S T A T E _ P R O C E E D I N G

S T A T E _ T E R M I N A T E D

S T A T E _ T E R M I N A T I N G

C o r e S e r v i c e I m p l . c r e a t e S e s s i o n ( )

S e s s i o n . s t a r t ( )

S e s s i o n . u p d a t e ( )

S e s s i o n L i s t e n e r . s e s s i o n U p d a t e F a i l e d ( )S e s s i o n L i s t e n e r . s e s s i o n U p d a t e A c c e p t e d ( )

S e s s i o n . t e r m i n a t e ( )

S e s s i o n L i s t e n e r . s e s s i o n T e r m i n a t e d ( )

S e s s i o n L i s t e n e r . s e s s i o n S t a r t e d F a i l e d ( )

S e s s i o n L i s t e n e r . s e s s i o n S t a r t e d ( )

S I P I N V I T E

S I P O K

S I P A C K

t e r m i n a t e ( )

t e r m i n a t e ( )

S I P C A N C E L

S I P B Y E

S I P O K

Figure E.2: State diagram for the IMS session. INVITE, UPDATE and BYEoriginating at the UE. Session/listener calls and SIP messages displayed.

S T A T E _ E S T A B L I S H E D

S T A T E _ I N I T I A T E D

S T A T E _ N E G O T I A T I N G

S T A T E _ P R O C E E D I N G

S T A T E _ T E R M I N A T E D

S T A T E _ T E R M I N A T I N G

C o r e S e r v i c e I m p l . c r e a t e S e s s i o n ( R e q u e s t )

S e s s i o n I m p l ( R e q u e s t )

C o r e S e r v i c e L i s t e n e r . s e s s i o n I n v i t a t i o n R e c e i v e d ( )

S e s s i o n . a c c e p t ( )

S e s s i o n L i s t e n e r . s e s s i o n U p d a t e R e q u e s t ( )

S e s s i o n . r e j e c t ( )S e s s i o n . a c c e p t ( )

S e s s i o n L i s t e n e r . s e s s i o n T e r m i n a t e d ( )


S I P I N V I T E

S I P O K

S I P A C K

S I P C A N C E L

S e s s i o n . r e j e c t ( )

S I P B Y E

S I P O K

S e s s i o n . r e j e c t ( )

Figure E.3: State diagram for the IMS Session for INVITE, UPDATE and BYEterminating at the UE.Session/listener calls and SIP messages displayed.

92


Leonard BromanAPPENDIX E. STATE DIAGRAMS

P E N D I N G

A C T I V E

A C T I V E

I N A C T I V E

P E N D I N G _ P U B L I S H

P E N D I N G _ U P D A T E

P E N D I N G _ R E F R E S H

P E N D I N G _ U N P U B L S H

T E R M I N A T E D

Figure E.4: Datagram for publications. This diagram presents both the majorstates visible to the API user as well as the internal states used in the implemen-tation.

I N A C T I V EP E N D I N G

A C T I V E

A C T I V E

P E N D I N G _U N S U B S C R I B E

P E N D I N G _S U B S C R I B E

P E N D I N G _R E S U B S C R I B E

I N A C T I V E

T E R M I N A T E D

Figure E.5: State diagram for subscriptions. This diagram presents both the majorstates visible to the API user as well as the internal states used in the implemen-tation.

S T A T E _ A C T I V E

S T A T E _ D E L E T E DS T A T E _ I N A C T I V E

S T A T E _ P E N D I N G

Figure E.6: State diagram for the life cycle of a Media

93

Appendix F

Sequence diagrams

94

Lulea

univ

ersityoftech

nolo

gy

Octo

ber

11,2008

Leo

nard

Bro

man

AP

PE

ND

IXF.

SE

QU

EN

CE

DIA

GR

AM

S

O r i g i n a t i n g U E T e r m i n a t i n g U EP r o x y - C S C F S e r v i n g - C S C F A p p l i c a t i o n s e r v e r

S I P I N V I T E

S I P I N V I T E

I n s p e c t S e r v i c e - R o u t e

Or ig ina t i ng i n i t i a lr e q u e s t r o u t i n g :I F C M a t c h

S I P I N V I T E

S I P I N V I T E

A d d R e c o r d - R o u t ei f s u p e r v i s i n g S e s s i o n

L o c a t e t e r m i n a t i n gn e t w o r k S I P I N V I T E

Te rm ina t i ng i n i t i a lr e q u e s t r o u t i n gI F C M a t c h

S I P I N V I T E

S I P I N V I T ED e s t i n a t i o n r o u t i n g

S I P I N V I T E

S I P I N V I T E

S I P : U E S e s s i o n s e t u pS I P : P a r s e S D PS I P : C h e c k m e d i a s u p p o r tS I P : C o r e S e r v i c e L i s t e n e r . s e s s i o n I n v i t a t i o n R e c e i v e d ( )S I P : S e s s i o n . a c c e p t ( )M S R P : C r e a t e c o n n e c t i o n o f f e r .M S R P : P r e p a r e r e c e i v i n g i n c o m i n g T C P c o n n e c t i o n .S I P : S e n d o f f e r r e s p o n s e .S I P : R e s p o n s e f o l l o w s r o u t e d e t e r m i n e d b y i n i t i a l r e q u e s t

S I P O K

S I P O K

S I P O K

S I P O K

S I P O K

S I P O K

1 0 0 T r y i n g

S I P O K

J A I N - S I P : C r e a t e d i a l o gM S R P : C r e a t e o u t g o i n g c o n n e c t i o nS I P : S e s s i o n L i s t e n e r . s e s s i o n S t a r t i n g ( )

1 0 0 T r y i n g

1 0 0 T r y i n g

1 0 0 T r y i n g

1 0 0 T r y i n g

1 8 0 R i n g i n g

1 8 0 R i n g i n g

1 8 0 R i n g i n g

1 8 0 R i n g i n g

1 8 0 R i n g i n g

1 8 0 R i n g i n g

1 8 0 R i n g i n g

S I P : S e s s i o n L i s t e n e r . s e s s i o n A l e r t i n g ( )

S I P A C K

T C P S Y N

{ S I P A C K ( S i m p l y f i e d ) }

T C P A C K

M S R P V I S I T

M S R P 2 0 0 O K

C o n n e c t i o n L i s t e n e r . c o n n e c t i o n C o n n e c t e d ( )

A d d R e c o r d - R o u t ei f s u p e r v i s i n g S e s s i o n

Fig

ure

F.1

:IM

SN

etwork

level

sequen

cefo

resta

blish

ing

apeer-to

-peer

session

betw

eentw

oIM

Sterm

inals

95

Lulea

univ

ersityoftech

nolo

gy

Octo

ber

11,2008

Leo

nard

Bro

man

AP

PE

ND

IXF.

SE

QU

EN

CE

DIA

GR

AM

S

T e r m i n a t i n g U A

O r i g i n a t i n g U A

M S R P S t a c k I M S S t a c kI M S S t a c k M S R P S t a c k C o r e S e r v i c e . c r e a t e S e s s i o n ( )

S e s s i o n . c r e a t e M e d i a ( )

M s r p S t a c k . c r e a t e C o n n e c t i o n ( O U T G O I N G )

S e s s i o n . s t a r t ( )S I P I N V I T EC o r e S e r v i c e L i s t e n e r . s e s s i o n I n v i t a t i o n R e c e i v e d ( )

S e s s i o n . a c c e p t ( ) M s r p S t a c k . c r e a t e C o n n e c t i o n ( I N C O M I N G )

C o n n e c t i o n . p r e p a r e ( )

C h a n n e l s t a r t s l i s t e n i n g f o r s o c k e t

S I P 2 0 0 O K S e s s i o n L i s t e n e r . s e s s i o n S t a r t e d ( )

M s r p S t a c k . p r e p a r e ( )

S I P A C K

T C P c o n n e c t


F r a m e d M e d i a . s e n d B y t e s ( " H e l l o ! " ) C o n n e c t i o n . c r e a t e T r a n s m i s s i o n ( " H e l l o ! " ) M S R P S E N D C o n n e c t i o n L i s t e n e r . r e c e i v e ( T r a n s m i s s i o n )

M S R P 2 0 0 O K

S I P O K

F r a m e d M e d i a L i s t e n e r . r e c e i v e C o m p l e t e ( )

F r a m e d M e d i a . g e t B y t e s ( )

I P N e t w o r k

Fig

ure

F.2

:U

Eco

mponen

tlev

elseq

uen

cedia

gra

mfo

rsessio

nesta

blish

men

t

96

Documents

LTU-EX-08210-SE