SLL /P. Podhradsk, E. Mikoczy, J. Matejka, S. Schumann, O. Labaj, R. Kadlic, R. Tomek, S. Massner, J.Mikula, M.

Dungel/

Train2Cert

Next Generation Network Protocols Professional

Laboratory part - Student Guide

2 NGN architecture design, platform setup and protocol analyses based troubleshooting

Exercise 2: IMS elements, design, installation

Average Duration
1 hr

Overview and Student Prerequisites

This chapter should help the student to understand how the IMS based NGN works. The lesson will introduces all key elements in theory. During the lesson, the student will understand important IMS elements, designing principles and example of installation requirements. The open-source IMS environment from FOKUS Fraunhofer OpenIMS will be analyzed and main IMS functions it will handle explained.

Technical Requirements for the Experiment

IP infrastructure (L2/L3 switch, L3 router, Ethernet hub, PCs/Laptops, PDA) Basic IMS architecture platform (UE/with IMS clients, IMS servers, Application servers) Software tools for protocol analyses and IMS configuration

Introduction on how to set up the Experiment

Usually the IMS is set-up already on a virtual machine. If not, or if the teacher wants to go through the installation process to understand the configuration and deployment process, this module will explain all steps and introduce the used platform.

Learning Outcomes
This laboratory work will give basic advice to the student about laboratory IMS architecture setup and core elements. The training will include explanation about basic procedures how to design IMS like platform and what are important parameters and designing rules. The training focussed on the FOKUS Fraunhofer developed OpenIMS. The main advantage of this platform is that it is open source software. The student can use, modify and extend it without limitations.

Description of the Experiment

Task 1: Design principles of distributed IMS based NGN architecture (theoretical)
See handbook and review the recommended chapters.

Task 2: Show installation procedures and important platform parameter

The installation guide was taken from http://www.openimscore.org/installation_guide and has been extended by own experiences. The OpenIMS core is best installed on a up-to-date Linux distribution. Debian GNU/Linux 4.0 has been the choice, as the package management enables the very easy installation of required packages. Moreover, it is a very stable and production proofed distribution.

Steps of the Experiment

Step 1: Prerequisites

Software requirements o ~100 MBytes of disk space to be on the safe side o GCC3/4, make, JDK1.5, ant Debian installation: # apt-get install gcc make sun-java5-jdk ant
o

MySQL installed and started (or other DBMS if you can deal with it)

Debian installation: # apt-get install mysql-server

o

bison, flex

Debian installation: # apt-get install bison flex

o

libxml2 (> 2.6), libmysql - both with development

Debian installation: # apt-get install libmysqlclient15off libmysqlclient15-dev

o

Linux kernel 2.6 and ipsec-tools (setkey) if you want to use IPSec security

Debian installation: # apt-get install ipsec-tools (Kernel 2.6 standard in Debian 4.0)
o o

Optional: openssl if you would like to enable the TLS security bind installed and running (or other name server if you can deal with it)

Debian installation: # apt-get install bind9 (Configuration will be explained in detail in chapter 3) Moreover, the following tools are recommended to perform all necesasry actions and later tasks: Debian installation: # apt-get install subversion ngrep

Step 2: Get the Source Code

Create /opt/OpenIMSCore and go there

o mkdir /opt/OpenIMSCore cd /opt/OpenIMSCore

Create a new directory ser_ims and checkout the CSCFs there:

o mkdir ser_ims svn checkout http://svn.berlios.de/svnroot/repos/openimscore/ser_ims/trunk ser_ims

Create a new directory FHoSS and checkout the HSS there:

o mkdir FHoSS svn checkout http://svn.berlios.de/svnroot/repos/openimscore/FHoSS/trunk FHoSS

Step 3: Compile

ser_ims
o o o

Do "make install-libs all" in ser_ims

cd ser_ims make install-libs all cd ..

If something breaks, you probably don't have all the prerequisites.

FHoSS
o o o cd FHoSS ant compile ant deploy cd ..

Step 4: Configure the Environment

Notes:
o o o

All the installation examples configured to work only on the local loopback and the default domain configured as "open-ims.test". The MySQL access rights are set only for local access We recommend that you try it first like this and then do your changes: Replace 127.0.0.1 where required with your IP address Replace the home domain (open-ims.test) with your own one Change the database passwords

For this operation the ser_ims/cfg/configurator.sh might help you.

DNS
o o o o o

A sample DNS zone file can be found in ser_ims/cfg/open-ims.dnszone Copy it to your bind configuration directory Edit named.conf and insert the file there (Would be great to also add reverse DNS entries) Restart the name server Test that the names are resolvable (don't forget about /etc/resolv.conf pointing to your new DNS server!) Run the SQL dumps (mysql -u root -p -h localhost < dump.sql): New!!! "hssdb.sql" was replaced by "hss_db.sql" !!!
mysql -u root -p -h localhost < ser_ims/cfg/icscf.sql mysql -u root -p -h localhost < FHoSS/scripts/hss_db.sql mysql -u root -p -h localhost < FHoSS/scripts/userdata.sql

MySQL
o o o o o

Check if the databases are in there and accessible

Step 5: Configure the IMS Core

By now you should have MySQL and DNS working CSCFs o Copy the following files to /opt/OpenIMSCore or another location comfortable for you: pcscf.cfg, pcscf.sh, icscf.cfg, icscf.xml, icscf.sh, scscf.cfg, scscf.xml, scscf.sh,
o o o cp ser_ims/cfg/*.cfg . cp ser_ims/cfg/*.xml . cp ser_ims/cfg/*.sh .

FHoSS 4

o Take a look at the configuration files in FHoSS/deploy/ (available after Step 3 completes) Edit these files to your own preferences (don't forget to update the DNS zone file accordingly and restart the name server)

Step 6: Start the components

CSCFs
o o o o

Start pcscf.sh, icscf.sh and scscf.sh All these should run in parallel. We love debugging, so by default they would stay in foreground. By default you should see periodically log messages with the content of the registrar and with the opened diameter links Start FHoSS/deploy/startup.sh If the previous step fails, check that you have the JAVA_HOME environment variable correctly exported and/or modify the script that you just tried to start. Check the web interface on http://localhost:8080/ Check if the Diameter Peers are connecting to each other. You can see this in the console of FHoSS or in that of I/S-CSCF

FHoSS
o o o o

Conclusions for the Experiment / Lab Questions

After the experiment, the student will have a running IMS core with an HSS server. This is the main base for the upcoming session. The IMS call session controllers are all based on the SIP Express Router (SER), a predecessor of the SIP AS OpenSIPS, which has been deeply explained in the first session. The students can analyze the configuration files and study, which functions have been deployed and how.

Answers to the Questions and Conclusions

Exercise 3: Configuration and testing of the IMS platform

Average Duration
4 hrs

Overview and Student Prerequisites

This chapter should help the student to configure the IMS system that has been set up in the last experiment. The tasks include the configuration of CSCFs servers and HSS. Moreover, currently available IMS clients will be set up and configured. The IMS clients will be connected with the IMS to be able to perform the next experiment.

Technical Requirements for the Experiment

IP infrastructure (L2/L3 switch, L3 router, Ethernet hub, PCs/Laptops, PDA) Basic IMS architecture platform (UE/with IMS clients, IMS servers, Application servers) Software tools for protocol analyses and IMS configuration

Introduction on how to set up the Experiment

Usually the IMS is set-up already on a virtual machine. If not, or if the teacher wants to go through the installation process to understand the configuration and deployment process, the previous module explains the set up. The client applications can be downloaded from given sources within this experiment. Some clients will also be available in a specified folder of the virtual machine.

Learning Outcomes
This laboratory exercise will explain examples of the configuration work during setup and configuration of simplified IMS platform. After exercise the student will have a general idea about how to configure an IMS like platform (e.g. HSS settings, basic configuration parameter) Although all configuration will be done with the FOKUS Fraunhofer developed OpenIMS, the CSCF/HSS parameters can be considered as universal parameters that should exist on other platforms as well. The explanations within this chapter should not be considered OpenIMS-specific, but rather as general IMS configuration parameters.

Description of the Experiment

Task 1: Check IMS platform setup

(A) Installed Components 1 DNS-Server (all IP-entries are static - no DHCP Server is required) - Standard Components and Desktop Environment 6

- DNS-Server (Bind9.3.2 or Bind9.3.1) - Wireshark

2 P-/I-/S-CSCF - Standard Components and Desktop Environment (set static IP-address) - (MySQL Database on I-CSCF only!) - Wireshark

3 HSS - Standard Components and Desktop Environment (set static IP-address) - MySQL Database - Wireshark

4 Clients Debian-Linux - Standard Components and Desktop Environment (set static IP-address) - Wireshark Windows - Standard Installation (set static IP-address) - Wireshark

(B) Compiling IMS Components from SourceCode as described in OpenIMS tutorial.

Task 2: Setting of DNS and DHCP servers

(C) Set DNS entries and configuration as described in documentation about OpenIMSCore. Bold typed 'x' has to be set to your desired IP-configuration. Please take care by granting rights for the following configuration files. It is recommended that you use these setting:

user group /etc/network/interfaces etc/bind/named.conf /etc/bind/open-ims.dnszone /etc/bind/107.168.192.in-addr.arpa /etc/udev/rules.d/z25_persistent-net.rules root /etc/hostname f) /etc/hosts /etc/resolv.conf root root bind bind root section root root root bind bind e) root root a) root c) d) b)

root root

g) h)

a) /etc/network/interfaces
# This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5).

# The loopback network interface auto lo iface lo inet loopback

# The primary network interface auto eth0 iface eth0 inet static address 192.168.x.x netmask 255.255.255.0 network 192.168.x.0

b) /etc/bind/named.conf
// Customized configuration file for the BIND DNS server named. // Please read the instruction manual ***BEFORE*** you change the configuration. //

// This is the primary configuration file for the BIND DNS server named. // // Please read /usr/share/doc/bind9/README.Debian.gz for information on the // structure of BIND configuration files in Debian, *BEFORE* you customize // this configuration file. // // If you are just adding zones, please do that in /etc/bind/named.conf.local

include "/etc/bind/named.conf.options";

// security options used to control dns by dhcp dynamicly // define where did you control it from and where the key is stored // secret must be the same as in /etc/bind/rndc.conf include "/etc/bind/rndc.key"; controls { inet 127.0.0.1 allow { 127.0.0.1; } keys { "rndc-key"; }; };

// access control list - here you can add other zones where you can request // from to resolve dns entries acl "internal_open-ims" { 192.168.x.0/24; 127.0.0.1; };

logging { channel "named_log" { // send most BIND logs to a dedicated log file // You have to create this log-file if it doesn't exist! file "/var/log/bind/named.log" versions 10 size 2M; severity debug; print-category yes; print-severity yes; print-time yes;

};

channel "query_log" { // query logs go to a separate file // You have to create this log-file if it doesn't exist! file "/var/log/bind/query.log" versions 10 size 2M; severity debug; print-category yes; print-severity yes; print-time yes; };

category default { named_log; }; category queries { query_log; }; };

// prime the server with knowledge of the root servers zone "." { type hint; file "/etc/bind/db.root"; }; // be authoritative for the localhost forward and reverse zones, and for // broadcast zones as per RFC 1912

zone "localhost" { type master; file "/etc/bind/db.local"; };

zone "127.in-addr.arpa" { type master;

10

file "/etc/bind/db.127"; };

zone "0.in-addr.arpa" { type master; file "/etc/bind/db.0"; allow-query { any; }; allow-transfer { none; }; notify yes; };

zone "255.in-addr.arpa" { type master; file "/etc/bind/db.255"; allow-query { any; }; allow-transfer { none; }; notify yes; };

// zone "com" { type delegation-only; }; // From the release notes: // Because many of our users are uncomfortable receiving undelegated answers // from root or top level domains, other than a few for whom that behaviour // has been trusted and expected for quite some length of time, we have now // introduced the "root-delegations-only" feature which applies delegation-only // logic to all top level domains, and to the root domain.

// include "/etc/bind/named.conf.local";

zone "open-ims.test" in { type master;

11

file "/etc/bind/open-ims.dnszone"; allow-query { any; }; allow-transfer { none; }; allow-update { key "rndc-key"; }; notify yes; };

zone "107.168.192.in-addr.arpa" { type master; file "/etc/bind/open-ims.dnszone.rev"; allow-query { any; }; allow-transfer { none; }; allow-update { key "rndc-key"; }; notify yes; };

c) /etc/bind/open-ims.dnszone
$ORIGIN . $TTL 86400 open-ims.test ; 1 day IN SOA localhost.open-ims.test. root.localhost.open-ims.test. ( 2009010101 ; serial 10800 900 604800 86400 ) NS NAPTR NAPTR $ORIGIN open-ims.test. ns.open-ims.test. 10 50 "s" "SIP+D2T" "" _sip._tcp.open-ims.test. 10 50 "s" "SIP+D2U" "" _sip._udp.open-ims.test. ; refresh (3 hours) ; retry (15 minutes) ; expire (1 week) ; minimum (1 day)

12

ns

192.168.x.253

_sip _sip._tcp _sip._udp

SRV SRV SRV

0 0 5060 icscf 0 0 5060 icscf 0 0 5060 icscf

open-ims.test. open-ims.test.

1D IN NAPTR 10 50 "s" "SIP+D2U" "" _sip._udp.open-ims.test. 1D IN NAPTR 20 50 "s" "SIP+D2T" "" _sip._tcp.open-ims.test.

icscf scscf pcscf hss

A A A A

192.168.x.250 192.168.x.240 192.168.x.230 192.168.x.220

client1 client2

A A

192.168.x.201 192.168.x.202

d) /etc/bind/open-ims.dnszone.rev
$ORIGIN . $TTL 86400 ; 1 day localhost.open-ims.test. 2009010101 ; serial 10800 900 604800 86400 ) NS $ORIGIN x.168.192.in-addr.arpa. 253 PTR ns.open-ims.test. ns.open-ims.test. ; refresh (3 hours) ; retry (15 minutes) ; expire (1 week) ; minimum (1 day)

x.168.192.in-addr.arpa IN SOA root.localhost.open-ims.test. (

13

250 240 230 220

PTR PTR PTR PTR

icscf.open-ims.test. scscf.open-ims.test. pcscf.open-ims.test. hss.open-ims.test.

201 202

PTR PTR

client1.open-ims.test. client2.open-ims.test.

e) /etc/udev/rules.d/z25_persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules # program, probably run by the persistent-net-generator.rules rules file. # # You can modify it, as long as you keep each rule on a single line. # MAC addresses must be written in lowercase.

# PCI device 0x8086:0x103b (e100) SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="<MAC-Address", NAME="eth0"

f) /etc/hostname
ns

g) /etc/hosts
127.0.0.1 localhost

# The following lines are desirable for IPv6 capable hosts ::1 ip6-localhost ip6-loopback

fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes

14

ff02::2 ip6-allrouters ff02::3 ip6-allhosts

h) /etc/resolv.conf
search open-ims.test nameserver 192.168.x.253

Task 3: Configuration of CSCF servers and HSS

(D) Set configuration as described in documentation about OpenIMSCore components. Bold typed 'x' has to be set to your desired IP-configuration.

After common configuration information detailled configure settings are described in separate chapters: a) P-CSCF b) I-CSCF c) S-CSCF d) HSS

After installating the operating system and the required software you should specify one proxy-value at first:
/etc/apt/apt.conf ACQUIRE::http::Proxy "http://user:password@server:port"

Now you have to install the following packets and according dependencies: - libxml2 - libxml-dev - ipsec-tools - subversion - ant {HSS only}

- Java 1.6 JDK or higher (http://java.sun.com) {HSS only} 15

- mysql

{HSS and I-CSCF only}

And then you have to set some variables and to complete some attributes in your configuration files:
/root/.subversion/servers completition of your proxy entries $:>export ANT-HOME=/usr/local/ant $:>export PATH=${PATH}:${ANT_HOME}/bin $:>export $JAVA_HOME=/usr/local/java (linked on current Java-version!)

You should insert these variables to your /root/.bashrc file to make it shell-known.
JAVA_HOME="/usr/local/java" ANT_HOME="/usr/local/ant" PATH="... :/usr(local/ant/bin:/usr/local/java/bin"

The next step is to create your OpenIMSCore directory:

$:>mkdir /opt/OpenIMSCore $:>cd /opt/OpenIMSCore $:/opt/OpenIMSCore>mkdir ser_ims

You can load the OpenIMSCore with subversion as follow:

$:/opt/OpenIMSCore>subversion checkout \\ http://svn.berlios.de/svnroot/repos/openimscore/ser_ims/trunk ser_ims

Now you are able to compile the source code for each CSCF by doing:
$:/opt/OpenIMSCore>cd ser_ims $:/opt/OpenIMSCore/ser_ims>make install-libs all $:/opt/OpenIMSCore/ser_ims>cd ..

16

At next you should check the network configuration. Open the file /etc/network/interfaces and check if it is similar and if each machine has its own IP address set according to zone-file configuration in the domain name server:
# This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5).

# The loopback network interface auto lo iface lo inet loopback

# The primary network interface auto eth0 iface eth0 inet static address 192.168.x.x network 192.168.x.0 netmask 255.255.255.0 # gateway (if neccessary)

a) P-CSCF If it is done be sure that the directory /opt/OpenIMSCore/ser_ims exist. Copy the files as follow into the directory /opt/OpenIMSCore by typing:
$:>cp /opt/OpenIMSCore/ser_ims/cfg/file /opt/OpenIMSCore/ file = pcscf.sh pcscf.cfg killser.sh stopser.sh

Take a look at the configuration file pcscf.cfg and edit it to your own preferences like here:
$:>vi /opt/OpenIMSCore/pcscf.cfg Note: P-CSCF-Address: 192.168.x.230 P-CSCF-SIP-Port: 5060

17

The different "modparam" entries are descripted in the document from Sebastian Schumann and the configuration in detail too.

To start your P-CSCF you have to type these commands:

$:>cd /opt/OpenIMSCore $:/opt/OpenIMSCore>./pcscf.sh

Then you should read some lines of status information. If your P-CSCF crashes take a look into the chapter "Trouble Shooting".

b) I-CSCF Check that the directory /opt/OpenIMSCore/ser_ims exist. Copy the files as follow to the directory /opt/OpenIMSCore by typing:
$:>cp /opt/OpenIMSCore/ser_ims/cfg/file /opt/OpenIMSCore/ file = icscf.sh icscf.cfg icscf.xml killser.sh stopser.sh

Take a look at the configuration file pcscf.cfg and edit it to your own preferences like here:
$:>vi /opt/OpenIMSCore/icscf.cfg Note: I-CSCF-Address: 192.168.x.250 I-CSCF-SIP-Port: 5060

The different "modparam" entries are descripted in the document from Sebastian Schumann and the configuration in detail too.

Take a look at the configuration file icscf.xml and edit it to your own preferences like here:
$:>vi /opt/OpenIMSCore/icscf.xml

18

Note: I-CSCF-Address:

192.168.x.250

I-CSCF-DIAMETER-Port: 3868 HSS-Address: 192.168.x.220

HSS-DIAMETER-Port: 3868

Now you have to check for mysql is running:

$:>pstree -p | grep mysql

If yes you have to add the I-CSCF-Database by typing:

$:>mysql -u root -p -h localhost < /opt/OpenIMSCore/ser_ims/cfg/icscf.sql Note: You need the "root"-password for mysql!

To start your I-CSCF you have to type these commands:

$:>cd /opt/OpenIMSCore $:/opt/OpenIMSCore>./icscf.sh

If the I-CSCF is running without configured mysql daemon some error messages will be displayed. Please read the chapter e) before running your I-CSCF. If your I-CSCF crashes take a look into the chapter "Trouble Shooting".

c) S-CSCF Check that the directory /opt/OpenIMSCore/ser_ims exist. Copy the files as follow into the directory /opt/OpenIMSCore by typing:
$:>cp /opt/OpenIMSCore/ser_ims/cfg/file /opt/OpenIMSCore/ file = scscf.sh scscf.cfg scscf.xml killser.sh stopser.sh

Take a look at the configuration file pcscf.cfg and edit it to your own preferences like here: 19

$:>vi /opt/OpenIMSCore/scscf.cfg Note: S-CSCF-Address: 192.168.x.240 S-CSCF-SIP-Port: 5060

The different "modparam" entries are descripted in the document from Sebastian Schumann and the configuration in detail too.

Take a look at the configuration file scscf.xml and edit it to your own preferences like here:
$:>vi /opt/OpenIMSCore/scscf.xml Note: S-CSCF-Address: 192.168.x.240 S-CSCF-SIP-Port: 5060 HSS-Address: 192.168.x.220

HSS-DIAMETER-Port: 3868

To start your S-CSCF you have to type these commands:

$:>cd /opt/OpenIMSCore $:/opt/OpenIMSCore>./scscf.sh

Then you should read some lines of status information. If your S-CSCF crashes take a look in the chapter "Trouble Shooting".

d) HSS You have to compile the source code for FHoSS by doing:
$:/opt/OpenIMSCore>mkdir FHoSS $:/opt/OpenIMSCore>subversion checkout \\ http://svn.berlios.de/svnroot/repos/openimscore/FHoSS/trunk FHoSS

$:/opt/OpenIMSCore>cd FHoSS/trunk $:/opt/OpenIMSCore/FHoSS/trunk>vi xsd/ZhDataType.xsd

Comment/uncomment the following lines according to your preferences: <xs:import namespace="http://www.w3.org/xml/1998/namespace"

20

schemaLocation="http://www.w3.org/2001/xml.xsd"/> <!-- <xs:import namespace="http://www.w3.org/xml/1998/namespace" schemaLocation="file:///opt/OpenIMSCore/FHoSS/xsd/xml.xsd"/> -->

$:/opt/OpenIMSCore/FHoSS/trunk>ant gen $:/opt/OpenIMSCore/FHoSS/trunk>ant compile $:/opt/OpenIMSCore/FHoSS/trunk>ant deploy $:/opt/OpenIMSCore/FHoSS/trunk>cd .. $:/opt/OpenIMSCore/FHoSS>mv trunk/* . $:/opt/OpenIMSCore/FHoSS>cd /

If it is done be sure that the directory /opt/OpenIMSCore/FHoSS/deploy exist. Take a look at the configuration file DiameterPeerHSS.xml and edit it to your own preferences like here:
$:>vi /opt/OpenIMSCore/FHoSS/deploy/DiameterPeerHSS.xml Note: Acceptor port: Bind address: 3868 192.168.x.220

I-CSCF-DIAMETER-port: 3868 S-CSCF-DIAMETER-port: 3868

In case you want to use more than one S-CSCF please add the following lines to your DiameterPeerHSS.xml below the existing lines including similar content:
<Peer FQDN="<your_scscf_name>.open-ims.test" Realm="open-ims.test" port="3868"/> <Auth id="167772xx" vendor="10415"/>

Note: If the FHoSS is running without configured mysql daemon some error messages will be displayed. Please read the next chapter before running your Home Subscriber Server.

e) Database "mysql" Two instances of your IMS testbed needs a mysql database in backround. To configure your mysql daemon you should read this chapter. At first check out if mysql database is installed including dev-packages. Please change your root passwort used in mysql!

21

1 FHoSS To insert the database change in the directory /opt/OpenIMSCore/FHoSS and type the following commands:
$:/opt/OpenIMSCore/FHoSS>mysql -u root -p -h localhost <scripts/hssdb.sql $:/opt/OpenIMSCore/FHoSS>mysql -u root -p -h localhost <scripts/userdata.sql

After configuring your interfaces you are able to run FHoSS by typing:
$:/opt/OpenIMSCore/FHoSS>cd deploy $:/opt/OpenIMSCore/FHoSS/deploy>./startup.sh

2 I-CSCF To insert the database change in the directory /opt/OpenIMSCore/ser_ims and type the following commands:
$:/opt/OpenIMSCore/ser_ims>mysql -u root -p -h localhost <cfg/icscf.sql

After configuring your interfaces you are able to run your I-CSCF by typing:
$:/opt/OpenIMSCore/ser_ims>./icscf.sh

Task 4: Configuration of IMS clients and realization of a voice call

The following open source IMS clients are currently available: UCT IMS Client http://uctimsclient.berlios.de/ IMS Communicator http://imscommunicator.berlios.de/

The following free IMS clients are available at the moment: OpenIC IMS Client http://www.open-ims.org/openic/ Mercuro IMS Client http://www.mercuro.net/

Steps of the Experiment

UCT Client This client is available for the Linux operating system. The following settings have be changed to connect the client to the IMS core: 22

Options - Preferences Profile Your name: Optional Name Presence: Disabled (if no Presence AS installed) Video Calling: Disabled IMS Public UID: sip:xxx@open-ims.test Private UID: xxx@open-ims.test Proxy CSCF: pcscf.open-ims.test:4060 Realm: open-ims.test Password: xxx QoS Strength: Mandatory QoS Type: Segmented Access Network: IEEE-802.11a Media 1st Codec: GSM 13,2 2nd Codec: PCMU 64 DTMF Events: SIP INFO Message Media Interface: Default Video Bandwidth: Low 40 IPTV Server: Not implemented yet IPTV HW Acc.: Ena XDMS Root: http://xcap.open-ims.test:8000/xcap-root (if XDMS installed) User: xxx Pass: xxx Option - Register registers the user. IMS Communicator (http://imscommunicator.berlios.de/) This program can run under Windows and Linux. 23

It requires the Java Media Framework (JMF) to be installed. The following settings have be changed to connect the client to the IMS core: Settings - Configure sip-ims IMC Client: true Private UID: xxx@open-ims.test Preffered Identity: xxx@open-ims.test Preferred Display Name: As you wish Access-Type: IEEE-802.11 rest as is sip Public SIP Address: sip:xxx@open-ims.test Name: Feel free Prefered SIP Port: 5060 Registrar Address: open-ims.test Registrar Port: 4060 R. Transport Prot: UDP DEFAULT DOMAIN and AUTHENTICATION: open-ims.test rest as is jain SIP Outbound Proxy: pcscf.open-ims.test:4060/udp In the appearing dialog as username enter sip:xxx@open-ims.test and as pass enter xxx. The client will register. Mercuro (http://www.mercuro.net/) This program runs under Windows. It requires the .NET Framework to be installed. A message will show during the installation if some requirements are not met. The following settings have be changed to connect the client to the IMS core: At start:

24

Display Name: Optional Name Public ID: sip:xxx@open-ims.test Private ID: xxx@open-ims.test Secret key: xxx

After starting (probably with error) Tools-Options from the menu Network (3rd tab) Defaults server pcscf.ope-ims.test Defaults port 4060 Registration should work with all provided types, MD5 akav1 is standard.

Note: For all clients, xxx is the dummy for username or password. The settings according the HSS setup have to be put there. The domain open-ims.test is an example domain. If DNS is not configured properly or the respective IP is used instead, the values must be changed accordingly.

References: Configuration IMS-Testbed; Stephan Massner, HfT Leipzig - University of Applied Sciences; June 2007

Conclusions for the Experiment / Lab Questions Answers to the Questions and Conclusions

25

Exercise 4: SIP protocol extensions used in NGN/IMS

Introduction
This laboratory exercise will require from trainee analyze SIP protocol used in NGN architecture to be able understand basic principles and procedures flows. Some network traffic dump will be shown, the trainee will have to discover valuable information and explain service behaviour. Basic extensions of IMS will be shown.

Average Duration
2 hours

Overview and Student Prerequisites

This chapter should help the student to understand how the IMS based NGN works. The lesson will introduces IMS extensions in theory. During the lesson, the student will understand important IMS extensions described in teory. The opensource IMS environment from FOKUS Fraunhofer OpenIMS will be analyzed and main IMS functions like P-CSCF, I-CSCF, S-CSCF it will handle explained form point of view their extensions compare to plain SIP severs.

Technical Requirements for the Experiment

IP infrastructure (L2/L3 switch, L3 router, Ethernet hub, PCs/Laptops, PDA) Basic IMS architecture platform (UE/with IMS clients, IMS servers, Application servers) Software tools for protocol analyses and IMS configuration

Learning Outcomes
This laboratory work will give basic advice to the student about laboratory IMS architecture core elements from perspective of IMS extensions. The training will include explanation about basic IMS extension of open source Open IMS core developed by FOKUS Fraunhofer. Of course OpenIMS implement all IMS extension but we show on sniffed SIP messages extensions in SIP headers as well as other extension of P-CSCF, I-CSCF, S-CSCF compare to ordinary SIP Sever (e.g. compare to OpenSIPs server) based on RFC 3261.

Description of the Experiment

Task 1: Design principles of IMS extensions in NGN architecture (theoretical)
See handbook and review the recommended chapters.

Task 2: Show a important extensions of IMS platform

Steps of the Experiment

Task 1: Design principles of IMS extensions in NGN architecture (theoretical)
See handbook and review the recommended chapters. 26

Task 2: Show a important extensions of IMS platform

Step 1: Start Open IMS core elements:

CSCFs
o o

Start pcscf.sh, icscf.sh and scscf.sh All these should run in parallel. Start FHoSS/deploy/startup.s

FHoSS
o

Step 2: Start OpenSIPS sever Step 3: Run IMS/SIP client Step 4: Sniff SIP messages from client to SIP servers or IMS severs

Open IMS core (Source: Fokus)

http://www.fokus.fraunhofer.de/en/fokus_testbeds/open_ims_playground/components/osims/cscfs/inde x.html

Proxy CSCF

Figure 1: Proxy CSCF In the current implementation of the Open Source IMS Core, the P-CSCF component is able to firewall the core network at the application level: only registered endpoints are allowed to insert messages inside the IMS network and the P-CSCF asserts the identity of the users. For this, upon registration, the P-CSCF establishes secured channels individually for each User Endpoint (UE) that it services. To keep track of the registered users, it has an internal reversed-registrar that is updated by intercepting the registration process and later by subscribing in User Agent Client (UAC) mode to the registration package at the S-CSCF and receiving notifications. The actual data is kept in a hash-table to allow fast retrieval. 27

For originating call signaling it generates unique charging vectors and inserts network and path identifiers that are needed for the correct further processing of the SIP messages. UE forged information that might lead to an attack is removed and/or corrected. After a successful registration process to an IMS home network, subsequent user messages are forwarded based on DNS information towards the requested IMS home network. Regarding NAT issues for the SIP signaling, in the outgoing direction, towards the user endpoints, it can act as a router by simply being active in both networks. Also, NAT traversal modules were adapted for the specific user location storage mechanisms. Features of the Open Source IMS P-CSCF: signaling firewall and user identity assertion (P-Preferred-Identity, P-Asserted-Identity header support) local registrar synchronization through "reg" event RFC 3680 Path header support Service-Route verification/enforcement Dialog statefulness and Record-Route verification/enforcement IPSec set-up using CK and IK from AKA Integrity-protection for authentication Security-Client, Security-Server, Security-Verify header support basic P-Charging-Vector support Visited-Network-ID header support NAT support for signaling NAT support for media through RTPProxy

Interrogating CSCF

28

Figure 2: Interrogating CSCF The Interrogating-CSCF (I-CSCF) has the role of a stateless proxy that, by using the indicated public identities of the caller or the callee, queries the Home Subscriber Server (HSS) and based on responses routes the message to the correct S-CSCF. It implements the Cx interface [1] of an I-CSCF to the HSS. Therefore it supports the required Diameter commands to locate the user-assigned S-CSCF or to select, based on capabilities, a new S-CSCF and check identities, roaming authorizations as specified in 3GPP TS 29.228. After receiving a successful answer for the Diameter query the I-CSCF forwards the SIP messages in a transactional mode. It is optimized for speed and minimalist state information is kept in it. To protect the home network, it has a firewalling capacity that only allows signaling messages coming from trusted networks through Network Domain Security (NDS). Features of the Open Source IMS I-CSCF: full Cx interface support (LIR, UAR) S-CSCF selection based on user capabilities Serial forking for forwarding to S-CSCF Visited-Network-ID header support and roaming permission verification Topology Hiding (THIG) Network Domain Security (NDS)

[1] 3GPP TS 29.228 IP Multimedia (IM) Subsystem Cx and Dx interfaces; Signaling flows and message contents; (Release 6)

Serving CSCF

Figure 3: Serving CSCF The S-CSCF implementation also communicates with the HSS using Diameter (over the Cx interface) to retrieve authentication vectors, update registration information and download the user profiles as specified in [1]. The S-CSCF can apply the user profile based initial Filter Criteria (iFC) to enforce specific SIP routing 29

rules. It implements support for carrying out the IMS Digest AKA version 1 [2]. Rather than generating authentication vectors it relies on the HSS for this task and compares these values to the ones calculated in the UE. For fast response times with minimal locking, the registrar of the S-CSCF has a complex structure based on hash-tables. The information that is required to relate a user identity to a physical UE is stored here and used further on for call routing. It also accepts subscriptions to registration state events and notifies the subscribers about changes in the registrar. Features of the Open Source IMS S-CSCF : full Cx interface support (MAR, SAR, PPR, RTR) Authentication through AKAv1-MD5, AKAv2-MD5 and MD5 Service-Route header support Path header support P-Asserted-Identity header support Visited-Network-ID header support Download of Service-Profile from HSS Initial Filter Criteria triggering ISC interface routing towards Application Servers "reg" event server with access restrictions Dialog statefulness

[1] 3GPP TS 29.228 IP Multimedia (IM) Subsystem Cx and Dx interfaces; Signaling flows and message contents; (Release 6) [2] A. Niemi, J. Arkko, V. Torvinen Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA), RFC 3310, September 2002

FOKUS Home Subscriber Server (FHoSS)

The Open Source IMS Core would be incomplete without a Home Subscriber Server. FOKUS developed an own prototype HSS, the FOKUS HSS (FHoSS) which is entirely written in Java and based upon Open Source software. The user data is kept inside a MySQL database. As its purpose in the Open Source IMS Core is that of a database, the FHoSS is targeted mainly towards conformance rather than performance. It is mostly a configurator for the Database Management System and the Diameter interfaces with the CSCFs and IMS application layer.

30

Figure 4: FOKUS Home Subscriber Server Protocol checks and Diameter command logic are implemented in the FHoSS based upon FOKUS own Java based Diameter stack. The FHoSS allows the generation of authentication vectors and it provides a HTTPbased management interface for easy management of user profiles and associated iFCs.

Figure 5: FHoSS User Profile

31

Figure 5: FHoSS Trigger Point

Features of the HSS: support for the 3GPP Cx Diameter application support for the 3GPP Sh Diameter application support for the 3GPP Zh Diameter application integrated simple AuC functionality Java Diameter Stack implementation web-based management console

Step 5: Show SIP header P-Preferred-Identity, P-Asserted-Identity header support P-Charging-Vector Visited-Network-ID header Path header support 32

Service-Route header support Different Authentication mechanism: AKAv1-MD5, AKAv2-MD5 and MD5 Initial Filter Criteria triggering

Conclusions for the Experiment / Lab Questions

After the experiment, the student will understand how IMS core elements are extended compare to ordinary SIP servers. This is based on previous session about IMS and complete knowledge based about IMS.. The IMS call session controllers are all based on the SIP Express Router (SER), a predecessor of the SIP AS OpenSIPS, which has been deeply explained in the first session. The students can in this session analyze the signalling and SIP extensions by comparing SIP messages on CSCFs and OpenSIPs as well as on client side with IMS clients.

Answers to the Questions and Conclusions

1) Extension SigComp (RFC 3320) defines: a) how to compress media packet for voice b) can be SIP used for media session setup c) how to compress SIP textual signaling data and shorten message d) describe offer/answer for SDP

2) Which IMS extension specifies the exchange cryptographic keys to be used for IPSec association? a) Media Authorization (RFC 3313) b) AKA MD5 (RFC 3310) c) Reg event Package (RFC 3680) d) SigComp (RFC 3320)

3) IMS used P headers (RFC 3455 and RFC 3325) to: a) obtaining information about the access network (cell ID) and the visited network (roamed network) and determining caller identity b) receive P-CSCF address 33

c) determine length of message body d) deliver presence status of UE via specific header

4) Which statement is incorrect for Media Authorization (RFC 3313)extension? a) extension ensures that only authorized media resources are used b) integrate Quality of Service admission control with call signaling c) provide authorization for open RTP ports to deliver media d) use policy control of the underlying network

5) IMS require that the participant reserve network resources before continuing with the session to assure: a) participant have to only use existing resource obtained by reservation mechanisms before the session establishment b) participant is using allocated resource obtained by reservation mechanisms after the session termination c) participant is registered to S-CSCF d) required media bandwidth is higher as was reserved in network resources

6) Routing PATH header is used in SIP messages: a) to find nearest HSS b) to deliver path to user profile folder c) to record the signalling path from P-CSCF to S-CSCF d) to register P-CSCF to S-CSCF

7) IMS extends SDP with several extensions but not for: a) grouping of media lines b) QoS and preconditions attributes c) Supplemental codec support d) describe UMTS version

8) Which standardization bodies in not using IMS in their specification?

34

a) ETSI TISPAN b) Softswitch Forum c) PacketCable d) ITU-T

35

Exercise 5: NGN protocols supporting AAA

5.1 Introduction
This laboratory exercise is focused on AAA protocols used in VoIP , especially in IMS platform. The goal is to analyze and understand these protocols and their usage in NGN architecture. In the first part of exercise, trainee will focus on theoretical principles of AAA functionalities and protocols bases, in the second part, practical experience will be acquired.

Theoretical part of exercise involves: Overview of DIAMETER protocol, comparison with RADIUS Overview of IMS platform Overview of AAA functionalities in IMS platform

Practical part of exercise (in Open IMS lab setup) involves : Set up and configure environment Generate and dump network traffic Analyze generated outputs

During the lesson, trainee will absolve following exercise tasks: 1) Analyze some interfaces and procedures used methods of Diameter protocol 2) Analyse of Diameter protocol, including its applications for HSS (extract and explain information from Diameter messages)

5.2 DIAMETER and RADIUS protocol overview

The Diameter protocol is designed to provide an Authentication, Authorization and Accounting (AAA) functions for various kinds of applications in network access scope, including IP mobility. The basic concept behind DIAMETER is to provide a base protocol that can be extended in order to provide AAA services to new access technologies. DIAMETER was derived from RADIUS protocol with some improvements required by new coming applications demanding different approach to AAA functionalities. It does not use the same RADIUS protocol data unit, but is backward compatible with RADIUS. Both protocols transfer user credentials in AVP messages, what makes them extensible for attributes and values.

36

Basic functionalities regarding VoIP scope:

Authentication register user to the VoIP networks Authorization allow user to use specific functions (calls to PSTN, etc.) Accounting - network resources usage, offline and online charging

RADIUS protocol scenerio

Uses UDP for message transport Client server architecture, so that only client may initiate a request May use several nodes, refered to as proxies Can not handle online charging Typical scenerio with SER, Open SER with RADIUS client and Free RADIUS server

DIAMETER protocol scenerio

Uses TCP for message transport Peer to peer architecture, so that every node may initiate a request May use several nodes, refered to as agents Can handle online charging Typical scenerio with SER in Open IMS platform with HSS as DIAMETER server

As can be seen from above points, DIAMETER is nowadays considered as leading AAA protocol in NGN architecture, namely in IMS platform (RADIUS is not used in IMS).

5.2.1 Diameter message format

Diameter protocol has defined several types of Diameter messages, which are identified by their command code. The structure of message is displayed on figure 2.1 and is described below:

37

messa ge Diamet er packet format :

Message field Version Message length

Description Indicate Diameter version Indicate message length (header + AVPs)

Command Flags

informs the receiver how each attribute must be handled Describe command message Application specific..) associated with a

Command Code

Application-ID

identifier

(AAA,

vendor

Hop-by-hop Id End-by-end Id

Matches the request and replays Detect duplicate requests

AVP format description:

Message field AVP Code

Description combined with the Vendor-Id field, identifies the attribute uniquely. AVP numbers 1 through 255 are reserved for backward compatibility with RADIUS. informs the receiver how each attribute 38

AVP Flags

must be handled AVP Length Indicates the number of octets in this AVP including the AVP Code, AVP Length, AVP Flags, Vendor-ID field (if present) and the AVP data. optional field, specifies a vendor

Vendor-ID

AVP-data

Data containing information specific to the attribute in variable length

Common messages defined in the Diameter base protocol:

Message name Abort-Session-Request Abort-Session-Answer Accounting-Request Accounting-Answer Capabilities-Exchanging-Request

Abbreviation ASR ASA ACR ACA CER

Command code 274 274 271 271 257

Capabilities-Exchanging-Answer Device-Watchdog-Request Device-Watchdog-Answer Disconnect-Peer-Request Disconnect-Peer-Answer Re-Auth-Request Re-Auth-Answer Session-Termination-Request Session-Termination-Answer STA

CEA DWR DWA DPR DPA RAR RAA STR STA

257 280 280 282 282 258 258 275 275

Some extended messages defined for SIP applications (RFC4740):

39

Message name User-Authorization-Request

Abbreviation UAR

Command code 283

User-Authorization-Answer Server-Assignment-Request Server-Assignment-Answer Location-Info-Request Location-Info-Answer Registration-Termination-Request Registration-Termination-Answer

UAA SAR SAA LIR LIA RTR RTA

283 284 284 285 285 287 287

5.3 Open IMS scenerio overview

The Open Source IMS Core consists of Call Session Control Functions (CSCFs), the central routing elements for any IMS signaling, and a Home Subscriber Server (HSS) to manage user profiles and associated routing rules. The central components of the Open Source IMS Core project are the Open IMS CSCFs (Proxy, Interrogating, and Serving) which are extensions to the SIP Express Router (SER), acting as SIP registrar, proxy or redirect server. As for the HSS, there is a FOKUS Home Subscriber Server (FhoSS), with DIAMETER engine included.

5.3.1 Diameter interfaces in IMS architecture

Diameter is used in the Sh and Cx interfaces defined by 3GPP for the IMS. The Sh and Cx Diameter applications extend the Base Diameter Command codes and AVPs to support the authentication and authorization functions required for the respective interfaces. Figure 3.1 depicts these interfaces in the IMS network along with the Dh and Dx interfaces.

40

The Sh interface operates between a SIP AS (application server) and the HSS network elements in the IMS. The Sh interface allows for: Download and update of transparent and non-transparent user data Request and send notifications on changes in the user data

The Dh interface is used between the AS and the SLF (subscriber location functions). It is used to get the address of the HSS serving an IMS Public User Identity or Public Service Identity. The Dh interface uses the same message set as the Sh interface.

The Cx interface operates between I-CSCF and HSS and between S-CSCF and the HSS. The Cx interface allows for: Location management procedures (exchange of location information) User data handling procedures (download user data stored in the server) User authentication procedures HSS implements the Diameter Multimedia server side of the Cx interface while the I-CSCF and the S-CSCF implement the Diameter Multimedia client side of the Cx interface. The Dx interface is used between the Call Session Control Function (CSCF) and the Subscriber Locator Function (SLF). It is used to get the address of the HSS serving an IMS Public User Identity or Public Service Identity. The Dx interface uses the same message set as the Cx interface. For charging, the 3GPP defines two types of interfaces. The online charging interface (Ro) is used for real-time billing while a service is occurring. Charging information can affect the service being rendered. The offline charging interface (Rf) is used to transfer charging information that will not affect, in real-time, the service being rendered. The Ro interface is based on the IETF defined Credit Control Application (RFC 4006[x]). It uses the Credit-Control command (CCR/CCA). The Rf interface is based on the accounting functionality of IETF-diameter base (RFC 3588[x]) and uses the accounting command (ACR/ACA).

5.4 DIAMETER Lab exercise

Exercise will focus on Sh Diameter interface between AS and HSS. For configuration setup, we will need : Installation of Open IMS (see http://www.openimscore.org/installation_guide for installation issues ). Korn shell (KSH) Seagull protocol generator (download from http://gull.sourceforge.net/doc/index.html) 41

SIP phone (SW installation) Network Traffic analyzer

Use the installed equipment to complete these tasks : Study and configure Seagull protocol generator for generating Diameter messages. Use it like an AS Generate some messages to establish a Diameter connection ( DPR, DPA, DWR , DWA) Generate some Diameter messages used on Sh interfaces,like request user data from the HSS and update user profile information in the HSS(Messages UDR,PUR,SNR,PNR) Explain message flow on Sh interface Dump some network traffic and analyze Diameter messages and their AVP s

42

Exercise 6: Media gateway control protocols (MEGACO/H.248)

Introduction
This laboratory lesson is focused on the MEGACO/H.248 protocol. Within this laboratory exercise the trainees will analyze Megaco protocol used in NGN architecture to be able to understand basic principles and procedures flows. Some network traffic dump will be shown, the trainee will have to discover valuable information and explain service behaviour. The structure and conception of this laboratory lesson provides to trainees the occasion to acquire the knowledge and experience in the area of Megaco protocol used in the NGN architecture from the theoretical and practical point of view. Task 1: Simulate and analyze Megaco message flow during basic call setup between two analogue subscribers Task 2: Simulate and analyze Megaco message flow during call setup between PSTN subscriber and SIP user Task 3: Simulate and analyze Megaco message flow during setup of three-party call conference

Average Duration
2 hours

Overview and Student Prerequisites

Students must have knowledge about: Basics of signalling in telecommunications networks Overview of NGN architecture Basics of Megaco protocol

Technical Requirements for the Experiment

There are no special HW requirements for this experiment. It is necessary to have: computer for the lecturer digital projector

Learning Outcomes
It is not easily feasible to perform simulations/observations of Megaco traffic from the real world network. The goal of this experiment is therefore to theoretically design possible message flow within given 43

scenario (with specified network setup and other preconditions). These flows are then compared to a correct flow the correct conversation between network entities is revealed by the teacher. Trainees then compare and discuss their solutions with the teacher. The outcome of this experiment is better understanding of how Megaco protocol works in various possible situations, how does a typical conversation look like.

Theoretical summary
MEGACO/H.248 is the latest industry standard protocol for interfacing between hosts and call agents called Media Gateway Controllers (MGC's) and Media Gateways (MG's) eg. an IP Telephone and the PSTN. The standard is the result of a unique collaborative effort between the IETF and ITU standards organizations. Megaco/H.248 is defined as master / slave architecture based protocol which is used for communication between MGC (Media Gateway Controller and one or more decomposed MGs (Media Gateways). Megaco/H.248 instructs an MG to connect streams coming from outside a packet or cell data network onto a packet or cell stream such as the RTP. The Gateway Control protocol permits the MGC to provide specialized services such as NAS services, Realtime fax services, conferencing services and IVR services by using the signal processing resources available at the MG. MEGACO provides: Control for various types of terminations Support for negotiation of call capabilities Multi user call scenarios Rich termination dynamics Quality of Service (QoS)and traffic measurement support Error reporting on protocol, call, capability and network failures When a gateway detects an off hook condition, it tells the gateway controller, which might respond with a command to instruct the gateway to put dial tone on the line and listen for DTMF tones indicating the dialled number. After detecting the number or identity of the called party, the gateway controller determines how to route the call and, where possible uses an inter-gateway signalling protocol such as SIP or even H.323. The connection model for the protocol Megaco/H.248 describes the logical entities, or objects, within the Media Gateway that can be controlled by the Media Gateway Controller. The main terms used in the connection model are terminations and contexts. A termination sources and/or receives one or more streams. A context is an association between terminations. There is a special type of context, the NULL Context, which contains all terminations that are not present in any other context and therefore not associated to any other termination.

44

Following figure shows the simple model of Megaco connection. Megaco allows putting several terminations into the context in order to create a communication between them.

RTP

T3
Termination

RTP

T4

Context

T2

RTP

Unidirectional flow

T1

RTP

E.g. considering call-waiting scenario Megaco allow one of the calling parties (terminations) leave the actual context and put it into the context with new caller, which was in the null context so far. By this way Megaco gives the possibility easily manage connections via moving the termination within and between contexts according to the actual communication needs. Megaco is more complex as MGCP, it provides higher flexibility in controlling of media flows. The main differences are shown in the table Megaco/H.248 MGCP

The call is represented by the terminations The call is represented by the end-points within the context within the connection Call typically includes any combination of Call typically can be point-to-point or point-tomedia and call conference multipoint Syntax is text or binary form Transport layer is UDP or TCP Formalized by IETF and ITU-T Syntax is text Transport layer is UDP Modified by vendors

Contexts
A context is an association between terminations. The context describes the topology (who sees whom) and the media switching parameters if more than two terminations are involved in the association.

Context attributes and descriptors

45

The attributes of contexts are: ContextID. The Topology Descriptor (who sees whom). The priority is used for a context in order to provide the MG with information about a certain preference for a context. Priority 0 is the lowest priority and a priority of 15 is the highest priority. An indicator for an emergency call is also provided to allow a preference handling in the MG. An indicator for an IEPS call is provided to allow the features and techniques of E.106 to be achieved. A Context Attribute Descriptor that enables extra context attributes to be defined by using the packages extension mechanism.

Creating, deleting and modifying contexts

The protocol can be used to create contexts and modify the parameter values of existing contexts. The protocol has commands to add terminations to contexts, subtract them from contexts, and to move terminations between contexts. Contexts are deleted implicitly when the last remaining termination is subtracted.

Terminations
A termination is a logical entity on a MG that sources or receives media and control streams. Terminations represent streams entering or leaving the MG (for example, analog telephone lines, RTP streams, or MP3 streams). A termination may have more than one stream, and therefore a context may be a multi-stream context. Audio, video, and data streams may exist in a context among several terminations.

Termination ID
Terminations are referenced by a TerminationID, which is a schema chosen by the MG. TerminationIDs of physical terminations are provisioned in the Media Gateway.

Packages
Different types of gateways may implement terminations that have a lot of different characteristics. In order to support many termination variations protocol allows terminations to have optional properties, events, signals and statistics implemented by MGs. These options are grouped into packages, and typically a termination realizes a set of such packages.

Termination properties and descriptors

Terminations have properties. Most properties have default values, which are explicitly defined in the protocol specification or in a package or set by provisioning. Related properties are grouped into descriptors. When a termination is added to a context, the value of its properties can be set by including the appropriate descriptors as parameters to the Add Command. The following table lists all of the possible descriptors and their use. Not all descriptors are legal as input or output parameters to every command.

Descriptor name Modem Mux

Description Identifies modem type and properties when applicable. (Note) Describes multiplex type for multimedia terminations (e.g.
46

Descriptor name

Description H.221, H.223, H.225.0) and terminations forming the input mux.

Media TerminationState Stream Local Remote LocalControl Events EventBuffer Signals Audit Packages DigitMap

A list of media stream specifications (see 7.1.4). Properties of a termination (which can be defined in packages) that are not stream specific. A list of Remote/Local/LocalControl Descriptors for a single stream. Contains properties that specify the media flows that the MG receives from the remote entity. Contains properties that specify the media flows that the MG sends to the remote entity. Contains properties (which can be defined in packages) that are of interest between the MG and the MGC. Describes events to be detected by the MG and what to do when an event is detected. Describes events to be detected by the MG when event buffering is active. Describes signals (see 7.1.11) applied to terminations. In Audit commands, identifies which information is desired. In AuditValue, returns a list of packages realized by the termination. Defines patterns against which sequences of a specified set of events are to be matched so they can be reported as a group rather than singly. In ServiceChange, what, why ServiceChange occurred, etc. In Notify or AuditValue, report of events observed. In Subtract and Audit, report of statistics kept on a termination or stream. Specifies flow directions between terminations in a context. Contains properties (which can be defined in packages) that affect the context as a whole Contains an Error Code and optionally error text; it may occur in command replies and in Notify requests.

ServiceChange ObservedEvents Statistics Topology ContextAttribute Error

NOTE Modem Descriptor has been deprecated in ITU-T Rec. H.248.1 version 2 (05/2002).

Commands
All Megaco/H.248 messages are in the format of ASN.1 text messages. Megaco/H.248 provides a series of commands to manipulate logical entities of the protocol connection model, terminations and contexts. The following is a list of the commands: 1. Add - The Add command adds a termination to a context. The Add command on the first Termination in a Context is used to create a Context. 47

2. Modify - The Modify command modifies the properties, events and signals of a termination. 3. Subtract - The Subtract command disconnects a Termination from its Context and returns statistics on the Termination's participation in the Context. The Subtract command on the last Termination in a Context deletes the Context. 4. Move - The Move command atomically moves a Termination to another context. 5. AuditValue - The AuditValue command returns the current state of properties, events, signals and statistics of Terminations. 6. AuditCapabilities - The AuditCapabilities command returns all the possible values for Termination properties, events and signals allowed by the Media Gateway. 7. Notify - The Notify command allows the Media Gateway to inform the Media Gateway Controller of the occurrence of events in the Media Gateway. 8. ServiceChange - The ServiceChange Command allows the Media Gateway to notify the Media Gateway Controller that a Termination or group of Terminations is about to be taken out of service or has just been returned to service. ServiceChange is also used by the MG to announce its availability to an MGC (registration), and to notify the MGC of impending or completed restart of the MG. The MGC may announce a handover to the MG by sending it ServiceChange command. The MGC may also use ServiceChange to instruct the MG to take a Termination or group of Terminations in or out of service.

Description of the Experiment Task 1

Simulate successful call setup from one analogue device to another via 2 Media gateways controlled by single Media gateway controller using Megaco transactions. The network configuration for this scenario is on Fig. 1. On Fig.2 there is an empty frame for message flow which is to be filled by the trainees while the Fig.3 contains the correct Megaco message flow between MGC and MG1 and between MGC and MG2.

Figure 1

48

MG1

MGC

MG1

Off hook Dialing Answer

RTP stream

Figure 2 empty frame for message flow

Figure 3 correct message flow

Task 2
49

Simulate a call initiated by PSTN subscriber towards SIP User Agent via MG connected to PSTN exchange, MG is controlled by MGC. SS7 signalling goes through signaling gateway to MGC. MGC communicates with SIP UA using SIP messages and controls MG using Megaco transactions. Network configuration for this scenario is on Figure 4. The empty conversation frame is in Figure 5 while Figure 6 contains the correct message flow. The SS7 signalling messages are shown in red and SIP messages are shown in blue.

Figure 4

50

PSTN
IAM

MG

MGC

SIP UA

Invite Ringing ACM Answer ANM 200 OK ACK RTP Stream Hang up REL Bye Alerting

200 OK RLC

Figure 5 empty message flow frame

51

PSTN
IAM

MG
Add Reply

MGC

SIP UA

Invite Ringing ACM Modify Reply ANM 200 OK ACK RTP Stream Hang up REL Subtract Bye Alerting

Answer

Reply 200 OK RLC

Figure 6 correct message flow for task 2

Task 3
Simulate setting up three-party call conference. The network setup is depicted on Figure 7. Figure 8 contains empty message flow frame which should be filled in. The correct message flow is in Figure 9.

52

Figure 7

MG1
Off hook Dial tone Digits

MGC

MG2

MG3

Ringing Ring back Off hook

RTP Stream MG1 <-> MG2

RecvOnly Flash Dial tone Digits Ring back Ringing Off hook

RTP Stream MG2 <-> MG3

Flash

RTP Stream Conference MG1, MG2, MG3

Onhook

RTP Stream MG1 <-> MG3

Busy tone Onhook

Onhook

Figure 8 empty message flow frame 53

MG1
Off hook

MGC
Notify Reply Modify

MG2

MG3

Dial tone Digits

Reply

Notify Reply
Ringing

Modify
Ring back

Modify Reply Notify Reply Add

Off hook

Reply Add Reply

Modify Reply

Reply

RTP stream MG1 <-> MG2

Figure 9a correct message flow for task 3 - call setup between MG1 and MG2

54

MG1

MGC
Modify

MG2
Flash

MG3

RecvOnly

Modify Reply

Reply

Dial tone Digits

Notify Reply Modify Reply

Ring back Ringing

Modify Reply Notify Reply Add Reply Modify Reply RTP stream MG2 <-> MG3
Flash Off hook

Notify Add Reply Reply Add Reply Modify Reply Add Reply Modify Reply RTP stream (MG1,MG2,MG3)

Figure 9b correct message flow for task 3 - conference setup MG1, MG2, MG3 55

MG1

MGC
Notify Reply Subtract Reply Subtract Reply

MG2
Onhook

MG3

Subtract Reply RTP stream MG1 <-> MG3

Onhook

Notify
Busy tone

Reply Modify Reply Subtract Reply Notify Reply Subtract Reply

Onhook

Figure 9c correct message flow for task 3 - termination of conference

Steps of the Experiment Task 1

The call setup is marked by following events: 1) Subscriber A goes off-hook 2) Subscriber A dials number of subscriber B 56

3) Subscriber B hears ringing and answers the call 4) RTP stream between A and B is made up Analyze the situation and fill in Megaco messages in correct order to complete the message flow in the scheme (Fig.2), the correct flow is on Fig.3. After completing the message flow compare the trainees solutions with the correct solution (Fig. 3)

Task 2
The call setup and termination between PSTN subscriber and SIP user are depicted on Figure 5. There are however some messages missing. Its the Megaco messages between MGC and MG. Try to fill in the missing part of the communication which is divided into two phases: Call setup (from the initiation of the PSTN user until setting up the RTP stream between parties) Call termination (since SIP user hangs down until all procedures of correct call termination are completed)

After completing the message flow compare the trainees solutions with the correct solution (Fig. 6)

Task 3
Try to fill in the communication between MGC and MGs during the setup of a three-party conference which is marked by following events: a. User A (MG1) initiates a call to User B (MG2) who receives the call (RTP stream is established as in exercise 1). b. User B press flash hook and dials User C (MG3). c. User C answers the call d. Call goes flash hook again to connect User A and User C e. User A, User B and User C are in the call conference f. User B terminates the conf. call only A and C left in the conversation g. User C terminates the call

After completing the message flow compare the trainees solutions with the correct solution (Fig. 9)

Conclusions for the Experiment / Lab Questions

Conclusions contain finalization of obtained knowledge in form of discussions. Then teacher puts questions to students. This exercise should enhance the knowledge of the trainees with the deeper sense of the MEGACO protocol and its importance within the NGN architecture. 57

Examples of questions: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Where is used the MEGACO protocol and which elements are communicating with that? What are the two basic abstractions/terms relating to the Megaco model and what is their meaning? What are the commands specified in MEGACO protocol? At least how many Terminations must have one point-to-point connectivity? What is used to reference the Terminations? What is the limit for the number of terminations within one Context? What is null Context? Which options/characteristics are not included in Termination's Packages? Which command will send MG to announce its availability to MGC? What is the format of MEGACO messages?

58