02 ngn architecture design lab guide student

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


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.





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.


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


- MySQL Database

- Wireshark

4 Clients

Debian-Linux


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

};


type master;


allow-query { any; };

allow-transfer { none; };

notify yes;

};


type master;




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-update { key "rndc-key"; };

notify yes;

};

zone "107.168.192.in-addr.arpa" {

type master;

file "/etc/bind/open-ims.dnszone.rev";



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:


$:/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:


file = icscf.sh

icscf.cfg

icscf.xml

killser.sh

stopser.sh


$:>vi /opt/OpenIMSCore/icscf.cfg

Note: I-CSCF-Address: 192.168.x.250

I-CSCF-SIP-Port: 5060



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:


$:/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:


file = scscf.sh

scscf.cfg

scscf.xml

killser.sh

stopser.sh


20

$:>vi /opt/OpenIMSCore/scscf.cfg

Note: S-CSCF-Address: 192.168.x.240

S-CSCF-SIP-Port: 5060



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:


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



$:/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/


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:[email protected]

Private UID: [email protected]

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.


Settings - Configure

sip-ims

IMC Client: true

Private UID: [email protected]

Preffered Identity: [email protected]

Preferred Display Name: As you wish

Access-Type: IEEE-802.11

rest as is

sip

Public SIP Address: sip:[email protected]

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:[email protected] 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.


At start:

25

Display Name: Optional Name

Public ID: sip:[email protected]

Private ID: [email protected]

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



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


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.





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.


Task 1: Design principles of IMS extensions in NGN architecture (theoretical)


Task 2: Show a important extensions of IMS platform


Task 1: Design principles of IMS extensions in NGN architecture (theoretical)


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


• 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


33

• Service-Route header support

• Different Authentication mechanism: AKAv1-MD5, AKAv2-MD5 and MD5

• Initial Filter Criteria triggering


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.


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

message

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


Students must have knowledge about:

- Basics of signalling in telecommunications networks

- Overview of NGN architecture

- Basics of Megaco protocol


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 RTPRTP

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.


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


Off hook

Dial tone

Digits

Ring back

Ringing

Off hook

Flash

Dial tone

Digits


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


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


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


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. It’s 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)


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



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?

02 ngn architecture design lab guide student

Documents