1

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
2

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.
3

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 Optional: openssl if you would like to enable the TLS security
o 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
4

Step 3: Compile
ser_ims
o Do "make install-libs all" in ser_ims
o cd ser_ims
o make install-libs all
cd ..
If something breaks, you probably don't have all the prerequisites.
FHoSS
o cd FHoSS
o ant compile
o ant deploy
cd ..
Step 4: Configure the Environment
Notes:
o All the installation examples configured to work only on the local loopback and the default
domain configured as "open-ims.test".
o The MySQL access rights are set only for local access
o 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 A sample DNS zone file can be found in ser_ims/cfg/open-ims.dnszone
o Copy it to your bind configuration directory
o Edit named.conf and insert the file there (Would be great to also add reverse DNS entries)
o Restart the name server
o Test that the names are resolvable (don't forget about /etc/resolv.conf pointing to your
new DNS server!)
MySQL
o Run the SQL dumps (mysql -u root -p -h localhost < dump.sql):
New!!! "hssdb.sql" was replaced by "hss_db.sql" !!!
o mysql -u root -p -h localhost < ser_ims/cfg/icscf.sql
o mysql -u root -p -h localhost < FHoSS/scripts/hss_db.sql
o mysql -u root -p -h localhost < FHoSS/scripts/userdata.sql
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 cp ser_ims/cfg/*.cfg .
o cp ser_ims/cfg/*.xml .
o cp ser_ims/cfg/*.sh .

FHoSS
5

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 Start pcscf.sh, icscf.sh and scscf.sh
o All these should run in parallel.
o We love debugging, so by default they would stay in foreground.
o By default you should see periodically log messages with the content of the registrar and
with the opened diameter links
FHoSS
o Start FHoSS/deploy/startup.sh
o 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.
o Check the web interface on http://localhost:8080/
o 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
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
6

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
7

- 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:
8

user
group section
/etc/network/interfaces root root a)
etc/bind/named.conf root root b)
/etc/bind/open-ims.dnszone bind bind c)
/etc/bind/107.168.192.in-addr.arpa bind bind d)
/etc/udev/rules.d/z25_persistent-net.rules root root e)
/etc/hostname root root
f)
/etc/hosts root root g)
/etc/resolv.conf root root 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.
//
9

// 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;
10

};

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;
11

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;
12

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 ; 1 day
open-ims.test IN SOA localhost.open-ims.test.
root.localhost.open-ims.test. (
2009010101 ; serial
10800 ; refresh (3 hours)
900 ; retry (15 minutes)
604800 ; expire (1 week)
86400 ; minimum (1 day)
)
NS ns.open-ims.test.
NAPTR 10 50 "s" "SIP+D2T" "" _sip._tcp.open-ims.test.
NAPTR 10 50 "s" "SIP+D2U" "" _sip._udp.open-ims.test.
$ORIGIN open-ims.test.
13

ns A 192.168.x.253

_sip SRV 0 0 5060 icscf
_sip._tcp SRV 0 0 5060 icscf
_sip._udp SRV 0 0 5060 icscf

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

icscf A 192.168.x.250
scscf A 192.168.x.240
pcscf A 192.168.x.230
hss A 192.168.x.220

client1 A 192.168.x.201
client2 A 192.168.x.202

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

14

250 PTR icscf.open-ims.test.
240 PTR scscf.open-ims.test.
230 PTR pcscf.open-ims.test.
220 PTR hss.open-ims.test.

201 PTR client1.open-ims.test.
202 PTR 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
15

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}
16

- 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 ..

17

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
18


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
19

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:
20

$:>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"
21

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: 3868
Bind address: 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!

22

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:
23

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.
24

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:
25

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

26

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 open-
source 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.
27

Task 2: Show a important extensions of IMS platform

Step 1: Start Open IMS core elements:
CSCFs
o Start pcscf.sh, icscf.sh and scscf.sh
o All these should run in parallel.
FHoSS
o Start FHoSS/deploy/startup.s
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.
28

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

29

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
30

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.
31


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 HTTP-
based management interface for easy management of user profiles and associated iFCs.

Figure 5: FHoSS User Profile
32


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
33

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
34

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?
35

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

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.

37




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:

38


messa
ge
Diamet
er
packet
format
:

Message field Description
Version Indicate Diameter version
Message length

Indicate message length (header + AVPs)
Command Flags

informs the receiver how each attribute
must be handled
Command Code

Describe command associated with a
message
Application-ID Application identifier (AAA, vendor
specific..)
Hop-by-hop Id Matches the request and replays
End-by-end Id Detect duplicate requests

AVP format description:

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

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.
Vendor-ID

optional field, specifies a vendor
AVP-data Data containing information specific to the
attribute in variable length

Common messages defined in the Diameter base protocol:

Message name Abbreviation Command code
Abort-Session-Request ASR 274
Abort-Session-Answer ASA 274
Accounting-Request ACR 271
Accounting-Answer ACA 271
Capabilities-Exchanging-Request

CER 257
Capabilities-Exchanging-Answer CEA 257
Device-Watchdog-Request DWR 280
Device-Watchdog-Answer DWA 280
Disconnect-Peer-Request DPR 282
Disconnect-Peer-Answer DPA 282
Re-Auth-Request RAR 258
Re-Auth-Answer RAA 258
Session-Termination-Request STR 275
Session-Termination-Answer
STA
STA 275

Some extended messages defined for SIP applications (RFC4740):

40

Message name Abbreviation Command code
User-Authorization-Request

UAR 283
User-Authorization-Answer UAA 283
Server-Assignment-Request SAR 284
Server-Assignment-Answer SAA 284
Location-Info-Request LIR 285
Location-Info-Answer LIA 285
Registration-Termination-Request RTR 287
Registration-Termination-Answer RTA 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.






41

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)
42

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

43

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
44

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, Real-
time 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.
45

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.


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
within the context
The call is represented by the end-points
within the connection
Call typically includes any combination of
media and call conference
Call typically can be point-to-point or point-to-
multipoint
Syntax is text or binary form Syntax is text
Transport layer is UDP or TCP Transport layer is UDP
Formalized by IETF and ITU-T 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
T3
T1
T4 T2 RTP
RTP
RTP
RTP
Context
Unidirectional
flow
Termination
46

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 Description
Modem Identifies modem type and properties when applicable. (Note)
Mux Describes multiplex type for multimedia terminations (e.g.
47

Descriptor name Description
H.221, H.223, H.225.0) and terminations forming the input
mux.
Media A list of media stream specifications (see 7.1.4).
TerminationState Properties of a termination (which can be defined in packages)
that are not stream specific.
Stream A list of Remote/Local/LocalControl Descriptors for a single
stream.
Local Contains properties that specify the media flows that the MG
receives from the remote entity.
Remote Contains properties that specify the media flows that the MG
sends to the remote entity.
LocalControl Contains properties (which can be defined in packages) that are
of interest between the MG and the MGC.
Events Describes events to be detected by the MG and what to do when
an event is detected.
EventBuffer Describes events to be detected by the MG when event
buffering is active.
Signals Describes signals (see 7.1.11) applied to terminations.
Audit In Audit commands, identifies which information is desired.
Packages In AuditValue, returns a list of packages realized by the
termination.
DigitMap 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.
ServiceChange In ServiceChange, what, why ServiceChange occurred, etc.
ObservedEvents In Notify or AuditValue, report of events observed.
Statistics In Subtract and Audit, report of statistics kept on a termination
or stream.
Topology Specifies flow directions between terminations in a context.
ContextAttribute Contains properties (which can be defined in packages) that
affect the context as a whole
Error Contains an Error Code and optionally error text; it may occur
in command replies and in Notify requests.
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.
48

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
49


Figure 2 empty frame for message flow


Figure 3 correct message flow
Task 2
MG1 MGC MG1
Off hook
Dialing
Answer
RTP stream
50

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


51

Figure 5 empty message flow frame
RTP Stream
IAM
MG MGC SIP UA PSTN
Invite
Alerting
Ringing
ACM
200 OK
Answer
ANM
ACK
Hang up
Bye
REL
200 OK
RLC
52


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.

RTP Stream
IAM
MG MGC SIP UA PSTN
Add
Reply
Invite
Alerting
Ringing
Modify
ACM
Reply
200 OK
Answer
ANM
ACK
Hang up
Bye
REL
Subtract
Reply
200 OK
RLC
53


Figure 7
Figure 8 empty message flow frame
MG1 MGC MG2 MG3
RTP Stream MG1 <-> MG2
RTP Stream Conference MG1, MG2, MG3
RTP Stream MG1 <-> MG3
Off hook
Dial tone
Digits
Ring back
Ringing
Off hook
Flash
Dial tone
Digits
RTP Stream MG2 <-> MG3
Ringing
Off hook Ring back
RecvOnly
Flash
Onhook
Onhook
Busy tone
Onhook
54


Figure 9a correct message flow for task 3 - call setup between MG1 and MG2
MG1 MGC MG2 MG3
Add
Notify
Off hook
Notify
Reply
Reply
Modify
Dial tone
Notify
Digits
Reply
Reply
Modify Modify
Reply Reply
Ring back
Ringing
Off hook
Add
Reply
Reply
Modify
Reply
RTP stream MG1 <-> MG2
55


Figure 9b correct message flow for task 3 - conference setup MG1, MG2, MG3
MG1 MGC MG2 MG3
Notify
Reply
Flash
Modify
Reply Modify
RecvOnly
Dial tone
Reply
Digits
Modify
Reply
Ringing
Modify
Reply
Ring back
Notify
Reply
Off hook
Add
Reply
Modify
Reply
RTP stream MG2 <-> MG3
Flash
Notify
Reply
Add
Reply
Add
Reply
Add
Reply
Modify
Reply
Modify
Reply
RTP stream (MG1,MG2,MG3)
56


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
MG1 MGC MG2 MG3
Onhook
Reply
Notify
Reply
Subtract
Reply
Subtract
Reply
Subtract
Reply
RTP stream MG1 <-> MG3
Onhook
Busy tone
Modify
Reply
Notify
Reply
Subtract
Subtract
Reply
Reply
Notify
Onhook
57

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.
58


Examples of questions:

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