Tech Report MacDonald

Configuration and Deployment of an IMS Test Bed
Alton Kenneth MacDonald Laboratorio de Redes Avanzadas Instituto Tecnolgico Autnomo de Mxico (ITAM) Reporte Tcnico LRAV 10809 August 2009
Contents
Preface 1 Introduction 1.1 Next Generation Networking . . . . . . . . . . . . . . . . . . . . . . . 1.2 Service Delivery Models . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 IP Multimedia Subsystem . . . . . . . . . . . . . . . . . . . . . . . . 2 Static Routes 2.1 Initial State . . . 2.2 Cisco Routers . . 2.3 FreeBSD Routers 2.4 Caronte . . . . . 2.5 Vesta . . . . . . 3 DNS Entries 4 IMS Realms 4.1 Requirements 4.2 Compilation . 4.3 Configuration 4.4 Deployment . 1 2 2 3 3 5 5 6 7 8 9 11 15 15 15 16 17
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
5 PSTN Gateway 5.1 Digium Hardware . . . . . . . . . . . . . . . . 5.2 Asterisk Software . . . . . . . . . . . . . . . . 5.3 Feature Setup . . . . . . . . . . . . . . . . . . 5.3.1 Global Settings . . . . . . . . . . . . . 5.3.2 Trunks . . . . . . . . . . . . . . . . . 5.3.3 Incoming and Outgoing Calling Rules ii
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
21 . 21 . 23 . 25 . 26 . 27 . 28
CONTENTS
CONTENTS
5.3.4 5.3.5 5.3.6
Dial Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Finishing Touches . . . . . . . . . . . . . . . . . . . . . . . .
29 30 32 36 36 37 38 38 45 46 51 51 52 53 54 55 57 60
6 Content Server 6.1 Darwin Streaming Server . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 UCT IPTV Streaming Server . . . . . . . . . . . . . . . . . . . . . . 7 Presence Server 7.1 OpenSIPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 OpenSIPS-mi-proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3 OpenXCAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Configuration of Application Servers 8.1 Presence Server . . . . . . . . . . . . 8.2 Content Server . . . . . . . . . . . . 8.3 PSTN Gateway . . . . . . . . . . . . 8.4 Service Profile . . . . . . . . . . . . . 9 IMS Clients Glossary References
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
iii
List of Figures
2.1 2.2 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 6.1 8.1 8.2 8.3 8.4 8.5 8.6 9.1 Physical Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . Static Routes in Caronte . . . . . . . . . . . . . . . . . . . . . . . . . Wiring Diagram for RJ45 and RJ11 SIP Settings . . . . . . . . . . . . . Analog Trunk . . . . . . . . . . . . VOIP Trunk . . . . . . . . . . . . Outgoing Calling Rules . . . . . . . Incoming Calling Rules . . . . . . . FXS Asterisk User . . . . . . . . . SIP Asterisk User . . . . . . . . . . Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 8 22 26 27 28 29 29 30 31 36 52 52 53 53 54 54 56
Playlist Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . Presence Application Server Configuration . . . . Presence Application Server Trigger Point . . . . Content Application Server Configuration . . . . Content Application Server Initial Filter Criteria Service Profile . . . . . . . . . . . . . . . . . . . . Service Profile Priorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IMS Client Configuration . . . . . . . . . . . . . . . . . . . . . . . .
iv
List of Tables
2.1 4.1 5.1 7.1 7.2 8.1 8.2 Names and IP Addresses . . . . . . . . . . . . . . . . . . . . . . . . . Ports Used by the IMS Realms . . . . . . . . . . . . . . . . . . . . . Ports Used by Asterisk . . . . . . . . . . . . . . . . . . . . . . . . . . opensipsctlrc Value Substitution . . . . . . . . . . . . . . . . . . . . . Ports Used by the Presece Server . . . . . . . . . . . . . . . . . . . . Content Application Server Trigger Point . . . . . . . . . . . . . . . PSTN Gateway Application Server Trigger Point . . . . . . . . . . . 6 19 35 39 50 53 54
Preface
This document serves as a guide presenting a step by step procedure for the installation and configuration of an IP Multimedia Subsystem (IMS) test bed. Said test bed is capable of offering a basic telecommunications infrastructure through the creation of a Service Delivery Platform with the help of three Application Servers (ASs). The IMS test bed described in this document is composed of the following: 1. Two IMS realms. 2. An AS serving as a Public Switched Telephone Network (PSTN) Gateway. 3. An AS serving as a Content Server. 4. An AS serving as a Presence Server. 5. Clients used to test the features of the test bed. The information provided herein is specific to the test bed deployed at the Laboratorio de Redes Avanzadas located at the facilities of the Instituto Tecnolgico Autnomo de Mxico (ITAM). However, it may be used as a guide for the creation or improvement of other IMS test beds.
Chapter 1 Introduction
This Chapters serves as a brief introduction to the IP Multimedia Subsystem (IMS) and its importance in Next Generation Networks (NGN), which in turn, can help explain the need for the IMS test bed. The purpose of this Capter is to present the reader with available reference material for ruther reading. A longer, more detailed, version of this Capter can be consulted in my Bachelors thesis [14].
1.1
Next Generation Networking
Currently, there are two types of telecommunication service providers: network operators and Internet Service Providers (ISPs) [16]. The differences between these two are many, but the main difference (at least for this documents purpose) is that the former possess a physical infrastructure and their business model has a Walled Garden approach. Meanwhile, the latter does not necessarily possess it own infrastructure and follows an Open Plain approach to new services. This means that network operators have complete control over the few services they provide while ISPs have very little control over the large array of services freely available. The business model followed by ISPs have enabled businesses to reach their customers through previously unimaginable channels [17]. An enormous array of new and innovative services have been developed thanks to the open protocols provided by the Internet. Users demand converged services from intelligent networks [17]. They have become active mobile users that expect the network to adapt to their needs and provide them with access to anything from anywhere at anytime on any device [17]. A new network with a new set of rules has to be created to cater to new users with new demands [17]. Network operators are slowly becoming nothing more than simple 2
1.2. Service Delivery Models
Chapter 1. Introduction
ISPs. Unfortunately, their original infrastructure was originally designed to support a limited amount of content and does not currently support the multitude of existing services available today. NGN aim to solve the problems briefly mentioned and many more. The International Telecommunications Union (ITU) has defined NGN as: A packet-based network able to provide telecommunications services and able to make use of multi broadband, QoS-enabled transport technologies and in which service related functions are independent from underlying transport-related technologies. It offers unfettered access by users to different service providers. It supports generalized mobility which will allow consistent and ubiquitous provision of services to users [16]. In order to avoid extinction network operators must concentrate on the convergence of services, migrate to an All-IP network, and offer a Service Delivery Platform for the rapid creation and deployment of services [16]. The first and second step have already been taken [16], while the last step is scheduled for completion in late 2011 [7, 12].
1.2
Service Delivery Models
Network operators can essentially choose between two different service delivery models: a vertical or horizontal approach. Until recently, network operators have decided to use a vertical delivery model better known as The Silo Syndrome which requires the creation of services from scratch [5]. Said creation forces a high dependency between the different layers used to build the silo. This approach also stagnates the maintenance and creation of services due to its high Capital Expenditure (CAPEX) and Operational Expenditure (OPEX) costs [5]. These, costs in turn, have forced network operators to spend most of their revenues maintaining a collapsing silo [5]. Service Delivery Platforms, on the other hand, are the current means of offering a horizontal service delivery model. Said platform is able to group common silo functions into separate entities at a single layer allowing these to be used as modular components in the creation of new services [5]. Therefore, new services are simply created by reconfiguring the modular entities into unique combinations.
1.3
IP Multimedia Subsystem
THe IMS is a Service Delivery Platform proposed by the Third Generation Partnership Project (3GPP) under its Release 5 [11, 13] and has been improved upon in Releases 6 [2] and 7 [1, 3, 4]. Originally, it was designed to help enable integrated 3
1.3. IP Multimedia Subsystem
Chapter 1. Introduction
Internet services for mobile telephony. Contrary to Third Generation (3G) mobile network, which are already Internet capable, IMS aims to improve the Quality of Service (QoS) and Quality of Experience (QoE) for the user, as well as improve the control network operators have over service flows and reduce overall costs with the help of a thriving new business model. The IMS is also proposed by the Open Mobile Alliance (OMA) as the first Service Delivery Model capable of supporting different data streams within a given network. It will ease the migration network operators must forgo in order to avoid becoming mere transport networks [8]. IMS provides definitions for generic functions which can be used by any service within its network [10]. Said functions eliminate the need for silo specialists; service maintenance can now be accomplished by someone with overall service knowledge [9]. This enables the creation of a Service Delivery Platform which among its many aforementioned benefits, also reduces the Time to Market (TTM) for new services and reduces costs for both users and network operators. By migrating to IMS, network operators no longer have to maintain two parallel network architectures. The world of promises presented by IMS has motivated the involvement of other organizations such as Third Generation Partnership Project 2 (3GPP2), Internet Engineering Task Force (IETF), Fraunhofer Institute for Open Communications Systems (FOKUS), University of Cape Town (UCT), HP, T-Mobile, NTT DoCoMo, Ericsson, Intel, and OpenCloud, among others. For example, 3GPP2 has adopted IMS specifications from Release 5 and modified them to fit current access technologies [6]. On the other hand, IETF and 3GPP2 have been using open technologies to specify a real world implementation of IMS. In conclusion, IMS is a critical component in the deployment of NGN due to its significant role in service convergence [6].
Chapter 2 Static Routes

The static routes described in this Chapter improve the QoE witnessed by the test bed users, specifically those posessing low bandwidth connections. High bandwidth streams are redirected through the 210 network segment while low bandwidth streams are directed through de 211 network segment.
2.1
Initial State
This section provides a brief overview of the physical topology of the IMS test bed. Figure 2.1 shows a diagram of the underlying physical network while Table 2.1 shows an outline of the computers used by the IMS test bed.
Figure 2.1: Physical Topology
2.2. Cisco Routers Name Prefix IP Address Astrea 148.205.208.108 Caronte 148.205.209.3 148.205.208.99 CoT1 148.205.211.1 148.205.209.99 CoT2 148.205.211.2 Fobos 148.205.208.101 Hebe 148.205.208.105 148.205.209.2 Nereida 148.205.210.2 Oberon 148.205.208.104 Titania 148.205.208.107 148.205.208.102 Triton 148.205.210.1
Chapter 2. Static Routes
Table 2.1: Names and IP Addresses
2.2
Cisco Routers
The Cisco routers Cot1 and Cot2 must be configured remotely through telnet. The following block of code shows the changes that need to be executed on CoT1. CoT1
1 2 3 4 5 6 7 8 9 10 11 12 13 14 telnet 148.205.208.99 password : enable password : password : show run config t ip route 0.0.0.0 0.0.0.0 148.205.208.2 ip route 148.205.208.0 255.255.255.0 148.205.208.102 ip route 148.205.209.0 255.255.255.0 148.205.211.2 ip route 148.205.210.0 255.255.255.0 148.205.208.102 exit show run exit
The output of line 6 will show the initial configuration. It is highly recommended to backup this output if the desire to return the configuration to its initial state should 6
2.3. FreeBSD Routers
arise. The output of line 13 is used to verify the changes made. The following block of code shows the changes that need to be executed on CoT2. CoT2
1 2 3 4 5 6 7 8 9 10 11 12 telnet 148.205.209.99 password : enable password : password : show run config t ip route 0.0.0.0 0.0.0.0 148.205.211.1 ip route 148.205.210.0 255.255.255.0 148.205.209.2 exit show run exit
Once again, the output generated by line 6 shows the current router configuration. It is highly recommended to backup this output if the desire to return the configuration to its initial state should arise. The output of line 11 is used to verify the changes made.
2.3
FreeBSD Routers
Computers Nereida and Triton are software routers running FreeBSD. In order to properly configure these routers a few lines of code must be modified from the following file: /etc/rc.conf The next two configurations do not include the complete file listing, they only include the necessary modifications for the proper deployment of the test bed located at the Laboratorio de Redes Avanzadas. Triton
1 2 3 4 5 defaultrouter ="148.205.208.2" static_routes =" SubRed209 SubRed211 " route_SubRed209 ="148.205.209.0/24 148.205.210.2" route_SubRed211 ="148.205.211.0/24 148.205.208.99"
2.4. Caronte
Nereida
1 2 3 4 5 6 7 defaultrouter ="148.205.209.99" static_routes =" SubRed208 SubRed211 ipTV asterisk " route_SubRed208 ="148.205.208.0/24 148.205.209.99" route_SubRed211 ="148.205.211.0/24 148.205.209.99" route_ipTV ="148.205.208.103/32 148.205.210.1" route_asterisk ="148.205.208.107/32 148.205.210.1"
2.4
Caronte
The main user affected by the 2Mb/s bottleneck (caused by the serial connection between the Cisco routers) is housed in Caronte, which means that three static routes must be configured on that machine in order to have access to IP Television (IPTV) and Asterisk without suffering from the delays caused by the 211 network segment. These routes can be configured with either system-config-network as shown in Figure 2.2 or by directly modifying the file /etc/sysconfig/networking/devices/route-eth0.
Figure 2.2: Static Routes in Caronte In case direct modification is preferred, the following block of code shows the necessary changes. 8
2.5. Vesta
route-eth0
1 2 3 4 5 6 7 8 9 GATEWAY2 =148.205.209.2 NETMASK2 =255.255.255.255 ADDRESS2 =148.205.208.104 GATEWAY1 =148.205.209.2 NETMASK1 =255.255.255.255 ADDRESS1 =148.205.208.107 GATEWAY0 =148.205.209.2 NETMASK0 =255.255.255.255 ADDRESS0 =148.205.208.103
2.5
Vesta
A properly configured route must possess an incoming and outgoing route. Up to this point, the incoming route from the Content Server has not been taken into account. Therefore, it must be configured immediately. Due to the fact that the Content Server is hosted on a Mac, the easiest way to do configure the new route is through a terminal. First, a new directory must be created as shown in the following block of code. Terminal
1 2 3 cd / System / Library / StartupItems / sudo mkdir AddRoutes cd AddRoutes
Once these commands have been executed, two new files will be created and saved in this directory. The name of the files and their content is shown in the following two blocks of code. StartupParameters.plist
1 2 3 4 5 6 { Description Provides Requires OrderPreference } = = = = "Add static routing tables "; (" AddRoutes "); (" Network "); "None ";
2.5. Vesta
AddRoutes
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 #!/ bin/sh # Set up static routing tables # Roark Holz , Thursday , April 6, 2006 . /etc/rc. common StartService () { ConsoleMessage route add -net route add -net route add -net route add -net } StopService () { return 0 } RestartService () { return 0 } RunService "$1"
" Adding Static Routing Tables " 148.205.209.3/32 148.205.208.102 148.205.209.0/24 148.205.208.99 148.205.211.0/24 148.205.208.99 148.205.210.0/24 148.205.208.102
10
Chapter 3 DNS Entries

The modified configuration files presented in this Chapter were successfully tested using named running on FreeBSD 4.4. All the files mentioned in this Chapter can be found in the directory /etc/namedb/. First, a couple lines must be added to the Domain Name Server (DNS) configuration file named.conf as shown in the following block of code: named.conf
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 // configuraciones para usar openIMSCore y Asterisk zone " astrea .ipv6.itam.mx" { type master ; file "open -ims. dnszone "; notify no; allow - update { none ; }; }; zone " titania .ipv6.itam.mx" { type master ; file "open -ims2. dnszone "; notify no; allow - update { none ; }; }; zone "hebe.ipv6.itam.mx" { type master ; file " asterisk . dnszone "; notify no; allow - update { none ; }; };
Next, three additional files must be created in the same directory. These files register the IMS realms and Asterisk within the DNS server. The name of each file 11
Chapter 3. DNS Entries
and its contents are listed in the following three blocks of code: open-ims.dnszone
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 $ORIGIN astrea .ipv6.itam.mx. $TTL 1W @ 1D IN SOA localhost . root. localhost . ( 2006101001 ; serial 3H ; refresh 15M ; retry 1W ; expiry 1D ) ; minimum ns 148.205.208.108 148.205.208.108 148.205.208.108 148.205.208.108
ns pcscf astrea .ipv6.itam.mx. icscf _sip _sip._udp _sip._tcp astrea .ipv6.itam.mx. astrea .ipv6.itam.mx. scscf hss ue presence iptv 1D IN A 1D IN A
1D IN NS 1D IN A 1D IN A 1D IN A 1D IN A
1D SRV 0 0 5060 icscf 1D SRV 0 0 5060 icscf 1D SRV 0 0 5060 icscf 1D IN NAPTR 10 50 "s" "SIP+D2U" "" 1D IN NAPTR 20 50 "s" "SIP+D2T" "" 1D IN A 1D IN A 1D IN A 148.205.208.108 148.205.208.108 148.205.208.108 _sip._udp _sip._tcp
148.205.208.108 148.205.208.108
open-ims2.dnszone
1 2 3 4 5 6 7 8 $ORIGIN titania .ipv6.itam.mx. $TTL 1W @ 1D IN SOA localhost . root. localhost . ( 2006101001 ; serial 3H ; refresh 15M ; retry 1W ; expiry 1D ) ; minimum
12
9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
ns pcscf titania .ipv6.itam.mx. icscf _sip _sip._udp _sip._tcp titania .ipv6.itam.mx. titania .ipv6.itam.mx. scscf hss ue presence iptv 1D IN A 1D IN A
1D IN NS 1D IN A 1D IN A 1D IN A 1D IN A
ns 148.205.208.105 148.205.208.105 148.205.208.105 148.205.208.105
1D SRV 0 0 5060 icscf 1D SRV 0 0 5060 icscf 1D SRV 0 0 5060 icscf 1D IN NAPTR 10 50 "s" "SIP+D2U" "" 1D IN NAPTR 20 50 "s" "SIP+D2T" "" 1D IN A 1D IN A 1D IN A 148.205.208.105 148.205.208.105 148.205.208.105 _sip._udp _sip._tcp
148.205.208.105 148.205.208.105
asterisk.dnszone
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 $ORIGIN hebe.ipv6.itam.mx. $TTL 1W @ 1D IN SOA localhost . root. localhost . ( 2006101001 ; serial 3H ; refresh 15M ; retry 1W ; expiry 1D ) ; minimum
ns asterisk
1D IN NS ns 1D IN A 148.205.208.107 1D IN A 148.205.208.107 1D IN A 148.205.208.107
hebe.ipv6.itam.mx. _sip _sip._udp _sip._tcp
1D SRV 0 0 5060 asterisk 1D SRV 0 0 5060 asterisk 1D SRV 0 0 5060 asterisk
13
20 21
hebe.ipv6.itam.mx. hebe.ipv6.itam.mx.
1D IN NAPTR 10 50 "s" "SIP+D2U" "" 1D IN NAPTR 20 50 "s" "SIP+D2T" ""
_sip._udp _sip._tcp
The modification of named.conf and the creation of the three additional files is suffice for the configuration of the DNS registries. In order to verify the changes successfully, Fobos (our DNS) must be rebooted. Subsequently, the following block of code can be used to test the changes. The commands and proper output are included below. Terminal
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 $ nslookup asterisk .hebe.ipv6.itam.mx Server : 148.205.208.101 Address : 148.205.208.101#53 Name: asterisk .hebe.ipv6.itam.mx Address : 148.205.208.107 $ nslookup hss. astrea .ipv6.itam.mx Server : 148.205.208.101 Address : 148.205.208.101#53 Name: hss. astrea .ipv6.itam.mx Address : 148.205.208.108 $ nslookup hss. titania .ipv6.itam.mx Server : 148.205.208.101 Address : 148.205.208.101#53 Name: hss. titania .ipv6.itam.mx Address : 148.205.208.105
14
Chapter 4 IMS Realms

The IMS realms are composed of a Free and Open Source Software (FOSS) implementation of the Call/Service Control Function (CSCF) and Home Subscriber Server (HSS) functions developed by FOKUS with the name of OpenIMS Core. These realms form the heart of the IMS test bed due to their enormous role in controlling Session Initiation Protocol (SIP) sessions and multimedia streams between users. The installation of this component requires one to download and compile the source code. The installation and configuration of the IMS realms were deployed successfully on Ubuntu versions 6.06 and 8.04.
4.1
Requirements
The successful compilation of OpenIMS Core requires the aid of various development libraries. The following block of code shows how to install all the necessary libraries. The command used to install said libraries under a different Linux distro may vary. Additionally, the package names should be more or less the same. Terminal
1 sudo apt -get install subversion gcc make sun -java6 -jdk ant libmysql ++dev bison flex libxml2 -dev libxml2 - utils ipsec - tools
4.2
Compilation
The compilation of OpenIMS Core is fairly straightforward. Downloading the source code into the directory /opt is achieved with subversion. The HSS function is 15
4.3. Configuration
Chapter 4. IMS Realms
compiled with ant, while the CSCF function is compiled with make. The following block of code shows how to download and compile the source code from a terminal. Terminal
1 2 3 4 5 6 7 8 9 10 sudo -s mkdir /opt/ OpenIMSCore cd /opt/ OpenIMSCore / svn checkout http :// svn. berlios .be/ svnroot / repos / openimscore / FHoSS / trunk FHoSS svn checkout http :// svn. berlios .be/ svnroot / repos / openimscore / ser_ims / trunk ser_ims cd FHoSS ant compile deploy cd ../ ser_ims make install -libs all cd ..
If, for any reason, a compilation error was encountered on lines 7 or 9, the existence of the aforementioned libraries should be checked (see Section 4.1).
4.3
Configuration
The first step in configuring OpenIMS Core resides in creating the database tables used by the CSCF and the HSS functions. The following block of code shows how to customize the name and Internet Protocol (IP) address used by said database. It is very important to replace the string of characters Dominio with the actual name and the string IP with its respective IP address. The test bed deployed at Laboratorio de Redes Avanzadas was configured with the realms astrea.ipv6.itam.mx and titania.ipv6.itam.mx. Terminal
1 2 3 4 5 6 7 8 cd /opt/ OpenIMSCore / ser_ims /cfg/ sed 's/open -ims.test/ Dominio /g' icscf .sql > icscf0 .sql mysql -uroot -p < icscf0 .sql cd /opt/ OpenIMSCore /FHoSS/ scripts / sed 's/open -ims.test/ Dominio /g' userdata .sql | sed 's /127.0.0.1/ IP/g' > userdata0 .sql mysql -uroot -p < hss_db .sql mysql -uroot -p < userdata0 .sql
16
4.4. Deployment
Next, copy the configuration files created after compilation to the directory OpenIMSCore. Then execute a script that changes the name and IP address used by the realm. The following block of code shows how to go about this procedure. Terminal
1 2 3 4 5 6 cd cp cp cp /opt/ OpenIMSCore / ser_ims /cfg /*. cfg . ser_ims /cfg /*. xml . ser_ims /cfg /*. sh .
./ configurator .sh
The IMS realms provide a web interface used to administer its users, applications, and services. The last configuration requires customizing the web interface available at the address http://REALM:8080. The port number can be changed by modifying a line in the file /opt/OpenIMSCore/FHoSS/deploy/hss.properties. The following code shows how to customize the name and IP used. Again, the strings IP and Dominio must be changed to their proper values. Terminal
1 2 3 4 5 cd /opt/ OpenIMSCore /FHoSS/ deploy / cp hss. properties hss. properties .bak sed 's /127.0.0.1/ IP/g' hss. properties .bak > hss. properties cp DiameterPeerHSS .xml DiameterPeerHSS .xml.bak sed 's/open -ims.test/ Dominio /g' DiameterPeerHSS .xml.bak | sed 's /127.0.0.1/ IP/g' > DiameterPeerHSS .xml
4.4
Deployment
One final step is necessary before the IMS realm can be executed. Open file /opt/OpenIMSCore/FHoSS/deploy/startup.sh with your favorite text editor to initialize the variable CLASSPATH and change the last line of code to match the block of code shown below: startup.sh
1 2 3 4 5 6 #!/ bin/bash # -------------------------------------------------------------# Include JAR Files # -------------------------------------------------------------echo " Building Classpath "
17
4.4. Deployment
7 8
CLASSPATH ="/ usr/ share/java/log4j .jar :/ opt/ OpenIMSCore / FHoSS /bin /:/ usr/ share / tomcat5 .5/ server /lib/tomcat -util.jar :/ opt/ OpenIMSCore / FHoSS / tomcat /lib/commons - logging .jar:lib/xml -apis.jar:lib/ xercesImpl .jar: lib/xerces -2.4.0. jar:lib/xalan -2.4.0. jar:lib/tomcat -util.jar:lib/ tomcat -http.jar:lib/tomcat - coyote .jar:lib/ struts .jar:lib/servlets default .jar:lib/servlet -api.jar:lib/naming - resources .jar:lib/naming factory .jar:lib/mysql -connector -java -3.1.12 - bin.jar:lib/mx4j -3.0.1. jar:lib/ log4j .jar:lib/junit .jar:lib/ junitee .jar:lib/jta.jar:lib/jsp api.jar:lib/jmx.jar:lib/jdp.jar:lib/jasper - runtime .jar:lib/jasper compiler -jdt.jar:lib/jasper - compiler .jar:lib/ hibernate3 .jar:lib/ FHoSS .jar:lib/ehcache -1.1. jar:lib/dom4j -1.6.1. jar:lib/commons validator .jar:lib/commons - modeler .jar:lib/commons - logging .jar:lib/ commons -logging -1.0.4. jar:lib/commons -lang.jar:lib/commons fileupload .jar:lib/commons -el.jar:lib/commons - digester .jar:lib/ commons - collections -3.1. jar:lib/commons - beanutils .jar:lib/cglib -2.1.3. jar:lib/catalina - optional .jar:lib/ catalina .jar:lib/c3p0 -0.9.1. jar:lib/ base64 .jar:lib/asm.jar:lib/asm - attrs .jar:lib/antlr -2.7.6. jar" CLASSPATH = $CLASSPATH :log4j. properties :. for i in lib /*. jar; do CLASSPATH =" $i ":" $CLASSPATH "; done echo " Classpath is $CLASSPATH ." # -------------------------------------------------------------# Start -up # -------------------------------------------------------------java -cp $CLASSPATH de.fhg.fokus.hss.main. HSSContainer $1 $2 $3 $4 $5 $6 $7 $8 $9
9 10 11 12 13 14 15 16 17 18
Finally, the realm can be initiated by executing the four commands shown below as root on separate terminals. /opt/OpenIMSCore/fhoss.sh /opt/OpenIMSCore/icscf.sh /opt/OpenIMSCore/pcscf.sh /opt/OpenIMSCore/scscf.sh The proper execution of each IMS function results in messages being exchanged between them. Table 4.1 shows an outline of the ports used by the IMS realm.
18
4.4. Deployment Function P-CSCF I-CSCF S-CSCF HSS (Diameter)
Chapter 4. IMS Realms Port Number 4060 5060 6060 3868, 3869, 3870, 8080
Table 4.1: Ports Used by the IMS Realms It is important to note that OpenIMS Core comes pre-configured with two users: sip:alice@REALM and sip:bob@REALM with passwords alice and bob respectively. Executing the IMS realm can be simplified by automating the execution of each IMS function. This is achieved by creating a file named /etc/init.d/OpenIMSCore which contains the information shown in the following block of code. OpenIMSCore
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 #! /bin/sh case "$1" in start ) /opt/ OpenIMSCore /fhoss.sh & /opt/ OpenIMSCore /pcscf.sh & /opt/ OpenIMSCore /icscf.sh & /opt/ OpenIMSCore /scscf.sh & ;; stop) /opt/ OpenIMSCore / killser icscf && /opt/ OpenIMSCore / killser pcscf && /opt/ OpenIMSCore / killser scscf && kill `ps aux | grep OpenIMSCore | grep java | awk '{ print $2}'` ;; restart ) /opt/ OpenIMSCore / killser icscf && /opt/ OpenIMSCore / killser pcscf && /opt/ OpenIMSCore / killser scscf && kill `ps aux | grep OpenIMSCore | grep java | awk '{ print $2}'` /opt/ OpenIMSCore /fhoss.sh & /opt/ OpenIMSCore /pcscf.sh & /opt/ OpenIMSCore /icscf.sh & /opt/ OpenIMSCore /scscf.sh & ;; *) echo " Usage : /etc/init.d/ OpenIMSCore { start |stop| restart }" exit 1 ;; esac exit 0
19
4.4. Deployment
Now, the IMS realm can be controlled by simply executing the file created. Additionally, symlinks can be set at the appropriate runlevel directories (i.e. /etc/rc*.d/) in order to automatically initiate the IMS realm on system boot. The following block of code shows an example of how to establish the symlinks at runlevels 0 through 6. Only set up those which are useful to your organization. Terminal
1 2 3 4 5 6 7 ln ln ln ln ln ln ln -s -s -s -s -s -s -s /etc/init.d/ OpenIMSCore /etc/init.d/ OpenIMSCore /etc/init.d/ OpenIMSCore /etc/init.d/ OpenIMSCore /etc/init.d/ OpenIMSCore /etc/init.d/ OpenIMSCore /etc/init.d/ OpenIMSCore /etc/rc0.d/ K30OpenIMSCore /etc/rc1.d/ K30OpenIMSCore /etc/rc2.d/ S30OpenIMSCore /etc/rc3.d/ S30OpenIMSCore /etc/rc4.d/ S30OpenIMSCore /etc/rc5.d/ S30OpenIMSCore /etc/rc6.d/ K30OpenIMSCore
Once the IMS realm has been deployed any future configurations or customizations can be done with the help of the web interface available at http://REALM:8080. This procedure is repeated as many times as necessary until all the IMS realms used in the test bed have been successfully deployed.
20
Chapter 5 PSTN Gateway

The Public Switched Telephone Network (PSTN) Gateway is composed of two separate entities: an Asterisk server and a Peripheral Component Interconnect (PCI) card capable of filling the void between the analog and digital worlds. Each of these entities require its own installation. Asterisks source code must be modified in order to achieve a successful integration with the IMS test bed. This forcefully requires the compilation of both softare and hardware (driver) components. It is recommended to approach this Chapter with a basic understanding of compilation tools for Linux environments.
5.1
Digium Hardware
The PCI card used for the creation of the PSTN Gateway must be Asterisk certified and have at least one Foreign eXchange Office (FXO) port. The card used for the deployment of this test bed is a Digium Wildcard TDM400P with three FXO ports and one Foreign eXchange Station (FXS) port used to connect an analog phone. The extra FXO ports can be used to connect additional PSTN providers to Asterisk. Beforehand, it is of vital importance to adapt two ethernet cables for their use with RJ11 male connectors. These cables are used to connect Asterisk to our PSTN provider and an analog phone. The only special considerations necessary in the modification is to ensure the blue pair of wires from the RJ45 are joined to the red and green wires of the RJ11 connector as shown in Figure 5.1. The installation of the Digium card requires the compilation of its drivers and system tools. The following procedure was successfully replicated on Ubuntu version 6.06; the installation on other linux distributions is fairly similar. First the kernel headers must be installed with the latest version of the kernel available from the 21
5.1. Digium Hardware
Chapter 5. PSTN Gateway
Figure 5.1: Wiring Diagram for RJ45 and RJ11 Compatibility package manager. The following command shows how to install the kernel headers after the kernel has been updated and the machine rebooted. apt-get install linux-source linux-headers-`uname -r` At the time of writing this document, the drivers and system tools were available at the following urls for their successful download. http://downloads.asterisk.org/pub/telephony/dahdi-linux/dahdilinux-current.tar.gz http://downloads.asterisk.org/pub/telephony/dahdi-tools/dahditools-current.tar.gz http://downloads.asterisk.org/pub/telephony/libpri/libpri-1.4current.tar.gz Next, the downloaded archives are to be unpacked, compiled and installed with the set of instructions shown in the following block of code. They must be compiled in this order to avoid compilation errors. Terminal
1 2 3 4 5 6 7 8 9 10 11 12 13 tar xzf dahdi -linux -*. tar.gz tar xzf dahdi -tools -*. tar.gz tar xzf libpri -1.4.*. tar.gz cd dahdi -linux -* make sudo make install cd ../ dahdi -tools -* make sudo make install sudo make config cd ../ libpir -1.4.* make sudo make install
22
5.2. Asterisk Software
Fortunately, dahdi-tools is able to correctly identify the Digium card. The load time of the dahdi modules can be reduced by commenting out all the lines from the file /etc/dahdi/modules, except the one containing the variable wctdm. Even though, the drivers have been successfully installed, it is recommended to finish installing Asterisk before proceeding to their configuration.
5.2
Asterisk Software
The Asterisk source code is available at http://downloads.digium.com/pub/ asterisk/releases/asterisk-1.4.22.tar.gz. After unpacking the downloaded archive, and before compiling, a small modification is to be made to the source code in order to enable calls with OpenIMS Core. Said modification may not be optimum for future SIP enhancements, but works. The lines 14,085 an 14,090 must be commented out from the file asterisk-1.4.22/channels/chan_sip.c. The following block of code shows the final result. chan_sip.c
14079 14080 14081 14082 14083 14084 14085 14086 14087 14088 14089 14090 14091 14092 /* Find out what they require */ required = get_header (req , " Require "); if (! ast_strlen_zero ( required )) { required_profile = parse_sip_options (NULL , required ); if ( required_profile && required_profile != SIP_OPT_REPLACES ) { /* At this point we only support REPLACES */ // transmit_response_with_unsupported (p, "420 Bad extension ( unsupported )", req , required ); ast_log ( LOG_WARNING ," Received SIP INVITE with unsupported required extension : %s\n", required ); p-> invitestate = INV_COMPLETED ; if (!p-> lastinvite ) sip_scheddestroy (p, DEFAULT_TRANS_TIMEOUT ); // return -1; } }
The next block of code shows how to compile Asterisk and setup its initial configuration from sample files. Line 3 generates a command line interface for the selection of modules to be included in the installation of Asterisk. It also provides the user with a message stating the dependencies of each module. The PSTN Gateway developed in this test bed has every module enabled except for those which depend on odbc, speex, jabber, gtalk, PostgreSQL, radius, sqlite, tds, and H.323; the latter of these is included as an additional module that will be described later on. Line 6 is 23
5.2. Asterisk Software
optional due to its dependence on a customized configuration of Apache and CGI. More information can be found on Asterisk in OReillys manual [15] for this step. Terminal
1 2 3 4 5 6 7 8 9 cd asterisk -1.4.22/ ./ configure make menuselect make sudo make install sudo make webvmail sudo make samples sudo make progdocs sudo make config
The default H.323 driver included in Asterisk does not play nice with IMS or the Digium card. Which is why an alternative driver with the name of chan_ooh323 is used instead. Said driver can be downloaded from http://downloads.digium. com/pub/asterisk/asterisk-addons-1.4.7.tar.gz. The following block of code shows how to unpack and install the driver. Line 4 provides a similar interface as Asterisk for the selection of additional modules, we only want to select chan_ooh323. Terminal
1 2 3 4 5 6 7 tar xzf asterisk -addons -1.4.7. tar.gz cd asterisk -addons -1.4.7 ./ configure make menuselect make sudo make install sudo make samples
A web interface is going to be installed to help ease the Asterisk configuration process. Said interface automatically generates the necessary configurations needed for complex scenarios. It also is able to configure our Digium card automatically the first time it is used. Once the sequence of commands shown in the next block of code is executed, the web interface will be available at http://hebe.ipv6.itam.mx: 8088/asterisk/static/config/index.html. Terminal
1 2 3 4 svn checkout http :// svn. digium .com/svn/asterisk -gui/ branches /2.0 asterisk -gui cd asterisk -gui ./ configure make
24
5.3. Feature Setup
5 6 7
sudo make install sudo make samples make checkconfig
Finally, the driver configurations must be generated. The dahdi driver and Asterisk must be restarted afterwards as well. This process is done with the three commands shown in the next block of code. Terminal
1 2 3 sudo dahdi_genconf sudo /etc/init.d/ dahdi restart sudo /etc/init.d/ asterisk restart
5.3
Feature Setup
The first step in configuring Asterisk consists of enabling the web interface and configuring the user that has access to it. This can be done by checking certain variables in the configuration files /etc/asterisk/http.conf and /etc/asterisk/manager.conf. The former is used to configure the web server while the latter is used to configure the administrator. The following two blocks of code show the necessary modifications. Please note that the whole file is not included, only the relevant information. http.conf
1 2 3 4 [ general ] enabled = yes enablestatic = yes bindport = 8088
manager.conf
1 2 3 4 5 6 7 [ general ] webenabled =yes [ usuario ] secret = claveDeAcceso read = system ,call ,log ,verbose ,command ,agent ,user , config write = system ,call ,log ,verbose ,command ,agent ,user , config
Obviously, lines 4 and 5 shown above must be changed to suit your organization. Additional users can be configured by following the example shown above and modifying the read and write permitions. 25
5.3.1. Global Settings
Now the Digium card is going to be configured by entering the web interface with a valid username and password at http://hebe.ipv6.itam.mx:8088/asterisk/ static/config/index.html. The time has come to use the web interface to configure the majority of Asterisk. The following sections shall be configured with the aid of the menu located at the left hand side of the web interface.
5.3.1
Global Settings
Before any customizations are made to Asterisk, there are a few global settings that must be configured to enable special services within the software Private Branch eXchange (PBX). The first of which is Voicemail with extension 5000; it should have the Say message Caller-ID feature disabled and the Play envelope feature enabled. Extension 4000 is then assigned to the Directory. Under the menu item Call Features, Blind Transfer is enabled and so is everything else under the tab Dial Options. Advanced Options must be enabled from the menu item Options in order to configure SIP global settings. Figure 5.2 finally shows the SIP settings used.
Figure 5.2: SIP Settings Last but not least, restrictions are applied to the available codecs used by SIP to avoid communication problems present with UCT IMS Client due to a bug in gstreamers Global System for Mobile communications (GSM) codec. All codecs must be disabled except for u-law, a-law, and GSM under the tab Codecs. 26
5.3.2. Trunks
5.3.2
Trunks
A total of three trunks are to be created: one analog and two digital (SIP). The analog trunk simply states the FXO channels used. The name given to this trunk is canalesFXO which contains all the FXO channels. The configuration of said trunk should look like Figure 5.3.
Figure 5.3: Analog Trunk The SIP trunks are used to register incoming calls made from IMS users. Without these, the calls still go through but are never registered by Asterisk until a session is established. A SIP trunk is created for each IMS realm within the test bed. Figure 5.4 shows a sample of a SIP trunk configuration.
27
5.3.3. Incoming and Outgoing Calling Rules
Figure 5.4: VOIP Trunk
5.3.3
Incoming and Outgoing Calling Rules
Calling rules must be defined in order to successfully use the trunks created in the previous Section. These calling rules dictate trunk behavior when predefined extension patterns are dialed. The first set of rules define the prefixes used for identifying outgoing calls through the trunks. The creation of any calling rule should be carefully planned to avoid overlapping patterns with existing extensions or other calling rules. Asterisk does not have extensions configured starting with 8 or 9, making them ideal prefixes for outgoing calling rules. Prefix 9 is configured to route calls through ITAMs PSTN while prefixes 81 and 82 are configured to route calls through the IMS realms. Figure 5.5 shows an example of both outgoing calling rules. Before any incoming calling rules can be established, a time frame must be defined. This is easily done through the menu option Time Intervals. The new time frame established is called entreSemana which spans from Monday to Friday 24 hours a day. Incoming rules work in the exact same way as outgoing rules, except for the fact that the former route calls to local destinations. The destination can be another trunk, an Asterisk service, or an extension. Within the context of the deployed IMS test bed, all incoming calls from the PSTN are routed to the FXS extension 3663 doubling as an operator. On the other hand, all incoming calls from the IMS realms are routed directly to their extension (be it local or otherwise). Figure 5.6 shows two examples of the different incoming calling rules configured. Even though the 28
5.3.4. Dial Plan
(a) FXO Trunk
(b) SIP Trunk
Figure 5.5: Outgoing Calling Rules web interface was able to drastically reduce the configuration time of the trunks and calling rules, there still is a small modification pending which is further explained in Section 5.3.6.
(a) FXO Trunk
(b) SIP Trunk
Figure 5.6: Incoming Calling Rules
5.3.4
Dial Plan
Dial plans are used to enable or disable calling features on a per user basis. The features enabled in this Section can only be accessible to the end user by subscribing 29
5.3.5. Users
them to a dial plan that offers said features. Since the IMS test beds purpose is to enable as many features as possible, all these are included in the default dial plan named default along with the calling rules. This can be configured through the web interface easily.
5.3.5
Users
There are three types of users configured in Asterisk within the context of the IMS test bed: (1) SIP users exclusive to Asterisk, (2) an analog FXS user, and (3) IMS users whose sole purpose is to provide a smooth semi-intelligent transfer with the help of the Directory feature. The web interface is only capable of creating the first two types of users due to the third type posessing invalid Asterisk extensions. Figure 5.7 shows the configuration used for the analog user. This extension should be mapped to an FXS port in order to properly route calls; if not, the creation of the analog user is rendered useless.
Figure 5.7: FXS Asterisk User Figure 5.8, on the other hand, shows an example of the configuration used by SIP users. The fundamental difference between these two lie in the need to authenticate 30
5.3.5. Users
SIP users via password confirmation. The codecs enabled in the Technology section must be the ones shown in Figures 5.7 and 5.8 in order to achieve a successful communication with IMS users.
Figure 5.8: SIP Asterisk User The third type of user has invalid extensions in the sense that these contain alphanumeric characters that cannot be represented with Dual-Tone Multi-Frequency (DTMF) signals, therefore impossible to dial from an analog phone. The only function these users hold within Asterisk is their listing in the Directory. This enables the analog operator to transfer incoming calls with ease to IMS users, without the need of a visual aid. The transfer process follows these steps: 1. Operator (ext. 3663) answers incoming call from PSTN. 2. Operator parks call at a temporary extension. Dial extension 700. 3. Operator uses the directory to call the IMS user. Dial extension 4000. 4. Operator calls the IMS user and informs him of an incoming transfer. Dial # to transfer. 31
5.3.6. Finishing Touches
5. Operator transfers IMS user to temporary extension where incoming call is waiting. Dial extension 7XX. This extension is given by extension 700 when call is parked. The third type of users can only be configured manually by editing file /etc/asterisk/users.conf with the information shown in the following block of code. users.conf
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 [81 alice] hassip = yes fullname = alice@astrea .ipv6.itam.mx context = DLPN_default host= dynamic [81 bob] hassip = yes fullname = bob@astrea .ipv6.itam.mx context = DLPN_default host= dynamic [82 alice] hassip = yes fullname = alice@titania .ipv6.itam.mx context = DLPN_default host= dynamic [82 bob] hassip = yes fullname = bob@titania .ipv6.itam.mx context = DLPN_default host= dynamic
5.3.6
Finishing Touches
The web interface is designed to perform relatively common tasks. Therefore, complex customizations, such as the the ones required for the deployment of an IMS capable gateway must be configured manually. The first modification deals with enhancing call features enabled at the analog FXS extention and trunk transfers. This is solved my adding or modifying the sections called [default] and [echoLatency] in the file /etc/asterisk/extensions.conf. The necessary changes are shown in the following block of code. 32
extensions.conf
1 2 3 4 5 6 7 8 9 10 11 [ echoLatency ]; extension 1000 , for evaluating echo latency . exten => 1000 ,1 , Playback (demo - echotest ) ; Let them know what 's going on exten => 1000 ,n,Echo ; Do the echo test exten => 1000 ,n, Playback (demo - echodone ) ; Let them know it 's over exten => 1000 ,n,Goto(s ,6) ; Start over [ default ] include = echoLatency exten = 3663 ,1 , Dial(DAHDI /1|10| tThHkK ) exten = 3663 ,2 , Voicemail (3663 ,u) exten = 5000 ,1 , VoiceMailMain (${ CALLERID (num)} @default )
These changes fix a routing problem present with incoming calls directed to extension 3663 as mentioned in Section 5.3.3. In case the call is not answered by the operator in 10 seconds, the calling party is presented with an option to leave a message. The extension 1000 is also created for echo latency tests. In order to enable transfers outside the Asterisk domain, i.e. through trunks, section [macro-trunkdial-failover-0.3] has to be modified in the file /etc/asterisk/extensions.conf. The relevant line can be appreciated on line 13 in the following block of code. extensions.conf
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 [macro -trunkdial -failover -0.3] exten = s,1, GotoIf ($[${LEN(${ FMCIDNUM })} > 6]?1 - fmsetcid ,1) exten = s,2, GotoIf ($[${LEN(${ GLOBAL_OUTBOUNDCIDNAME })} > 1]?1 setgbobname ,1) exten = s,3, Set( CALLERID (num)=${IF($[${LEN(${ CID_$ { CALLERID (num)}})} > 2]?${ CID_$ { CALLERID (num)}}:) }) exten = s,n, GotoIf ($[${LEN(${ CALLERID (num)})} > 6]?1 - dial ,1) exten = s,n,Set( CALLERID (all)=${IF($[${LEN(${ CID_$ {ARG3 }})} > 6]?${ CID_$ {ARG3 }}:${ GLOBAL_OUTBOUNDCID })}) exten = s,n,Goto (1-dial ,1) exten = 1- setgbobname ,1, Set( CALLERID (name)=${ GLOBAL_OUTBOUNDCIDNAME }) exten = 1- setgbobname ,n,Goto(s ,3) exten = 1-fmsetcid ,1, Set( CALLERID (num)=${ FMCIDNUM }) exten = 1-fmsetcid ,n,Set( CALLERID (name)=${ FMCIDNAME }) exten = 1-fmsetcid ,n,Goto (1-dial ,1) exten = 1-dial ,1, Dial(${ARG1 }|10| tThHkK ) exten = 1-dial ,n, Gotoif (${LEN(${ARG2 })} > 0 ?1-${ DIALSTATUS } ,1:1 -out ,1) exten = 1- CHANUNAVAIL ,1, Dial(${ARG2 }) exten = 1- CHANUNAVAIL ,n, Hangup () exten = 1- CONGESTION ,1, Dial(${ARG2 })
33
18 19
exten = 1- CONGESTION ,n, Hangup () exten = 1-out ,1, Hangup ()
None the less, this last modification alone is not enough to warant its desired operation due to a tendency the web interface has of replacing this value with its own. To avoid this problem, line 102 from file /var/lib/asterisk/static-http/config/js/pbx.js must be changed as well. The following block of code shows the final version of said modification. pbx.js
89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 check_For_Contexts [ 'macro -' + ASTGUI . contexts . dialtrunks ] = [ // "; Macro by = Brandon Kruse <bkruse@digium .com > & Matthew O' Gorman mogorman@digium .com", 'exten =s,1, GotoIf ($[${LEN(${ FMCIDNUM })} > 6]?1 - fmsetcid ,1) ', 'exten =s,2, GotoIf ($[${LEN(${ GLOBAL_OUTBOUNDCIDNAME })} > 1]?1 setgbobname ,1) ', 'exten =s,3, Set( CALLERID (num)=${IF($[${LEN(${ CID_$ { CALLERID (num)}})} > 2]?${ CID_${ CALLERID (num)}}:) }) ', 'exten =s,n, GotoIf ($[${LEN(${ CALLERID (num)})} > 6]?1 - dial ,1) ', 'exten =s,n,Set( CALLERID (all)=${IF($[${LEN(${ CID_$ {ARG3 }})} > 6]?${ CID_$ {ARG3 }}:${ GLOBAL_OUTBOUNDCID }) }) ', 'exten =s,n,Goto (1-dial ,1) ', 'exten =1- setgbobname ,1, Set( CALLERID (name)=${ GLOBAL_OUTBOUNDCIDNAME }) ', 'exten =1- setgbobname ,n,Goto(s ,3) ', 'exten =1- fmsetcid ,1, Set( CALLERID (num)=${ FMCIDNUM }) ', 'exten =1- fmsetcid ,n,Set( CALLERID (name)=${ FMCIDNAME }) ', 'exten =1- fmsetcid ,n,Goto (1-dial ,1) ', 'exten =1-dial ,1, Dial(${ARG1 }|10| tThHkK )', 'exten =1-dial ,n, Gotoif (${LEN(${ARG2 })} > 0 ?1-${ DIALSTATUS } ,1:1 -out ,1) ', 'exten =1- CHANUNAVAIL ,1, Dial(${ARG2 }) ', 'exten =1- CHANUNAVAIL ,n, Hangup () ', 'exten =1- CONGESTION ,1, Dial(${ARG2 }) ', 'exten =1- CONGESTION ,n, Hangup () ', 'exten =1-out ,1, Hangup ()' ];
Calls between IMS clients and PSTN clients generate a slight delay that does not occur with calls between SIP and PSTN clients. This delay causes an incomprehensible amount of jitter during the call. The only way to fix this is by adding a buffer on the analog channel by uncommenting the line that says jbenable = yes in the file /etc/asterisk/chan_dahdi.conf.
34
The successful deployment of the PSTN Gateway can be appreciated by making calls between the various IMS, SIP, and PSTN users. Table 5.1 shows the ports used by Asterisk. Function SIP Requests H.323 Requests Web Server Port Number 5060 1720 8088
Table 5.1: Ports Used by Asterisk
35
Chapter 6 Content Server

The Content Server doubles as a content provider within the IMS test bed. This Application Server (AS) uses Darwin Streaming Server (DSS) for the delivery of multimedia content and UCT Advanced IPtv to establish SIP sessions. This Chapter contains the configuration for each of its components.
6.1
Darwin Streaming Server
Three playlists are created from the web interface provided by DSS at http:// vesta.ipv6.itam.mx:1220. These playlists loop infinitely simulating traditional television channels. Figure 6.1 shows how to configure each individual playlist.
Figure 6.1: Playlist Configuration
36
6.2. UCT IPTV Streaming Server
Chapter 6. Content Server
6.2
UCT IPTV Streaming Server
The configuration presented in this section was tested successfully on Ubuntu 8.04 and should work with any future releases. The installation of this component consists of downloading a deb archive located at http://prdownload.berlios. de/uctimsclient/uctiptv_advanced1.0.0.deb and installing with gdebi o dpkg. Then the playlists configured in Section 6.1 have to be mapped to Session Initiation Protocol Universal Resource Identifiers (SIP-URIs) which are used by the AS to establish SIP sessions. The following block of code shows an example of three channels configured in the file /usr/share/uctiptv_advanced/key_value_file. key_value_file
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 <?xml version ="1.0" encoding ="UTF -8"? > <key - value_pairs > <key - value_pair > <key >channel1 </key > <value >rtsp :// vesta.ipv6.itam.mx/ channel1 .sdp </ value > </key - value_pair > <key - value_pair > <key >channel2 </key > <value >rtsp :// vesta.ipv6.itam.mx/ channel2 .sdp </ value > </key - value_pair > <key - value_pair > <key >channel3 </key > <value >rtsp :// vesta.ipv6.itam.mx/ channel3 .sdp </ value > </key - value_pair > </key - value_pairs >
The UCT IPTV Streaming Server is now ready to accept SIP INVITE requests at port 8010. The AS can be started by executing the following command: uctiptv_as /usr/share/uctiptv_advanced/key_value_file
37
Chapter 7 Presence Server

The AS that implements a Presence Server is created with the help of three applications: OpenSIPS, OpenSIPS-mi-proxy, and OpenXCAP. Each one of these is installed differently and requires a slight modification to achieve the desired integration. The installation and configuration presented in this Chapter was successfully tested on Ubuntu 8.04. The installation ad configuration process does not work on previous versions. The rapid development of FOSS projects may render the process described herein unnecessary. Never the less, the process can be used as a reference point in case unexpected errors occur. The AS described in this Chapter was installed on a server that already had an IMS realm. Therefore, the port numbers mentioned in this Chapter are not the default ports used by the Presence Server. The names and IP addresses of the configuration files presented must be changed to suit your organization.
7.1
OpenSIPS
At the time of writing this document there were three available distribution methods supported by OpenSIPS: (1) pre-compiled binaries, (2) source code, or (3) source code with Transport Layer Security (TLS) support. The second and third options can be downloaded from http://opensips.org/pub/opensips/latest/src/. The first distribution method was selected for use in the installation of OpenSIPS. The deb packages were downloaded from http://opensips.org/pub/opensips/1.4.4/ packages/debian/stable/ (although newer versions are now available at http: //opensips.org/pub/opensips/latest/packages/debian/). The following block of code shows how to install the list of packages requiered by the Presence Server. Additional modules can be installed if desired. 38
7.1. OpenSIPS
Chapter 7. Presence Server
Terminal
1 2 3 4 5 6 7 8 sudo -s gdebi opensips_1 .4.4 -0 _i386.deb gdebi opensips -jabber - module_1 .4.4 -0 _i386 .deb gdebi opensips -mysql - module_1 .4.4 -0 _i386 .deb gdebi opensips -presence - modules_1 .4.4 -0 _i386 .deb gdebi opensips -radius - modules_1 .4.4 -0 _i386 .deb gdebi opensips -xmlrpc - module_1 .4.4 -0 _i386 .deb gdebi opensips -xmpp - module_1 .4.4 -0 _i386.deb
First, the database name used by OpenSIPS has to be configured, as well as the authorized user and his corresponding password used to access it. Table 7.1 shows the modifications that need to be done to the file /etc/opensips/opensipsctlrc. Original Value # DBENGINE=MYSQL # DBNAME=opensips # DBRWUSER=opensips # DBRWPW=opensipsrw New Value DBENGINE=MYSQL DBNAME=xcap DBRWUSER=xcapAdmin DBRWPW=xcap
Table 7.1: opensipsctlrc Value Substitution The command opensipsdbctl uses the above information to administer the database. The following block of code shows how this command is used to create the database and add the four IMS users with their appropriate IMS credentials (i.e. password). Terminal
1 2 3 4 5 opensipsdbctl create opensipsctl add alice@astrea .ipv6.itam.mx alice opensipsctl add bob@astrea .ipv6.itam.mx bob opensipsctl add alice@titania .ipv6.itam.mx alice opensipsctl add bob@titania .ipv6.itam.mx bob
OpenSIPS uses a routing based configuration to define its behavior. It can be configured to act as many different entities, here it is configured to act as an Resouce List Server (RLS) and XML Document Manager Server (XDMS). Customizing this configuration is very complicated. Documentation on how to go about OpenSIPSs behaviour can be found at http://www.opensips.org/Resources/Documentation. A sample configuration file can also be found at http://openxcap.org/wiki/ Installation and be used as a starting point. Or better yet, the following block 39
7.1. OpenSIPS
of code shows the configuration file /etc/opensip/opensips.cfg used in the deployment of this IMS test bed. The IP address and ports are also defined in this file. opensips.cfg
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 # # # OpenSIPS Presence Server with OpenXCAP permission rules config script # # ----------- global configuration parameters -----------------------/* Uncomment these lines to enter debugging mode */ debug =7 # debug level (cmd line: -dddddddddd ) fork=yes log_stderror =yes check_via =no # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns =no # (cmd. line: -R) # listen =udp :148.205.208.108:5060 listen =udp :148.205.208.108:5065 listen =tcp :148.205.208.108:5065 children =4
# # uncomment the following lines for TLS support # disable_tls = 0 # listen = tls: your_IP :5061 # tls_verify_server = 1 # tls_verify_client = 1 # tls_require_client_certificate = 0 # tls_method = TLSv1 # tls_certificate = "/ usr/local /etc/ opensips /tls/user/user -cert.pem" # tls_private_key = "/ usr/local /etc/ opensips /tls/user/user - privkey .pem" # tls_ca_list = "/ usr/local/etc/ opensips /tls/user/user - calist .pem" # ------------------ module loading ---------------------------------mpath ="/ usr/lib/ opensips / modules /" loadmodule loadmodule loadmodule loadmodule loadmodule " db_mysql .so" "sl.so" " maxfwd .so" " textops .so" "tm.so"
40
7.1. OpenSIPS
42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85
loadmodule loadmodule loadmodule loadmodule loadmodule loadmodule loadmodule loadmodule
"rr.so" " presence .so" " presence_xml .so" " usrloc .so" " registrar .so" " mi_fifo .so" "xlog.so" " mi_datagram .so"
modparam (" mi_datagram ", " socket_name ", "/ var/run/ opensips / socket ") modparam (" mi_datagram ", " unix_socket_user ", " opensips ") modparam (" mi_datagram ", " unix_socket_group ", " opensips ") modparam (" mi_fifo ", " fifo_name ", "/ var/run/ opensips /fifo ") modparam (" mi_fifo ", " fifo_user ", " opensips ") modparam (" mi_fifo ", " fifo_group ", " opensips ") # Uncomment this if you want digest authentication # db_mysql .so must be loaded ! # loadmodule "/ usr/ local/lib/ opensips / modules /auth.so" # loadmodule "/ usr/ local/lib/ opensips / modules / auth_db .so" # ----------------- setting module - specific parameters --------------# -- usrloc params -# Uncomment this if you want to use SQL database # for persistent storage and comment the previous line modparam (" usrloc ", " db_mode ", 2) modparam (" usrloc ", " db_url ", " mysql :// xcapAdmin : xcap@localhost /xcap ") # -- auth params -# Uncomment if you are using auth module # # modparam (" auth_db ", " calculate_ha1 ", yes) # # If you set " calculate_ha1 " parameter to yes ( which true in this config ), # uncomment also the following parameter ) # # modparam (" auth_db ", " password_column ", " password ") # -- rr params -# add value to ;lr param to make some broken UAs happy modparam (" rr", " enable_full_lr ", 1)
41
7.1. OpenSIPS
86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129
# -- mi_xmlrpc params -# be careful to set the same port in OpenXCAP configuration file # modparam (" mi_xmlrpc "," port", 8888) # -- presence params -modparam (" presence | presence_xml ", " db_url ", " mysql :// xcapAdmin : xcap@localhost /xcap ") modparam (" presence ", " server_address ", "sip: presence . astrea .ipv6.itam. mx :5065" ) modparam (" presence_xml ", " integrated_xcap_server ", 1) # ------------------------# main routing logic route{ # initial sanity checks -- messages with # max_forwards ==0, or excessively long requests if (! mf_process_maxfwd_header ("10") ) { sl_send_reply ("483" ," Too Many Hops "); exit; }; if (msg:len >= 2048 ) { sl_send_reply ("513" , " Message too big "); exit; }; route (2); ######################################### # we record - route all messages -- to make sure that # subsequent messages will go through our proxy ; that 's # particularly good if upstream and downstream entities # use different transport protocol if (! method ==" REGISTER ") record_route (); # subsequent messages withing a dialog should take the # path determined by record - routing if ( loose_route ()) { # mark routing logic in request append_hf ("P-hint: rr - enforced \r\n"); route (1); }; request routing logic -------------------
42
7.1. OpenSIPS
130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175
if (! uri == myself ) { # mark routing logic in request append_hf ("P-hint: outbound \r\n"); # if you have some interdomain connections via TLS #if(uri =~" @tls_domain1 .net ") { # t_relay (" tls: domain1 .net "); # exit; #} else if(uri =~" @tls_domain2 .net ") { # t_relay (" tls: domain2 .net "); # exit; #} route (1); }; # if the request is for other domain use UsrLoc # (in case , it does not work , use the following command # with proper names and addresses in it) if (uri == myself ) { # presence handling if( is_method (" PUBLISH | SUBSCRIBE ")) route (2); if ( method ==" REGISTER ") { # Uncomment this if you want to use digest authentication #if (! www_authorize (" opensips .org", " subscriber ")) { # www_challenge (" opensips .org", "0"); # exit; #}; save (" location "); exit; }; # native SIP destinations are handled using our USRLOC DB if (! lookup (" location ")) { sl_send_reply ("404" , "Not Found "); exit; }; append_hf ("P-hint: usrloc applied \r\n"); }; route (1); }
43
7.1. OpenSIPS
176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209
route [1] { # send it out now; use stateful forwarding as it works reliably # even for UDP2TCP if (! t_relay ()) { sl_reply_error (); }; exit; } # presence handling route route [2] { # absorb retransmissions if (! t_newtran ()) { sl_reply_error (); exit; }; # handle presence requests if( is_method (" PUBLISH ")) { handle_publish (); t_release (); } else if( is_method (" SUBSCRIBE ")) { handle_subscribe (); t_release (); }; exit; }
Next, a line has to modified from file /etc/default/opensips telling OpenSIPS it has a configuration file to run. This is done by changing the line with variable RUN_OPENSIPS to yes. This component of the Presence Server can be executed with the command opensips. If the service wants to be initiated on every server reboot a couple lines have to be added to the function check_fork from the file /etc/init.d/opensips. Specifically, lines 7 to 11 show the new lines in the following block of code. opensips
1 check_fork ()
44
7.2. OpenSIPS-mi-proxy
2 3 4 5 6 7 8 9 10 11 12
{ if grep -q "^[[: space :]]* fork [[: space :]]*=[[: space :]]* no .*" /etc/ opensips / opensips .cfg; then echo "Not starting $DESC: fork=no specified in config file; run / etc/init.d/ opensips debug instead " exit 1 fi #Fix /var/run purge if test ! -d $HOMEDIR ; then mkdir $HOMEDIR chown -R ${USER }:${GROUP } $HOMEDIR fi }
7.2
OpenSIPS-mi-proxy
This component replaces a faulty OpenSIPS module used to communicate with OpenXCAP. Its installation requires enabling an additional repository in the package manager, obtaining the digital signature to avoid error messages from synaptic and finally its installation with the package manager. The repositories can be added manually at the end of the file /etc/apt/sources.list with your favorite text editor. The next block of code shows the repositories to be added to the file. sources.list
1 2 deb http ://ag - projects .com/ debian unstable main deb -src http ://ag - projects .com/ debian unstable main
The following block of code authorizes the digital signature of the maintainer and proceeds to install OpenSIPS-mi-proxy. Terminal
1 2 3 4 wget http :// download .ag - projects .com/agp -debian -gpg.key apt -key add agp -debian -gpg.key apt -get update apt -get install opensips -mi -proxy
This component is started automatically every time the server is rebooted. Finally, in order for OpenSIPS-mi-proxy to communicate with OpenXCAP, the following line must be added to the end of the configuration file /etc/opensips-mi-proxy/config.ini: listen_url=http://148.205.208.108:8888 45
7.3. OpenXCAP
7.3
OpenXCAP
Since OpenXCAP requires newer libraries than the ones available in Ubuntu 8.04, this must be circumvented by compiling the source code with the available system libraries. First, the repositories enabled in Section 7.2 have to be disabled by commenting the new additions in file /etc/apt/sources.list. Then, the required development libraries are installed with the commands shown in the following block of code. Terminal
1 2 3 sudo -s apt -get update apt -get install python python - central python -lxml python - zopeinterface python -twisted -core python -twisted -web python -twisted -web2 python application python - gnutls python - sqlobject python - support python -xml python - mysqldb
Even though OpenXCAP is available through the package manager it cannot be installed because it breaks the integrity of the system. Therefore, the source code must be downloaded from http://download.ag-projects.com/XCAP/. The name of the archive to be downloaded should resembleopenxcap_VERSION.tar.gz. The following block of code shows how to unpack, install and register OpenXCAP with the systems package manager.
1 2 3 4 5 6 tar xzf openxcap *. tar.gz cd openxcap * sudo python setup .py install sudo checkinstall sudo python setup.py install sudo cp config .ini. sample /etc/ openxcap / config .ini sudo cp debian / openxcap .init /etc/init.d/ opensips
If OpenXCAP does not start on every reboot of the system a file is missing from the archive. This will be noticed if the execution of line 6 from the block of code above returns an error message. In order to automatically start OpenXCAP the file /etc/init.d/openxcap has to be created with the information shown in the following block of code. openxcap
1 2 3 4 5 #!/ bin/sh # ### BEGIN INIT INFO # Provides : # Required - Start :
openxcap $syslog $network $local_fs $time
46
7.3. OpenXCAP
6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49
# Required -Stop: # Default - Start : # Default -Stop: # Short - Description : # Description : ### END INIT INFO
$syslog $network $local_fs 2 3 4 5 0 1 6 Start the OpenXCAP server Start the OpenXCAP server
PATH =/ usr/ local /sbin :/ usr/local /bin :/ sbin :/ bin :/ usr/sbin :/ usr/bin INSTALL_DIR ="/ usr/bin" RUNTIME_DIR ="/ var/run/ openxcap " SERVER =" $INSTALL_DIR / openxcap " PID =" $RUNTIME_DIR / openxcap .pid" # Options for the OpenXCAP server . Do not include --pid <pidfile > # --pid <pidfile > will be added automatically if needed . OPTIONS ="" NAME =" openxcap " DESC =" OpenXCAP server " test -f $SERVER || exit 0 if [ "$PID" != "/ var/run/ openxcap / openxcap .pid" ]; then OPTIONS ="--pid $PID $OPTIONS " fi start () { echo -n " Starting $DESC: $NAME " start -stop - daemon --start --quiet --pidfile $PID --exec $SERVER -$OPTIONS echo "." } stop () { echo -n " Stopping $DESC: $NAME " start -stop - daemon --stop --quiet --oknodo --signal 15 --pidfile $PID echo "." } case "$1" in start ) start ;;
47
7.3. OpenXCAP
50 51 52 53 54 55 56 57 58 59 60 61 62 63 64
stop) stop ;; restart |force - reload ) stop #sleep 1 start ;; *) echo " Usage: /etc/init.d/$NAME { start |stop| restart |force - reload }" >&2 exit 1 ;; esac exit 0
Next, some source code has to be commented out to avoid problems when running OpenXCAP on Ubuntu 8.04. Line 48 of file /usr/bin/openxcap which says start_log() has to be commented. Line 44 of file /usr/lib/python2.5/site-packages/xcap/element.py which says sys.exit(1) also has to be commented. This finishes the installation process of OpenXAP. In order to configure OpenXCAP, first digital signatures and certificates used by the HyperText Transfer Protocol over SSL (HTTPS) interface have to be created. This can easily be done with openssl as shown in the following block of code. Each line containing openssl has data fields which must be filled in according to your organization. Terminal
1 2 3 4 5 6 7 8 9 10 11 12 13 sudo -s apt -get install openssl cd /etc/ openxcap /tls openssl genrsa -des3 -out server .key 4096 openssl req -new -key server .key -out server .csr openssl x509 -req -days 365 -in server .csr -signkey server .key -out server .crt openssl rsa -in server .key -out server .key. insecure mv server .key server .key. secure mv server .key. insecure server .key openssl genrsa -des3 -out ca.key 4096 openssl req -new -x509 -days 365 -key ca.key -out ca.crt openssl genrsa -des3 -out server .key 4096 openssl req -new -key server .key -out server .csr
48
7.3. OpenXCAP
14 15 16
openssl x509 -req -days 365 -in server .csr -CA ca.crt -CAkey ca.key set_serial 01 -out server .crt cp server .key server .key.pass openssl rsa -in server .key.pass -out server .key
Information hungry users can verify the correct generation of the digital certificates and signatures by executing the commands shown in the following block of code. Terminal
1 2 3 4 openssl openssl openssl openssl rsa -noout -text -in server .key req -noout -text -in server .csr rsa -noout -text -in ca.key x509 -noout -text -in ca.crt
The next step configures OpenXCAP to use OpenSIPS as its backend. The configuration file /etc/openxcap/config.ini has to be changed to mimic the information shown in the following block of code. config.ini
1 2 3 4 5 6 7 8 9 10 11 12 13 14 [ Server ] root = https :// presence . astrea .ipv6.itam.mx/xcap - root@titania .ipv6.itam .mx/ root = https :// presence . astrea .ipv6.itam.mx/xcap - root@astrea .ipv6.itam. mx/ root = https :// presence . astrea .ipv6.itam.mx/xcap -root/ default_realm = astrea .ipv6.itam.mx [ Authentication ] authentication_db_uri = mysql :// xcapAdmin : xcap@localhost /xcap [ Database ] storage_db_uri = mysql :// xcapAdmin : xcap@localhost /xcap [ OpenSIPS ] xmlrpc_url = http :// presence . astrea .ipv6.itam.mx :8888/ RPC2/
OpenXCAP provides a simple client to test features called xcapclient. This client can be installed with the package manager after enabling the previously disabled repositories added in Section 7.2. Once the repositories have been enabled the following block of code installs the client.
1 2 3 sudo -s apt -get update apt -get install python - xcaplib
49
7.3. OpenXCAP
The successful deployment of the Presence Server can be apreciated by using xcapclient to administer Presence Information Data Format (PIDF) documents and by witnessing the presence status of other clients using UCT IMS Client. Table 7.2 shows the ports used by the Presence Server. Port 8888 is only used between the modules OpenSIPS and OpenXCAP. It should not, and cannot, be used directly by the user. Function XCAP (HTTPS) Requests XML-RPC Requests SIP Requests Port Number 443 8888 5065
Table 7.2: Ports Used by the Presece Server
50
Chapter 8 Configuration of Application Servers

If the instructions in every Section of this document have been followed sequentially, the components of the IMS test bed should have been deployed. This Chapter joins each component to the IMS realms and completes the creation of a Service Delivery Platform. The configurations mentioned in this Chapter cater to one IMS realm, and should be repeated for every realm within the IMS test bed. Each component is added as an AS to the IMS realms by following these four steps: 1. Add the AS to the HSS registry. 2. Add a Trigger Point to the HSS registry. The Trigger Point defines a pattern used by the Serving-CSCF (S-CSCF) to enable (or disable) services for given SIP messages. The Trigger Point defines the behavior of the AS. 3. Join steps 1 and 2 with an Initial Filter Criteria (iFC), allowing the creation of a service route. 4. Add the iFC to a Service Profile. This profile is used to administer the services into groups, which are later used to enable or disable services for users with certain profiles.
8.1
Presence Server
The installation of OpenIMS Core provides a default AS as a working example. Therefore, modifying said example is suffice for the registration of the first AS. 51
8.2. Content Server
Chapter 8. Configuration of Application Servers
The configuration interface provided by OpenIMS Core can be accessed at http: //REALM:8080. The new configuration of the sample AS must be modeled after the configuration presented in Chapter 7. The menu item Services -> Application Servers configures the name, IP address, and port used by the first AS. Figure 8.1 shows the configuration displayed from the web interface. Figure 8.2 shows the configuration for the Trigger Point accessible from the menu item Services -> Trigger Points
Figure 8.1: Presence Application Server Configuration
Figure 8.2: Presence Application Server Trigger Point
8.2
Content Server
An AS is created for the subsequent components instead of modifying an existing one. Fortunately, the creation process is exactly the same as the editing process except for the fact that the menu option selected is named Create. Figure 8.3 shows the configuration used by the AS. Instead of providing an image to show the Trigger 52
8.3. PSTN Gateway
Chapter 8. Configuration of Application Servers
Point configuration, Table 8.1 helps demostrate it in a concise manner. Finally an iFC has to be created which assigns the Trigger Point to an AS. Figure 8.4 shows how this is done via the menu item Services -> Initial Filter Criteria
Figure 8.3: Content Application Server Configuration
Secton Main Trigger Point 1 Trigger Point 2
Field Condition Type CMF SIP Method SIP Header SIP Header Content
Value Conjunctive Normal Format INVITE To .*iptv.astrea.ipv6.itam.mx.*
Table 8.1: Content Application Server Trigger Point
Figure 8.4: Content Application Server Initial Filter Criteria
8.3
PSTN Gateway
As can clearly be seen, the AS configuration only depends on the name, IP address, and port used by the server. The most important configuration of the AS depends on the Trigger Point assigned to it. Table 5.1 can be used to obtain the SIP port used to configure the AS used in this Section. The Trigger Point is then created with the values given by Table 8.2. Finally, the iFC is created by linking the AS and Trigger Point as was done in the previous Section.
53
8.4. Service Profile Section Main Trigger Point 1 Trigger Point 2
Chapter 8. Configuration of Application Servers Field Condition Type CMF SIP Method SIP Method SIP Header SIP Header Content Value Conjunctive Normal Format INVITE INFO To .*hebe.ipv6.itam.mx.*
Table 8.2: PSTN Gateway Application Server Trigger Point
8.4
Service Profile
The final configuration requiered to use the AS within the IMS realm consists of adding these to a Service Profile. This can easily be done by adding each iFC to the Service Profile as shown in Figure 8.5. Each iFC must also be assigned a priority within the Service Profile as show in Figure 8.6 via the menu item Services -> Shared iFC Sets.
Figure 8.5: Service Profile
Figure 8.6: Service Profile Priorities
54
Chapter 9 IMS Clients

The IMS clients used in this test bed are developed by UCT, appropriately named UCT IMS Client. The test bed has four IMS clients: two installed on machines running Fedora Core 6 and two running on Ubuntu 8.04. Their installation under Ubuntu can be done easily by downloading the deb archive http://prdownload. berlios.de/uctimsclient/uctimsclient1.0.12.deb and installing it with the following command: dpkg -i uctimsclient1.0.12.deb On Fedora, however, they have to be compiled from source. The following block of code takes care of the depenencies requiered by the compilation. Please note that if the desire arises to install from source on Ubuntu the packages ending in devel must be changed to dev; and libcurl3-devel must be changed to libcurl4-openssl-dev. Terminal
1 yum install libosip2 -devel libexosip2 -devel libgtk2 .0- devel libxml2 devel libcurl3 -devel libgstreamer0 .10 -0 - devel libgstreamer -plugins base0 .10 - devel gstreamer0 .10 - ffmpeg gstreamer0 .10 - fluendo -mp3 gstreamer0 .10 - plugins -good gstreamer0 .10 - plugins -bad gstreamer0 .10 plugins -ugly libavcodec libvlc -dev vlc
Next, the source code is downloaded from http://prdownload.berlios.de/ uctimsclient/uctimsclient1.0.12.tar.gz and compiled and installed with the instructions show in the following block of code.
55
Chapter 9. IMS Clients
Terminal
1 2 3 4 5 6 7 8 9 10 mv uctimsclient1 .0.12. tar.gz /usr/ local/ cd /usr/ local tar xzf uctimsclient1 .0.12. tar.gz rm uctimsclient1 .0.12. tar.gz chmod +w -R uctimsclient / cd uctimsclient ./ configure make cd /usr/ local /bin ln -s /usr/ local / uctimsclient / uctimsclient .
The client can now be executed by runing the command uctimsclient. Finally, Figure 9.1 shows a sample configuration of the client used to communicate with the IMS realms and the Content Server.
(a) IMS Realm Configuration
(b) Multimedia Configuration
Figure 9.1: IMS Client Configuration
56
Glossary
3G Third Generation. 4 3GPP Third Generation Partnership Project. 3 3GPP2 Third Generation Partnership Project 2. 4 AS Application Server. 1, 3638, 5154 CAPEX Capital Expenditure. 3 CSCF Call/Service Control Function. 15, 16 DNS Domain Name Server. 11, 14 DSS Darwin Streaming Server. 36 DTMF Dual-Tone Multi-Frequency. 31 FOKUS Fraunhofer Institute for Open Communications Systems. 4, 15 FOSS Free and Open Source Software. 15, 38 FXO Foreign eXchange Office. 21, 27 FXS Foreign eXchange Station. 21, 28, 30, 32 GSM Global System for Mobile communications. 26 HSS Home Subscriber Server. 15, 16, 51 HTTPS HyperText Transfer Protocol over SSL. 48
57
Glossary
Glossary
IETF Internet Engineering Task Force. 4 iFC Initial Filter Criteria. 51, 53, 54 IMS IP Multimedia Subsystem. 15, 11, 15, 1721, 24, 27, 28, 3032, 3436, 3840, 51, 5456 IP Internet Protocol. 16, 17, 38, 40, 52, 53 IPTV IP Television. 8 ISP Internet Service Provider. 2, 3 ITAM Instituto Tecnolgico Autnomo de Mxico. 1, 28 ITU International Telecommunications Union. 3 NGN Next Generation Networks. 24 OMA Open Mobile Alliance. 4 OPEX Operational Expenditure. 3 PBX Private Branch eXchange. 26 PCI Peripheral Component Interconnect. 21 PIDF Presence Information Data Format. 50 PSTN Public Switched Telephone Network. 1, 21, 23, 28, 31, 34, 35 QoE Quality of Experience. 4, 5 QoS Quality of Service. 4 RLS Resouce List Server. 39 S-CSCF Serving-CSCF. 51 SIP Session Initiation Protocol. 15, 23, 26, 27, 30, 31, 3437, 51, 53 SIP-URI Session Initiation Protocol Universal Resource Identifier. 37 58
Glossary
Glossary
TLS Transport Layer Security. 38 TTM Time to Market. 4 UCT University of Cape Town. 4, 55 XDMS XML Document Manager Server. 39
59
References
[1] 3GPP: Telecommunications and Internet converged Services and Protocols for Advanced Networks (TISPAN); Support of Short Message Service (SMS) over NGN IMS subsystem; Stage 2; [Endorsement of 3GPP TS 23.204 Release 7]. Ts 23.521, 3rd Generation Partnership Project (3GPP), Dec. 2007. http://www. 3gpp.org/ftp/Specs/html-info/23521.htm. [2] 3GPP: Messaging service using the IP Multimedia (IM) Core Network (CN) subsystem; Stage 3. Ts 24.247, 3rd Generation Partnership Project (3GPP), Mar. 2008. http://www.3gpp.org/ftp/Specs/html-info/24247.htm. [3] 3GPP: TISPAN; IP Multimedia Call Control Protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Stage 3 [3GPP TS 24.229 (Release 7), modified]. Ts 24.503, 3rd Generation Partnership Project (3GPP), Sept. 2008. http://www.3gpp.org/ftp/Specs/html-info/ 24503.htm. [4] 3GPP: TISPAN; Support of SMS and MMS over NGN IMS subsystem; Stage 3 [Endorsement of 3GPP TS 24.341 Release 7]. Ts 24.451, 3rd Generation Partnership Project (3GPP), Mar. 2008. http://www.3gpp.org/ftp/Specs/ html-info/24451.htm. [5] M. Brenner and M. Unmehopa: The Open Mobile Alliance: Delivering Service Enablers for Next-Generation Applications. J. Wiley & Sons, Chichester, England; Hoboken, NJ, Apr. 2008. [6] G. Camarillo and M.A. Garca-Martn: The 3G IP Multimedia Subsystem (IMS) : Merging The Internet And The Cellular Worlds. J. Wiley & Sons, Chichester, England; Hoboken, NJ, 2nd ed., May 2006.
60
REFERENCES
REFERENCES
[7] Content Team BSNL Portal Intelligroup Asia Pvt. Ltd.: IMS Investment To Reach $10.1 Billion in 5 yrs, June 2006. [http://portal.bsnl. in/telecomnewsanalysis.asp?intNewsId=69133, accesado 12/10/08]. [8] A. Cuevas, J.I. Moreno, P. Vidales, and H. Einsiedler: The IMS Service Platform: A Solution For Next-Generation Network Operators To Be More Than Bit Pipes. Communications Magazine, IEEE, 44(8):7581, 2006. [9] Ericsson: IMS IP Multimedia Subsystem. White Paper, Oct. 2004. [10] Ericsson: Introduction to IMS. White Paper, Mar. 2007. [11] M. Garcia-Martin: Input 3rd-Generation Partnership Project (3GPP) Release 5 Requirements on the Session Initiation Protocol (SIP). Rfc 4083, Internet Engineering Task Force, May 2005. http://www.rfc-editor.org/rfc/rfc4083. txt. [12] A. Lotsson: Expect 4G Telephony In 2012 Says Ericsson Research Head, May 2004. [http://www.arnnet.com.au/article/65267/expect_4g_telephony_ 2012_says_ericsson_research_head, accesado 12/10/08]. [13] J. Loughney: Diameter Command Codes for Third Generation Partnership Project (3GPP) Release 5. Rfc 3589, Internet Engineering Task Force, Sept. 2003. http://www.rfc-editor.org/rfc/rfc3589.txt. [14] A.K. MacDonald: Servicios Personalizados de Multimedia Ofrecidos Sobre la Plataforma IP Multimedia Subsystem. Instituto Tecnolgico Autnomo de Mxico (ITAM), Bachelors Thesis, 2009. [15] J.V. Meggelen, L. Madsen, and J. Smith: Asterisk: The Future of Telephony. OReilly Media, Inc, 1005 Gravenstein Highway North, Sebastopol, CA, 2nd ed., Aug. 2007. [16] J.L. Salina and P. Salina: Next Generation Networks: Perspectives and Potentials. J. Wiley & Sons, Chichester, England; Hoboken, NJ, Feb. 2008. [17] S. Shepard: IMS Crash Course. McGraw-Hill, New York, 2006.
61

Tech Report MacDonald

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tech Report MacDonald

Uploaded by

Copyright:

Available Formats

Configuration and Deployment of an IMS Test Bed

5.3.4 5.3.5 5.3.6

Dial Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Finishing Touches . . . . . . . . . . . . . . . . . . . . . . . .

IMS Client Configuration . . . . . . . . . . . . . . . . . . . . . . . .

Next Generation Networking

1.2. Service Delivery Models

Service Delivery Models

1.3. IP Multimedia Subsystem

Chapter 2 Static Routes

Figure 2.1: Physical Topology

Chapter 2. Static Routes

Table 2.1: Names and IP Addresses

2.3. FreeBSD Routers

Chapter 2. Static Routes

Chapter 2. Static Routes

Chapter 2. Static Routes

Chapter 2. Static Routes

Chapter 3 DNS Entries

Chapter 3. DNS Entries

Chapter 3. DNS Entries

ns 148.205.208.105 148.205.208.105 148.205.208.105 148.205.208.105

1D IN NS ns 1D IN A 148.205.208.107 1D IN A 148.205.208.107 1D IN A 148.205.208.107

hebe.ipv6.itam.mx. _sip _sip._udp _sip._tcp

1D SRV 0 0 5060 asterisk 1D SRV 0 0 5060 asterisk 1D SRV 0 0 5060 asterisk

Chapter 3. DNS Entries

1D IN NAPTR 10 50 "s" "SIP+D2U" "" 1D IN NAPTR 20 50 "s" "SIP+D2T" ""

Chapter 4 IMS Realms

Chapter 4. IMS Realms

Chapter 4. IMS Realms

Chapter 4. IMS Realms

4.4. Deployment Function P-CSCF I-CSCF S-CSCF HSS (Diameter)

Chapter 4. IMS Realms

Chapter 5 PSTN Gateway

5.1. Digium Hardware

Chapter 5. PSTN Gateway

5.2. Asterisk Software

Chapter 5. PSTN Gateway

5.2. Asterisk Software

Chapter 5. PSTN Gateway

5.3. Feature Setup

Chapter 5. PSTN Gateway

sudo make install sudo make samples make checkconfig

5.3.1. Global Settings

Chapter 5. PSTN Gateway

Chapter 5. PSTN Gateway

5.3.3. Incoming and Outgoing Calling Rules

Chapter 5. PSTN Gateway

Figure 5.4: VOIP Trunk

Incoming and Outgoing Calling Rules

5.3.4. Dial Plan

Chapter 5. PSTN Gateway

(a) FXO Trunk

(b) SIP Trunk

(a) FXO Trunk

(b) SIP Trunk

Figure 5.6: Incoming Calling Rules

Chapter 5. PSTN Gateway

Chapter 5. PSTN Gateway

5.3.6. Finishing Touches

Chapter 5. PSTN Gateway

5.3.6. Finishing Touches

Chapter 5. PSTN Gateway

5.3.6. Finishing Touches

Chapter 5. PSTN Gateway

Value Conjunctive Normal Format INVITE To .iptv.astrea.ipv6.itam.mx.