Mobile VoIP Server (NVS)

Nokia Siemens Networks
Mobile VoIP Server (NVS) and

MSC Server (MSS) SIP User
Guide
DN70398199
Issue 7-0
Nokia Siemens Networks Mobile VoIP Server (NVS)
and MSC Server (MSS) SIP User Guide
The information in this document is subject to change without notice and describes only the
product defined in the introduction of this documentation. This documentation is intended for the
use of Nokia Siemens Networks customers only for the purposes of the agreement under which
the document is submitted, and no part of it may be used, reproduced, modified or transmitted
in any form or means without the prior written permission of Nokia Siemens Networks. The
documentation has been prepared to be used by professional and properly trained personnel,
and the customer assumes full responsibility when using it. Nokia Siemens Networks welcomes
customer comments as part of the process of continuous development and improvement of the
documentation.
The information or statements given in this documentation concerning the suitability, capacity,
or performance of the mentioned hardware or software products are given "as is" and all liability
arising in connection with such hardware or software products shall be defined conclusively and
finally in a separate agreement between Nokia Siemens Networks and the customer. However,
Nokia Siemens Networks has made all reasonable efforts to ensure that the instructions
contained in the document are adequate and free of material errors and omissions. Nokia
Siemens Networks will, if deemed necessary by Nokia Siemens Networks, explain issues which
may not be covered by the document.
Nokia Siemens Networks will correct errors in this documentation as soon as possible. IN NO
EVENT WILL Nokia Siemens Networks BE LIABLE FOR ERRORS IN THIS DOCUMENTA-
TION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDI-
RECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUT NOT LIMITED
TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY
OR DATA,THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THE INFORMATION
IN IT.
This documentation and the product it describes are considered protected by copyrights and
other intellectual property rights according to the applicable laws.
The wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark
of Nokia Corporation. Siemens is a registered trademark of Siemens AG.
Other product names mentioned in this document may be trademarks of their respective
owners, and they are mentioned for identification purposes only.
Copyright © Nokia Siemens Networks 2010/6/12. All rights reserved
f Important Notice on Product Safety

Elevated voltages are inevitably present at specific points in this electrical equipment.
Some of the parts may also have elevated operating temperatures.
Non-observance of these conditions and the safety instructions can result in personal
injury or in property damage.
Therefore, only trained and qualified personnel may install and maintain the system.
The system complies with the standard EN 60950 / IEC 60950. All equipment connected
has to comply with the applicable safety standards.
The same text in German:

Wichtiger Hinweis zur Produktsicherheit
In elektrischen Anlagen stehen zwangsläufig bestimmte Teile der Geräte unter Span-
nung. Einige Teile können auch eine hohe Betriebstemperatur aufweisen.
Eine Nichtbeachtung dieser Situation und der Warnungshinweise kann zu Körperverlet-
zungen und Sachschäden führen.
Deshalb wird vorausgesetzt, dass nur geschultes und qualifiziertes Personal die
Anlagen installiert und wartet.
Das System entspricht den Anforderungen der EN 60950 / IEC 60950. Angeschlossene
Geräte müssen die zutreffenden Sicherheitsbestimmungen erfüllen.
2
Table of Contents
This document has 103 pages.
1 Summary of changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1 Changes in functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2 Changes in documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2 NVS functionality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1 SIP subscriber database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 Registration in NVS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.1 Registration in Application Server mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.2 Registration in Standalone Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3 Call handling in NVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.1 Call handling in Application Server mode . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.2 Call handling in Standalone Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3.3 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3.4 Domain lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3.5 Calling Line Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.4 Messaging in NVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.4.1 Messaging in Application Server Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.4.2 Messaging in Standalone Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.5 Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.6 Charging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.7 Control of supplementary services in NVS . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.8 SIP video telephony interworking support. . . . . . . . . . . . . . . . . . . . . . . . . . 55
2.9 Call Transfer support on SIP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
2.10 SIM-based authentication for NVS convergence . . . . . . . . . . . . . . . . . . . . 61
2.11 Early media handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
2.11.1 Communication of SDP on SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
2.11.2 Indication of early media on SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
2.12 SIP protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
2.13 NVS SIP interface, Standalone Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
2.14 NVS ISC interface, Application Server Mode . . . . . . . . . . . . . . . . . . . . . . . 81
2.15 NVS LDAP interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
2.16 Session Initiation Protocol in the MSC Server . . . . . . . . . . . . . . . . . . . . . . 86
2.17 BICC-SIP interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
2.18 Incoming CGR and SIP signaling variant selection . . . . . . . . . . . . . . . . . . 92
2.19 Reachability check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
2.20 Trunk Group ID (IETF RFC 4904) support . . . . . . . . . . . . . . . . . . . . . . . . . 98
3 Managing NVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Id:0900d80580652f5c 3
List of Figures
Figure 1 Network architecture of NVS working in application server mode . . . . . 10
Figure 2 The network architecture of NVS working in Standalone Mode . . . . . . . 11
Figure 3 Interfaces towards subscriber information related databases. . . . . . . . . 13
Figure 4 Client-server connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Figure 5 Registration in AS mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Figure 6 Registration in Standalone Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Figure 7 SIP to SIP call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Figure 8 SIP to Mobile Station (MS) call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Figure 9 MS to SIP call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Figure 10 SIP to PSTN call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Figure 11 PSTN to SIP call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Figure 12 SIP to SIP call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Figure 13 SIP to Mobile Station (MS) call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Figure 14 MS to SIP call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Figure 15 SIP to PSTN call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Figure 16 PSTN to SIP call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Figure 17 SIP messaging and SMS interworking in application server mode. . . . . 39
Figure 18 SIP messaging-SMS interworking in standalone mode . . . . . . . . . . . . . 42
Figure 19 UA-A calls MS-B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Figure 20 UA-A calls UA-B through ISUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Figure 21 UA-A sends message to UA-B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Figure 22 Supplementary services and affected SIP interfaces . . . . . . . . . . . . . . . 53
Figure 23 IMS-CS video call interworking. Call originates in the IMS . . . . . . . . . . . 56
Figure 24 IMS-CS video call interworking. Call originates in the CS . . . . . . . . . . . 57
Figure 25 Video call in the NVS Application Server, adding prefix based on the call
type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Figure 26 SIP-CS video interworking in standalone NVS solution . . . . . . . . . . . . . 59
Figure 27 CS-SIP video interworking in the standalone NVS solution . . . . . . . . . . 60
Figure 28 Video to Audio fallback due to the MGW on the user plane . . . . . . . . . . 60
Figure 29 SIP client without PRACK, precondition support, default configuration . 63
Figure 30 SIP client without PRACK, precondition support, unreliable SDP sending is
turned on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Figure 31 SIP client with PRACK support, without precondition support . . . . . . . . 65
Figure 32 SIP client with PRACK, with precondition support . . . . . . . . . . . . . . . . . 66
Figure 33 SIP client without PRACK, precondition support, default configuration . 68
turned on (send SDP immediately) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
turned on (send SDP early media detected). . . . . . . . . . . . . . . . . . . . . . 70
Figure 36 SIP client with PRACK, without UPDATE support . . . . . . . . . . . . . . . . . 71
Figure 37 SIP client with PRACK, with UPDATE support . . . . . . . . . . . . . . . . . . . . 72
Figure 38 PEM header usage on SIP-CS interworking point . . . . . . . . . . . . . . . . . 76
Figure 39 PEM header and ringback tone connection . . . . . . . . . . . . . . . . . . . . . . 77
Figure 40 Access and trunk network interfaces of NVS . . . . . . . . . . . . . . . . . . . . . 79
Figure 41 Access and Trunk Network interfaces of the NVS . . . . . . . . . . . . . . . . . 81
Figure 42 NVS executing originating services . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4 Id:0900d80580652f5c
Figure 43 NVS executing terminated services . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Figure 44 NVS originating SIP call from the CS domain towards the called party on
the ISC interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Figure 45 NVS terminating SIP call from the caller towards the CS domain on the ISC
interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Figure 46 LDAP interface of NVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Figure 47 LDAP protocol layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Figure 48 SIP and BICC in the 3GPP circuit-switched core network . . . . . . . . . . . 87
Figure 49 Interfaces of the MSC Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Figure 50 MSC Server network environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Figure 51 SIP CGR selection with Trunk Group ID . . . . . . . . . . . . . . . . . . . . . . . . 93
Figure 52 Trunk Group ID Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Id:0900d80580652f5c 5
List of Tables
Table 1 SIP message structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6 Id:0900d80580652f5c
Nokia Siemens Networks Mobile VoIP Server (NVS) Summary of changes
1 Summary of changes
1.1 Changes in functionality

Changes in functionality between release M14.5 and M14.4
No changes

Information concerning optional Trunk Group ID functionality and its impact on incoming
CGR and SIP signaling variant selection, and various NVS SIP, NVS ISC Access and
Trunk interfaces has been added.

No changes.
Changes in functionality between releases M14.2 and M14.1

The following functionality has been introduced:
• Call Transfer support on SIP
The Explicit Call Transfer (ECT) service enables a subscriber involved in a commu-
nication to transfer that communication to a third party.
• SIM-based authentication for NVS convergence
This feature enhances authentication with the implementation of Digest AKAv1 and
AKAv2.
Changes in functionality between releases M14.1 and M14.0

From this release on, the OPTIONS request can be used to check the reachability of the
remote SIP end.
1.2 Changes in documentation

Changes in documentation between issues 7-0 and 6-0
Feature 1451: BICC-SIP Interworking has been renamed to Feature 1451: IMS-CS
Interworking.
Troubleshooting information has been transferred to Troubleshooting DX MSC/MSS/DX
HLR.

The following section has been added:
• Trunk Group ID (IETF RFC 4904) support
The following sections have been updated:
• NVS functionality
• NVS SIP interface, Standalone Mode
• NVS ISC interface, Application Server Mode
• Session Initiation Protocol in the MSC Server
• MSS-MSS SIP interface
• Incoming CGR and SIP signaling variant selection
• NVS SIP Access interface
Id:0900d80580652f59 7
Summary of changes Nokia Siemens Networks Mobile VoIP Server (NVS)
• NVS ISC SIP Access interface

• NVS SIP trunk interface
• NVS ISC SIP trunk interface

Editorial changes have been made.

Editorial changes have been made.

Section Early media handling has been added to the document.
The company and product names have been changed according to the official Nokia
Siemens Networks portfolio.

The following sections have been added to the document:
• Call Transfer support on SIP
• SIM-based authentication for NVS convergence
The following sections have been modified:
• Configuring registration
• 'authentication parameters' has been removed from Step 'Set SIP Group Pro-
file.'
• A new step; 'Set SIP Authentication Profile.' has been added.
• Registration is unsuccessful
A new step; 'Check the default SIP Authentication Profile setting.' has been added.

The following sections have been added to the document:
• Incoming CGR and SIP signalling variant selection
• Reachability check
8 Id:0900d80580652f59
Nokia Siemens Networks Mobile VoIP Server (NVS) NVS functionality
2 NVS functionality
Nokia Siemens Networks Mobile VoIP Server (NVS) introduces the Session Initiation
Protocol (SIP) access interface and the SIP registrar functionality to the MSC Server
(MSS) product to provide voice connectivity for users who use the SIP. It provides mes-
saging interworking between the SIP and Global System for Mobile Communication
(GSM) \ Universal Mobile Telecommunication System (UTMS) Short Message Service
(SMS), and also supports end-to-end SIP services, such as instant messaging.
NVS is based on the MSS software, so it can provide the same services that the MSS
System offers. Therefore, NVS is able to provide GSM-related services, such as supple-
mentary services, network services or regulatory services to VoIP clients.
NVS used in Application Server Mode

NVS can be used as an Application Server for the IMS, where NVS is controlled by the
IMS Service Control Interface (ISC). The purpose of the ISC interface in IMS is to
provide an open interface to which different external Application Servers can be
attached. This enables flexibility compared to existing Circuit Switched mobile networks,
where specific Customized Applications for Mobile Network Enhanced Logic
(CAMEL) or Core Intelligent Network Application Protocol (CoreINAP) protocols are
used to provide service control interface. In Third Generation Partnership Project
(3GPP) IMS, ISC is based on SIP protocol.
The following figure shows the network architecture of the NVS working in Application
Server Mode:
Id:0900d80580652d04 9
NVS functionality Nokia Siemens Networks Mobile VoIP Server (NVS)
LDAP DNS SMSC SCP
DNS MAP
BSC/RNC
LDAP CAP/
INAP
IMS
A (BSSAP)/
domain IuCS (RANAP) BTS
IMR HLR
MAP over IP
(SIGTRAN)
Dx, Cx, Xs MAP over IP or
(DIAMETER) (SIGTRAN) TDM-based MAP
BICC,
S-CSCF ISC (SIP) SIP-T, ISUP C7 (ISUP)
Mg, Mj (SIP)
SIP
Mobile MSC GMSC
VoIP
S Multiaccess MSC Server Server
Server C7 (ISUP)
domain
SIP softphones
S H.248 SIGTRAN H.248 SIGTRAN Transit Switch
S
DSLAM ATM, IP C7 (ISUP)
SIP deskphones RTP/UDP/IP or TDM SIP-I (profile C)
MGW MGW PSTN/
ATM
Soft Switch
POTS
IP
S
IAD
Multiradio TDM
POTS terminals
Figure 1 Network architecture of NVS working in application server mode
When the SIP ISC interface is used from the NVS with the 3GPP-defined MSS function-
ality, it is possible to provide services for both fixed and mobile networks through a single
converged architecture. Additionally, it is also possible to offer VoIP calls, messaging
interworking between SMS and SIP messaging, as well as end-to-end SIP services (for
example, instant messaging directly between terminals). The NVS can also offer the
possibility to use the same IN services such as CAMEL pre-paid, or Virtual Private Num-
bering (VPN) service for SIP subscribers registered into the IMS, similarly as in the case
of GSM/UMTS subscribers. In this case, NVS provides flexible routing schemes to
enable the use of the same national numbering plans when both GSM/UMTS and SIP
subscribers are making calls.
10 Id:0900d80580652d04
NVS used in Standalone Mode

NVS can be used as a standalone solution to provide SIP access interface directly for
SIP subscribers to be able to utilize the same services that are currently offered for GSM
and UMTS subscribers. The standalone solution runs independently from the IMS and
there is no requirement for the operator to deploy IMS in order to provide the SIP inter-
face.
The following figure shows the network architecture of NVS working in standalone
mode:
LDAP DNS SMSC SCP
DNS MAP
BSC/RNC HLR
LDAP CAP/
INAP
A (BSSAP)/ MAP over IP

IuCS (RANAP) (SIGTRAN)
or
MAP over IP
TDM-based MAP
(SIGTRAN)
SIP Access SIP Trunk

interface Network C7 (ISUP)
BTS BTS
(3GPP/IETF) interface
(3GPP/IETF)
Mobile Mobile GMSC
VoIP MSC Server VoIP
S Multiaccess Server Server C7 (ISUP)
domain
SIP softphones
S
H.248 SIGTRAN H.248 SIGTRAN Transit Switch
S DSLAM
RTP/UDP/IP C7 (ISUP)
SIP deskphones ATM, IP
or TDM SIP-I (profile C)
MGW MGW PSTN/

ATM Soft Switch
POTS
S IP
IAD
Multiradio TDM
terminals
POTS
Figure 2 The network architecture of NVS working in Standalone Mode
Both solutions use the standard DX HLR (HLR) subscriber register product in order to
store SIP subscriber related information, such as Mobile Subscriber International
ISDN Number (MSISDN), Intelligent Network (IN) and supplementary service related
information. The HLR is also required in order to provide functionality for the SIP termi-
nating transactions, such as VoIP calls and messaging. The HLR does not need any
changes because of NVS.
Id:0900d80580652d04 11
Signaling protocols
NVS supports all the signaling protocols that are supported by MSS, for example the fol-
lowing protocols:
• ISDN user part (ISUP)
• Bearer-independent Call Control (BICC)
• SIP for ISDN User Part (SIP-I) and SIP for Telephone (SIP-T: a special configuration
of SIP-I)
• SIP for Media Gateway Control Function (MGCF)
Interworking between these protocols and the new NVS-specific SIP protocols are pos-
sible.
2.1 SIP subscriber database

One of the access types is fixed and mobile SIP phones. The main target of the solution
is to provide the SIP end user the same services that the current mobile subscribers
already benefit from.
Using the SIP subscriber database, you can get the International Mobile Subscriber
Identity (IMSI) of the subscribers who register to the NVS and SIP User Agent (SIP-
UA) identification by SIP uniform resource identifier (SIP URI). IMSI is necessary for
handling calls inside the NVS, while the SIP URI must be transformed to MSISDN
because the existing MSS-based soft switch routes calls based on MSISDNs.
The other main functionality of the SIP subscriber database is the storage of attributes.
Besides the SIP URI, the SIP subscribers need additional attributes compared to the
GSM subscribers. Since the role of the HLR is to store GSM subscription related data,
an additional database is needed as common storage for SIP-related additional data.
The SIP Subscribers Database stores these SIP-related attributes.
An LDAP server stores the SIP protocol related user data. LDAP is an internet standard
for accessing directory services, which describes how to construct and store information
about network users, applications, and data in a central directory. By adding a standard-
based (LDAP) database to the operator's network as a supplement to the HLR data-
base, the operator can store all the information necessary to handle SIP calls in their
network.
Instead of having a big new database substituting the HLR, the operator can just extend
the existing HLR with some additional SIP-related subscriber attributes. This way, an
already working system, the HLR does not need to be modified or upgraded. This makes
the introduction of SIP subscribers in the network easier.
In Application Server mode, overall service management is done in the Serving Call
State Control Function (S-CSCF), based on the initial filter criteria information that is
stored in the Home Subscriber Server (HSS). In case the criteria have been configured
to use NVS for INVITE and MESSAGE requests, the S-CSCF routes the request to the
NVS through the ISC interface.
NVS accesses the HLR to retrieve supplementary service and IN related information.
Also, NVS uses the HLR enquiry procedure to find out the VLR address or MSRN (rout-
ing) address to route terminating SIP or short messages and terminating VoIP or normal
voice calls.
This solution does not cause any new requirements for the HLR network element or for
the MAP interface if no Nokia Siemens Networks specific features, such as MultiSIM,
12 Id:0900d80580652d04
are used. This is achieved by the introduction of an additional external database, which
must provide LDAP towards the NVS/MSS, in order to retrieve SIP subscription related
information.
In Application Server mode, if a subscriber registers primarily into the IMS (S-CSCF),
but still services are provided from NVS functionality co-located within the MSS product,
IMS subscription data is also needed, which is located in User Mobility Server (UMS),
in addition to HLR and LDAP directory based subscription data.
In Standalone Mode, (in principle) MSS requires every SIP subscription in the network
to contain static information according to the LDAP schema defined by Nokia Siemens
Networks fetched at certain intervals through the LDAP interface. This information con-
sists, for example, of theAddress Of Record (AOR) of the SIP subscriber (that is, the
SIP Uniform Resource Identifier (URI) used by the SIP UA to register to the MSS),
user name and password for Hypertext Transfer Protocol (HTTP) digest authentica-
tion purposes, and other information needed by the MSS to simulate GSM/UMTS
behaviour towards other network elements.
The following figure shows both the MAP and the LDAP interfaces towards the required
subscriber information related databases or directories. Note that in AS mode, there is
no interface in the NVS towards UMS.
LDAP
Subscriber
database
LDAP
SIP
subscriptions
MAP
CS
subscriptions
NVS HLR
Figure 3 Interfaces towards subscriber information related databases

Each SIP subscription requires an individual IMSI as well as the E.164 address within
the Public Land Mobile Network (PLMN). In terminating transactions (for example,
Mobile Terminating SMS or Mobile Terminating Call), it is possible to use either the
specific allocated E.164 address directly or to use group address of MultiSIM hunting
group, if the functionality is active in the system, to complete the call or the SMS.
The LDAP directory has only the information that is additional to support SIP subscrib-
ers:
• IMSI of the subscriber
Used as key to the HLR database to obtain circuit switched related data for the sub-
scription. It is also used when registering (through location update procedure) in
order to handle routing within the network and within other services as similar as
possible to the GSM/UMTS network.
• SIP URI (logical name) of the subscriber
Used as key to obtain E.164 address related to the subsciption.
• E.164 address of the subscriber
• Hypertext Transfer/Transport Protocol (HTTP) digest authentication parameters
(user name, password or nonce)
• SIP-specific service data
Id:0900d80580652d04 13
The solution contains a client-server model. The client runs on the NVS side, while the
server runs on a separate hardware. The communication between client and server
occurs according to the LDAP protocol definitions, which is a layer above the Transmis-
sion Control Protocol/Internet Protocol (TCP/IP) connection between the remote sides.
This section describes the client implementation. The server can be any third party
LDAP server that works according to the LDAP RFCs.
The recommended server solution is described in the SIP Subscriber Database Users
Guide.
Each Call Processing Unit (SCPU) of the MSS has one running LDAP client.
The LDAP client can work in 'simple mode' by having one single permanent TCP con-
nection to an LDAP server, or it can work in redundancy mode by connecting to two
servers. The recommended solution is always the 'redundancy mode' solution. Without
this, indicators for high availability cannot be guaranteed.
In the redundant solution one connection is primary and the other is secondary. By con-
figuring a primary and a secondary server in the LDAP client with the JDM command, the
connection to both servers is built up immediately and the LDAP client can enter the
servers in high availabilty mode.
Figure Client-server connection shows the high availability solution with two separate
LDAP servers having the same database on each.
NVS
Primary LDAP
SCPU 1 Server
TCP
TCP
LDAP-client TCP
SCPU 2
LDAP-client
...
Secondary LDAP
SCPU n Server
TCP
TCP
LDAP-client TCP
Figure 4 Client-server connection

The secondary server is in a 'hot' state, running the same configuration, and having the
same database as that of the primary server. All service requests are made towards the
primary server. The secondary server is used only if the primary server fails.
One NVS can run more LDAP clients, one per each SIP Call Processing Unit (SCPU).
Each LDAP client has a separate TCP connection to the server. All the LDAP clients of
one NVS connect to the same LDAP server. Configuration takes place per switch basis
with the JDM command.
14 Id:0900d80580652d04
The LDAP client communicates with the server through the LDAP- Application Program-
ming Interface (API). It implements an LDAP v2 interface towards the servers.
Connection handling
Once the NVS unit starts up, the LDAP client tries to connect to the preconfigured
primary and secondary server. If nothing was configured, or the configuration data is not
valid, the client cannot connect to the server. In these cases an alarm is displayed by
the client in the NVS alarm system and also an error log is written.
The clients always try to use their primary connection. If there is any kind of failure in the
primary connection, the secondary connection is used for data retrieval.
To maintain the connection between the client and server, and to recover immediately
from a failed connection, the following supervisions are introduced:
Periodical supervision:
The LDAP client checks the connection availability periodically by sending dummy
requests to the server. If it finds a failed connection, it tries to reconnect immediately to
the same server. The current supervision timer is seven seconds.
Extra server supervision:
The connection can be down but the client does not notice the connection failure,
because the seven seconds period has not expired yet. The LDAP client at service
request (search) notices the problem and tries to reconnect to the server immediately.
Server unavailability:
If the configured server is down, the clients try to connect the server periodically. Con-
nection attempts are made in every ten seconds. As soon as the server becomes avail-
able and the periodic check succeeds, the LDAP clients connect to the server.
For related information, see Feature 1670: SIP Subscriber Database, Feature Descrip-
tion and section LDAP interface.
2.2 Registration in NVS
2.2.1 Registration in Application Server mode

When the NVS is working in Application Server (AS) mode, it accepts third-party regis-
tration from the S-CSCF and it provides standard GSM/UMTS features and services for
SIP subscribers.
NVS introduces the following new SIP ISC interfaces for the MSS:
• ISC Access interface
• ISC Network interface
These interfaces, illustrated in Figure Registration in AS mode, are typically used in the
private network. These interfaces are used by S-CSCF to communicate with the NVS in
order to originate and terminate service execution. In AS mode, NVS can be reached
through the public IP address and the Public Application Server Port of the NVS.
Subscriber data management

For description, see section SIP subscriber database.
Id:0900d80580652d04 15
Serving Profile Database (SPD)

The SPD in the MSS is a kind of VLR, with limited functionality. It is located in the SCPUs
and stores all the SIP user related data, like URI, password, and so on. The SPD is
linked to the VLR, and contains SIP-related data, while the VLR stores the standard
GSM-related data of the user. When the subscriber registers to the MSS, the SIP data
is downloaded from the LDAP and is stored in the SPD. GSM-related data comes from
the HLR and is stored in the VLR. Therefore, the relational data is distributed to different
units, which means that the management of user data is harmonized, minimising the
inconsistency of the SPD and VLR.
LDAP
MAP
HLR
NVS
ISC SIP ISC SIP

Access Network
interface
SIP UA
IMS
S-CSCF
Figure 5 Registration in AS mode
Registration
In case NVS acts as an Application Server, the main point of registration for the SIP User
Agent (UA) is the S-CSCF, not the MSS. This means that authentication is not executed
between the SIP UA and the MSS, but between the SIP UA and the S-CSCF. The S-
CSCF of the subscriber utilizes the initial Filter Criteria (iFC) stored within the UMS of
that particular subscriber, in order to determine whether third-party registration is
executed towards the NVS functionality through the ISC. When a third-party registration
is received from the IMS, SIP-specific user data is received from the external LDAP
server and CS-specific user data is received from the HLR.
Registrar/Registration functionality is defined in RFC 3261 SIP: Session Initiation Proto-
col.
For detailed description on the following use cases, see Feature 1673: NVS Registration
(Standalone Mode), Feature Description:
• Third-party registration
• Re-registration
• Deregistration, user-initiated
• Deregistration, network-initiated
16 Id:0900d80580652d04
Configuration
The basic configuration of NVS registration in AS mode is described in Feature 1673:
NVS Registration (Standalone Mode), Feature Activation Manual.
2.2.2 Registration in Standalone Mode

NVS can be used as a standalone solution to provide SIP access interface directly for
SIP subscribers to be able to utilize the same services that are currently offered for GSM
and UMTS subscribers. The standalone solution runs independently from the IMS and
there is no requirement for the operator to deploy IMS in order to provide the SIP inter-
face.
LDAP
HLR
SIP UA SIP
Access
NVS
Figure 6 Registration in Standalone Mode
In Standalone Mode, the User Agents (UAs) are directly connected to the NVS (MSS)
through Ethernet, Asymmetric Digital Subscriber Line (ADSL), Wireless Local Area
Network (WLAN), and so on. Direct connection means that there is no need for an S-
CSCF. However, it is likely that there is Proxy Call State Control Function (P-CSCF),
Session Border Controller (SBC) or some third-party SIP Proxy (for example,
outbound proxies) before the MSS. SBC is needed to ensure safe and co-ordinated
access to the SIP infrastructure. In case of standalone MSS with SIP access interface,
SBC can be located between the SIP UA (end user) and the MSS (acting as a SIP reg-
istrar).
The Standalone NVS can be reached via the Public IP address and the Public Port of
the NVS.
Subscriber data management

For description, see section SIP subscriber database.
Registration
SIP UAs register to the same MSS even when they are abroad. This means that no SIP-
level roaming is provided on system level (compared to the IMS P-CSCF). However, IP-
level roaming (for example, the use of the same SIP UA from different IP networks) is
supported and makes it possible to have, for example, the same E.164 address for
mobile-terminated calls, regardless of the used physical IP network.
From functionality point of view, it means that SIP UAs needs to have pre-configured
AOR information with the address of Registrar server, for example the address of MSS
(inter-SPD registration can be made only when the registrar address is changed in the
UA).
Id:0900d80580652d04 17
The registrar address can be either URI, FQDN which can be used by UA to resolve into
a usable IP address through the Domain Name System (DNS), or it can be a direct IP
address, presenting the address of the signaling unit in MSS; or the address of the SBC
when SBC is used. If DNS is used to resolve IP address of signaling unit, access to the
DNS server from SIP UA in IP layer must be provided. In case DNS resolves the SBC's
address, SBC eventually resolves the IP address of signaling unit of MSS. MSS acts as
a registrar towards the SIP UA (Registrar/Registration functionality is defined in RFC
3261 SIP: Session Initiation Protocol).
For detailed description on the following use cases, see Feature 1673, NVS Registration
(Standalone Mode), Feature Description:
• Registration without Authentication
• Registration with Authentication
• Re-registration
• Deregistration, user-initiated
• Deregistration, network-initiated
Configuration
The basic configuration of NVS registration in Standalone Mode is described in Feature
1673: NVS Registration (Standalone Mode), Feature Activation Manual.
2.3 Call handling in NVS
2.3.1 Call handling in Application Server mode

The following sections describe basic call scenarios.
18 Id:0900d80580652d04
SIP to SIP call
LDAP HLR
Orig Term
NVS NVS
ISC SIP ISC SIP ISC SIP

Access Network Access
interface
Optional Optional
MGW MGW
SIP UA-A SIP UA-B
IMS IMS
Originating Terminating
S-CSCF S-CSCF
IP
Blue lines show the signaling path, while the red line represents the user plane
path.
Figure 7 SIP to SIP call
The figure above shows a call scenario when the originating SIP user agent calls
another SIP user agent and both of them have the VoIP service enabled.
The use of the MGWs on the user plane is configurable in each NVS, so it is possible
for the user plane going through the MGW(s) or the SIP UAs to exchange Real-Time
Transport Protocol (RTP) traffic directly through the IP backbone.
If the user agents use the logical names (for example bob@operator.com) to address
each other, the LDAP server translates between the logical names and the MSISDN.
SIP to CS Network
Id:0900d80580652d04 19
SIP to MS call
LDAP
MSC Server
Orig BSSAP/
Nc, PSTN
NVS RANAP
GSM/UMTS
radio network
ISC SIP ISC SIP Nc, PSTN

Access Network
interface
Optional Mg GCS MGW

MGW (MGCF)
SIP UA-A
IMS
Originating MGW
S-CSCF
IP
Figure 8 SIP to Mobile Station (MS) call

This figure shows when an IMS subscriber calls a GSM/UMTS subscriber. In the basic
scenario, the originating NVS executes the originating VoIP services and leaves the
routing to the S-CSCF by sending the received call back to the S-CSCF. It is also
possible that the originating NVS makes ISC->CS interworking (dashed line).
The access network for GSM/UMTS is not detailed in the figure.
20 Id:0900d80580652d04
Mobile to SIP call
HLR
MSC Server
BSSAP/
Nc, PSTN Term
RANAP
GSM/UMTS NVS
radio network
Nc, PSTN ISC SIP ISC SIP

Network Access
interface
MGW GCS Mg Optional

(MGCF) MGW
SIP UA-B
IMS
MGW Terminating
S-CSCF
IP
Figure 9 MS to SIP call

This figure shows the case when a GSM/UMTS subscriber calls an IMS subscriber and
this IMS subscriber has VoIP services enabled. In the basic scenario the originating
MSS sends the call to the MGCF, which forwards the request to the IMS domain. Ter-
minating services are executed by the terminating NVS. It is also possible that the orig-
inating MSS sends the request directly to the NVS and in this case the terminating NVS
does the CS->ISC interworking.
Id:0900d80580652d04 21
SIP to PSTN call
LDAP
Orig PSTN
NVS PSTN
network
ISC SIP ISC SIP PSTN

Access Network
interface
Optional Mg GCS
MGW (MGCF)
SIP UA-A
IMS
Originating MGW
S-CSCF
IP
Figure 10 SIP to PSTN call
22 Id:0900d80580652d04
PSTN to SIP call
HLR
Nc, PSTN Term

PSTN NVS
network
Nc, PSTN ISC SIP ISC SIP

Network Access
interface
GCS Mg Optional
(MGCF) MGW
SIP UA-B
IMS
MGW Terminating
S-CSCF
IP
Figure 11 PSTN to SIP call
Efficient MGW resource usage

NVS can work in two modes from the user plane perspective:
• Call Mediation Node (CMN = Active): the user plane (for example, RTP traffic) does
not go through the MGW
• Normal mode using MGW (CMN = Inactive): the MGW handles the RTP traffic
CMN mode can be used when incoming and outgoing signaling is SIP. If there is a need
for signaling conversion (for example, from SIP to ISUP), the CMN mode is not possible,
because it would require the user plane to be converted (for example, from IP to TDM).
In CMN mode, it is still possible to provide services with the MGW (for example,
announcement). During these services, NVS switches to CMN Inactive mode and
reserves MGW resources. When the service is no longer needed, the MGW resources
are freed and the call continues in CMN mode.
For related information, see Feature 1671, NVS Call Handling (Application Server
Mode), Feature Description.
2.3.2 Call handling in Standalone Mode

The following sections describe basic call scenarios.
Id:0900d80580652d04 23
SIP to SIP call
LDAP HLR
SIP UA-A NVS NVS SIP UA-B

SIP
SIP Access Network interface SIP Access
Optional MGW Optional MGW
IP
backbone
Blue lines show the signaling path, while the red line represents the user plane
path. Dashed lines show alternative flows.
Figure 12 SIP to SIP call
The figure above shows a call scenario when the originating SIP user agent calls
another SIP user agent who is registered to the same network.
The use of MGWs on the user plane is configurable in each NVS, so it is possible for the
user plane going through the MGW(s) or SIP UAs to exchange RTP traffic directly
through the IP backbone.
It is not mandatory to use the SIP protocol between the network elements ISUP, BICC
and other protocols can be also used however, in this case the MGW is always needed
for user plane protocol conversion.
If the user agents use the logical names (for example bob@operator.com) to address
each other, the LDAP server translates between the logical names and the MSISDN.
SIP to CS Network
24 Id:0900d80580652d04
SIP to MS call
HLR
SIP UA-A NVS MSC Server

BICC/ISUP/ BSSAP/
SIP Access SIP/SIP-I/SIP-T RANAP
GSM/UMTS
radio network
MGW MGW
Figure 13 SIP to Mobile Station (MS) call
This figure shows the case when the SIP user calls a GSM/UMTS subscriber. The
protocol between the network elements can be any MSS-supported protocol (for
example, ISUP or SIP-I).
Since the user plane differs on the access and network side, the MGW is mandatory on
the user plane to handle the user plane protocol conversion (for example RTP <-> TDM).
MS to SIP call
HLR
MSC
Server NVS SIP UA-A
BSSAP/ BICC/ISUP/
RANAP SIP/SIP-I/SIP-T SIP Access
GSM/UMTS
radio network
MGW MGW
Figure 14 MS to SIP call
Id:0900d80580652d04 25
This figure shows the case when a GSM/UMTS subscriber calls a SIP subscriber. The
protocol between the network elements can be any MSC Server supported protocol (for
example ISUP, SIP-I).
SIP to PSTN call
SIP UA-A NVS
SIP Access ISUP/SIP-I/SIP-T PSTN

network
MGW
Figure 15 SIP to PSTN call
When the SIP UA calls a PSTN number and NVS makes the conversion between the
signaling protocols according to 3GPP TS 29.163 Interworking between the IP Multime-
dia (IM) Core Network (CN) subsystem and Circuit Switched (CS) networks and the
MGW handles the user plane protocol conversion. In addition to ISUP, SIP-I can be
used towards PSTN softswitches.
PSTN to SIP call
NVS SIP UA-B
PSTN ISUP/SIP-I/SIP-T SIP Access

network
MGW
Figure 16 PSTN to SIP call
Efficient MGW resource usage

NVS can work in two modes from the user plane perspective:
• Call Mediation Node (CMN = Active): the user plane (for example, RTP traffic) does
not go through the MGW
• Normal mode using MGW (CMN = Inactive): the MGW handles the RTP traffic
CMN mode can be used when incoming and outgoing signaling is SIP. If there is a need
for signaling conversion (for example, from SIP to ISUP), the CMN mode is not possible,
because it would require the user plane to be converted (for example, from IP to TDM).
26 Id:0900d80580652d04
In CMN mode, it is still possible to provide services with the MGW (for example,
announcement). During these services, the NVS switches to CMN Inactive mode and
reserves MGW resources. When the service is no longer needed, the MGW resources
are freed and the call continues in CMN mode.
For related information, see Feature 1671, NVS Call Handling (Standalone Mode),
Feature Description.
2.3.3 Services
The aim of the VoIP convergence is to enable the subscriber to use the services inde-
pendently from the access method (that is, control and user plane protocols).
Since S-CSCF is not intended to run the GSM/UMTS/PSTN-like services, NVS is used
as an application server for IMS network. NVS running in application server mode is con-
nected to S-CSCF through the ISC (SIP) interface and it executes the originating or ter-
minating services.
g NVS has integrated MGCF functionality as well, which is described in Feature 1331:
Session Initiation Protocol in the MSC Server, Feature Description.
Since NVS is based on the MSS, it uses all the current functionality of this product, so
the existing services can be used by subscribers using SIP as access signaling.
For more information on the services that NVS offers for S-CSCF through the ISC inter-
face, see section Services in Feature 1671, NVS Call Handling (Application Server
Mode), Feature Description and in Feature 1671, NVS Call Handling (Standalone
Regulatory services
Regulatory services include emergency calls, number portability, lawful interception,
and Carrier Selection (Equal Access). For detailed information on these services, see
section Regulatory service in Feature 1671, NVS Call Handling (Application Server
Mode), Feature Description and in Feature 1671, NVS Call Handling (Standalone
Supporting emergency calls

SIP subscribers in NVS are allowed to initiate VoIP calls using regulated numbers (for
example, '112' or other country-specific numbers) and operator-defined URIs (for
example, police).
NVS receives the special number requesting an emergency service and, based on the
internal configuration, NVS selects a proper routable E.164 address to contact the emer-
gency centre. In addition to this, the location information can also be delivered based on
the configuration stored in the LDAP directory on subscriber basis. Note that the real
location information of the SIP subscriber is not stored in the directory, only the informa-
tion defined in the configuration phase. This can lead to situations where the actual
location of the subscriber is not known.
• Creating an emergency list:
By default, NVS handles 112, 911, and 08 as emergency numbers. This means that
if the user dials these numbers, the call is handled as an emergency call. This has
an effect on the authentication and authorization. Additionally, the JHP command
can be used to add additional numbers or emergency strings. This way it is possible
to extend the initial list. If an emergency string is added to the list, only the user part
needs to be added to avoid the user entering a wrong domain part. For example, if
Id:0900d80580652d04 27
'police' is added to the list, the emergency call is started if the user sends, for
example, police@example.com or police@operator.com. In addition to this, more
emergency numbers can be defined in the preanalysis but if the authentication fails,
the call will fail since the preanalysis comes after the authentication.
• Allowing SIP emergency calls in NVS without authentication:
In accordance with national regulations, the operator can decide whether an emer-
gency call should be authenticated.
The PRMT_EMRG_CALL_WO_AUTH parameter can be used either to allow or to reject
SIP emergency calls in NVS without authentication.
• Allowing SIP emergency calls in NVS if SIP subscriber not found in database:
The PRMT_EMRG_CALL_NOT_REG parameter can be used to allow a SIP emer-
gency call if the SIP subscriber is not found in the database.
When this parameter is set and the user is not in the SPD/VLR, NVS first tries to
download the subscriber data from the LDAP server to get the preconfigured
location but if this fails, the call still continues.
When the call is considered as an emergency call, the operator can additionally set
whether to start:
• an emergency setup (no dialling preanalysis is executed)
• a normal call setup where the received number is in the Called Party Number
parameter (a dialling preanalysis or an extended preanalysis is executed). In this
case the operator can set the call characteristics to the emergency call in the
preanalysis.
Please note that if the emergency number is configured only in preanalysis, the call
can fail because of the missing user in SPD or because of failed authentication since
the preanalysis is executed only after user authorization and authentication. It is rec-
ommended to add these numbers to the emergency list.
• Configuring the location of the user in LDAP:
The location of the user can be configured in the LDAP server. It can be fixed or can
be dynamically updated by any 3rd party software. However, it is assumed currently
that the location ID in the LDAP is a preconfigured number.
The Location ID parameter can be used to configure the different locations of the
user. This Location ID is translated to a Global Cell ID (CGI) in NVS based on the
operator's configuration. If the Location ID parameter is missing from LDAP or there
is no CGI assigned to the Location ID in NVS, the CGI configured to the Group
Profile will be used.
The commands of the JI command group can be used to manage the Location ID
and CGI mapping.
Provisioning VoIP services

To provide a VoIP service for a certain subscriber, the user needs to be provisioned to
the network. This means that
• the user needs to be created in the HLR with a new IMSI,
• an MSISDN number needs to be assigned,
It is recommended to use single numbering so that all the basic services use the
same MSISDN.
It is also recommended to give the MSISDN in international format in LDAP and not
to add the “+” visual character to the MSISDN. NVS always treats the retrieved
MSISDN as an international number.
• service-related parameters, for example CLIP or CF, need to be provisioned, and
28 Id:0900d80580652d04
• the user needs to be created in LDAP with the same E.164 number and IMSI, and
a SIP URI needs to be assigned to identity the user.
The following SIP URIs are accepted:
• username@domain (for example, alice@example.net)
• E.164@domain (for example, 1234567@example.net)
If the second format is used, the E.164 is recommended to be the provisioned
MSISDN number.
Notes for Standalone mode:
A password and a user name can be assigned to the users. If the password is not pro-
visioned, NVS skips the authentication. If the user name is not filled in, the user name
for the authentication will be the user part of the SIP URI.
Notes for Application Server mode:
LDAP provisioning is needed also when NVS works as an Application Server. In later
releases, the LDAP interface can be replaced with the Sh interface towards HSS.
It is recommended to create the user also in HSS and assign the user the same SIP URI
stored in LDAP. S-CSCF will use this SIP URI during third party registration.
2.3.4 Domain lists

The operator can configure the following domain lists in the NVS:
• Home Domain list (JH command group)
• Denied Domain list (JH command group)
The following sections describe the usage of these lists.
For related information, see section Configuring domain lists.
Registration
When a REGISTER message is received, NVS checks whether the domain part of the
user identity (received in the To SIP header) is on the Home Domain list. If yes, the reg-
istration continues with the LDAP query. If not, the registration is denied with the 403
Forbidden response.
The denied list is not checked during registration.
Call handling
NVS uses the Home and Denied domain lists only when the called or calling party
identity is a SIP URI containing a logical identity (for example, bob@domain.com). In
case of E164@domain type of numbers, these lists are not used.
Access interface:
When an INVITE message is received on the Normal Access or the ISC Access inter-
face and the called party is identified by the logical SIP URI, NVS can query LDAP for
the E164 number of the called party:
• If the domain part of the called party address (received in the Request URI SIP
header) is on the home domain list, the NVS tries to resolve the logical name (user-
part@domain) to an E164 number through the LDAP server. If it fails, the call will be
rejected. This means that all users who have logical names need to be configured
to the LDAP server.
Note that if the needed NVS can be configured to make an additional LDAP query
with the domain part (which is in the home domain), the resolution with the SIP URI
Id:0900d80580652d04 29
will fail. This MSISDN will be used to route the call inside the NVS but will not be
seen on the SIP interfaces.
• If the domain part of the called party address is on the Denied list, the call will be
rejected.
• If the domain part of the called party address is not on the Denied or Home domain
list, the call is considered as a call to a foreign domain. In this case, the NVS
requests the LDAP with the domain part of the logical SIP URI (for example,
operator2.com). If this query fails, the call will be rejected. To make the LDAP reso-
lution successful, the operator need to add these allowed foreign domains (for
example, the operator2.com without the user part) to the LDAP server, and fill the
MSISDN parameter for the given SIP URI. This MSISDN will be used to route the
call inside the NVS, added to CDRs and reported towards IN (SCP). This is a dummy
MSISDN number that can be different or can be the same for different foreign
domains.
Note:
• The other LDAP parameters of these foreign domains are not used.
• When the called number is in E164@domain format (independently from the
existence of the user=phone parameter), LDAP query is not done.
Trunk/Network interfaces:
When an INVITE is received on the Normal Trunk/Network or the ISC Trunk interface
(for example, terminating service execution on the ISC interface), and the called party
is identified by the logical SIP URI, NVS can query LDAP for the E164 number of the
called party:
part@domain) to an E164 number through the LDAP server. If it fails, the call will be
rejected. This means that all users who have logical names need to be configured
to the LDAP server.
• If the domain part of the called party address is on the Denied list, the call will be
rejected.
list, the call is considered as a call to a foreign domain and the LDAP is queried with
the domain part of the logical SIP URI of the Request URI. If this resolution fails, the
call will be rejected.
In addition to these, NVS also tries to figure out the E164 address of the calling party.
This is not necessarily needed for a successful call setup but it is useful if some IMS-CS
conversion is needed (for example, logical addresses cannot be shown as a CLI for CS
terminals). When NVS receives an INVITE message and neither the From nor P-
Asserted-Identity SIP header contains an E.164 address, the following functional-
ity will be executed:
• If the domain part of the From/P-Asserted-Identity is on the Home domain list,
the LDAP server is requested with the full logical SIP URI. If this is successful, the
receive number will be used as E.164 CgPN. If the resolution fails, the E.164 CgPN
will be left empty.
• If the domain part of the From/P-Asserted-Identity is on the Denied domain
list, the request will be rejected.
• If the domain part of the From/P-Asserted-Identity in not on the Home and
Denied domain lists, the LDAP will be requested with the domain part of the logical
30 Id:0900d80580652d04
SIP URI. If this is successful, the receive number will be used as E.164 CgPN. If the
resolution fails, the E.164 CgPN will be left empty.
Please note the following:
• If the P-Asserted-Identity header is received, it is used instead of the From
header.
• If there is no P-Asserted-Identity header and the From header has an 'invalid'
top level domain (for example, anonymous@anonymous.invalid), the LDAP will not
be requested for resolution and the CgPN will be left empty.
Call diversion
In SIP the call diversion means that the succeeding party sends a 302 Temporarily
Unavailable or a 301 Permanently Unavailable response which contains the
forwarded to address. This address can be a logical SIP URI. If the domain part of the
logical SIP URI is not on the Home domain list, the call diversion will not be executed to
the new address, otherwise the LDAP will be queried with the full logical SIP URI.
Note that there are several other configuration parameters which control call diversion.
Instant messaging
NVS uses the Home and Denied domain lists only when the called or calling party
identity is a SIP URI containing a logical identity (for example, bob@domian.com). In
case of the E164@domain type of numbers, these lists are not used.
Access interface:
When a MESSAGE (Instant message) is received on the Normal Access or the ISC
Access interface and the called party is identified by the logical SIP URI, NVS can query
LDAP for the E164 number of the called party:
part@domain) to an E164 number through the LDAP server. If it fails, the whole
operation will be rejected.
• If the domain part of the called party address is on the denied list, the instant
message operation will be rejected.
list, the instant message needs to be forwarded to a foreign domain (for example,
towards a 3rd party messaging system). In this case, the NVS requests the LDAP
with the domain part of the logical SIP URI. If this query fails, the operation will be
rejected. This MSISDN will be used during instant messaging related service exe-
cution, will be added to CDRs, and will be reported towards IN (SCP).
Trunk/Network interfaces:
When a MESSAGE is received on the Normal Trunk/Network or the ISC Trunk interface
(for example, terminating service execution on ISC interface), and the called party is
identified by the logical SIP URI, NVS can query LDAP for the E164 number of the called
party:
header) is on the Home domain list, the NVS will try to resolve the logical name
(userpart@domain) to an E164 number through the LDAP server. If it fails, the oper-
ation will be rejected. This means that all users who have logical names need to be
configured to the LDAP server.
Id:0900d80580652d04 31
• If the domain part of the called party address is on the Denied list, the operation will
be rejected.
lists, the call is considered as a message towards a foreign domain and the LDAP
is queried with the domain part of the logical SIP URI of the Request URI. If this res-
olution fails, the operation will be rejected.
In addition to these, NVS also tries to figure out the E164 address of the calling party.
This is not necessarily needed for a successful call setup but useful if some IMS-CS con-
version is needed (for example, logical addresses cannot be shown as a CLI for CS ter-
minals). When NVS receives a MESSAGE and none of the From or P-Asserted-
Identity SIP headers contains an E.164 address, the following functionality will be
executed:
• If the domain part of the From/P-Asserted-Identity is on the Home Domain List, the
LDAP server is requested with the full logical SIP URI. If it succeeds, the received
number will be used as E.164 CgPN. If the resolution fails, the E.164 CgPN will be
the MSC number.
• If the domain part of the From/P-Asserted-Identity is on the Denied Domain
List, the request will be rejected.
• If the domain part of the From/P-Asserted-Identity in not on the Home and
Denied domain lists, the LDAP is requested with the domain part of the logical SIP
URI. If it succeeds, the receive number will be used as E.164 CgPN. If the resolution
fails, the E.164 CgPN will be the MSC number.
• If the P-Asserted-Identity header is received, it will be used instead of the
From header.
• If there is no P-Asserted-Identity header and the From header has an 'invalid'
top level domain (for example, anonymous@anonymous.invalid), the LDAP will not
be requested for resolution and the CgPN will be the MSC number.
2.3.5 Calling Line Identification

There are two possibilities to transfer CLI In SIP:
• From header
• P-Asserted-Identity header
P-Asserted-Identity contains the verified CLI when it is coming from a trusted
network. Currently, NVS assumes that all the interfaces are connected to trusted net-
works. As a result, the P-Asserted-Identity header has higher priority than the
From header.
Incoming side
When NVS receives an INVITE message, it searches the message for the following two
calling party identities:
• SIP URI with logical name
• SIP URI or TEL URI which contains the E.164 number
Note that if the user part of the SIP URI starts with a number, it will be treated as an
E.164 number, independently from the user=phone URI parameter. This is needed to
32 Id:0900d80580652d04
be compatible with User Agents who do not support the user=phone SIP URI param-
eter.
Functionality on incoming ISC Access interface and Normal Access interface

When an INVITE message is received on these interfaces, the P-Asserted-
Identity or the From header should contain the registered SIP URI, since it is used
to identify the originating user and executes the originating services. In this case, the
E.164 number of the calling party is used by the VLR, which received the number from
the HLR during registration.
Functionality on incoming ISC Network interface and Normal Network interface

When an INVITE message is received on these interfaces, the P-Asserted-
Identity, P-Prefered-Identity, or the From headers are searched for the above
mentioned identities. If the E.164 cannot be extracted form the CLI, NVS tries to make
an LDAP query for the SIP URI received in the CLI headers for the E.164 number:
• If the domain part of the CLI is on the Home domain List, the LDAP is requested with
the complete SIP URI.
• If the domain part of the CLI is on the Denied domain List, the request is rejected.
• If the domain part of the CLI is not on the Home and Denied domain lists, the LDAP
is requested with the domain part of the SIP URI.
• If the LDAP resolution fails, the E.164-based Calling Party Number is left empty.
• If the CLI SIP URI has an 'invalid' top level domain (for example, the From header
is hidden and there is no P-Asserted-Identity header), LDAP is not requested
and the E.164-based Calling Party Number is left empty.
Outgoing side
When an INVITE message has to be sent, NVS inserts the following CLI headers in the
outgoing requests:
• One TEL-URI-based P-Asserted-Identity
• One SIP-URI-based P-Asserted-Identity
• From field
Note that if an additional Calling Party Number is available:
• it will be inserted in the From field on the trunk interfaces.
• it will overwrite the Calling Party Number on the Normal or ISC Access interfaces.
An additional Calling Party Number can be received in ISUP or through the IN interface.
SIP-URI-based P-Asserted-Identity
If the incoming side has received:
• a logical SIP URI (for example, john@operator.com), it will be added to the SIP-URI-
based header.
• an E.164 SIP URI (for example, 123456@operator.com), the domain part will be
preserved but the user part will be modified if the E.164 number is modified by the
Call Control of NVS, for example by using CLI formatting.
If the incoming side is not SIP, the P-Asserted-Identity header will be composed
in the following way:
• user part = E.164 number
• domain part = the Domain Level FQDN configured with the JHK MML command
Id:0900d80580652d04 33
When the Calling Party Number is not available or the screening of the number has
failed, the SIP-URI-based P-Asserted-Identity will not be added.
TEL URI based P-Asserted-Identity

The calling party E.164 number is added. This number can differ from the received
E.164 number since the Call Control of NVS can modify the CLI. If the screening of the
Calling Party Number has failed, the TEL URI based P-Asserted-Identity will not
be added.
From field
If the Additional Calling Party Number does not exist, the From field will be filled in as
the SIP URI based P-Asserted-Identity described above.
If the Additional Calling Party Number exists, the From field will be filled in with this
number. In case of SIP URI, the domain part is the Domain Level FQDN configured with
the JHK MML command.
When the Calling Party CLI is not available or the screening of the number has failed,
unavailable@anonymous.invalid will be set in the From header.
When the Calling Party CLI is restricted, anonymous@anonymous.invalid will be set in
the From header.
Note that:
• CLI can be hidden by presentation status settings (for example, CLIR).
• Format of From (SIP URI or TEL URI) can be configured.
Examples
In the following cases, the presentation status is always allowed. These examples are
applicable on all the interfaces.
Received Sent Note

From: P-Asserted-identity: CgPN is
sip:john@operator.com sip:john@operator.com received
P-Asserted-identity: tel:+123456789 from LDAP
(Network) or
From: sip:john@operator.com VLR
(Access).
From: P-Asserted-identity: If LDAP
sip:john@operator2.co sip:john@operator2.com does not
m From: sip:john@operator2.com contain
operator2.c
om.
From: P-Asserted-identity: If LDAP
sip:john@operator2.co sip:john@operator2.com contains
m P-Asserted-identity: tel:+43000000 operator2.c
om.
From: sip:john@operator2.com
P-Asserted-identity: P-Asserted-identity:
sip:john@operator.com sip:john@operator.com
From: P-Asserted-identity: tel:+123456789
sip:bob@operator.com From: sip:john@operator.com
34 Id:0900d80580652d04
Received Sent Note

P-Asserted-identity: P-Asserted-identity: CLI is for-
sip:123456789@operato sip:+44123456789@operator.com matted by
r.com P-Asserted-identity: tel: adding the
From: +44123456789 +44 prefix.
sip:john@operator.com From: sip:+44123456789@operator.com
P-Asserted-identity: P-Asserted-identity:
sip:123456789@operato sip:123456789@operator.com
r.com P-Asserted-identity: tel:123456789
P-Asserted-identity: From: tel:123456789 or
tel:123456789 sip:123456789@domain.com
From:
sip:1234@operator.com
From: tel:123456789 P-Asserted-identity: tel:123456789
P-Asserted-identity:
sip:123456789@operator.com
From: tel:123456789 or
sip:123456789@domain.com
ISUP: CgPN = P-Asserted-identity:
123456789 sip:123456789@domain.com
P-Asserted-identity: tel:123456789
From: tel:123456789 or
sip:123456789@domain.com
ISUP: CgPN = P-Asserted-identity: Network
123456789 sip:123456789@domain.com interface
ISUP: Additional CgPN P-Asserted-identity: tel:123456789
= 1234 From: tel:1234 or sip:1234@domain.com
ISUP: CgPN = P-Asserted-identity: Access
123456789 sip:1234@domain.com interface
ISUP: Additional CgPN P-Asserted-identity: tel:1234
= 1234 From: tel:1234 or sip:1234@domain.com
ISUP: CgPN = empty or From:
screening failed sip:unavailable@anonymous.invalid
From: From:anonymous@anonymous.invalid
anonymous@anonymous.i
nvalid
Calling Line Identification Presentation Restriction

CLIR is an originating service running in the originating NVS and can be provisioned in
the HLR for each subscriber.
When an INVITE message is received on the access interface, there are two pieces of
information that affect NVS behaviour:
• Subscriber option, configured in HLR:
• Service not provisioned (for example, permanently allowed)
• Temporary with “presentation restricted”
• Temporary with “presentation allowed”
• Information received in the SIP INVITE message:
Id:0900d80580652d04 35
• Privacy header
• Dialled function/facility code before the called party: there are user agents
*31#dialled number for the network
NVS supports the id and none privacy header values. When the id is presented, it is
assumed that the user requests for hiding his entity. When it is set to none, the user
requests the network to show his entity. And when the Privacy header is missing, the
user lets the network decide based on the HLR settings.
Facility codes can be used to request for the identity presentation service when the
Privacy header is not supported by the SIP UA. Facility/functional codes are kind of
prefixes defined by 3GPP TS 22.030, Man-Machine Interface (MMI) of the User Equip-
ment (UE). For CLIR the *31#dialled number for identity presentation request and the
#31# and 141 for identity presentation restriction request are used. These codes need
to be added to the dialled number or the dialled logical SIP URI. For example, the user
can dial the following numbers to use the facility codes:
• tel: *31#+12345567
• tel: 141+12345567
• sip: #31#6789098@operator.com
• sip: #31#bob@operator.com
The facility code has a higher priority than the privacy header: if both of them exist in the
INVITE message, the privacy header is not used.
Subscriber option in DX User option received in Functionality in originating

HLR INVITE on access interface NVS
Service not provisioned No option is received Presentation allowed
Privacy: id Clear call/ Presentation
allowed*
Privacy: none Presentation allowed
#31# Clear call/ Presentation
allowed*
*31# Presentation allowed
141 Clear call/ Presentation
allowed*
Permanent No option is received Presentation restricted
Privacy: id Presentation restricted
Privacy: none Presentation restricted
#31# Presentation restricted
*31# Presentation restricted
141 Presentation restricted
Temporary with “presentation No option is received Presentation restricted
restricted”
36 Id:0900d80580652d04
Subscriber option in DX User option received in Functionality in originating

HLR INVITE on access interface NVS
Temporary with “presentation No option is received Presentation allowed
allowed”
* depends on the call control parameter file settings (c0para)

On the outgoing network interface, the Privacy header of the sent INVITE message
is used to indicate the identity presentation restriction.
Functionality in NVS Option sent in INVITE on network interface

Presentation information does not exist No privacy header
Presentation restricted Privacy: id
Presentation allowed Privacy: none
Note that if the Privacy header is the id in the outgoing request, the From header is
always set to “sip:anonymous@anonymous.invalid”.
On the incoming network interface, the Privacy header of the received INVITE
message can be used to indicate the identity presentation restriction.
User option received in INVITE on network Functionality in NVS

interface
No privacy header Presentation information does not exist
Calling Line Identity Presentation

CLIP is a terminating service running in the terminating NVS and can be configured in
the HLR on subscriber basis.
Normal Access Interface

If the CLIP is not provisioned or not active for the called party, the identity of the calling
subscriber will be hidden: neither P-Asserted-Identity nor the Privacy header is
added to the outgoing INVITE message and the From field is set to “sip:anony-
mous@anonymous.invalid”.
If the CLIP is provisioned and active for the called party and:
• the A party allows the presentation of his identity, the identity of the calling sub-
scriber is shown in the From header and P-Asserted-Identity. Privacy
headers are added to the outgoing INVITE message.
• the A party restricts the presentation of his identity, the headers of the INVITE
message are the same as when CLIP is not provisioned.
Id:0900d80580652d04 37
ISC Access Interface

If the CLIP is not provisioned for the called party, the identity of the calling subscriber is
hidden: the From field is set to “sip:anonymous@anonymous.invalid” and the P-
Asserted-Identity carries the identity. Privacy header is set to id to ensure that the
P-CSCF will remove them before contacting the B party.
If the CLIP is provisioned and active for the called party and
• the A party allows the presentation of his identity, the identity of the calling sub-
scriber is shown in the From and the P-Asserted-Identity headers and the
Privacy header is added to the outgoing INVITE message with the none value.
• the A party restricts the presentation of his identity, the headers of the INVITE
message are the same as when CLIP is not provisioned.
Calling Line Presentation Restriction Override

CLIR Override is a terminating service running in the terminating NVS and can be con-
figured in the HLR on subscriber basis.
If the CLIR override is set to the called party independently from the A party option
received on the incoming side, the identity is shown in the From and the P-Asserted-
Identity headers and the Privacy header is added to the outgoing INVITE
message with the none value.
CLI formatting
The operator can re-format the calling party number. For instructions, see the command
description of CL - Calling Line Identity Handling.
2.4 Messaging in NVS
2.4.1 Messaging in Application Server Mode

This functionality introduces instant messaging to the MSS product, enabling it to handle
SIP UA originated and terminated MESSAGEs, as well as instant messaging and SMS
interworking. The originating and terminating service execution during normal and direct
message delivery and the instant messaging and SMS interworking are handled by the
current SMS architecture of the MSS. In this way, SIP subscribers can have similar
services to those that the GSM and UMTS subscribers currently have.
SIP is designed to support VoIP and is the selected protocol for 3GPP IMS networks to
establish, modify, and terminate multimedia sessions or calls.
It is a text-based protocol which makes it very flexible to accommodate new services and
easy to implement new service ideas. The SIP has excellent support for multimedia,
presence, messaging, and group services as a result of the Internet Engineering Task
Force (IETF) framework of protocols of which the SIP can take advantage.
When the SIP ISC Access and ISC Network interfaces are used between the IMS and
the 3GPP-defined MSS function, it is possible to introduce interworking between SMS
and SIP messaging. In this way, it is possible to provide IMS and SMSC interworking
that enables SMS application usage for IMS subscribers. It also provides storing and for-
warding functions through SMS fallback for IMS subscribers using SIP messaging. It is
also possible to provide services for both fixed and mobile networks through single con-
verged architectures.
38 Id:0900d80580652d04
Additionally, it is also possible to offer end-to-end SIP messaging. For this, the NVS
provides the direct message delivery method, which enables SIP message transfer
between SIP users without SMSC interaction and data truncation.
Interworking between the direct message delivery and the SMS is supported, as well. In
the case of an unsuccessful direct message delivery, the message can be sent to the
SMSC for later delivery, although for the SMS fallback function, the operator must have
the SIP messaging and SMS interworking function besides the end-to-end SIP messag-
ing function.
SIP messaging and SMS interworking

The MSS can provide interoperability for messaging between the IMS and GSM/UMTS
networks. Interworking provides a means to transfer text content between SIP
MESSAGE and GSM/UMTS SMS messages. For this, the
MSC_AS_VOIP_MESSAGE_SUP (002:1213) FIFILE parameter has to be activated.
When the MSS receives a Short Message (SM) from the GSM/UMTS network side, it
executes all functionalities that are typically involved in mobile-terminated short mes-
saging. After these functionalities, the received SM content is encoded into an SIP
MESSAGE and sent to the IMS domain to the S-CSCF of the recipient subscriber.
In the other direction, when a MSS receives a SIP MESSAGE from the originating S-
CSCF that is destined to the E.164 address of a GSM/UMTS subscriber or to an SMS
application, functionalities typically executed for the mobile-originated short messages
are done, and the received content is encoded to a standardized SM.
Figure SIP messaging and SMS interworking shows the SIP messaging and SMS inter-
working functionality.
Public Hot Spot IMS Domain Mobile Core Mobile RAN
SMSC
MO-SM MT-SM
SO-
MESSAGE MT-SM
WiFi UMTS
S S
WLAN
AP ST- MO-SM
Session S- MESSAGE MSC RAN
Multiradio phone
border CSCF Server
GSM/WLAN
controller
MGW
USER A sends and MSCServer handles the USER B sends and

receives MESSAGEs SM-MESSAGE interworking receives SMs
Figure 17 SIP messaging and SMS interworking in application server mode
End-to-end SIP messaging

End-to-end SIP messaging is a type of end-to-end Instant Messaging (IM) that can be
either implemented by using a store and forward framework similar to the SMS, or one-
Id:0900d80580652d04 39
shot messaging. In the NVS-based solution, the one-shot messaging type of IM —

called direct message delivery — is supported between:
• two SIP UAs,
• an SIP UA and a third party messaging system,
• a third party messaging system and an SIP UA.
If the DIRECT_MESSAGE_SUP_AS (002:1215) FIFILE parameter is activated, the
MESSAGE can be delivered directly (the message is not truncated):
• to subscriber B if the Request URI (RURI) is a home subscriber,
• to a third party messaging system if the recipient is not a home subscriber.
Messaging scenarios
For detailed information on the following messaging scenarios, see Feature 1760, NVS
Messaging (Application Server Mode), Feature Description.
• MESSAGE from S-CSCF over the ISC Access IF -> MO-SM
• MT-SM -> MESSAGE to S-CSCF over the ISC Access IF
• MESSAGE from S-CSCF over the ISC Access IF -> MESSAGE to S-CSCF over the
ISC Network IF, and MESSAGE from S-CSCF over the ISC Network IF ->
MESSAGE to S-CSCF over the ISC Access IF (full ISC scenario)
ISC Network IF, and MESSAGE from S-CSCF over the ISC Network IF ->
MESSAGE to S-CSCF over the ISC Access IF (unsuccessful full ISC scenario) ->
MO-SM (fallback)
• MESSAGE from S-CSCF over the ISC Access IF -> Direct MESSAGE Delivery
(limited ISC scenario) -> MESSAGE to S-CSCF over the ISC Access IF
• MESSAGE from S-CSCF over the ISC Access IF -> direct message delivery (limited
ISC scenario) -> Unsuccessful MESSAGE to S-CSCF over the ISC Access IF ->
MO-SM (fallback)
• MESSAGE from S-CSCF over the ISC Access IF -> direct message delivery -> MT-
SM
ISC Access IF (NVS-A = NVS-B)
• MESSAGE from S-CSCF over the ISC Access IF-> MT-SM (NVS-A = NVS-B)
• MESSAGE from S-CSCF over the ISC Access IF-> third party messaging system
• MESSAGE from third party messaging system over the ISC Network IF -> direct
message delivery -> MESSAGE to S-CSCF over the ISC Access IF
• MESSAGE from third party messaging system over the ISC Network IF-> direct
message delivery -> MT-SM
• MESSAGE from third party messaging system over the ISC Network IF ->
MESSAGE to S-CSCF over the ISC Access IF (Transit NVS = NVS-B)
• MESSAGE from third party messaging system over ISC Network IF -> MT-SM
(Transit NVS = NVS-B)
Transport
TCP support:
TCP is supported in the NVS, and it can be enabled or disabled with the
MSC_VOIP_TCP_SUPP FIFILE parameter. If activated, the TCP can be switched on or
off with the PRFILE parameters.
40 Id:0900d80580652d04
In application server mode, TCP can be activated and deactivated with the
TCP_ACTIVATED_ON_ISC_IF (052:0048) PRFILE parameter on the ISC interfaces. If
the NVS is activated only in application server mode, TCP is supported only if both the
MSC_VOIP_TCP_SUPP and the TCP_ACTIVATED_ON_ISC_IF (052:0048) PRFILE
parameters are active. If any of them is deactivated, TCP is not supported on the ISC
interfaces.
In case of a limited ISC scenario, the Normal Network IF is involved as well. On this inter-
face, TCP can be activated and deactivated with the TCP_ACTIVATED_ON_NET_IF
(052:0049) PRFILE parameter.
SCTP support:
Support of the SIP over SCTP in the context of NVS messaging in application server
mode means support of SCTP on the following interfaces:
• ISC Access interface (controlled by the VOIP_SCTP_ON_SIP_ACCESS
(052:0071) PRFILE parameter),
• ISC Network interface, and
• Normal Network interface.
2.4.2 Messaging in Standalone Mode

This functionality introduces instant messaging to the MSS product, enabling it to handle
the SIP UA originated and terminated MESSAGEs, as well as SIP messaging-SMS inter-
working. The originating and terminating service execution during normal and direct
message delivery, and the SIP messaging-SMS interworking are handled by the current
SMS architecture of the MSS. In this way, SIP subscribers can have similar services to
those that the GSM and UMTS subscribers currently have.
When the SIP Access interface is used from the MSS with the 3GPP-defined MSS func-
tion, it is possible to introduce VoIP or messaging interworking between SMS and SIP
messaging, as well as to provide services for both fixed and mobile networks through
single converged architectures.
Additionally, it is also possible to offer end-to-end SIP messaging. For this, the NVS
provides the direct message delivery method, which enables SIP message transfer
between SIP users without SMSC interaction and data truncation.
Interworking between direct message delivery and SMS is supported, as well. In the
case of an unsuccessful direct message delivery, the message can be sent to the SMSC
for later delivery, although for the SMS fallback function, the operator must have the SIP
messaging-SMS interworking function besides end-to-end SIP messaging.
SIP messaging-SMS interworking

The MSS is able to provide interoperability for messaging between SIP and GSM/UMTS
networks. Interworking provides means to transfer text content between SIP MESSAGE
and GSM/UMTS Short Message Service (SMS) messages. For this, the
MSC_VOIP_MESSAGE_SUP (002:1212) FIFILE parameter has to be activated.
When MSS receives a Short Message (SM) from the GSM/UMTS network side, it
executes all functions that are typically involved in mobile-terminated short messaging.
After the execution of these functions, the received SM content is encoded to a SIP
MESSAGE and is sent to the recipient subscriber over the SIP Normal Access interface.
In the other direction, when a MSS receives a SIP MESSAGE that is destined to the
E.164 address of a GSM/UMTS subscriber or to an SMS application, functions that are
Id:0900d80580652d04 41
typically executed for the mobile-originated short messages are performed, and the
received content is encoded to a standardized SM.
Figure SIP messaging and SMS interworking in standalone mode shows SIP messaging
and SMS interworking.
Public Hot Spot Mobile Core Mobile RAN

SMSC
MO-SM MT-SM
SO-
MESSAGE MT-SM
WiFi UMTS
S S
WLAN ST- MO-SM
AP MESSAGE MSC
Multiradio Session RAN phone
GSM/WLAN border Server
controller
MGW
USER A sends and receives MESSAGEs MSCServer handles the USER B sends and
SM-MESSAGE interworking receives SMs
Figure 18 SIP messaging-SMS interworking in standalone mode
End-to-end SIP messaging

End-to-end SIP messaging is a sort of end-to-end Instant Messaging (IM) that can be
either implemented by using a store-and-forward framework similar to the SMS, or one-
shot messaging. In the NVS based solution, the one-shot messaging type of IM, called
direct message delivery, is supported between:
• two SIP UAs,
• an SIP UA and a third party messaging system, or
• a third party messaging system and an SIP UA.
If the DIRECT_MESSAGE_SUP (002:1214) FIFILE parameter is activated, the
MESSAGE can be delivered directly (the message is not truncated):
• to the subscriber B if the Request URI (RURI) is a home subscriber, or
• to a third party messaging system if the recipient is not a home subscriber.
Delivery between two SIP UAs

If party B is a home subscriber, an HLR inquiry has to be performed to get the MSS
address where the subscriber is located. A SendRoutingInfoForSM (SRIforSM)
response returns with the VMSC address, which cannot be used for IP routing directly.
In order to achieve the direct message delivery, the operator has to define/configure a
special mapping table for the purpose of MSC address - FQDN resolution. This FQDN
points to the private address of the SCPU of the target MSS.
If the VMSC address returned in the SRIforSM response is the same as the own MSC
address, it means that subscribers A and B are located in the same MSS/NVS. In this
case, the above mentioned MSC address resolution table is not necessary, as the
42 Id:0900d80580652d04
MESSAGE can be delivered internally between the originating and terminating sides. In
this case, there is no need for the outgoing and incoming Normal Network IFs, therefore,
the SIP Normal Network/Trunk specific configuration is not necessary.
In the case of unsuccessful delivery, if the Instant Messaging-SMS interworking is sup-
ported (the MSC_VOIP_MESSAGE_SUP FIFILE parameter is activated), SMS fallback is
executed.
Note that due to the necessary HLR inquiry, the direct message delivery solution
requires the MSS to have gateway function.
Delivery between an SIP UA and a third party messaging system

If party B is a foreign subscriber, the SIP URI of party B cannot be resolved (to sub-
scriber B's MSISDN) by the home SDB, so it is not possible to get the VMSC address of
the subscriber. In this case, the MESSAGE is delivered to a third party messaging
system and the remote IP address, determined through a DNS query, is executed with
the domain part of the R-URI.
In case of an unsuccessful delivery, even if the Instant Messaging-SMS interworking
function is supported (the MSC_VOIP_MESSAGE_SUP FIFILE parameter is activated),
SMS fallback does not happen.
Delivery between a third party messaging system and an SIP UA

From a third party messaging system, the SIP MESSAGE arrives over the Normal
Network IF. As subscriber B does not belong to the sender network element, it is not
able to send the MESSAGE directly to the correct MSS (if there are more MSS/NVSs in
the network). In this case, the visited MSS of subscriber B has to be found out similarly
as in case of a direct message delivery between two SIP UAs belonging to the same
(home) domain.
If subscriber B's MSISDN is not available, it is retrieved from the SDB and then an HLR
inquiry is performed by sending an SRIforSM request to the HLR of party-B. If the
returned VMSC address is not the same as the own MSC address, the NVS is in transit
role and it has to route the MESSAGE to the MSS/NVS-B, where the services for sub-
scriber B can be executed. For this purpose, an MSC address resolution is performed,
based on the V MSC address received in the SRIforSM response. The result FQDN can
be used for routing the MESSAGE over the Normal Network IF to the MSS in which the
recipient is located.
If the VMSC address returned in the SRIforSM response is the same as the own MSC
address, it means that the transit and the terminating NVS (MSS/NVS-B) functions are
located in the same MSS. In this case, the MSC address resolution table does not have
to be used as the MESSAGE can be delivered internally between the transit and termi-
nating sides.
The operator can decide whether MESSAGEs coming from third party messaging
systems are allowed or not. In this case, besides the DIRECT_MESSAGE_SUP
(002:1214) FIFILE parameter, the 3RD_PARTY_MESSAGE_SUP (052:0046) PRFILE
parameter is also checked. SIP MESSAGEs coming from third party messaging systems
are handled only if the DIRECT_MESSAGE_SUP FIFILE parameter is activated and the
3RD_PARTY_MESSAGE_SUP PRFILE is turned on (that is, set to T).
In case of an unsuccessful delivery, even if the Instant Messaging-SMS interworking
function is supported, (the MSC_VOIP_MESSAGE_SUP FIFILE parameter is activated),
SMS fallback does not happen.
Id:0900d80580652d04 43
Messaging scenarios
For detailed information on the following messaging scenarios, see Feature 1760, NVS
Messaging (Standalone Mode), Feature Description.
• SO MESSAGE -> MO-SM
• MT-SM -> ST MESSAGE
• SO MESSAGE -> direct message delivery -> ST MESSAGE
• SO MESSAGE -> direct message delivery -> Unsuccessful ST MESSAGE -> MO-
SM (fallback)
• SO MESSAGE -> direct message delivery -> MT-SM
• SO MESSAGE -> ST MESSAGE (NVS-A = NVS-B)
• SO MESSAGE -> MT-SM (NVS-A = NVS-B)
• SO MESSAGE -> third party messaging system
• MESSAGE from third party messaging system -> direct message delivery -> ST
MESSAGE
• MESSAGE from third party messaging system -> direct message delivery -> MT-SM
• MESSAGE from third party messaging system -> ST MESSAGE (transit NVS =
NVS-B)
• MESSAGE from a third party messaging system -> MT-SM (Transit-NVS = NVS-B)
Transport
TCP support:
TCP is supported in the NVS, and it can be enabled or disabled with the
MSC_VOIP_TCP_SUPP (002:1219) FIFILE parameter. If activated, the TCP can be
switched on or off with the PRFILE parameters.
In Standalone Mode, the TCP can be activated or deactivated separately for Normal
Access (public) and Normal Network (private) interfaces with the
TCP_ACTIVATED_ON_ACC_IF (052:0047) and the TCP_ACTIVATED_ON_NET_IF
(052:0049) PRFILE parameters.
SCTP support:
Support of the SIP over SCTP in the context of NVS messaging in Standalone Mode
means support of SCTP on the following interfaces:
• Normal Access interface (controlled by the VOIP_SCTP_ON_SIP_ACCESS
(052:0071) PRFILE parameter), if there is some network element between the NVS
and the SIP subscriber (for example, Session Border Controller (SBC)), and
• Normal Network interface.
2.5 Statistics
NVS statistics provides statistical support for the Mobile VoIP Server network element.
For this purpose, some of the existing measurement and observation reports are
extended with new information, that is, new information appears in existing fields, new
counters and new fields are introduced, and furthermore, new measurement and obser-
vation reports are implemented.
The NVS/MSS acts as a registrar towards the SIP User Agents and downloads user-
related data from the external Lightweight Directory Access Protocol (LDAP) server. The
NVS/MSS can also authenticate the user by HTTP digest. A new measurement is
44 Id:0900d80580652d04
created to provide information on the registration and authentication related events for
statistical purposes: the SIP Registration measurement.
The following statistical reports and functions provide NVS-related statistical informa-
tion:
• SIP registration measurement
• Authentication for SIP
• SIP registration
• Subscriber and Equipment Trace
• Load observations
• Rejected Calls Observation
• Restart Measurement
• Traffic Measurement
• Instant Messaging and SMS Interworking
• VLR Measurement
• Clear Codes
• Supplementary Services
• Traffica
• SIP protocol measurement
• The Traffica support (SIP event report, etc.) for the feature requires to have the basic
and optional Traffica reports activated in the system.
• IMEI is not used for SIP access. Even if there is a GSM/UMTS-capable phone,
which is also capable for SIP through WLAN, and is phone is GSM-attached,
whenever it makes an initial registration, the SIP registration procedure will overwrite
the GSM attach in the VLR, therefore it is not possible to trace any SIP actions via
IMEI.
• The overload control for SIP access and SIP trunk-related calls in the NVS can be
managed (activated or deactivated) by the following PRFILE parameters:
• SIP_TRUNK_OLC (012:0116)
• SIP_ACCESS_OLC (012:0117)
On the SIP interface of the NVS, the WAC method is applied to:
• INVITE requests in the SIP access and SIP trunk interfaces
• REGISTER requests in the SIP access interface
• MESSAGE requests in the SIP access and SIP trunk interface
BLC method control is implemented on the SIP interface of the NVS to:
• Messages going to SIP (access and trunk) interface
Already existing WAC and BLC methods on existing interfaces (MAP, TCP/IP, etc.)
are still available in the NVS.
Reports
The NVS-specific SCPU unit is object of the following reports:
• Control Unit Measurement Report (18/12H)
• Control Unit Load Observation Report (118/76H)
• Computer Unit Load Observation Report (119/77H)
• Restart Measurement Report (129/81H)
• Rejected Calls Observation Report (114/72H)
Id:0900d80580652d04 45
SIP access information is presented in the following reports:

• Location Update Observation Report (90/5AH)
• MSC Observation Report (96/60H)
• SMS Observation Report (98/62H)
New measurement and observation reports:
• SIP Registration Measurement (357/165H)
• SIP Observation Report (358/166H)
• SIP protocol measurement report (360/168H)
The SIP protocol measurement can be used to locate and analyse SIP-related
network problems.
There are two different report types in this measurement. The first report part
contains both the incoming and outgoing SIP requests and responses. The length
of the SIP messages is also shown in these reports to help calculate the used band-
width. The last report part contains information about TCP usage: the average and
maximum number of TCP connections per signaling unit in one result accumulation
period.
The object list of the measurement includes the interfaces between different network
elements. In addition to the interface-level objects, IP addresses and METHODs also
need to be defined as objects.
Subscriber and Equipment Trace support:
Trace provides detailed information about subscriber-related events in the NVS, such
as registrations, authentications, calls (INVITE sessions) and messaging. A new report,
the SIP observation report, is introduced that will provide the SIP/NVS-specific informa-
tion about the mentioned events for trace.
Equipment trace is not possible for SIP User agents.
Traffica support:
A new report is introduced to monitor SIP registration events.
The new SCPU unit is added to the CUL reports. This way the load of the SCPU units
are measured the same way as other signaling units (for example CCSUs), and SCPU
is added to the Traffica overload control mechanism. SIP access type is indicated in the
existing reports (RTTs, VLR, SMS and SS reports).
Counters
Service measurement report (128/80H)

Provides statistics about services used in the NVS. Furthermore, NVS-specific events
counters are provided:
• 'SOM ','SIP ORIG MESSAGE DELIVERY ', /* 87H */
• 'STM ','SIP TERM MESSAGE DELIVERY ', /* 88H */
• 'SDM ','SIP DIRECT MESSAGE DELIVERY ', /* 89H */
• 'SFM ','SIP SMS FORWARDING ', /* 8AH */
Traffic Category Measurement Report (20/14H)

New traffic categories have been introduced to measure NVS-related traffic in the
network element:
46 Id:0900d80580652d04
• SIP ORIG SIP originating traffic ID = 74

• SIP TERM SIP terminating traffic ID = 75
• SIP INC SIP incoming traffic ID = 76
• SIP OUT SIP outgoing traffic ID = 77
• ISC ORIG ISC originating traffic ID = 78
• ISC ORIG INT ISC originating internal traffic ID = 79
• ISC TERM ISC terminating traffic ID = 80
• ISC TERM INT ISC terminating internal traffic ID = 81
VLR measurement, part 1 (82/52H)

New counters are added to the VLR measurement, measuring the IMSI attaches (ID:
M82B5C107) and detaches (ID: M82B5C109) and periodic location update attempts
(ID: M82B6C12) for the SIP access separately.
AC/VLR measurement (86/56H)

SIP-related authentications are preformed by the SPD, therefore these are not
measured by the AC/VLR measurement. The information is provided by the SIP regis-
tration measurement.
Files
Statistics-related reports (both the ASCII and XML formats) are available through logical
files. Each logical file must be connected to a defined printing or storing device for the
reports to be printed or stored. If connected to a physical disk, each logical file can only
be connected to one physical disk file for disk storage.
There are new logical files for the SIP registration measurement:
• SIPREGA for ASCII reports
• SIPREGX for XML reports
The new SIP observation reports are directed to the same logical files as the other trace
reports:
• GSMME1PR for ASCII reports
• GSMME1MX for off-line XML reports
• GSMME1MXO for on-line XML reports
It is recommended to check the NSS Statistics document for further information about
linking the logical files. For information about logical files for other measurement, see
NSS Statistics, Reports.
Parameters
The Traffica-related functionality of the feature can be managed by PRFILE parameters.
Parameter TPP_OBS_TRANSFER_MODE (9:54) is extended with a new bit, which
controls the SIP event report sending to Traffica.
Parameter TRAFFICA_CONNECTION (9:116) is extended with a new bit, which
controls the SIP event report sending to different Traffica connections.
For more detailed information, see Feature 939: MSC Support for Real Time Reporting
(Traffica) and PRFILE description.
Id:0900d80580652d04 47
Configuration
For information on the related commands, see section MMLs in Feature 1696, NVS Sta-
tistics, Feature Description.
2.6 Charging
NVS charging is a part of Nokia Siemens Networks Convergence Solutions. With
Charging Data Records (CDRs) on the Circuit Switched (CS) network side, this feature
enables customers to charge for the usage of NVS, AS, and other possible IMSS in
cases where the user or usage is related or interfaced to the CS network through SIP.
This feature is needed also in pure IMS network related cases, when the MSS operates
as an AS and subscribers are directly connected to the MSS, because there is no other
charging information generated on the IMS side in addition to what is generated by this
feature.
The following basic charging capabilities are introduced in the following features:
• Feature 1671: NVS Call Handling
• Feature 1673: NVS Registration
• Feature 1760: NVS Messaging
CDR types
The following five CDR types are introduced for NVS-related calls and actions:
• SOC
SIP Originated Calls
• STC
SIP Terminated Calls
• SOM
SIP Originated Messaging
• STM
SIP Terminated Messaging
• SIPR
SIP Registration
Please note that these CDR types have to be acknowledged by the Billing Centre so that
the operator could charge for NVS-related calls and messaging which originate or ter-
minate in a circuit-switched network.
The structure of these CDRs is described in CDR Field Description M13, Interface Spec-
ification and MSC/HLR-BC Universal M13, Interface Specification.
With CDRs on the CS network side, this functionality enables the customer to charge for
NVS, AS, and other IMS network related calls and messaging that originate or terminate
in a CS network through SIP. This is done by introducing five CDRs; two for calls, two
for messaging, and one for registration. Basic session related data is inserted in the
CDRs from which the appropriate charge can be decided and addressed to the correct
party.
CDRs made in the NVS in the IMS network and CDRs related to the same call but made
in the CS network, can be concatenated with an IMS Charging Identifier (ICID). ICID can
be found in SOC, STC, SOM, and STM CDRs as well as in CDRs made in the IMS
network. The SIP Registration (SIPR) CDR does not have an ICID as it is not call or mes-
saging related, and is not related to any other generated CDRs.
48 Id:0900d80580652d04
CDR fields
CALL_MEDIA
Type of a SIP call. The field is available in SOC and STC charging records.
Possible values are:
• 00H
Does not exist
• 01H
Speech
• 02H
Multimedia
Format: 1 hexadecimal byte
VAL
IMS Charging Identifier (ICID). It is a globally unique identifier used to concatenate
CDRs from IMS, SIP, and CS networks that belong to the same call. The field is avail-
able in SOC, STC, SOM, and STM charging records.
Format: 32 hexadecimal bytes
LEN
This field indicates the length of received ICID information. The field is available in SOC,
STC, SOM, and STM charging records.
ICID_OVERFLOW
This field indicates if the received ICID information is too long and therefore cut in the
ICID field. The field is available in SOC, STC, SOM, and STM charging records.
• 00H
No ICID overflow
• 01H
ICID overflow
MESSAGE_SIZE
The message size of message service user data, including addresses, types, and short
message text. The field is available in SOM and STM charging records.
Format: HEX dword
SIP_SIG_MODE
Mode of a SIP call. The field is available in SOC and STC charging records.
• 00H
Unknown
• 01H
SIP ISUP tunneling: SIP-I, SIP-T
Id:0900d80580652d04 49
• 02H
Media Gateway Control Function (MGCF)
• 03H
SIP Access interface of MSS
• 04H
SIP Trunk interface of MSS
• 05H
ISC Interface of NVS for originating services
• 06H
ISC Interface of NVS for terminating services
Basic use cases with CDRs

This subsection describes three basic use cases and the CDRs generated during these
sessions.
UA-A calls MS-B
MSS
Radio 1
Operator
IP Cloud Options Close
UA-A MS-B
MGW BSC
Figure 19 UA-A calls MS-B
1. UA-A calls MS-B

2. MS-B answers the call
3. UA-A clears the call
Generated CDRs:
• SOC
• MTC
50 Id:0900d80580652d04
UA-A calls UA-B through ISUP
MSS (AS) MSS (AS)
ISUP
MGW MGW
IP Cloud
UA-A UA-B
Figure 20 UA-A calls UA-B through ISUP
1. UA-A calls UA-B through ISUP

2. UA-B answers the call
3. UA-A clears the call
Generated CDRs:
• SOC
• PTC
• POC
• STC
Id:0900d80580652d04 51
UA-A sends message to UA-B
MSS
MGW
IP Cloud
UA-A UA-B
Figure 21 UA-A sends message to UA-B
Generated CDRs:
• STM
• SOM
Parameters
Feature 1671: NVS Call Handling describes the optionality and the management of the
NVS Call Handling.
Feature 1673: NVS Registration describes the optionality and the management of the
registration and messaging cases.
This feature itself does not have optionality, but the management of the CDR generation
parameters is affected by MSC_VOIP_SUPPORT (002:1078) or
MSC_AS_VOIP_SUPPORT (002:1089) FIFILE parameters. With CDR format it is
possible to handle whether the NVS call related CDRs and information is available or
not. If the functionality of feature 1671 is OFF, there is no NVS call specific information
for the CDRs. If the functionality of feature 1673 is OFF, there is no NVS messaging
specific information for the CDRs.
Configuration
For information on the related commands and their parameters, see section MMLs in
Feature 1703, NVS Charging, Feature Description and Detailed Charging Handling, GT
Command Group.
2.7 Control of supplementary services in NVS

This functionality is part of the NVS solution for fixed access (fixed Plain Old Telephone
Service (POTS)/ISDN, wireless local area network mobiles or fixed SIP phones). It uses
facility codes as a simple method to control the services connected to Plain Old Tele-
phone Service (POTS) phones. It enables the NVS users to use the same Man-Machine
52 Id:0900d80580652d04
Interface (MMI) via SIP (RFC 3261 SIP: Session Initiation Protocol) that is used by the
GSM/UMTS subscribers.
In GSM/UMTS networks the User Equipment (UE) converts the interactions on the MMI
interface (that is, on the phone) to L3 interface signaling. The conversion is based on
the supplementary service specific 3rd Generation Partnership Project (3GPP) stan-
dards. These A interface operations are translated to Mobile Application Part (MAP)
operations towards the HLR. Since the interface between the users and NVS is SIP, the
following requirements cannot apply to the User Agents but are implemented in NVS:
• The user can initiate a call (for example, send an INVITE) with a supplementary
control string (for example, to deactivate unconditional call forwarding, the user
enters #21# and presses the dial button).
• When the NVS receives a supplementary service control string, NVS converts it to
MAP operation towards the HLR.
• The operator can configure different announcements based on the result of the
operation (for example announces the actual service settings if the operation is suc-
cessful, or announces the reason of the failure.
Using facility codes, the user can activate and deactivate services, register and erase
service settings, and interrogate the current service configuration.
The following figure presents an overview of the supplementary services architecture:
IMS domain MSC

ISC Server
CPS (SIP) HLR domain
MAP over IP
SIP SIP (SIGTRAN)
Access
Multiaccess NVS
S
SIP softphones
S
S DSLAM H.248 SIGTRAN
SIP deskphones
POTS
S MGW
POTS IAD Multiradio

terminals
Figure 22 Supplementary services and affected SIP interfaces
Supported services
The supplementary service control operations on the A interface are described by the
TS 24.xxx class specifications. 3GPP TS 29.011 Signaling interworking for supplemen-
tary services, Release 6, January 2005 specifies the interworking between the A and D
(MSC / VLR - HLR) interfaces.
Id:0900d80580652d04 53
Supplementary services
With feature 1741, SIP users can use the MMI for call control and supplementary service
control. Subscribers can register, erase, activate, deactivate, and interrogate the follow-
ing supplementary services:
• call forwarding (unconditional call forwarding, call forwarding on mobile subscriber
busy, call forwarding on not reachable, and call forwarding on no reply)
• call barring
• line identification services (calling line identification and calling line identification
restriction)
• call waiting (currently this does not have an effect on SIP calls)
The following services are not supported:
• enhanced multi-level precedence and pre-emption (Currently, this does not have an
effect on SIP calls.)
• multicall (Multicall is not applicable for SIP calls.)
• user to user signaling
• Connected Line Identification Presentation (COLP) and Connected Line Iden-
tification Restriction (COLR)
Possible operations for services

For information on the standardized operations for the supported services, see section-
Supported services in Feature 1741, Control of Supplementary Services in NVS,
Feature Description.
Password check
Password checking is usually invoked by parent procedure (for example, service activa-
tion), and not used as a standalone procedure. L3 interface is specified by 3GPP TS
24.010 V6.0.0 Mobile radio interface layer 3, Supplementary services specification;
General aspects, Release 6, January 2005 and the L3 - MAP interworking is described
by 3GPP TS 29.011 V6.0.0 Signaling interworking for supplementary services, release
6.
For detailed information, see section Supported services in Feature 1741, Control of
Supplementary Services in NVS, Feature Description.
Password registration
Password registration is used to modify the provisioned password as described by
3GPP TS 24.010 V6.0.0 Mobile radio interface layer 3, Supplementary services specifi-
cation; General aspects, Release 6.
For detailed information, see sectionSupported services in Feature 1741, Control of
Call forwarding
All call forwarding registration, erasure, activation, and deactivation procedures are
described by 3GPP TS 24.082 V6.0.0 Call forwarding (CF) supplementary services;
Stage 3, Release 6, January 2005 for A interface.
54 Id:0900d80580652d04
Call barring
All call barring registration, erasure, activation and deactivation procedures are
described by 3GPP TS 24.088 V6.0.0 Call barring (CB) supplementary service; Stage
3, release 6, April 2003 for A interface.
Line identification services

All line identification related registration, erasure, activation, and deactivation proce-
dures are described by 3GPP TS 24.081 V6.0.0 Line identification supplementary ser-
vices; Release 6, January 2005 for A interface.
Charging
Offline charging:
Facility control is executed by initiating a SIP call. It is similar to a speech call, but it does
not generate SOC CDR. For the charging of the user-initiated supplementary service
modifications it generates a Supplementary Service Charging Record (SUPS CDR).
Online charging:
Online charging can be turned ON/OFF for the SIP based facility code by suppressing
the IN triggering with the VOIP_SS_IN_TRIG_SUPPR PRFILE parameter.
Configuration
For more information on the commands and their parameters, see sections MMLs and
Parameters in Feature 1741, Control of Supplementary Services in NVS, Feature
Description and GSM Special Route Handling, RP Command Group.
2.8 SIP video telephony interworking support

In IMS-CS interworking, the audio call interworking is made by the MGCF/MSS and the
MGW. However, for the video call interworking there is a need for a separate VGW for
the interworking between the H.263 RTP based video and the 3G H.324M circuit
switched video. These video gateways usually handle the control and user plane in one
box.
MGCF can route the H.263 based SIP video calls to the VGW. In case of the 3G-324M
and the SIP RTP based video interworking, the role of the MGCF is the following:
• it identifies the call type based on the SDP content, which is included in the SIP
message,
• goes to the Call Mediation Node (CMN) and
• routes the call to the 3rd party VGW.
Since the MGCF works in CMN mode, the MGW is not used in the call. This BGCF func-
tionality is included in the MGCF.
The following figure shows an example on the system level. It illustrates how the IMS-
originated video call is terminated to the 3G Mobile Station (MS) which is capable of
handling the H.324M calls.
Id:0900d80580652d04 55
1. INVITE (SDP m=video) 2. INVITE (SDP m=video)

P-CSCF S-CSCF
RTP (H.263 video) 4. INVITE (SDP m=video) 3. INVITE (SDP m=video)

VGW MGCF/MSS
Interworking between Based on the call type (media lines of SDP)

the H.263 RTP based video MGCF routes the call to VGW
and 3G H.324M CS video call instead of GMSC.
MGCF is acting in CMN mode
6. SRI (B1F) 7. PRN (B1F)

HLR
9. SETUP
5. IAM (3G Video H.324M) 8. IAM (MSRN ( H.324M))
GMSS VMSS
3G H.324M 3G H.324M
MGW MGW 3G H.324M
Figure 23 IMS-CS video call interworking. Call originates in the IMS

Description of the call flow:
1. P-CSCF receives the video call from the SIP UA. The video call is indicated by the
media line(s) in the SDP.
2. P-CSCF sends the call to the S-CSCF which executes originating services using
external application servers (not shown on the figure).
3. Since the called party number is from the CS range, the S-CSCF sends the call to
the MGCF by using tElephone Number Mapping (ENUM) query.
4. The call type is analysed in the MGCF and the operator can configure, for example,
in routing attribute analysis to route the call to an external 3rd party VGW instead of
the standard IMS-CS routing. The operator can also set that in case the calls come
from the S-CSCF and are routed to the VGW, the MSS should be used in CMN
mode. In CMN mode the MGCF simply proxies the SDP and does not terminate it in
the MGW.
5. The VGW receives the call and makes the SIP video to CS video interworking and
sends the call to the Gateway MSC (GMSC).
6. The GMSC receives the H.324M 3G video call that makes the HLR inquiry for the
called number.
7. It finally routes the call to the Visited MSC (VMSC).
8. On the user plane, the MGW reserves the Unrestricted Digital Information Service
(UDI) termination.
Note that the GMSC can be located in the MGCF since the MGCF includes the MSS
functionality, as well.
9. The VMSC sends out the CS video call to the 3G terminal.
Note the following information:
• The user plane is converted in the VGW, as well.
56 Id:0900d80580652d04
• It is possible that the MGCF makes the HLR inquiry before routing the call to the
VGW. This way the VGW receives the Mobile Station Roaming Number (MSRN) as
a called number and routes the CS call to the VMSC directly. This way the number
of network elements are optimized.
• When the MSS/MGCF receives a video call on the SIP interface and the HLR inquiry
is configured, the Integrated Services Digital Network Bearer Capability Information
Element (ISDN BCIE) towards the HLR is empty. Therefore, the terminating VMSC
makes the service restriction when the B party has no B1F video bearer service pro-
visioned.
The following figure shows an example on the system level. It illustrates how the CS
originated video call can be terminated to a SIP UA. In the figure the MGCF is not used
because the VGW can route the call to I-CSCF.

P-CSCF S-CSCF
RTP (H.263 video) 3. INVITE (SDP m=video) 4. INVITE (SDP m=video)

VGW I-CSCF
VGW acts as an MGCF

and sends the call to IMS
1. SETUP
2. IAM (MSRN H.324M)
VMSS
3G H.324M
MGW 3G H.324M
Figure 24 IMS-CS video call interworking. Call originates in the CS

For more information, see Feature 1823: SIP Video Telephony Interworking, Feature
Description.
IMS-CS video interworking with the NVS in Application Server mode

The NVS that acts as an Application Server is also capable of identifying the call type
and this information can be used in several analyses.
The following figure shows an example when the originating NVS adds a prefix based
on the call type. This solution is used, for example, when the MGCF does not support
the functionality described above.
Id:0900d80580652d04 57
Based on the call type

(media lines of SDP)
and B number range
originating NVS adds
prefix to the called number
NVS
4. INVITE (prefix+B, SDP

3. INVITE (B, SDP m=video) m=video
By using ENUM the
1. INVITE (SDP m=video) 2. INVITE (SDP m=video) prefix points to VGW
P-CSCF S-CSCF instead of MGCF
5. INVITE
RTP (H.263 video) (prefix+B, SDP m=video)
VGW
8. PRN (B1F) 7. SRI (B1F)

HLR
10. SETUP
9. IAM (MSRN ( H.324M)) 6. IAM (3G Video H.324M)
VMSS GMSS
3G H.324M 3G H.324M
3G H.324M MGW MGW
Figure 25 Video call in the NVS Application Server, adding prefix based on the call
type
SIP-CS video interworking with NVS in Standalone Mode

The standalone NVS also supports the call routing based on the call type. Therefore, in
the standalone solution, the SIP to 3G UMTS video call is also possible with the 3rd party
VGW.
The following figure shows an example when the SIP UA initiates a SIP based H.263
video call towards a 3G user. In the example the 3G phones are in different number
range.
58 Id:0900d80580652d04
Based on the call type (media lines of SDP)

and B number range originating NVS routes
the call to VGW instead of the GMSC
1. INVITE (B, SDP m=video) 2. INVITE (B, SDP m=video)

NVS VGW
RTP (H.263 video)
5. PRN (B1F) 4. SRI (B1F)

HLR
7. SETUP
6. IAM (MSRN ( H.324M)) 3. IAM (3G Video H.324M)
VMSS GMSS
3G H.324M 3G H.324M
3G H.324M MGW MGW
Figure 26 SIP-CS video interworking in standalone NVS solution
1. SIP UA initiates a SIP video call.

2. The NVS is configured to the CMN mode (since the MGW does not support the RTP
based H.263 video calls). The NVS analyses the SDP; based on this procedure and
the number range of the 3G phones, the operator can route the call to the VGW
which makes the video interworking.
3. The VGW makes the user and control plane interworking, as usual, and sends the
H.324M video call to the GMSS.
4. The GMSC receives the H.324M 3G video call.
5. It makes the HLR inquiry for the called number and finally routes the call to the
VMSC.
6. On the user plane, the MGW reserves the UDI terminations.
Note that the GMSC can be located in the NVS.
7. The VMSC sends the CS video call to the 3G terminal.
If the 3G and the SIP mobile stations (MSS) share the same MSISDN range, the origi-
nating NVS makes the HLR inquiry for the B number:
• if the MSRN range is from a 3G range (for example, from a standard MSS) the call
is routed to the VGW based on the MSRN.
• if the MSRN range is from a SIP range (for example, from a SIP range of an NVS)
the call is routed to the target NVS without involving the VGW.
If an NVS serves 3G radio access and SIP access at the same time, the access based
roaming number allocation is used to route the calls in different ways. This means that
the GMSC receives MSRN from a different range if the user has 3G or SIP access.
The following figure shows an example of the situation when the 3G UE initiates a
H.324M CS video call towards a SIP UA user. In the example, the 3G UE are in different
number range from the SIP terminals.
Id:0900d80580652d04 59

NVS VGW
RTP (H.263 video)
1. SETUP 2. IAM (MSRN (H.324M))

VMSS
3G H.324M 3G H.324M
MGW
Figure 27 CS-SIP video interworking in the standalone NVS solution
Fallback of SIP video call to audio call

For better user experience, in some cases, the MSS (in all usage; MGCF, NVS) down-
grades the call to the audio call. The downgrade scenario that is only supported is
described below:
When the video call is received on SIP interface and the operator configures the
NVS/MGCF in CMN to 'inactive' the MGW is reserved on the user plane. In this case the
call is downgraded to an audio call and is not rejected. This happens when the
MGCF/NVS is configured to route out the call on an ISUP trunk. In this case, ISUP
contains speech call indication. According to the IETF-RFC 4566: SDP: Session
Description Protocol, July 2006, the SDP answer contains the rejected video line.
INVITE (SDP m=video)

ISUP: IAM B (speech) Transit
NVS
switch
183/200 (SDP with
rejected video line)
RTP speech TDM

MSC
Figure 28 Video to Audio fallback due to the MGW on the user plane
Installation and activation

For instructions, see the feature activating instructions of Feature 1823: SIP Video Tele-
phony Interworking.
2.9 Call Transfer support on SIP

The Explicit Communication Transfer (ECT) service provides the possibility of call
transfer which enables a served user involved in a communication to transfer that com-
munication to a third party. When using the Session Initiation Protocol (SIP), the call
transfer is an end-to-end feature which means that the network does not play any role
in the transfer. However, this leads to the following problems in the network:
• charging does not follow the CS-like (fixed or mobile) logic,
• the transferred call cannot be intercepted,
• the transfer target cannot be anonymous,
60 Id:0900d80580652d04
• the functionality does not work if subscriber B does not support the REFER method.
This feature introduces the REFER interworking which means that the NVS of the trans-
ferrer terminates the REFER and connects subscribers B and C using a third-party call
control logic.
This feature also introduces the handling of the REFER method in the Media Gateway
Control Function (MGCF) but because of charging- and interception-related problems,
it is recommended to be used in special scenarios where the sender of the REFER is a
trusted element (for example, a voice mail system). It is not recommended to accept
REFER from end users on this interface.
For related information, see Feature 1844: Call Transfer Support on SIP, Feature
Description.
2.10 SIM-based authentication for NVS convergence

SIM authentication based on Digest AKA and TLS is the key mechanism that enables
secured access to Voice Over IP Server (NVS) in the MSS FMC solution when a SIP
client uses USIM/IMSI as a subscriber identity source. Nokia Siemens Networks Com-
munication Suite (NCS) is located in a USB stick with a SIM reader and it accesses
standalone NVS over broadband connection.
The registration functionality includes optional end-to-end authentication. Feature 1673,
NVS Registration defines authentication using HTTP Digest (according to RFC2617,
HTTP Authentication: Basic and Digest Access Authentication). This feature enhances
authentication with the implementation of Digest AKAv1 and AKAv2 (according to
RFC3310, Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentica-
tion and Key Agreement (AKA) and RFC4169, Hypertext Transfer Protocol (HTTP)
Digest Authentication Using Authentication and Key Agreement (AKA) Version-2).
For related information, see Feature 1863: SIM-based Authentication for NVS Conver-
gence, Feature Description.
2.11 Early media handling

MSS/NVS uses the early media functionality to provide audible information to the calling
party during call setup. MSS can play various setup phase announcements to the calling
party such as:
• pre-connection announcements (triggered from analysis or IN)
• call forwarding announcements
• ringback tone
For more information about announcements and tones, see Announcements.
MSS/NVS uses the MGW to play announcements by controlling it with the H.248
MEGACO protocol.
When the MSS/NVS works in CMN=INACTIVE mode (for example, MGW is configured
to be used during the whole call) and an announcement needs to be played, the follow-
ing actions are done:
• if the bearer is not established, the MSS requests the MGW to reserve the incoming
side termination. This termination is used to send the early media. MSS/NVS can
communicate this termination to the calling party in an SDP in various ways. For
related information, see section Communicating the SDP on SIP.
Id:0900d80580652d04 61
• if the incoming termination is already reserved towards the calling party, that termi-
nation will be used to send the media. In this case the SDP representing the termi-
nation is already communicated on SIP.
When the MSS/NVS works in CMN=ACTIVE mode (for example, the MGW is configured
not to be used during the whole call), the call setup phase announcement can be played.
This means that the MSS/NVS changes its mode to CMN inactive and uses the MGW
to play the announcement. After the announcement, if needed, the termination is
removed and the MSS/NVS moves to CMN mode again. The CMN mode change for the
ringback tone is currently not supported.
When the MSS/NVS is in CMN mode and needs to play an announcement (for example,
a Call Forwarding announcement), the MSS requests the MGW to reserve the incoming
side termination. This termination is used to send the early media. MSS/NVS can com-
municate this termination to the calling party in an SDP in various ways. For related
information, see section Communicating the SDP on SIP. After the announcement, the
CMN mode is not automatically restored but is based on the coming CMN mode analy-
sis.
Note the following:
• The whole section applies also to the SIP-I/SIP-T interface.
• The whole section and the described use cases apply to both the Standalone and
Application Server modes.
2.11.1 Communication of SDP on SIP

To be able to play an announcement, the MSS selects a codec from the incoming SDP
and the MGW to reserve an incoming termination towards the calling party with this
codec. The MGW responds with termination-related information such as the IP address
and port, and the MSS/NVS creates the answer of the SDP based on these.
In these cases the P-Early-media header is turned off for more convenient use.
CMN inactive mode

When the MSS is in CMN inactive mode during the whole call, the communication of the
SDP on SIP is simple. The exact call flow varies based on the SIP calling party's capa-
bilities and the MSS configuration:
• support of PRACK (RFC 3262) in the preceding element (for example, user agent
or soft switch)
• support of precondition framework (RFC 3312) in the preceding element
• Extra FQDN configuration of the incoming CGR
The following cases are applicable for a standard call setup established for a conversa-
tion.
• SIP client without PRACK, precondition support, default configuration
The following figure illustrates a call flow where the calling party supports only the
basic SIP RFC 3261 and there is no PRACK support.
62 Id:0900d80580652d04
SIP-A MSS/NVS
INVITE (SDP offer A)
Announcement needed
Select codec and reserve

incoming termination MGW
Order MGW to play the

announcement
Continue call towards the called

party on ISUP/BICC/SIP etc.
180 Ringing
Call answered by party B
200OK (SDP answer from MGW)
ACK
Figure 29 SIP client without PRACK, precondition support, default configuration

In this case the SDP can be sent to the calling party (user agent, soft switch) only in
the 200OK message since all the other responses are unreliable. This means that
the RTP stream is sent to party A without sending the SDP to it. This usually works
for user agents because they can receive media immediately after they sent the
INVITE message on the listening media part and with any of the supported codecs.
But in certain cases party A does not hear the announcement because there is a
Session Border Controller (SBC) for the firewall between the SIP-A and the
MSS/NVS.
• When the SBC is installed, it needs an SDP answer to authorize the remote
party media port. If the SDP does not receive the SDP answer, it will reject the
RTP packets and will not send them towards the user agent.
• When there is only a firewall between party A and the MSS, the firewall can be
opened by the user agent. To open the firewall, the user agents usually send an
RTP packet to party B (for example, to the MGW in this case) and the firewall
lets the RTP packets inside on the same port. This means that the user plane
must use a symmetric RTP. UPnP is not widely supported by user agents, so
when the user agent receives an SDP, it immediately sends at least one RTP
packet towards the MGW to open the port on the firewall.
To solve the problem, there is an option in the Extra FQDN configuration (JNM) to
turn on the unreliable SDP sending function.
• SIP client without PRACK, precondition support, unreliable SDP sending is turned
on
When the unreliable SDP sending is turned on, the MSS/NVS sends the SDP in
unreliable responses. This is allowed by RFC 3261 too. Note that the configuration
parameter has no effect when the PRACK is supported.
Id:0900d80580652d04 63
SIP-A MSS/NVS
INVITE (SDP offer A)
Announcement needed

183 Session Progress
(SDP answer from MGW)

announcement

180 Ringing (SDP answer from MGW)

200OK (SDP answer from MGW)
ACK
Figure 30 SIP client without PRACK, precondition support, unreliable SDP

sending is turned on
If the unreliable SDP sending is turned on, the MSS/NVS sends the SDP in all the
responses (according to RFC 3261) including the 180 Ringing and 200OK
messages too. The SDP is always sent first in a 183 Session Progress. This
solves SBC- and firewall-related problems.
In the Extra FQDN configuration there are two choices to determine when the first
183 Session Progress is sent. These choices are as follows:
• The SDP is sent immediately when the termination/bearer is reserved in the
MGW.
• The SDP is sent first when the early media is sent. This is triggered by, for
example, an ISUP ACM with the InbandInfoAvailable=TRUE parameter.
After the SDP is sent, it is repeated in all the responses.
If the MSS/MGW is configured to CMN inactive mode, the second option (send the
SDP when IBI=True) has no real advantage and the first option is preferred. The
second option can be chosen when the CMN mode can change during call setup.
• SIP client with PRACK support, without precondition support
The INVITE message can contain the support for reliable provisional responses
which allows the reliable sending of the SDP. According to RFC 3262, reliable pro-
visional response sending is indicated by the Supported:100rel header in the
INVITE message.
If the Supported:100rel header is received by the MSS/NVS, the SDP is always sent
to party A in a 183 Session Progress message when the termination is
reserved. The Unreliable SDP sending Extra FQDN parameter has no effect.
After the 183 Session progress, the coming responses cannot contain any SDP
(according to RFC 3262). The use of PRACK also solves the firewall- and SBC-
related problems mentioned above.
64 Id:0900d80580652d04
SIP-A MSS/NVS
INVITE (SDP offer A, supported: 100rel)
Announcement needed

(SDP answer from MGW)
PRACK
200OK

announcement

180 Ringing

200OK
ACK
Figure 31 SIP client with PRACK support, without precondition support

Note that the MSS/NVS uses the PRACK method (for example, in case of reliable
response sending) when it adds SDP or ISUP content to the response. If PRACK is
not supported, the MSS still adds the ISUP content to the unreliable responses.
• SIP client with PRACK, precondition support
When the precondition is supported, party A can withhold the connection of early
media until it sends a notification indicating that the bearer is ready. This case is very
similar to the previous PRACK case but in this case SIP-A delays the MSS using the
precondition mechanism.
Note that
• Using the precondition mechanism is not possible without PRACK support.
• Precondition is usually not supported by user agents and soft switches. This
means that the MSS never mandates the usage of this extension.
• Precondition is similar to the COT functionality on ISUP.
Id:0900d80580652d04 65
SIP-A MSS/NVS
INVITE (SDP offer A, precondition,

supported: 100rel)
Announcement needed

Reserving bearer
UPDATE (SDP: precondition OK)
200OK (SDP from MGW)

announcement

180 Ringing

200OK
ACK
Figure 32 SIP client with PRACK, with precondition support
CMN active mode

When the MSS is in CMN active mode during the whole call or partially during the call
setup, the communication of SDP on SIP is more complicated. The exact call flow varies
based on the SIP calling party's capabilities and the MSS configuration:
• support of the PRACK method (RFC 3262) in the preceding element (for example
user agent or soft switch)
• support of the precondition framework (RFC 3312) in the preceding element
• support of the UPDATE method (RFC 3310) in the preceding element
• Extra FQDN configuration of the incoming CGR
The cases are very similar to the CMN inactive case but due to the CMN mode change
more than one SDPs should be communicated towards party A.
In this section an example call case is used to describe the functionality. The case
shows an NVS use case (call forwarding) but it is also valid for MGCF and SIP-I trunk
cases where the Call Forwarding is actually rerouting.
An example call case:
• Party A calls party B, CMN mode is configured.
• There is SDP early negotiation between A and B.
• CFNA is executed for C.
• The CFNA announcement is configured, CMN mode changes to inactive.
• The call is routed on SIP-I to the next node, CMN mode is active again.
66 Id:0900d80580652d04
During “call forwarding”/ ”rerouting”, the CMN mode can change too. For example, the
SIP-SIP call is begun to be established in CMN mode but the call is released towards
party B and rerouted on ISUP where CMN mode is not possible.
Note that precondition use cases are not described.
• SIP client without PRACK, default configuration
When the call setup is established between SIP-A and SIP-B, B sends the SDP in a
183 Session Progress message but since party A does not support the sending
of the reliable SDP and Extra FQDN is not configured, SDP 2 is not sent. When the
call is forwarded, the MSS reserves a termination and plays the announcement but
the SDP representing the MGW termination is not sent to user A.
When the call continues, the CMN mode analysis is configured so that between all
types of SIP signaling CMN active mode would be used.
When the SDP is received from the succeeding SIP-I node, SDP 3 is not communi-
cated to user A immediately but sent only after party C answered.
Id:0900d80580652d04 67
SIP-A MSS/NVS SIP-B MSS C
INVITE (SDP 1 )
INVITE (SDP 1, supported:100rel)
183 Session Progress (SDP 2)
PRACK
200OK
180 Ringing
180 Ringing
CFNA started, call towards B is released
CF announcement needed
announcement
181 Call is being forwarded
Continue call towards party C

on SIP-I
SIP->SIP-I CMN mode configured.

Release termination in MGW,
restore CMN mode.
INVITE (IAM, SDP 1, supported:100rel)
PRACK
200OK
180 Ringing 180 Session Progress (ACM(CalledPrtyState=FreeInd))
PRACK
200OK
200OK(SDP 3) 200OK(ANM)
ACK ACK
Figure 33 SIP client without PRACK, precondition support, default configuration

• SIP client without PRACK, unreliable SDP sending is turned on
When the Unreliable SDP sending is turned on to send the SDP during bearer res-
ervation, SDP 2 is sent without PRACK when it is received from SIP-B.
According to RFC 3261, the same SDP needs to be repeated until the 200OK is sent.
So the SDP for the announcement and the SDP received from the SIP-I node cannot
be sent. When the call is answered, the NVS/MSS sends a reINIVTE message with
the last received SDP to make the user plane routed. This means that possibly the
announcement is not heard by SIP-A.
68 Id:0900d80580652d04
INVITE (SDP 1 )
183 Session Progress (SDP 2) 183 Session Progress (SDP 2)
PRACK
200OK
180 Ringing
180 Ringing (SDP2)
announcement
181 Call is being forwarded (SDP 2)

on SIP-I

restore CMN mode.

PRACK
200OK
180 Ringing (SDP 2) 180 Session Progress (ACM(CalledPrtyState=FreeInd))
PRACK
200OK
ACK ACK
reINVITE (SDP 3)
200OK (SDP 4)
ACK

sending is turned on (send SDP immediately)
If the Extra FQDN configuration is configured to send the SDP when the early media
is sent, the first sent SDP comes from the MGW, and this SDP is repeated until the
call is answered.
Id:0900d80580652d04 69
INVITE (SDP 1 )
PRACK
200OK
180 Ringing
180 Ringing
announcement

(SDP 3 from MGW)

on SIP-I

restore CMN mode.

PRACK
200OK
180 Ringing (SDP 3) 180 Session Progress (ACM(CalledPrtyState=FreeInd))
PRACK
200OK
ACK ACK
reINVITE (SDP 4)
200OK (SDP 5)
ACK

sending is turned on (send SDP early media detected)
Note that when the succeeding node signals the presence of early media (in ISUP
ACM or using P-Early-media on SIP), the pending SDP is also sent. So for example
when SIP-B sends the PEM header in the 183 or 180 Ringing messages, the
SDP will be sent.
• SIP client with PRACK, without UPDATE support
When the reliable SDP sending is supported, the first received SDP is sent (for
example, SDP 2). Afterwards only the UPDATE method support allows to make a
new SDP offer/answer. Since it is not supported by party A, the SDP 3 (as the last
SDP) is sent in a reINVITE message.
70 Id:0900d80580652d04
INVITE (SDP 1, Supported:100rel,

Allow:UPDATE)
PRACK PRACK
200OK 200OK
180 Ringing
180 Ringing
announcement

on SIP-I

restore CMN mode.

PRACK
200OK
PRACK
200OK
200OK 200OK(ANM)
ACK ACK
reINVITE (SDP 3)
200OK (SDP 4)
ACK
Figure 36 SIP client with PRACK, without UPDATE support

• SIP client with PRACK, with UPDATE support
If UPDATE is supported, all the SDPs can be communicated to party A:
Id:0900d80580652d04 71
INVITE (SDP 1, Supported:100rel,

Allow:UPDATE)
PRACK PRACK
200OK 200OK
180 Ringing
180 Ringing
announcement
UPDATE (SDP 3 from MGW)
200OK (SDP 4)

on SIP-I

restore CMN mode.
UPDATE (SDP 5) 183 Session Progress (SDP 5)
200OK (SDP 6) PRACK (SDP 6)
200OK
PRACK
200OK
200OK 200OK(ANM)
ACK ACK
Figure 37 SIP client with PRACK, with UPDATE support
2.11.2 Indication of early media on SIP

The MSS/NVS can indicate the presence of the early media on SIP by using the P-Early-
Media SIP header. The P-Early-Media (PEM) header is standardized by RFC 5009. The
header is used on all SIP interfaces but ignored on the Normal SIP access and ISC SIP
Access interfaces. This means that the header is sent to the user agents on these inter-
faces but NVS ignores the header in SIP responses received from the called party.
Since the header is supported by core network elements and the user agents usually do
not support this header, the usage of the header is not required on the SIP access inter-
faces.
72 Id:0900d80580652d04
Using the PEM header on the SIP-I interface is recommended in cases where there are
certain network elements in the network (for example MSS, MGCF) which can interwork
with the SIP-I and MGCF SIP interfaces in CMN mode (for example, in B2B proxy
mode). In these cases the SIP-I node controlling an MGW needs the ringback tone con-
nection functionality.
When the PEM header usage is activated, NVS/MSS adds the header to the 18x
responses in the following cases:
• NVS/MSS locally generates the announcement/tone: when the announcement or
tone needs to be played, the incoming termination is reserved and NVS/MSS sends
an 18x response with the P-Early-media:sendonly header. The header type
depends on the use case:
• The 183 Session Progress response is used when a normal preconnection
announcement needs to be indicated.
• The 181 Call Is being forwarded response is used when the CF
announcement needs to be played during call forwarding.
• The 180 Ringing response is used when the ringback tone is connected.
• NVS/MSS receives ACM/CPG: MSS/NVS working as a SIP to CS interworking point
can receive ACM and CPG messages with the InbandInfoAvailable parame-
ter. MSS maps this to an 18x message (the exact message type depends on the
other parameters of the ISUP/BICC message) with the following possible PEM
headers:
• IBI = TRUE is mapped to P-Early-Media: sendonly
• IBI = FALSE is mapped to P-Early-Media: inactive
• IBI not exist is mapped to P-Early-Media: supported
The SIP->CS direction mapping is symmetric to this mapping.
• NVS/MSS receives an 18x message with the PEM header. It works in the same way
as in case of ISUP.
• When the MSS/NVS reserves the incoming termination, the SDP will be sent in a
183 Session Progress message which will communicate the SDP and will not
indicate early media. MSS/NVS also includes a P-Early-Media:supported header in
this 183 Session Progress response to inform the previous node that this node
supports the header and this message does not indicate (authorize) early media.
The PEM header is useful only when the connected core network elements support it.
For example in an IMS scenario the feature is useful when the Application Server and
the MGCF are based on the MSS. The PEM header can be used to transfer the ACM-
like messages that are useful to ensure that the ACM timer is stopped in the previous
network element.
For example when the Mobile GSM subscriber makes a call to the SIP network, for
example through an MGCF (or the CS-SIP interworking point) and in the SIP network
the NVS connects a preconnection announcement or CF announcement. To ensure that
the announcement is heard properly by the GSM A mobile, an ACM with IBI=T indication
is needed towards the mobile to reserve traffic channels on the radio side. If the PEM
header is not configured, the inband info is not transferred between the MGCF and NVS
and the announcement cannot be heard. Previously, this problem was solved by an
Extra FQDN parameter which enabled the mapping of the 183 Session Progress
message to an ACM message with IBI=T indication.
Id:0900d80580652d04 73
The SIP->CS and CS-> SIP mapping of the P-Early-Media header is specified in 3GPP
TS 29.163, Interworking between the IP Multimedia (IM) Core Network (CN) subsystem
and Circuit Switched (CS) networks.
Configuration of P-Early-Media header

There are two configuration parameters that affect the P-Early-Media header usage.
These parameters can be configured in the Extra FQDN parameter settings and can
be enabled on different routes.
• Put PEM header to INVITE: you can configure whether the PEM header is added to
the outgoing INVITE message or not.
• Put PEM header to responses: this feature activates the PEM functionality, you can
configure whether to report the inband info status in the PM header. It is possible to
make it dependent on the incoming INVITE PEM header, or always use PEM
header or never use PEM header.
Configuration of Ringback tone connection

The ringback tone connection is also effected by the P-Early-Media header. On all the
trunk interfaces the MSS/NVS is able to connect the ringback tone based on the
outgoing Extra FQDN settings. This helps to ensure that party A will hear the ringback
tone.
The RBTHAN parameter currently is recommended to be used only when NVS/MSS is in
CMN=inactive mode. When MSS/NVS receives a 180 Ringing message on the SIP
interface, the following actions are taken based on the parameter value:
• RINGBACK TONE: NEVER CONNECT: no special action is taken while handling
the 180 Ringing message (for example, no ringback tone is connected)
• RINGBACK TONE: ALWAYS CONNECT: when the 180 Ringing message is
received, the MSS/NVS separates the terminations (for example, no backward
direction media is transferred), reserves tone termination, and connects the
ringback tone towards the calling party (more precisely, the calling party network in
case of MGCF). When the 200OK message is received, the tone is disconnected,
and through connection is done on the user plane.
• RINGBACK TONE: CONTROLLED BY P-Early-Media HEADER: Firstly, it is deter-
mined whether the P-Early-media header is supported by the remote end (succeed-
ing network element)
• if PEM is not supported (no P-Early-media header is received in any of the
responses, for example 180/183/181, so far): the default interface functionality
is executed (MGCF: ALWAYS, ISC:NEVER)
• if PEM is supported (for example at least one response is received with the PEM
header): NVS/MSS examines the current status of the early media (indicated by
former PEM headers and the PEM header of the given 180 Ringing
response):
- if early media is coming from the terminating network when 180 Ringing is
received (for example, the last PEM header contained sendonly/sendrecv), the
ringback tone is not connected and the terminations are not separated.
- if early media is not coming from the terminating network when 180 Ringing
is received (for example the last PEM header contained inactive), the NVS/MSS
connects the ringback tone (if it is not already connected).
Note that:
74 Id:0900d80580652d04
• When an 18x message is received with PEM=sendonly/sendrecv: the ringback tone

is disconnected immediately and through-connection is done (for example let the
backward media go through the MGW towards party A).
• When the given MSS/NVS connects the ringback tone, the P-Early-media header in
the 180 Ringing sent towards party A contains the P-Early-media header:
sendonly (for example, it is indicated that the given MSS already connected the
ringback tone).
• in case of ALWAYS CONNECT the ringback tone is not stopped until the 200OK is
received.
• on the SIP-I interface the PEM header and not the embedded ISUP IBI value is used
for controlling the ringback tone.
The default value is:
• NEVER CONNECT on ISC, SIP Trunk, SIP-I interfaces
• ALWAYS CONNECT on MGCF interface
Configuration of the early ACM generation

Early ACM configuration is useful when the P-Early-Media header is not supported and
there is a need to generate an ACM message to ensure that the media coming from the
succeeding network can be heard by the calling party. If this Early ACM outgoing Extra
FQDN configuration is enabled, an ACM(IBI=T) message will be generated towards the
CS side when the first SDP in a 183 Session Progress response is received. If it
turns out during the call setup that the PEM header is supported, this parameter will
have no affect on the call since it is assumed that the PEM header will contain the ACM
information.
Example for P-Early-Media usage

PEM header usage on SIP-CS interworking point
The following figure illustrates a simple scenario where the MSS functions as a SIP->CS
interworking point.
Id:0900d80580652d04 75
SIP network MSS/NVS CS network
INVITE (SDP A, PEM=supported)
Reserve termination for SIP side
183 Session Progress (SDP MGW

PEM=supported)
PRACK
200OK
HLR inquiry -> CFU

(PEM=sendonly)
CF announcement
IAM
ACM (IBI=T, CdPS=Free)
180 Ringing (PEM=sendonly)
ANM
200OK
ACK
Figure 38 PEM header usage on SIP-CS interworking point

The MSS/NVS receives the INVITE message with PEM support and based on the con-
figuration the MSS decides to use the PEM header and indicates the early media
towards the calling party. The MSS reserves the incoming termination (for example
codec negotiation is turned off or not possible) and sends a 183 Session Progress
message with the SDP representing the MGW termination. This SDP contains the
PEM:supported header to indicate that the MSS supports the PEM header, but this 183
Session Progress does not mean that early media is connected.
If an HLR inquiry is done and CFu is executed, the CF announcement is configured so
that MSS will send a 181 Call Is being Forwarded response with the PEM:sen-
donly header to indicate the early media. Note that this indication is not withdrawn when
the announcement is stopped.
When the call is made on ISUP and the MSS receives an ACM, it is mapped to a 180
Ringing message and due to the IBI parameter, the PEM:sendonly header is added.
PEM header usage and effect on ringbactone connection
The second use case illustrates a much more complex call flow:
• Party A is located in the CS network and calls a SIP user.
• Before party B is contacted, a preconnection announcement is played towards party
A.
• Party B does not answer and CFNA is started.
• The CF announcement is configured.
• The call is routed back to the CS network.
76 Id:0900d80580652d04
The figure shows how the SIP-CS interworking point connects and disconnects the
ringback tone based on the PEM header.
CS network MSS/NVS NVS/MSS SIP UA B NVS/MSS CS network

IAM INVITE (SDP A,
PEM=supported)
Preconnection announcement is
configured, reserve incoming
termination
(SDP B. PEM=supported)
PRACK
200OK
(PEM=sendonly)
ACM (IBI=T)
Call continues, CMN mode
configured, release MGW
termination
INVITE (SDP A)
180 Ringing
CPG (ALERT, IBI=T) 180 Ringing (PEM=inactive)
Connect ringback tone

towards party A CFNA applies, call cancelled towards B
CF announcement
Reserve MGW termination
UPDATE (SDP C
from MGW)
200OK (SDP D)
CPG (IBI=T, 181 Call is being forwarded
CF indicator) (IBI=sendonly)
Stop ringback tone
Forward call. CMN mode

configured, remove
termination.
INVITE (SDP A)
183 Session Reserve

UPDATE (SDP E) Progress (SDP E) termination
200OK (SDP F) PRACK (SDP F)
200OK (SDP G) IAM
180 Ringing ACM (IBI=T,
(PEM=sendrecv) Free Ind)
180 Ringing Ringback tone

CPG (ALERT, IBI=T) (PEM=sendonly) comes from
CS network
ANM 200OK 200OK ANM
ACK ACK
Figure 39 PEM header and ringback tone connection
2.12 SIP protocol

SIP is a text-based and request-response based protocol, and is similar to HTTP in
design. It was developed by the Internet Engineering Task Force (IETF), and gained
popularity in the recent years, mostly in VoIP applications, and became a standard in
Id:0900d80580652d04 77
1999 (IETF RFC 2543 SIP: Session Initiation Protocol, 1999). It has been recently
replaced by a new version (IETF RFC 3261 SIP: Session Initiation Protocol, 2002). The
main functionality of SIP is session initiation, including multiparty, multimedia, or gaming
sessions; but it can also be used for other different purposes, for example, instant mes-
saging or value-added services. Its text-based nature provides great flexibility by inte-
grating the extension of the messages with additional header fields. Users are
addressed with e-mail type SIP URLs, such as sip:john_do@sipnetwork.com.
The structure of a SIP message is:
Request/Response line
Header fileds
Empty line
Message body
Table 1 SIP message structure
The 3rd Generation Partnership Project (3GPP) chose the SIP as the main signaling
protocol in the All-IP core network, and the standards are defined in 3GPP TS 24.228
Signaling flows for the IP multimedia call control based on Session Initiation Protocol
(SIP) and Session Description Protocol (SDP); Stage 3, and 3GPP TS 24.229 Internet
Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP)
and Session Description Protocol (SDP); Stage 3. The baseline SIP protocol was
extended by additional capabilities, for example, reliable provisional responses (PRACK
requests), indication of bearer establishment (UPDATE), and advanced registration to
better fit the protocol in a telephone-like environment and in the operator-subscriber
business model.
The International Telecommunication Union (ITU) has also defined three different SIP
profiles in the context of the Bearer Independent Call Control Protocol (BICC) and SIP
interworking: ITU-T Q.1912.5 Interworking between Session Initiation Protocol (SIP)
and Bearer Independent Call Control protocol or ISDN User Part. ITU specifications are
out of scope of this document, and are described in SIP Interface in MSC Server, Inter-
face Specification.
SIP is a text-based and flexible protocol with many header fields, as defined in the basic
protocol IETF RFC 3261 SIP: Session Initiation Protocol, 2002. This can be further
extended with many header fields, either private (proprietary) or accepted by IETF. The
MSC Server (MSS) SIP implementation uses only a limited set of methods, header fields
and Multi-purpose Internet Mail Extensions (MIME) types.
78 Id:0900d80580652d04
2.13 NVS SIP interface, Standalone Mode

BSC/RNC LDAP HLR
A, Iu MAP over IP
(SIGTRAN)
or
MAP over IP
TDM-based MAP
LDAP (SIGTRAN)
SIP Access SIP Trunk

interface Network C7 (ISUP)
BTS BTS
(3GPP/IETF) interface
(3GPP/IETF)
Mobile Mobile GMSC
VoIP VoIP
MSC Server
domain
SIP softphones
S
DSLAM RTP/UDP/IP C7 (ISUP)
MGW MGW PSTN/

ATM Soft Switch
POTS
S IP
IAD
Multiradio TDM
terminals
POTS
Figure 40 Access and trunk network interfaces of NVS
NVS and MSS SIP have several different SIP interface variants. These are as follows:
• SIP Access interface (NVS)
• SIP Network (Trunk) interface (NVS)
• ISC SIP network interface (NVS)
• MGCF SIP interface (NVS, MSS SIP)
• Session Initiation Protocol for ISDN user part (SIP-I) interface and SIP for Telephone
(SIP-T: a special configuration of SIP-I) (MSS SIP)
The section describes the SIP access and SIP network interfaces of the NVS.
For further information, see 3GPP TS 24.228 Signaling flows for the IP multimedia call
control based on Session Initiation Protocol (SIP) and Session Description Protocol
(SDP); Stage 3. MGCF, SIP-I and SIP-T interfaces are described in SIP Interface in
MSC Server, Interface Description.
The SIP Access interface is a non-trusted interface which typically resides in the public
network. This interface is used to communicate with access type devices, for example,
SIP soft phones, access gateways, Analog Telephone Adapters (ATA), Intelligent
Access Devices (IAD). This interface is based on the main SIP protocol specification,
IETF RFC 3261 SIP: Session Initiation Protocol, 2002, and supports several extensions
defined by additional SIP RFCs.
The SIP Network interface (or SIP Trunk interface) is a trusted interface which is used
to communicate with other network elements, for example, soft switches, SIP proxies,
Id:0900d80580652d04 79
and SIP network servers. This interface is based on IETF RFC 3261 SIP: Session Initi-
ation Protocol, 2002, and supports several extensions defined by additional SIP RFCs.
For information on the interaction between the Intelligent Network Application Protocol
(INAP) and SIP, as well as the interaction between the CAMEL Application Part (CAP)
and the SIP (except for SIP-I and SIP-T) in the MMS-SSP, see Mobile VoIP Server SIP-
INAP and SIP-CAP Interface Description.
NVS acting as a Back-to-Back User Agent

NVS always acts as a Back-to-Back User Agent (B2BUA). When a SIP request is
received on the access or network interface, the NVS may change any of the headers
of the request, and send out a completely new SIP request which is based on the
incoming request. The following modifications are done by the NVS:
• 'Via', 'Record-Route', 'Route' and 'Contact' are always terminated by the NVS and
not proxied to the next node. By doing this, the NVS always hides the network topol-
ogy.
• NVS always allocates new 'Call-ID', 'From' and 'CSeq' tags to the outgoing requests
independently from the received ones.
• The 'To' tag differs on the incoming and outgoing side.
• NVS may change the From header depending on the service executed in the NVS
(for example, Calling Line Identification Restriction (CLIR) or Common SIP URI
for calling subscribers).
• NVS does not proxy all the headers of the incoming request.
• NVS may remove/add/modify P-Asserted-Identity headers to the request.
• The number and type of the messages may differ on the incoming and outgoing
sides due to service execution (for example, handling call forwarding in the NVS or
end user capabilities).
If NVS acts as a Call Mediation Node (CMN), and therefore the MGW is not in the user
plane path, the SDPs received on the incoming side are proxied to the outgoing side with
the following changes:
• The session ID parameter of 'o' line is written with a new value.
• The version parameter of 'o' line is used (for example, incremented) independently
from the incoming side.
If MGW is used on the user plane path, the SDP is terminated by the incoming termina-
tion of the MGW, and the outgoing SDP reflects the outgoing side of MGW termination.
For detailed information on NVS method support and SIP call flows, see Mobile VoIP
Server SIP Interface Description, Standalone Solution.
80 Id:0900d80580652d04
2.14 NVS ISC interface, Application Server Mode
BSC/RNC
IMS
domain BTS
HSS LDAP HLR
MAP over IP
(SIGTRAN)
Dx, Cx, Xs or
MAP over IP
(DIAMETER) TDM-based MAP
LDAP (SIGTRAN)
CSCF BICC,
ISC (SIP) C7 (ISUP)
SIP-T, ISUP
Mg, Mj (SIP)
SIP
Mobile MSC GMSC
VoIP Server
S Multiaccess Server C7 (ISUP)
MSC Server
domain
SIP softphones
S
MGW MGW PSTN/

ATM Soft Switch
POTS
S IP
IAD
Multiradio TDM
terminals
POTS
Figure 41 Access and Trunk Network interfaces of the NVS
The NVS and MSS have the following SIP variants:
• SIP Access interface (NVS)
• SIP Network (Trunk) interface (NVS)
• ISC SIP Access interface (NVS)
• ISC SIP Network interface (NVS)
• MGFC SIP interface (NVS, MSS)
• SIP for ISDN user part (SIP-I) interface and SIP for Telephone (SIP-T: a special con-
figuration of SIP-I) (MSS SIP)
This section describes the ISC SIP Access and the ISC SIP Network interfaces of the
NVS.
The SIP Access and the SIP Network interfaces are described in 3GPP TS 24.228 Sig-
naling flows for the IP Multimedia (IM) call control protocol based on Session Initiation
Protocol (SIP) and Session Description Protocol (SDP), Stage 3, while the MGCF and
the SIP-I/SIP-T interfaces are described in the SIP Interface in MSC Server, Interface
Specification.
Id:0900d80580652d04 81
The ISC SIP Access interface is a trusted interface which typically resides in the private
network. This interface is used to communicate with the following SIP legs:
• the incoming SIP leg, originated by the Caller SIP user through the S-CSCF, which
executes the originating services, must send the requests on this interface
• the outgoing SIP leg, terminated by the Called SIP user through the S-CSCF, which
executes the terminating services, receives the requests on this interface
The ISC SIP Network interface, or the ISC SIP Trunk Interface, is a trusted interface.
The ISC SIP Network interface is used:
• to receive SIP requests from the S-CSCF for executing terminating services
• to send SIP requests to the S-CSCF to continue the execution of the originating ser-
vices.
This interface is based on the 3GPP TS 24.229 Internet Protocol (IP) multimedia call
control protocol based on Session Initiation Protocol (SIP) and Session Description
Protocol (SDP) specification and the IETF RFC 3261: SIP: Session Initiation Protocol
main SIP protocol specification, and supports several extensions defined by additional
SIP RFCs.
The following figure shows the usage of the interfaces.
NVS
Originating service
execution
ISC SIP Access ISC SIP Network

interface interface
INVITE INVITE
towards caller SIP UA towards IMS network

S-CSCF
Figure 42 NVS executing originating services
When the originating S-CSCF wants to execute the VoIP-related originating services for
the caller, it proxies the request on the ISC SIP Access interface. When the originating
services are executed, the NVS sends back the modified request to the S-CSCF on the
ISC Network interface which either continues the service execution with other applica-
tion servers or starts to locate the called party.
82 Id:0900d80580652d04
NVS
Terminating service
execution
ISC SIP Network ISC SIP Access

interface interface
INVITE INVITE
towards IMS network towards called SIP UA

S-CSCF
Figure 43 NVS executing terminated services
When the terminating S-CSCF wants to execute the VoIP-related terminating services
for the called party, it proxies the request on the ISC SIP Network interface. When the
terminating services are executed, the NVS sends back the modified request to the S-
CSCF on the ISC SIP Access interface which either continues the service execution with
other application servers or sends the request to the called party.
NVS ISUP/BICC/SIP-I
Originating service CS domain
execution
SETUP
ISC SIP Access

interface
INVITE
towards caller SIP UA towards IMS network

S-CSCF
Figure 44 NVS originating SIP call from the CS domain towards the called party on
the ISC interface
The originating service handler NVS or o-NVS can be configured so when it receives the
INVITE on the ISC Access interface, the request is not sent back to the S-CSCF.
Instead, the NVS is used to forward the call to the PSTN (AS-terminated call).
Id:0900d80580652d04 83
ISUP/BICC/SIP-I NVS
CS domain Terminating service
execution
SETUP
ISC SIP Access

interface
INVITE
towards IMS network towards called SIP UA

S-CSCF
Figure 45 NVS terminating SIP call from the caller towards the CS domain on the ISC
interface
The CS-originated call can be sent to the NVS where the called party is registered and
the NVS is used to forward the call to the IMS network on the ISC Access interface (AS-
originated call).
SIP call flows

For detailed information, see section SIP call flows in Mobile VoIP Server ISC Interface
Description, Application Server Solution.
2.15 NVS LDAP interface

This section describes the external Lightweight Directory Access Protocol (LDAP)
interface of the NVS, and it applies to both the standalone and the application server
solutions.
84 Id:0900d80580652d04
BSC/RNC LDAP HLR
A, Iu MAP over IP
(SIGTRAN)
or
S-CSCF MAP over IP
LDAP TDM-based MAP
(SIGTRAN)
ISC
interface
SIP Trunk
SIP Access Network C7 (ISUP)
BTS BTS
interface interface
(3GPP/IETF) (3GPP/IETF)
Mobile Mobile GMSC
VoIP VoIP
MSC Server
domain
SIP softphones
S
MGW MGW PSTN/

ATM Soft Switch
POTS
S IP
IAD
Multiradio TDM
terminals
POTS
Figure 46 LDAP interface of NVS
NVS that offers SIP interface uses the combination of HLR and external database or
LDAP directory in order to maintain SIP subscriber related information.
This solution does not cause any new requirements for the HLR NE or for MAP inter-
faces related to that interface. This is achieved by introducing the external database, the
purpose of which is to store SIP subscription-related information and to provide LDAP
towards the MSS in order to retrieve this information.
This external database can be, for example, an existing database that is needed by
some other application. The NVS requires the information about each SIP subscription
that is known in the network and needs to contain information according to the LDAP
schema defined by Nokia Siemens Networks. This information consists, for example, of
the following elements:
• a SIP subscriber's AddressOfRecord, that is, a SIP URI used by the SIP UA to
register to the MSS
• a user name and password for the HTTP-digest authentication purposes
• other information needed by the NVS to simulate GSM/3G behaviour towards other
NEs
The DX 200 NE searches and fetches LDAP objects from the external LDAP server. The
NE does not modify the data in the repository nor add new objects. This means that only
the 'bindRequest', 'searchRequest', 'bindResponse', and 'searchResponse' LDAP oper-
ations are exchanged between the NE and the repository. For more information on
LDAP operations, see Figure LDAP protocol layers below, or RFC 1777 and RFC 2251
technical specifications.
Id:0900d80580652d04 85
NE LDAP server
LDAP bindRequest
LDAP searchRequest
LDAP client LDAP server
functionalities LDAP bindResponse application
LDAP searchResponse
TCP Transport layer (TCP) TCP
Network layer (IP)

IPv4/v6 IPv4/v6
Figure 47 LDAP protocol layers

For more information on the supported LDAP versions, LDAP messages, and the
schema of the LDAP server data used by the Mobile VoIP Server, see Mobile VoIP
Server LDAP Interface Description.
Configuration
For instructions on creating LDAP server configuration, see LDAP Server for Mobile
VoIP Server.
See also Linux Installation in DX200 HW.
2.16 Session Initiation Protocol in the MSC Server

SIP in the MSS is part of the signaling services in the Network-Network Interface (NNI)
and improves the interworking between legacy circuit-switched networks and the 3G
UMTS IP multimedia network in the evolution towards an all-IP network.
The MSS has different SIP interface variants, which can be divided into two categories.
SIP is used as trunk signaling similar to BICC, and as the SIP interface of the MGCF.
SIP as trunk signaling has the SIP-I and SIP-T interface (a special configuration of the
SIP-I interface) variants.
The MGCF interface also has two varieties:
• the 3GPP-compliant interface
It is compliant with the 3GPP IMS standards.
• IETF interface
IETF proxies and user agent are assumed.
The MSS acts as an MGCF in the 3GPP network architecture. This interface exists both
in MSS and the Gateway Control Server (GCS) products. In the Nokia Siemens
Networks solution, all CSCFs along with the BGCF are integrated into the CPS product.
The MGCF in the IMS is a SIP endpoint that initiates and terminates requests on behalf
of the PSTN and MGW. The subsequent nodes consider signaling as if it came from an
S-CSCF. Agreements between network operators can allow PSTN termination in a
network other than the originator's home network to avoid long-distance or international
tariffs. The Nokia Siemens Networks All-IP core network architecture is shown in the fol-
lowing figures.
86 Id:0900d80580652d04
API
APPSE SCE APPSE
CAP
HLR
Network Operator
Application Plane
MAP,
SIGTRAN
A MSC BICC, SIP MSC

GSM PSTN
Server Server
BSS
Megaco/H.248 Megaco/H.248
Control Plane
ATM/IP STM-1 or
Backbone Ethernet
WCDMA lu-CS Network
RAN MGW MGW
Gateway Plane
SCE - Service Creation and BICC - Bearer Independent Call

Execution Platform Control
CAP - Camel Application Protocol MGW - Multimedia Gateway
API - Application Programming Megaco - Media Gateway Control
Interface Protocol
Figure 48 SIP and BICC in the 3GPP circuit-switched core network
Id:0900d80580652d04 87
CPS/
IETF PSTN
proxy
SIP
Mg/
UDP/TCP/SCTP TDM
Mj
IP
SIP-T/SIP-I
BICC/
UDP/TCP/SCTP
A SIGTRAN/IP
BSC MSS IP GMSS
TDM Nc
RANAP
SIGTRAN Mc/Mn Mc
IP
H.248 H.248
TCP/SCTP SCTP/TCP
PSTN IP
TDM IP
RNC ATM MGW IP/ATM MGW

Iu-CS Nb
Mb
Gi
GGSN
Figure 49 Interfaces of the MSC Server
MSS-MSS SIP interface

This interface is a point-to-point interface between the MSSs, so both ends of the inter-
face are MSSs. When SIP is used between more than one MSS for a single call, the
MSS does not act as a SIP proxy, so the messages are constructed from internal Call
Control (CC) messages. This behaviour is described as B2BUA.
Both SIP-T (IETF, obsolete) and SIP-I (ITU-T) can be used between MSSs. They
support GSM or ISDN services more effectively. Both ETSI and ANSI ISUP tunneling is
supported.
The SIP-T interface is proprietary: it is not part of the 3GPP specifications. The
messages are constructed according to the IETF RFC standards and drafts. This inter-
face is now obsolete since the SIP-I interface can be configured to achieve equivalent
functionality. In addition, the SIP-I interface has more advanced features, introduced by
recent SIP-I for Nc developments in 3GPP.
The SIP-I interface is compliant with Profile C of ITU-T Q.1912.5 Interworking between
Session Initiation Protocol (SIP) and Bearer Independent Call Control Protocol or ISDN
User Part, March 2004. The SIP-I interface has almost all the advanced features of the
88 Id:0900d80580652d04
SIP-I interface as defined by 3GPP for the Nc interface, covered by the following 3GPP
specifications:
• 3GPP TS 23.231 SIP-I based circuit-switched core network
• 3GPP TS 29.231 Application of SIP-I Protocols to Circuit Switched (CS) core
network architecture
The MGCF interface is compliant with 3GPP TS 29.163 Interworking between the IP
Multimedia (IM) Core Network (CN) subsystem and Circuit Switched (CS) networks; v
6.4.0.
ISUP tunneling:
Between the MSSs, ETSI and ANSI ISUP tunneling is supported. The ISUP base is indi-
cated in the ISUP MIME base header as defined in IETF RFC 3204 MIME media types
for ISUP and QSIG Objects, December 2001.
Although it is optional, the base ISUP is included when ISUP is tunnelled in the SIP
message.
For more information on the possible values, see section Tunnelled ISUP versions in
SIP Interface in MSC Server, Interface Description.
Call flows:
Because of the flexible usage of SIP header fields and messages, the interface is
described with examples. For detailed information, see section Call flows in SIP Inter-
face in MSC Server, Interface Description.
MGCF SIP interface

There are different types of network elements on the other side of the SIP interface. If
BGCF is used, the MSS connects to that element. If BGCF is not used (it is an optional
element), the MGCF connects to the CSCF, in most cases to the S-CSCF. In the Nokia
Siemens Networks implementation, these functionalities are in the CPS product.
The external SIP interface of the MSS is compliant with IETF RFC 3261 SIP: Session
Initiation Protocol, June 2002. It is also compliant with the current 3GPP IMS standards:
3GPP TS 24.228 Signaling flows for the IP multimedia call control based on SIP and
SDP; Stage 3, v 5.4.0, 3GPP TS 24.229 IP multimedia call control protocol based on
SIP and SDP; Stage 3, v 5.4.0, and 3GPP TS 29.163 Interworking between the IP Mul-
timedia (IM) Core Network (CN) subsystem and Circuit Switched (CS) networks; v 6.4.0.
Call flows:
The typical message flows and the contents of the corresponding SIP messages are
described in section Call flows in SIP Interface in MSC Server, Interface Description.
Supported SIP methods, response codes, header fields and tags

For detailed information, see the following sections in SIP Interface in MSC Server,
Interface Description:
• Supported SIP methods
• Supported SIP response codes
• SIP header fields and tags
Installation, activation, and deactivation

For detailed information on SIP installation and activation, see the feature activating
instructions of Feature 1331: Session Initiation Protocol in the MSC Server.
Id:0900d80580652d04 89
2.17 BICC-SIP interworking

The BICC Protocol and SIP are signaling types used in the Interface Serving Node
(ISN), where there is interworking between the IMS and the CS network.
MSC Server
MSC Server HLR or GCS IMS/IETF Proxy
A MAP SIP
Control Plane
BICC CS2 / 3 SIP-I
IP or ATM
Backbone
Sigtran Sigtran
Megaco / H.248 Megaco / H.248
A
GSM BSS PSTN User Plane
BSSAP
Iu-CS
3G RAN GGSN ext IP netw
RANAP
MGW SGSN MGW
Figure 50 MSC Server network environment

The interworking between different signaling types is important for call establishing and
service which are used between the networks.
Basic interworking between the SIP and the BICC/ISUP has already been implemented
as part of feature 1331: Session Initiation Protocol in the MSC Server. Feature 1451:
IMS-CS interworking extends the interworking according to current 3GPP/ITU-T stan-
dards. There are three different profiles of SIP interworking defined by ITU-T:
• Profile A: 3GPP IMS IW
• Profile B: IETF SIP IW
• Profile C: SIP-T/I (interworking when ISUP tunneling is used)
In case of Profile C, the call control and the user plane handling hide most of the inter-
working, and the tunnelled ISUP content provides the ISUP feature transparency.
Because of the ISUP feature transparency, the SIP-I does not require, for example,
mapping of services, since feature 1331: Session Initiation Protocol in the MSC Server
covers it already.
Feature 1451 handles the case when tunneling is not used, and the BICC/SIP function-
alities and services have to be mapped to SIP. Both UDP and TCP are supported as
signaling transport for SIP. In addition, semi-permanent SCTP associations can be used
optionally to transport SIP messages. With SCTP transport, multi-homing can be used
as well. The semi-permanent SCTP associations are not dynamically created, but they
are created before any SIP call, thus enabling quick re-routing if the association fails.
This feature implements the MGCF interface towards the IMS and the protocol conver-
sion between SIP and the call control protocols used with the MSS:
• SIP/BICC
• SIP/IUP
• SIP/trunk/SS7 signaling
90 Id:0900d80580652d04
• SIP/RANAP
This feature supports mid-call modification in speech phase. However, as this function-
ality does not interwork between the IMS and CS side, TrFO functionality is adversely
impacted by such codec modification.
As the number portability and carrier selection (equal access) ISUP parameters are also
mapped to request URI tags, these features can be used even when tunneling is not in
use.
It is a text-based protocol which makes it very flexible to accommodate services and
easy to implement service ideas. The SIP has excellent support for multimedia, pres-
ence, messaging, and group services as a result of the IETF framework of protocols of
which the SIP can take advantage.
Interworking between the legacy call control protocols and the SIP is still important to
help with providing basic call services for those subscribers who cannot use the SIP, as
they have not migrated to the IMS domain, or their equipment has no support for the IMS
domain yet. The interworking is necessary on message, parameter, and capability
levels.
Due to the easily extensible nature of the SIP, interworking must be provided ranging
from the basic SIP user agents with minimal or no support for SIP extensions to the fully-
fledged SIP user agents supporting all the SIP extensions required by 3GPP or even
some extensions that are not yet widely accepted.
3GPP and ITU-T constantly improve the mapping between the BICC/ISUP and the SIP
service in order to improve subscriber satisfaction due to the insufficient interworking
between these protocols. The most important benefit of this feature is to make this
mapping available as soon as they become known.
This feature also supports mid-call modification in speech phase. However, as this func-
tionality does not interwork between the IMS and the CS side, the TrFO functionality is
adversely impacted by such codec modification.
To request URI tags, support for mapping number portability and carrier selection (equal
access) ISUP parameters have been added in order to provide these features even
when tunneling is not in use, as in the case of IMS.
Extra FQDN Configuration, JN Command Group has been created to allow the defining
of additional hosts to the Fully Qualified Domain Names (FQDN) used in SIP Circuit
Group (SIP CGR) creation. Route FQDN level parameters can also be configured in this
way.
The additional hosts allow more flexible network topology as the incoming request can
be handled by the same SIP CGR as the outgoing request, even if they come from a
different network element (for example, outgoing requests are sent to the I-CSCF and
incoming requests come from the BGCF or directly from the S-CSCF).
The route FQDN level parameters allow that different configuration is used for each
route, for example, the remote port can be different, or number portability or carrier
selection can be enabled/disabled per route.
Another enhancement is that MGCF can work now in Call Mediation Node (CMN) mode.
In this way, if incoming and outgoing user planes are similar, the usage of MGW can be
avoided. This enhancement is based on the merging of the connected functionality with
NVS and thus much configuration flexibility is taken from the NVS. This, for example,
allows that no Domain Name Server (DNS) is used for own FQDN configuration.
Id:0900d80580652d04 91
A related enhancement is that MGCF can now also route multimedia (video) calls to the
interworking point, even if the MGW cannot support Real-time Transport Protocol (RTP)
video calls as the MGW is optimized out of the user plane path. In this case, based on
the SDP, the content correct call type (audio/multimedia) is indicated towards the call
control and the user plane, and the call control can route the calls differently.
The optional SCTP (with multi-homing support) has also been added to the supported
transport protocols for enhanced resilience.
2.18 Incoming CGR and SIP signaling variant selection

When MSS/NVS receives an INVITE message, it selects an incoming Circuit Group
(CGR). This incoming CGR can be used in several call control analyses. The following
sections describe how the incoming CGR is selected on different SIP interfaces and
how it is decided which SIP signaling variant needs to be used.
SIP-I/SIP-T/MGCF/IETF/IP Centrex interface

The SIP-I/SIP-T, MGCF, IETF MGCF, IP Centrex interfaces are provided by the SIGU
and CCSU units of the MSC Server. All these signaling variants use the same listening
IP address/port, so when an INVITE is received, it should be decided which signaling
variant needs to be used. This information also comes from the ASI parameter of the
selected incoming CGR.
When an INVITE is received by the SIGU/CCSU SIP port, the INVITE is examined:
• If the optional Trunk Group ID feature is activated, the Contact header and Request-
URI are checked for a tgrp (Trunk Group ID, IETF RFC 4904) parameter. If the
parameter exists, it is used to determine the incoming SIP CGR.
• If the optional Trunk Group ID feature is not activated, the tgrp parameter is missing,
or if the function used to determine the type of incoming CGR fails because of the
tgrp parameter(s), the topmost via header is identified. This SIP header contains the
previous hop address, for example, the sender of the SIP INVITE. The address in
the Via header can be an FQDN or an IP address.
If the tgrp parameter is used to determine the SIP CGR, the MSS/NVS checks its
internal MFQDN data for an MFQDN record with matching tgrp parameters. When
receiving SIP messages, the tgrp tag in the Contact header corresponds with the remote
Trunk Group ID; the tgrp tag in the Reuqest-URI corresponds with the local Trunk Group
ID.
The Trunk Group ID thus extends SIP CGR selection. See figure SIP CGR selection with
Trunk Group ID.
92 Id:0900d80580652d04
Initial INVITE request
IF=ISC?
Yes
Is
feature No
active?
Yes
PRB=ZS4?
No Yes
TGRP ID
usage
allowed?
No
No Yes
tgrp in top
No most Route
Header
tgrp in
Contact Yes
No
Header
No Yes
MFQDN search
tgrp tgrp with local ID
in in (from top-most Route)
R-URI? R-URI?
Yes No Yes
MFQDN search MFQDN search MFQDN search

with local ID with remote ID with both IDs
(from R-URI) (from Contact) (from Contac & R-URIt)
MFQDN and CGR tgrp in top

search according to No most Route
existing functionality Header
Yes
CGR search with root_fqdn

from MFQDN record
Figure 51 SIP CGR selection with Trunk Group ID

If the Trunk Group ID cannot be used to determine the type of incoming SIP CGR, or the
function fails, the MSS uses the top most Via header value to select the incoming CGR
in the following way:
Id:0900d80580652d04 93
• With the FQDN/IP address located in the topmost via header, MSS searches
through the 'additional host' list of the Extra FQDN database (created by the JNA
command) to select a Root FQDN. The Root FQDN has one to one relation to the
incoming CGR: the name of the FQDN of the incoming CGR (created by the RCC
command) is the same as the Root FQDN in the Extra FQDN database (created by
the JNC command).
• If the FQDN is not found in the MFQDN database, the MSS will search the CGR
database with the Via header FQDN/IPaddress and will check whether there is a
CGR with the same FQDN (created by the RCC command).
If the CGR has been found, the ASI parameter of the CGR indicates which is the
incoming signaling type:
• SI3MX: MGCF 3GPP interface
• SI4MX: SIP-I interface (for example, SIP with ISUP tunneling)
• Si6MX: SIP-I interface (for example, SIP with ISUP tunneling)
• SI7MX: IETF MGCF/IP Centrex interface
Please note that:
• In case of another ASI, the call will be rejected.
• If the CGR is not found, the call will be rejected.
• If the interface is SIP-I, the INVITE message must contain the ISUP IAM message
otherwise the call will be rejected.
• If the interface is MGCF, it can be configured by UTPFIL whether to allow ISUP also
on the SIP MGCF interfaces. By default, the MGCF interface does not use ISUP tun-
neling but in some cases (for example, when IMS is used as a transit IMS for SIP-I,
the 'accepting ISUP on MGCF' feature needs to be enabled). The configurable
values are as follows:
• Ignore ISUP (default): INVITE is handled as ISUP IAM will not be received but
if the SIP message indicates that the ISUP must be handled (Content-Disposi-
tion header), the call is rejected.
• Use ISUP: MGCF switches to a SIP-I interface.
• Reject Request: requests with ISUP information are rejected.
• Forced ignore ISUP: INVITE is handled as ISUP IAM will not be received and
the Content-Disposition header is ignored.
• When MSS sends an INVITE, it adds the network-element-level FQDN (configured
by the JHM command) to the topmost via header, if it is not configured, the unit-level
FQDN or IP address will be added.
NVS SIP Access interface

The NVS SIP Access interface is provided by the SCPU units of the MSC Server. This
interface is used in the standalone NVS configuration. For each unit there is a separate
IP address + port for this interface (Public Normal Interface created by the JIM com-
mand). The signaling variant is determined immediately because of this.
When an INVITE is received on this interface (for example, INVITE is received from
the user agents), the incoming CGR is selected in the following way:
• If the Trunk Group ID feature is enabled, it can be used on the SIP access interface.
If tgrp tag(s) are present, the tgrp tag(s) in the Contact/Request-URI headers are
used.
94 Id:0900d80580652d04
• The LDAP directory contains a Group Profile ID for the given user. If the Trunk
Group ID is not used and the 'Public Domain' parameter in the user-specific Group
profile is configured, then that FQDN will be used for searching the MFQDN param-
eter and CGR database for FQDN match as it is described in the previous section.
• If there is no match or the Group Profile parameter is not configured, the PUBLIC
FQDN FOR SIP ACCESS parameter of the General SIP configuration (JHM
command) is used for MFQDN and CGR database search.
• If the parameter is not configured, the topmost via header is used like in case of the
MGCF interface.
Please note that:
• Searching the CGRs with the via header is not recommended since if the user
agents are connected directly to the NVS, the via header will contain the local IP
addresses of the user agents.
• When the CGR has been found, the ASI must be SI3MX otherwise the call will be
rejected.
NVS ISC SIP Access interface

The NVS ISC SIP Access interface is provided by the SCPU units of the MSC Server.
This interface is used in the Application Server NVS configuration. For each unit there
is a separate IP address + port for this interface (Public AS Interface created by the JIM
command). The signaling variant is determined immediately because of this.
When an INVITE is received on this interface (for example, an INVITE is received from
the originating S-CSCF), the incoming CGR will be selected in the following way:
• Firstly, if Trunk Group ID usage is allowed and there is a tgrp tag in the topmost
Route header, the Trunk Group ID is used for CGR searching. After that (regardless
of Trunk Group ID usage) the NVS removes the topmost Route header (the topmost
Route header contains the SIP address of the NVS configured in the originating iFC
in HSS).
• After the top most Route header has been used, the NVS searches the incoming
CGR in the following order (if the Trunk Group ID is not used):
NVS checks the remaining topmost Route header (for example, the second
topmost) which usually contains the originating S-CSCF address, adds the 'orig.'
prefix to that FQDN, and uses that for MFQDN and CGR database searches.
(Example: scscf.operator.com -> orig.scscf.operator.com).
• If the Route header is not found, then the LDAP directory contains a Group Profile
ID for the given user. If the Public Domain parameter in the user-specific Group
profile is configured, then that FQDN will be used for searching the MFQDN param-
eter and CGR database for FQDN match.
• If there is no match or the Group Profile parameter is not configured, the PUBLIC
FQDN FOR SIP ACCESS parameter of the General SIP configuration (JHM
command) will be used for MFQDN and CGR database search.
• If the parameter is not configured, the topmost via header will be used like in case
of the MGCF interface.
Please note that when the CGR has been found, the ASI must be SI2MX.
NVS SIP trunk interface

The NVS SIP trunk interface is provided by the SCPU units of the MSC Server. This
interface is used in the standalone NVS configuration. For each unit there is a separate
Id:0900d80580652d04 95
IP address + port for this interface (Private Normal Interface created by the JIM com-
mand). The signaling variant is determined immediately because of this.
When an INVITE is received on this interface, (for example, anINVITE is received from
another NVS or on the Ma interface), the incoming CGR is selected in the same way as
it is selected on the MGCF/SIP-I interface:
• If the Trunk Group ID feature is enabled, and tgrp tag(s) are present, then the tgrp
tag(s) in the Contact/Request-URI headers are used.
• if the Trunk Group ID is not used with the FQDN/IP address located in the topmost
via header, the NVS searches through the 'additional host' list of the Extra FQDN
database (created by the JNA command) to select a Root FQDN. The Root FQDN
has one to one relation to the incoming CGR: the name of the FQDN of the incoming
CGR (created by the RCC command) is the same as the Root FQDN in the Extra
FQDN database (created by the JNC command).
• If the FQDN is not found in the MFQDN database, then MSS searches the CGR
database with the Via header FQDN/IP address and checks whether there is a CGR
with the same FQDN (created by the RCC command).
Please note that when the CGR has been found, the ASI must be SI3MX otherwise the
call will be rejected.
NVS ISC SIP trunk interface

The NVS ISC SIP trunk interface is provided by the SCPU units of the MSC Server. This
interface is used in the Application Server NVS configuration. For each unit there is a
separate IP address + port for this interface (Private AS Interface created by the JIM
command). The signaling variant is determined immediately because of this.
When an INVITE is received on this interface (for example, an INVITE is received from
the terminating S-CSCF), the incoming CGR is selected in the following way:
• Firstly, if Trunk Group ID usage is allowed, and there is a tgrp tag in the topmost
Route header, then the Trunk Group ID is used for CGR searching. After that
(regardless of Trunk Group ID usage), the NVS removes the topmost Route header
(the topmost Route header contains the SIP address of the NVS configured in the
terminating iFC in HSS).
• After the removal of the topmost Route header, the NVS searches the incoming
CGR in the following order:
The NVS checks the remaining topmost Route header (for example, the second
topmost) which usually contains the terminating S-CSCF address and adds the
'term.' prefix to that FQDN and uses that or the tgrp tag for MFQDN and CGR
database searches (Example: scscf.operator.com -> term.scscf.operator.com).
• If the Route header is not found, then the LDAP directory contains a Group Profile
ID for the given user. If the Public Domain parameter in the user-specific Group
profile is configured, then that FQDN is used for searching the MFQDN parameter
and CGR database for FQDN match as it is described in the previous section.
• If there is no match or the Group Profile parameter is not configured, then the
PUBLIC FQDN FOR SIP ACCESS parameter of the General SIP configuration (JHM
command) is used for MFQDN and CGR database search.
• If the parameter is not configured, the topmost via header is used like in case of the
MGCF interface.
Please note that when the CGR has been found, the ASI must be SI2MX.
96 Id:0900d80580652d04
2.19 Reachability check

Reachability check based on SIP OPTIONS enhances the resilience of the trunk SIP
interfaces. When UDP is used, it is important to help quick re-routing to avoid 'black-hole
endpoint'. In case of connection-oriented transports, this functionality provides an extra
tool to enhance resilience. The use of OPTIONS enables a quicker reaction than the
session-based refreshment.
SIP OPTIONS pinging (for example, checking reachability) ensures that the remote SIP
stack is up and running, so it has also applicability for TCP and even for SCTP, since
the existence of SCTP/TCP connection does not necessarily mean that the SIP stack
on top of these transport types is working properly.
SIP OPTIONS pinging can be activated on the following SIP interfaces:
• SIP-I/SIP-T interface (provided by SIGU/CCSU)
• MGCF, IETF MGCF, IP Centrex interfaces (provided by SIGU/CCSU)
• Normal SIP Trunk interfaces (provided by SCPU)
SIP OPTIONS pinging is not supported on the Access and ISC interfaces, since re-
routing in not applicable for these interfaces.
Configuration
Reachability check on CGR/MFQDN level can be configured with the JNM command.
• The OCHECK optional parameter specifies the time interval between two OPTIONS
queries. The parameter value is measured in seconds. Maximum 3 minutes (180
seconds) and minimum 5 seconds can be set. The special value zero means that no
OPTIONS based checking is done.
• The OTOUT optional parameter specifies the timeout value of the OPTIONS query.
The parameter value is measured in seconds. Maximum 3 minutes (180 seconds)
and minimum 1 second can be set.
For more information, see JN - Extra FQDN Configuration Commands.
Functionality
The most important aspects of SIP when it is used with the trunk interface and with UDP
transport are as follows:
• If some destination (IP address) becomes unreachable, then retransmission takes
too much time before the call can be re-routed to a working destination.
• Subsequent calls also try the same ('black-hole') destination.
• If there are no call-related SIP messages sent, it is not noticed that the destination
has become unreachable or it takes too much time (for example, when session
refreshment is used).
The reachability of a SIP endpoint is not known before the call setup is tried. It takes too
much time to notice that the destination cannot be reached and this information is not
utilized with subsequent calls.
The aim of this enhancement is that the OPTIONS message is sent to all IP addresses
that can be a target for SIP requests and the reachability of them is constantly moni-
tored. If they cannot be reached, the traffic to them is stopped and thus calls can be re-
routed without delay.
By default, any response received to the OPTIONS query is considered to be successful.
OPTIONS query is not successful in the following cases:
Id:0900d80580652d04 97
• No response to the OPTIONS query is received. The FQDN parameter determines

how long the message can be retransmitted and wait for the OPTIONS response.
After the timeout, the query is considered to have failed. (In-dialog OPTIONS is not
supported in the first phase.)
• If 408 Request Timeout is received and the in-dialog OPTIONS is used, the
query is considered to have failed.
• If 480 Temporarily Unavailable is received and the in-dialog OPTIONS is
used, the query is considered to have failed.
If 503 Service Unavailable is received, the query is not considered to have failed;
however, traffic is blocked on the tunneling SIP interface (SIP-I), the MGCF and NVS
trunks for the time indicated in Retry-After.
Using persistent connections/associations, the OPTIONS-based checking also
enhances the resilience to some extent by monitoring if the target SIP stacks can be still
reached even if there is no signaling traffic.
When the OPTIONS reachability check is activated, the MSS always knows which
addresses returned by the DNS are reachable. The MSS always selects from the reach-
able IP addresses. This means that when some of the remote IP addresses are down
or removed by the operator, the OPTIONS ping ensures that those IP addresses are not
used even if the DNS returns them.
The activation of the OPTIONS-based checking must be carefully planned because it
can have significant impact on the signaling traffic and may create significant signaling
load.
2.20 Trunk Group ID (IETF RFC 4904) support

Through Trunk Group ID support the MSS/NVS SIP routing architecture has even more
flexibility. SIP messages coming from the same IP (transport) address can be routed to
different SIP CGRs. This allows for a single network element to have multiple functions
or serve different subscribers. This can also be important if all the calls arriving at the
MSS/NVS are routed through some aggregate type of network element (for example, an
SBC), and they need to be separated for different SIP CGRs. In addition, all of the calls
of different SIP CGRs in the outgoing direction can be sent toward the aggregate
network element. This functionality is shown in figure Trunk Group ID Support.
98 Id:0900d80580652d04
Realm 1 MSS/MGCF MSS/MGCF Realm 4

NVS R_URI: ...;tgrp=realm-4 Contact: ...;tgrp=realm-1 NVS
R_URI: ...;tgrp=realm-5 Contact: ...;tgrp=realm-2
R_URI: ...;tgrp=realm-6 Contact: ...;tgrp=realm-3
INVITE
SIP SIP
SIP/SIP-I SIP/SIP-I
UP UP
Realm 2 Realm 5
Intermediate NE
that transparently transfers
tgrp in Contact & R-URI
H.248 (e.g. SBC, softswitch) H.248
PBX RTP RTP
Realm 3 Realm 6
MGW MGW
DSLAM
Figure 52 Trunk Group ID Support

This functionality extends the JN MML group and can be controlled at a higher level
using the following PRFILE/FIFILE parameters:
• 002:1559 SIP_TRUNK_GROUP_SUPP - The support of the Trunk Group ID is acti-
vated using this FIFILE parameter.
• 052:0086 SIP_TRUNK_CONTEXT_USED - The trunk-context parameter in
outgoing messages is activated using this PRFILE parameter.
• 052:0087 SIP_TGRP_NORM_ACC_ALLOW - The usage of Trunk Group ID on the
normal access interface is activated using this PRFILE parameter.
For more information, see JN - Extra FQDN Configuration Commands.
Id:0900d80580652d04 99
Managing NVS Nokia Siemens Networks Mobile VoIP Server (NVS)
3 Managing NVS
Configuring registration
This section outlines the major steps that you need to take in order to enable registration
in NVS. For detailed instructions, see the feature activating instructions of Feature 1673:
NVS Registration (Standalone Mode) and Feature 1673: NVS Registration (Application
Server Mode).
1. Configure DNS.
A public and a private DNS are necessary for the proper working of NVS.
2. Configure the LDAP server.
An LDAP server is used to store SIP-specific subscriber data. A primary and a sec-
ondary LDAP server can be connected to an NVS.
For more information on how to install and setup an LDAP server, see also LDAP
Server for NVS, Operating Instructions.
3. Set PRFILE and FIFILE parameters and licences.
Both NVS-specific and parameters commonly used with SIP-I and MGCF are used.
4. Activate NVS functionality.
5. Activate TCP support.
TCP is supported in NVS but it can be switched on and off with parameters.
6. Activate SCTP support.
SCTP is supported in NVS but it can be switched on and off with route parameters.
For SCTP settings, see Feature 1671: NVS Call Handling (Application Sever Mode),
Feature Activation Manual.
7. Configure Location Area Code and Service Area.
A separate Location Area Code (LAC) and Service Area (SA) must exist for SIP sub-
scribers (LAC and SA are SIP Group Profile specific parameters). They are not real
LAC and SA, because the subscriber is always located in the same location Cell
Global Identity (CGI), independently from whatever it registers to its 'home' NVS.
8. Configure NVS address.
Public and private SCPU addresses, FQDNs, and ports have to be configured in
NVS.
9. Map location ID.
Every SIP subscriber can have a location ID in the LDAP server. If it is given, the
CGI is determined from the Location ID mapping table, based on the ID. If it is not
given in the LDAP, the CGI is used from the SIP group profile.
10. Set general SIP parameters.
General SIP parameters valid for the whole NVS can be set. These are, for example,
cleaning time and NVS addresses.
11. Set SIP Group Profile.
There can be a maximum of 300 SIP Group Profiles. The SIP Group Profile ID is
given for each subscriber in LDAP. During registration, the subscriber's data is
downloaded from LDAP and the given profile is used. If the Group ID is not given in
LDAP, the group ID '0' is used.
12. Set SIP Authentication Profile.
There can be a maximum of 50 SIP Authentication Profiles. The SIP Authentication
Profile ID is given for each subscriber in LDAP. During registration the subscriber's
data is downloaded from LDAP, and the given profile is used. If the Authentication
Profile ID is not given in LDAP, the profile ID '0' is used.
100 Id:0900d8058053b530
Nokia Siemens Networks Mobile VoIP Server (NVS) Managing NVS
13. Activate SIP list handling.

There are three different kinds of lists handled by the same MML. Only the Home
and the Denied Domain Lists are used for registration.
14. Create subscriber.
SIP subscribers have to be created in LDAP and HLR with the same IMSI and E.164
number.
NVS subscribers always have to be in HOME PLMN in NATIVE COUNTRY (these are
PLMN parameters).
15. Activate implicit registration for early VCC implementation.
You can activate implicit registration on both the originating and the terminating
sides but use it only for for VCC on the terminating side.
16. Set the User Agent.
Create an FQDN as NVS1.operator.com in the DNS server. This FQDN needs to be
resolved to the Public IP address of the SCPUs or the Session Border Controller if
it is used.
Set the Outbound proxy, Registrar Address, Proxy address to this FQDN in the user
agent.
Configuring call handling

This section outlines the major steps that you need to take in order to enable call
handling in NVS. For detailed instructions, see the feature activating instructions of
Feature 1671, NVS Call Handling (Application Server Mode) and Feature 1671, NVS
Call Handling (Standalone Mode).
1. Configure DNS.
Both NVS-specific and parameters commonly used with SIP-I and MGCF are used.
NVS.
8. Configure route level SIP parameters.
There are several parameters which can be set based on route, for example, remote
port, transport, or supported headers.
9. Set transport and target IP address selection.
The transport and the target IP address selection method can be set based on the
routes.
Id:0900d8058053b530 101
Managing NVS Nokia Siemens Networks Mobile VoIP Server (NVS)
10. Configure SIP routing.

The routing has to be created in NVS for all necessary call scenarios (for example
pre- and digit analysis, CGRs).
11. Map location ID.
General SIP parameters which are valid for the whole NVS can be set. These are,
for example, cleaning time, authentication parameters, and NVS addresses.
SIP Group Profile '0' must be defined for SIM-less emergency calls.
In addition to the Home and the Denied Domain Lists, the Emergency List can also
be set.
15. Configure User Plane.
The User Plane Analysis selects an incoming UPD for the incoming SIP calls and
an outgoing UPD for the outgoing SIP calls, determines the CMN mode, etc.
16. Modify MGW settings.
RTCP has to be disabled for supervision purposes in the MGW. RTCP can be active
for statistical purposes.
17. Set PCM codec.
In NVS and MGW, you can set which PCM codec is to be used: 'A law' or 'u law'.
Each subscriber with SIP access has to be created in the HLR as well as in the
LDAP server with the same IMSI and MSISDN.
Configuring messaging
This section outlines the major steps that you need to take in order to enable messaging
in NVS. For detailed instructions, see the feature activating instructions of Feature 1760,
NVS Messaging (Application Server Mode) and Feature 1760, NVS Messaging (Stand-
alone Mode).
1. Configure DNS.
Set both NVS-specific and parameters commonly used with SIP-I and MGCF.
102 Id:0900d8058053b530
Nokia Siemens Networks Mobile VoIP Server (NVS) Managing NVS
7. Configure Location Area Code and Service Area.

A separate Location Area Code (LAC) and Service Area (SA) must exist for SIP sub-
scribers (LAC and SA are SIP Group Profile specific parameters). They are not real
LAC and SA, because the subscriber is always located in the same location Cell
Global Identity (CGI), independently from whatever it registers to its 'home' NVS.
NVS.
9. Map location ID.
General SIP parameters which are valid for the whole NVS can be set. These are,
for example, cleaning time, authentication parameters, and NVS addresses.
SIP Group Profile 0 must exist for direct message delivery.
There are three different kinds of lists handled by the same MML. Only the Home
and the Denied Domain Lists are used for messaging.
Each subscriber with SIP access has to be created in the HLR as well as in the
LDAP server with the same IMSI and MSISDN.
14. Use the MSC address resolution table.
For direct message delivery, NVS needs the FQDN or the IP address of the target
network element but it knows only its MSC address. The MSC address resolution
table provides the FQDN or the IP address based on the MSC address.
15. Activate SIP messaging and SMS interworking.
SIP message - SMS interworking is possible with NVS. It has to be activated sepa-
rately.
16. Activate end-to-end SIP messaging.
In NVS, end-to-end SIP messaging is achieved with direct message delivery.
17. Configure SMS routing.
SMS routing can be set for the already converted SIP originating messages.
18. Use Display Name information in From header.
If this functionality is turned on, NVS uses Display Name information in the From
header.
Id:0900d8058053b530 103

Mobile VoIP Server (NVS)

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Mobile VoIP Server (NVS)

Uploaded by

Copyright:

Available Formats

Nokia Siemens Networks

Mobile VoIP Server (NVS) and

f Important Notice on Product Safety

The same text in German:

3 Managing NVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Figure 43 NVS executing terminated services . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

1.1 Changes in functionality

Changes in functionality between release M14.4 and M14.3

Changes in functionality between release M14.3 and M14.2

Changes in functionality between releases M14.2 and M14.1

Changes in functionality between releases M14.1 and M14.0

1.2 Changes in documentation

Changes in documentation between issues 6-0 and 5-0

• NVS ISC SIP Access interface

Changes in documentation between issues 5-0 and 4-1

Changes in documentation between issues 4-1 and 4-0

Changes in documentation between issues 4-0 and 3-0

Changes in documentation between issues 3-0 and 2-0

Changes in documentation between issues 2-0 and 1-0

NVS used in Application Server Mode

LDAP DNS SMSC SCP

NVS used in Standalone Mode

A (BSSAP)/ MAP over IP

SIP Access SIP Trunk

MGW MGW PSTN/

2.1 SIP subscriber database

Figure 3 Interfaces towards subscriber information related databases

Figure 4 Client-server connection

2.2 Registration in NVS

2.2.1 Registration in Application Server mode

Subscriber data management

Serving Profile Database (SPD)

ISC SIP ISC SIP

2.2.2 Registration in Standalone Mode

Subscriber data management

2.3 Call handling in NVS

2.3.1 Call handling in Application Server mode

SIP to SIP call

ISC SIP ISC SIP ISC SIP

ISC SIP ISC SIP Nc, PSTN

Optional Mg GCS MGW

Figure 8 SIP to Mobile Station (MS) call

Mobile to SIP call

Nc, PSTN ISC SIP ISC SIP

MGW GCS Mg Optional

Figure 9 MS to SIP call

SIP to PSTN call

ISC SIP ISC SIP PSTN

Figure 10 SIP to PSTN call

PSTN to SIP call

Nc, PSTN Term

Nc, PSTN ISC SIP ISC SIP

Figure 11 PSTN to SIP call

Efficient MGW resource usage

2.3.2 Call handling in Standalone Mode

SIP to SIP call

SIP UA-A NVS NVS SIP UA-B

Optional MGW Optional MGW

SIP UA-A NVS MSC Server

SIP to PSTN call

SIP UA-A NVS

SIP Access ISUP/SIP-I/SIP-T PSTN

PSTN to SIP call

NVS SIP UA-B