Feature 1671- NVS Call Handling (Standalone Mode).pdf

Published on June 2016 | Categories: Documents | Downloads: 43 | Comments: 0 | Views: 170
of 39
Download PDF   Embed   Report

Comments

Content

MSC Server, Rel. M16.2,
Feature Documentation,
version 2
Feature 1671: NVS Call Handling
(Standalone Mode)

DN0621509
Issue 10-0-1

Nokia Siemens Networks is continually striving to reduce the adverse environmental effects of
its products and services. We would like to encourage you as our customers and users to join
us in working towards a cleaner, safer environment. Please recycle product packaging and
follow the recommendations for power use and proper disposal of our products and their components.
If you should have questions regarding our Environmental Policy or any of the environmental
services we offer, please contact us at Nokia Siemens Networks for any additional information.

Feature 1671: NVS Call Handling (Standalone Mode)

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 DOCUMENTATION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDIRECT, 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 2013/12/21. All rights reserved

f

Important Notice on Product Safety
This product may present safety risks due to laser, electricity, heat, and other sources
of danger.
Only trained and qualified personnel may install, operate, maintain or otherwise handle
this product and only after having carefully read the safety information applicable to this
product.
The safety information is provided in the Safety Information section in the “Legal, Safety
and Environmental Information” part of this document or documentation set.

The same text in German:

f

Wichtiger Hinweis zur Produktsicherheit
Von diesem Produkt können Gefahren durch Laser, Elektrizität, Hitzeentwicklung oder
andere Gefahrenquellen ausgehen.
Installation, Betrieb, Wartung und sonstige Handhabung des Produktes darf nur durch
geschultes und qualifiziertes Personal unter Beachtung der anwendbaren Sicherheitsanforderungen erfolgen.
Die Sicherheitsanforderungen finden Sie unter „Sicherheitshinweise“ im Teil „Legal,
Safety and Environmental Information“ dieses Dokuments oder dieses Dokumentationssatzes.

2

Id:0900d80580956c39

DN0621509
Issue 10-0-1

Feature 1671: NVS Call Handling (Standalone Mode)

Table of Contents
This document has 39 pages.
1
1.1
1.2
1.3
1.3.1
1.3.2
1.3.3
1.4
1.4.1
1.4.2
1.4.3
1.4.4
1.4.4.1

DN0621509
Issue 10-0-1

1.4.5
1.4.6
1.4.7
1.4.8
1.5
1.6
1.7
1.8
1.9
1.9.1
1.9.2
1.9.3
1.10
1.11
1.12

Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Benefits for the operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Requirements for using the feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Products. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Functionality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Basic call scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Regulatory services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
NVS support for GSMA IR.92 compliant multimedia telephony (MMTel)
services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Charging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Related and interworking features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Operator interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
MMLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Cause Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Subscriber interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Network elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
External interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2
2.1
2.2

Main changes in Feature 1671: NVS Call Handling (Standalone Mode) 36
Changes in the feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Changes in the document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Id:0900d80580956c39

3

Feature 1671: NVS Call Handling (Standalone Mode)

List of Figures
Figure 1
Figure 2
Figure 3
Figure 4
Figure 5
Figure 6
Figure 7
Figure 8
Figure 9
Figure 10
Figure 11

4

The network architecture of NVS working in Standalone Mode . . . . . . . . 8
SIP to SIP call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
SIP to Mobile Station (MS) call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
MS to SIP call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
SIP to PSTN call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
PSTN to SIP call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Calling Line Identification Restriction (CLIR) . . . . . . . . . . . . . . . . . . . . . 14
Calling Line Identity Presentation (CLIP) . . . . . . . . . . . . . . . . . . . . . . . . 14
CFNR with call forwarding announcement . . . . . . . . . . . . . . . . . . . . . . . 15
History-Info headers with privacy parameter applied during call setup. . 20
Storage of MMTel tag during network registration . . . . . . . . . . . . . . . . . 22

Id:0900d80580956c39

DN0621509
Issue 10-0-1

Feature 1671: NVS Call Handling (Standalone Mode)

Feature description

1 Feature description
1.1

Introduction
The NVS provides GSM-like services to Voice over IP (VoIP) clients. Such services are,
for example, supplementary services, network services, and regulatory services. The
NVS is based on MSS software, so it can provide the same services as an MSS.
The NVS can be used as a standalone mode server to provide a Session Initiation
Protocol (SIP) access interface directly for SIP subscribers, enabling them to use the
same services currently available to GSM and Universal Mobile Telecommunication
System (UMTS) subscribers. Standalone mode runs independently from IP Multimedia
Subsystem (IMS) and there is no requirement for the operator to deploy IMS in order to
provide the SIP interface.
The NVS can also be used as an application server for IMS where the NVS is controlled
by the IMS Service Control (ISC) interface. The purpose of the ISC interface in IMS is
to provide an open interface through which different external application servers can be
connected. This enables flexibility compared to existing circuit switched mobile networks
where specific Customised Application for Mobile Network Enhanced Logic (CAMEL) or
Core Intelligent Network Application Protocol (CoreINAP) protocols are used to provide
a service control interface. In 3GPP IMS, ISC is based on the SIP protocol.
Both modes use the standard DX HLR (HLR) product in order to store SIP subscriber
subscription-related information such as Mobile Subscriber International ISDN Number
(MSISDN), Intelligent Network (IN), and supplementary service-related information. The
HLR is also required to provide functionalities for SIP terminating transactions, such as
VoIP calls and messaging. The HLR does not need any changes because of the NVS.
This document describes standalone mode.

1.2

Benefits for the operator
In early GSM and UMTS networks voice (telephony) services were of primary importance. This is true of VoIP services today, through the use of SIP. VoIP is becoming
more and more significant as a result of the increasing growth in broadband access
throughout all developed countries.
Voice and data services are converging in order to reduce overall expenses for both
operators and end-users. There is a strong need for this development in the market, but
there is also a constant pressure to achieve Capital Expenditure (CAPEX) savings
through the re-use of existing investments such as Circuit-Switched Core Network (CS
CN) infrastructures. It is for these reasons that the SIP register and VoIP feature server
functionalities are implemented in the MSS.
With standalone mode, it is possible to start VoIP services without any major new investments if the MSS from Nokia Siemens Networks has already been deployed, or is
planned to be deployed. When the SIP Access interface is used from an MSS with 3GPP
defined MSS functionality, it is possible to provide services for both fixed and mobile
networks through single converged architecture. Additionally, it is also possible to offer
VoIP calls, message interworking between SMS and SIP messaging as well as end-toend SIP services, for example, direct instant messaging between terminals.
SIP is designed to support VoIP and is the selected protocol for Third Generation Partnership Project (3GPP) IMS networks to establish, modify, and terminate multimedia

DN0621509
Issue 10-0-1

Id:0900d80580956c35

5

Feature description

Feature 1671: NVS Call Handling (Standalone Mode)

sessions or calls. It is a text-based protocol, which makes it very flexible to accommodate new services and implement new service ideas. SIP has excellent support for multimedia, presence, messaging, and group services as a result of the Internet
Engineering task Force (IETF) framework of protocols, which SIP makes use of.

1.3
1.3.1

Requirements for using the feature
Software
This feature requires the following features to be active in the operator's network:




Feature 906: MSRN Allocation Enhancement
Feature 1670: SIP Subscriber Database
Feature 1673: NVS Registration

Malicious call identification functionality requires the following licenses to be activated:




g

PLMN Specific SS-CODE Support in MSS/VLR
For more information on this license, see Feature 1781: PLMN-Specific SS-Code
Support in MSS/VLR, Feature Description. For information on how to enable the
license’s functionality, see Feature 1781: PLMN-Specific SS-Code Support in
MSS/VLR, Feature Activation Manual.
PLMN Specific Services
This is a capacity license. As such you need to make sure that your HLR has enough
space for users who wish to subscribe to the Malicious Call Identification (MCID)
service.
There are different licenses for different PLMN specific SS codes.
Make sure the license PLMN Specific Services is activated. For more information on
this license, see Feature 1761: PLMN-Specific Services, Feature Description. For
information on how to enable the license’s functionality, see Feature 1761: PLMNSpecific Services, Feature Activation Manual.

Calling name presentation (CNAP) functionality for NVS/SIP subscribers requires the
following ON/OFF license to be activated:


g

MSG - CNAP to SIP access interface
This functionality is an extension of CNAP delivery—see Feature 1603: Calling
Name Presentation Alternatives, Feature Description. As such, at least one of the
following functions should first be activated and configured:
• A-party Calling Name Presentation
• B-party Calling Name Presentation
• ANSI TCAP-based Name Database
• MSS-internal Name Database

History-Info header functionality and Communications Diversion (CDIV) service for NVS
requires the following ON/OFF license to be activated:


SIP History Info

T.38 fax data service support for NVS requires the following ON/OFF license to be activated:


6

MSS - Support for T.38 Fax over IP

Id:0900d80580956c35

DN0621509
Issue 10-0-1

Feature 1671: NVS Call Handling (Standalone Mode)

Feature description

Multimedia Telephony video support for NVS requires the following ON/OFF license to
be activated:


MSG - SIP video support

Multimedia Telephony video share support for NVS requires the following ON/OFF
license to be activated:


MSG - SIP video share support

Multimedia Telephony MSRP based services support for NVS requires the following
ON/OFF license to be activated:


1.3.2

MSG - SIP MSRP support

Hardware
This feature requires a MSS and a SCPU.
SIP is a text-based protocol, which requires extra CPU capacity. For the DX platform, a
CP710-A or newer processor is required in the SCPU and in the CM/CMM.

1.3.3

Products
The feature functions in MSS and NVSs which have SIP interfaces available.

1.4
1.4.1

Functionality
General
New SIP interfaces of standalone NVS
NVS introduces new SIP interfaces for MSSr. These are the following:



SIP Access interface
SIP Network interface

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 such as SIP
Soft Phones, Access Gateways, Analog Telephone Adapters (ATAs), and Intelligent
Access Devices (IADs).
The SIP Network interface (or SIP Trunk interface) is a trusted interface which is used
to communicate with other network elements such as soft switches, SIP Proxies, and
SIP Network Servers.
Supported signaling protocols and interworking
NVS supports all signaling protocols supported by the MSS, for example:






DN0621509
Issue 10-0-1

ISDN user part (ISUP)
Bearer Independent Call Control (BICC)
SIP for ISDN User Part (SIP-I)
SIP for Telephony (SIP-T)
SIP Media Gateway Control Function (MGCF)

Id:0900d80580956c35

7

Feature description

Feature 1671: NVS Call Handling (Standalone Mode)

Interworking between these protocols and the new SIP protocols are possible. Interworking is based on 3GPP TS 29.163 Interworking between the IP Multimedia (IM) Core
Network (CN) subsystem and Circuit Switched (CS) networks.

1.4.2

Basic call scenarios
Architecture
The following figure shows the network architecture of NVS working in standalone
mode. The relevant interfaces of the NVS are highlighted in the figure.
LDAP

DNS

SMSC SCP

DNS
BSC/RNC

LDAP

MAP
HLR
CAP/
INAP

A (BSSAP)/
IuCS (RANAP)

MAP over IP
(SIGTRAN)
or
TDM-based MAP

MAP over IP
(SIGTRAN)

BTS

SIP Access
interface

BTS

SIP Trunk
Network
interface
(3GPP/IETF)

(3GPP/IETF)

S

Multiaccess

SIP softphones

Mobile
VoIP
Server

S

S

DSLAM

C7 (ISUP)

Mobile
VoIP
Server

MSS
domain

H.248

SIGTRAN

RTP/UDP/IP

H.248

SIGTRAN

MGW

Transit
ransit Switch
C7 (ISUP)

ATM,
TM, IP
or TDM

SIP deskphones

C7 (ISUP)

SIP-I (profile C)

MGW

PSTN/
Soft Switch

ATM

POTS
S
IAD
POTS

Figure 1

8

Multiradio
terminals

IP
TDM

The network architecture of NVS working in Standalone Mode

Id:0900d80580956c35

DN0621509
Issue 10-0-1

Feature 1671: NVS Call Handling (Standalone Mode)

Feature description

SIP to SIP call
LDAP

SIP UA-A

HLR

NVS

NVS
SIP
Network interface

SIP Access

Optional MGW

SIP UA-B
SIP Access

Optional MGW

IP
backbone

Figure 2

SIP to SIP call

Blue lines show the signaling path, while the red line represents the user plane
path. Dashed lines show alternative flows.
The figure above shows a call scenario when the originating SIP user agent calls
another SIP user agent who is registered under the same network.
The NVS can be configured to support Nokia Siemens Networks Mobile Media
Gateways (MGWs) on the user plane, thus it is possible for the user plane, passing
through the MGW(s) or SIP User Agents (SIP UAs), to exchange Real-time Transport
Protocol (RTP) traffic directly over the IP backbone.
It is not mandatory to use the SIP protocol between the network elements ISUP, BICC.
Other protocols can also be used; however, in such cases the MGW is always needed
for user plane protocol conversion.
If the user agents use logical names (for example, [email protected]) to address each
other, the Lightweight Directory Access Protocol (LDAP) server performs the translation
necessary between the logical names and the MSISDN.
SIP to CS Network
SIP to MS call

DN0621509
Issue 10-0-1

Id:0900d80580956c35

9

Feature description

Feature 1671: NVS Call Handling (Standalone Mode)

HLR

SIP UA-A

NVS
BICC/ISUP/
SIP/SIP-I/SIP-T

SIP Access

MGW

Figure 3

BSSAP/
RANAP

GSM/UMTS
radio network

MGW

SIP to Mobile Station (MS) call

This figure shows the case when a 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).
The access network for GSM/UMTS is not detailed in the figure.
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 to/from
TDM).
MS to SIP call
HLR

NVS
GSM/UMTS
radio network

BICC/ISUP/
SIP/SIP-I/SIP-T

BSSAP/
RANAP

MGW

Figure 4

10

SIP UA-A
SIP Access

MGW

MS to SIP call

Id:0900d80580956c35

DN0621509
Issue 10-0-1

Feature 1671: NVS Call Handling (Standalone Mode)

Feature description

This figure shows the case when a GSM/UMTS subscriber calls a SIP subscriber. The
protocol between the network elements can be any MSS supported protocol (for
example ISUP, SIP-I etc).
The access network for GSM/UMTS is not detailed in the figure.
SIP to PSTN call
SIP UA-A

NVS
SIP Access

ISUP/SIP-I/SIP-T

PSTN
network

MGW

Figure 5

SIP to PSTN call

When the SIP UA calls a PSTN number and the NVS performs the conversion between
the signaling protocols according to 3GPP TS 29.163 Interworking between the IP Multimedia (IM) Core Network (CN) subsystem and Circuit Switched (CS) networks, the
MGW being left to handle the user plane protocol conversion.
As well as ISUP, SIP-I can be used towards PSTN softswitches.
PSTN to SIP call
SIP UA-B

NVS
PSTN
network

ISUP/SIP-I/SIP-T

SIP Access

MGW

Figure 6

PSTN to SIP call

Efficient MGW resource usage
The NVS can work in two modes from the user plane’s 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), CMN mode is not possible
since it would require the user plane to be converted (for example, from IP to TDM).

DN0621509
Issue 10-0-1

Id:0900d80580956c35

11

Feature description

Feature 1671: NVS Call Handling (Standalone Mode)

In CMN mode, it is still possible to provide services through the MGW (for example,
announcements). With these services in operation, the NVS switches to CMN Inactive
mode and reserves MGW resources. When the service is no longer required, the MGW
resources are freed and the call continues in CMN mode.
For more information on Call Mediation Node operation, see User Plane Routing, Functional Description.

1.4.3

Regulatory services
Emergency calls
Using the NVS SIP subscribers can initiate VoIP calls using regulatory-defined
numbers, such as 911, 112, or some other country-specific number. SIP subscribers
can also initiate calls using operator-defined URIs, such as police. In such cases, the
NVS receives the called number/URI that points to an emergency service and, based on
its internal configuration, the MSS selects the proper routable E.164 address toward the
nearest emergency center.
The NVS checks the following list when processing IP calls:


Emergency List

The Emergency List can contain entries that make use of wildcard characters to indicate
emergency numbers—for example, 1234*. However, such numbers are only checked
when the SIP_USE_WILDC_EMERG_NUM (052:0104) PRFILE parameter is set to
TRUE; otherwise, they are skipped.
Thus, when an initial INVITE is received, the called number/URI is first checked against
the list of hard coded numbers, like 911, 112, and so on. It is then checked against the
Emergency List. If the called number/URI is still not found and the
SIP_USE_WILDC_EMERG_NUM (052:0104) PRFILE parameter is set to TRUE, the
entries in the Emergency List that contain wildcard characters are also checked. If the
first part of the number—found in the Request-URI—matches a wildcard entry, the call
is handled as an emergency.

g

Instructions concerning the handling of emergency calls that use wildcard characters
can be found in section Emergency call service of the Feature 1671: NVS Call Handling
(Standalone Mode), Feature Activation Manual.
Example
A PBX subscriber calls the following number: 123456789. Since the
SIP_USE_WILDC_EMERG_NUM (052:0104) PRFILE parameter is set to TRUE, the
wildcard numbers in the Emergency List are checked. An entry beginning 1234* exists,
so the call is handled as an emergency.

g

In addition, the NVS can deliver location information for the SIP subscriber based on the
subscriber’s profile data, stored in the LDAP directory. However, the location information
stored in the subscriber’s profile does not contain the subscriber’s real location, only the
location information that was defined when the subscriber’s profile was initially configured. This can lead to situations where the actual location of the subscriber is unknown.
Number portability
The MSS provides support for number portability (defined by the European Telecommunications Standards Institute (ETSI) in mobile number portability specifications) for sub-

12

Id:0900d80580956c35

DN0621509
Issue 10-0-1

Feature 1671: NVS Call Handling (Standalone Mode)

Feature description

scribers using SIP-based VoIP. Support of mobile number portability is an optional
feature of the MSS. For more information on mobile number portability, see Feature
1081: ETSI Mobile Number Portability, Functional Description.
The NVS provides support for number portability and the transport of SIP parameters in
order to make these features available in the VoIP environment and provides the interworking of information between SIP and CS protocols such as ISUP.
Lawful interception
In SIP networks, lawful interception can be implemented in several ways. One possible
way is to use Session Border Controllers in order to capture the actual content of a call
placed to the authorities. In the MSS, the lawful interception functionality can be handled
using optional Feature 703: On-line Call Monitoring, which enables the collection of
interception-related information as well as the content of communication through the
same interfaces as used for the interception of GSM/UMTS traffic. In these cases, an
MGW is also involved in direct SIP sessions between end users. Note that when SIP
subscribers are using multimedia sessions between each other, the call cannot be intercepted.
Carrier Selection (Equal Access)
The MSS provides support for carrier selection called equal access, (defined by ETSI in
carrier selection specifications) for subscribers using SIP-based VoIP. Support of carrier
selection is an optional feature of the MSS. For more information on mobile number portability, see Feature 1296: Carrier Selection, Feature Description and Feature 818:
World Zone 1 Equal Access and Numbering Plan, Feature Description.
The NVS provides support for the usage of carrier selection (equal access) and SIP
parameters in order to provide these features in its VoIP environment. It also supports
the interworking of information between SIP and CS protocols such as ISUP.

1.4.4

Services
The aim of VoIP convergence is to enable the subscriber to use the services independently from the access method (that is, control and user plane protocols).
Since the NVS is based on the MSS, it uses all the current functionality of this product,
thus the existing services can be used by subscribers using SIP for access signaling.
The following sections go through the services that NVS offers for Serving Call State
Control Function (S-CSCF) through the (ISC) interface.
Calling Line Identification Restriction (CLIR)
CLIR is an originating service running in the originating NVS. It can be provisioned and
activated in the HLR for each subscriber.
Users can overwrite these HLR settings (for example, temporary with 'presentation
restricted') by using a Privacy header or by entering a dialing function/facility code
before the called party number. Facility/functional codes are defined by 3GPP TS
22.030 Man-Machine Interface (MMI) of the User Equipment (UE). The user can dial the
following, for example:




DN0621509
Issue 10-0-1

tel: *31#12345567
sip: #31#[email protected]
sip: #31#[email protected]

Id:0900d80580956c35

13

Feature description

Feature 1671: NVS Call Handling (Standalone Mode)

A party has CLIR
service enabled

INVITE
From: +123456

INVITE
From: anonymous

NVS originating

Figure 7

Calling Line Identification Restriction (CLIR)

Calling Line Identification (CLIP)
CLIP is a terminating service running in the terminating NVS. It can be configured in the
HLR for each subscriber. This functionality is the same as that used in GSM. If CLIP is
not provided or is inactive for the called party, the identity of the calling subscriber is
hidden. Otherwise, the called party can see the user’s identity.
B party has no CLIP
service provisioned

INVITE
From: +123456

Figure 8

INVITE
From: anonymous

Calling Line Identity Presentation (CLIP)

Calling Line Identification Restriction (CLIR) Override
CLIR override is a terminating service running in the terminating NVS. This function can
be configured in the HLR for each subscriber.
If CLIR override is set for the called party, the identity is shown independently from the
A party option received on the incoming side.
CLI formatting
The operator can reformat the calling party number using MML commands. Calling Line
Identification (CLI) formatting is described in Supplementary Services for Mobile Subscriber, Functional Description.
For more information on restrictions with CLI formatting, see section Restrictions.
Announcements
The NVS can be used to play announcements in different situations, for example:





for the preconnection announcement during call setup
for configuring announcements during call forwarding
for clear code specific announcements when the call ends for some reason
when making announcements for services used by a particular subscriber (for
example, call hold)

When the NVS is working in CMN = ACTIVE mode, the MGW resources are reserved
temporarily, and after the announcement, the resources are freed up.

14

Id:0900d80580956c35

DN0621509
Issue 10-0-1

Feature 1671: NVS Call Handling (Standalone Mode)

Feature description

In this release, announcements in CMN = ACTIVE mode are supported before the
ringing phase. In the case of call forwarding, announcements are supported towards the
forwarded number until the ringing phase begins for the new leg.
Call-forwarding
Call forwarding services enables the user to divert the communication addressed to
him/her to another destination. There is no limitation to this destination, so it can be a
GSM/UMTS number located in other Public Land Mobile Networks (PLMNs), Public
Switched Telephone Network (PSTN) network, or a voicemail system.
The forwarding protocol used towards the new destination can be any kind supported
by NVS (for example: SIP, SIP-I, SIP-T, ISUP, BICC, BSSAP, or RANAP). The operator
can configure call forwarding announcements and SIP notifications (for example: '181
Call Is being forwarded' response) to notify the A party about the event.
NVS supports the following types of call forwarding:







Call Forwarding Not Reachable (CFNR; Not Logged in)
Call Forwarding Busy
Call Forwarding No Answer
Call Forwarding Unconditional
Call Deflection, Call Diversion
IN call forwarding (CAMEL, INAP)

Example for Call Forwarding not reachable:
NVSA

NVSB
SIP

SIP

H.248

MGWA
IP
network

Figure 9

NVSC

TA

TB
C1

SIP

SIP

H.248

SIP

MGWB
TC

TTONE
C2

IP
network

CFNR with call forwarding announcement

Call Forwarding Not Reachable (CFNR) is executed when there is no response from the
called party to the INVITE request. NVS-B executes call forwarding towards the C
number received from the HLR; but before the call is routed to the new destination, a CF
announcement is played. Note that the resources of MGW-B are reserved during the
announcement and only freed up after the announcement.
Call Transfer
NVS supports Call Transfer using the SIP REFER method. For more information, see
Feature 1844, SIP Call Transfer Support, Feature Description.
Barring
NVS supports the following supplementary services that belong to the call restriction
supplementary service (barring):

DN0621509
Issue 10-0-1

Id:0900d80580956c35

15

Feature description

Feature 1671: NVS Call Handling (Standalone Mode)





barring of outgoing calls:
– Barring of All Outgoing Calls (BAOC) (Barring program 1)
– Barring of Outgoing International Calls (BOIC) (Barring program 2)
– Barring of Outgoing International Calls except those directed to the Home PLMN
Country (BOIC-exHC) (Barring program 3)
barring of incoming calls:
– Barring of All Incoming Calls (BAIC) (Barring program 1)
– Barring of Incoming Calls when roaming outside the Home PLMN Country (BICRoam) (Barring program 2)

Call waiting
NVS supports the terminal-based call waiting service, meaning that the NVS allows and
does not prevent parallel calls for one user.
Call hold and codec modification
Call hold and codec modification are supported when MGW resources are reserved for
the call by modifying the reserved termination according to 3GPP TS 29.163.: Interworking between the IP Multimedia (IM) Core Network (CN) subsystem and Circuit Switched
(CS) networks.
If the NVS is configured to CMN = Active mode, this functionality has no effect on NVS,
but it is transparently proxied.
Nokia Siemens Networks One Number Service
NVS supports the Nokia Siemens Networks One Number Service solution with both
parallel and sequential alerting for SIP subscribers. This means that the operator can
add SIP subscribers to the ringing group with no restrictions placed on the other group
members. Nokia Siemens Networks One Number Service also includes the Common
CLI functionality which makes it possible to hide the real CLI of the user and even group
several users behind one identity.
For more information see Feature 1545: Sequential Alerting for MultiSIM Service,
Feature Description.
Common SIP URI
The common SIP Uniform Resource Identifier (SIP URI) functionality is similar to the
Common CLI functionality described in Feature 1451: IMS-CS Interworking, Feature
Description. Using this functionality, the operator can hide the real CLI of the user and
can group several users behind one identity.
Intelligent network
The NVS is based on the MSS and supports the CAMEL and CoreINAP interfaces.
Dual-Tone Multifrequency (DTMF) support
The MSS and the MGW support the following Dual-Tone Multifrequency (DTMF) functionalities:



receiving and sending DTMF inband G.711 co
receiving and sending RTP-based DTMF

The MSS can handle out of band DTMF signals as well. Support for out of band DTMF
enables the MSS to handle incoming SIP INFO messages and send them using the
application/dtmf-relay MIME type across all incoming and outgoing SIP interfaces.

16

Id:0900d80580956c35

DN0621509
Issue 10-0-1

Feature 1671: NVS Call Handling (Standalone Mode)

Feature description

This support is license based. The SIP out of band DTMF (FEA=1857) license needs to
be activated. For more information about this support, see Feature 1331: Session Initiation Protocol in the MSS, Feature Description, section Out of band DTMF support in
SIP.
Multimedia Call routing
The NVS can also route multimedia (video) calls to the interworking point even if the
MGW cannot support RTP video calls as the MGW is optimized out of the user plane
path. In such cases, based on the SDP content, the correct call type (audio/multimedia)
is indicated towards call control, thus user plane and call control can route calls differently.
SCTP Support
The NVS provides support for SCTP on all SIP interfaces:






SIP access interface if there is some network element between the NVS and the SIP
subscriber (for example, Session Border Controller (SBC))
IMS Service Control (ISC) interface
SIP trunk interface
MGCF interface
SIP-I interface

Anonymous call rejection
With the help of this supplementary service, the operator can be requested not to
connect calls if the calling party has activated the Calling Line Identification Restriction
(CLIR) service. However, should the operators still wish control over the calls coming
from some kind of signaling where Connected-line-identity Message (CLI) is unavailable
(for example, analog lines), they can control the blocking of these kinds of calls. The
CLIR override functionality is not an acceptable solution due to privacy issues.
The anonymous call rejection functionality is a requirement of the authorities in several
countries. This feature allows flexible configuration for allowing/restricting calls with different CLI presentation statuses.
Anonymous call setup and instant messaging on the SIP Access interface
When an IETF user agent wants to hide his identity, he fills the From header with an
anonymous URI and does not insert any P-header in the request. When the NVS
receives such an anonymous request, it cannot decide which user agent sent the
request. To make the user agent send his identity, the NVS sends a 401 Unauthorized
/ 494 Security Agreement Required response with a WW-Authenticate header which
contains a challenge (nonce). The user agent responds to this request by adding the
Authorization header which includes the mandatory 'username' parameter containing
his/her user identity.
Early answer
The NVS supports an early answer mechanism used over SIP interfaces. This function
allows the original caller’s SIP interface, the A party, to answer the call coming from the
network before the called party’s SIP interface, that is, the B party.
Early answer functionality enables the use of reINVITEs towards the A party to
exchange SDPs that initiate a new offer or provide an answer.

DN0621509
Issue 10-0-1

Id:0900d80580956c35

17

Feature description

Feature 1671: NVS Call Handling (Standalone Mode)

If this function is activated, Ringback tone connection in CMN mode functionality should
also be activated.
Ringback tone connection in CMN mode
The NVS connects the ringback tone if neither the calling nor the called party has connected a ring back tone.
Malicious call identification
The Malicious Call Identification (MCID) service enables SIP subscribers’ incoming
session-related information to be stored by the NVS. This allows the source of malicious
calls to be identified and investigated by the appropriate authorities, such as the
operator and/or regulatory authority.
When an initial INVITE is made, the NVS checks to see whether or not the MCID service
has been provisioned for the called party. If it has, the NVS stores the call-related information, such as the calling and called party numbers and the date and time of the call,
in the subscriber’s MSS Observation Report and the SIP Observation Report (in the
event of a SIP session).
For information concerning how to activate and configure this service, see section Malicious call identification of the NVS and MSS SIP User Guide.

g

The SIP_MCID_MAPPING (052:0096) PRFILE parameter should be enabled to allow
MCID XML mapping toward ISUP. If this parameter is not enabled, the MCID service will
not be able to detect malicious calls originating from ISUP IDR/IDS messages. For more
information, see section Parameters.
Calling name presentation service for NVS/SIP subscribers
The Calling Name Presentation (CNAP) supplementary service is available to both the
calling party (A-party CNAP) and the called party (B-party CNAP). The service provides
subscribers with the means to indicate or hide their name—identity—when making or
receiving a call. The subscriber’s calling name presentation information is taken from the
Nokia Siemens Networks Profile Server (NPS), which serves as a name database.
Further information concerning the basic services of CNAP can be found in Feature
1603: Calling Name Presentation Alternatives, Feature Description.
The basic service of CNAP has been extended to incorporate NVS/SIP subscribers. The
presentation (or display) name information can be placed in the From and/or PAsserted-Identity headers.
Example
From: user1 <sip:[email protected]>;
In this example, user1 represents the display name and sip:[email protected]
(enclosed in <>) the SIP URI.
When an NVS subscriber makes a call, an initial INVITE request is sent toward the
called party. During the SIP call setup process, the NVS checks to see whether or not
the NVS subscriber wishes to display his/her name by examining the value of the
SIP_USE_DISPLAY_NAME (052:0059) PRFILE parameter. If the parameter’s value
is greater than 0 but less than or equal to 3, the NVS adds the subscriber’s display name
to the From and/or P-Asserted-Identity headers of the outgoing INVITE (and all subsequent messages connected with the session).
If the parameter’s value is zero, the NVS will either add the text Anonymous to the From
header, signifying that the CNAP license has been activated but the subscriber has

18

Id:0900d80580956c35

DN0621509
Issue 10-0-1

Feature 1671: NVS Call Handling (Standalone Mode)

Feature description

chosen to withhold his/her display name, or not include any display information, signifying that even though the CNAP license has been activated, the subscriber doesn’t have
a presentation name in the name database to display.
For more information on possible values for the SIP_USE_DISPLAY_NAME
(052:0059) PRFILE parameter, see SIP_USE_DISPLAY_NAME (052:0059).
To activate this service for NVS/SIP subscribers, see section Calling name presentation
toward the SIP access interface of the Feature 1603: Calling Name Presentation Alternatives, Feature Activation Manual.
Communication Diversion (CDIV) using History-Info
The usage of History-Info headers provides a standard mechanism to capture the
request history of a SIP message in order to enable a wide variety of services for
networks and end-users. A SIP message with History-Info headers will deliver information about how and why the message arrived to a device. The NVS provides Communication Diversion (CDIV) support for calls where both ends use SIP signaling using the
History-Info headers. This feature also supports mapping between SIP History-Info
headers and the ISUP Call Diversion service according to the 3GPP TS 29.163: Interworking between the IP Multimedia (IM) Core Network (CN) subsystem and Circuit
Switched (CS) networks specification.
The NVS generates new History-Info headers if diversion services occur during the
internal call routing. When adding new History-Info headers, the NVS will add a Reason
URI parameter header to the penultimate entry, and a cause URI parameter to the last
entry.
Example:
If a request timeout occurs while trying to send a request to
sip:[email protected];user=phone and the call is redirected to
sip:[email protected]:user=phone as a result, the following HistoryInfo headers are added to a SIP message:
History-Info:
<sip:[email protected];user=phone?Reason=SIP%3Bcause%3D40
8%3Btext%3D%22Request%20Timeout%22>;index=1
History-Info:
<sip:[email protected];user=phone;cause=408>;index=1.1
When a SIP message is received with History-Info headers, the NVS searches for a
cause URI parameter first. If a valid cause parameter is found it ignores any Reason
parameters and performs the CDIV service based on the cause code. If a cause URI is
not found or is invalid then the NVS uses the Reason parameter to perform traditional
Call Forwarding (CF).
The NVS also supports the privacy parameter for both incoming and outgoing SIP
messages. A History-Info with a privacy parameter of ‘history’, ‘session’ or ’header’
will not be sent by the NVS, but can stil be used to perform any call or forwarding
services internally. See the following figure for an example of call setup where the
privacy parameter is applied.

DN0621509
Issue 10-0-1

Id:0900d80580956c35

19

Feature description

Feature 1671: NVS Call Handling (Standalone Mode)

UA-C

NVS-A

NVS-B

VoIP

VoIP

UA-E

UA-D

INVITE
INVITE
INVITE
No Reply
Reply Timeout
The call is diverted to sip:E
180 Call is Being Forwarded

INVITE

History-Info: <sip:C>; index=1
History-Info: <sip:D>; privacy=history;index=1.1
History-Info: <sip:E>; index=1.1.1

History-Info is sent with the
reply, but headers with the
privacy parameter are removed.
180 Call is Being Forwarded
History-Info: <sip:C>;index=1
History-Info: <sip:E>;index=1.1.1

Figure 10

1.4.4.1

History-Info headers with privacy parameter applied during call setup

NVS support for GSMA IR.92 compliant multimedia telephony
(MMTel) services
The One Voice Initiative aims to achieve an industry agreement on a harmonized way
to implement voice and SMS over LTE, based on existing standards. This agreement,
described in the One Voice profile, v 1.0.0 (2009-11), and subsequently redefined as
GSMA IR.92, has been used as the basis for implementing a group of common supplementary services defined in 3GPP MMTel Release 9 specifications. These services
include:











20

Originating Identification Presentation (OIP)
Originating Identification Restriction (OIR)
Terminating Identification Presentation (TIP)
Terminating Identification Restriction (TIR)
Communication Diversion (CDIV)
• Communication Forwarding Unconditional (CFU)
• Communication Forwarding on Busy (CFB)
• Communication Forwarding on No Reply (CFNR)
• Communication Forwarding on Not Logged in (CFNL)
• Communication Forwarding on Subscriber Not Reachable (CFNRc)
Communication Barring (CB)
• Barring of All Incoming Calls
• Barring of All Outgoing Calls
• Barring of Outgoing International Calls
Communication Hold (HOLD)
Communication Waiting (CW)

Id:0900d80580956c35

DN0621509
Issue 10-0-1

Feature 1671: NVS Call Handling (Standalone Mode)



Feature description

Message Waiting Indicator (MWI)

Since the SIP protocol already provides IP telephony services, and provides the means
to dynamically modify media components during a session, it has been selected as the
means to deliver MMTel services to subscribers of fixed and mobile IMS-based networks. As such, SIP user agents can make use of the ICSI identifier, included in the
Contact headers of SIP messages, to indicate various services and preferences for multimedia calls between subscribers, including MMTel services.
The NVS is capable of handling several types of media over SDP. In CMN active mode
the NVS can differentiate between Audio, Video, T.38, Video Share and Message
Session Relay Protocol (MSRP) services. In CMN inactive mode, only Audio and T.38
is supported. Adding and removing media or services during a call is supported when in
CMN active mode. Different types of call handling can be configured for each type of
service and media. This allows specific routing and charging to be applied as they are
added or removed from the call.
NVS support for GSMA IR.92 compliant multimedia telephony (MMTel) services, presently, supports MMTel services through the use of the MMTel feature tag, appended to
the ICSI identifier, described in section Handling multimedia information in SIP messages. In addition, this functionality also provides support for call waiting tones as an
alternative to ringback tones in both CMN active and inactive modes through the use of
the Alert-Info header—see section Handling the Alert-Info header.
Further information can be found in the NVS and MSS SIP User Guide, section NVS
support of GSMA IR.92 compliant MMTel services.
Handling multimedia information in SIP messages
The IMS Communication Service Identifier (ICSI) identifies IMS communication services, like MMTel. The service (or feature) tag is appended to the end of the ICSI in a
Uniform Resource Name (URN) contained in one of the following headers:



P-Preferred-Service
P-Asserted-Service

Example:
P-Preferred-Service: urn:urn-7:3gpp-service.ims.icsi.mmtel
It is also encoded in a tag value for +g.3gpp-icsi-ref and appended to the end of
the following headers:




Contact
Accept-Contact
Reject-Contact

The IMS Application Reference Identifier (IARI) identifies additional software applications supported by a SIP UA. This information is used by the NVS to further establish
the capabilities of a device, like the ability to share video. It is encoded in a tag value for
+g.3gpp.iairi-ref and appended to the end of the following headers:




Contact
Accept-Contact
Reject-Contact

The NVS also supports the following additional feature tags for generic multimedia services:


DN0621509
Issue 10-0-1

audio

Id:0900d80580956c35

21

Feature description

Feature 1671: NVS Call Handling (Standalone Mode)




video
+g.3gpp.cs-voice

Example:
Contact: <sip:1.2.3.4>;video;+g.3gpp.cs-voice;+g.3gpp.iariref="urn%3Aurn-7%3A3gpp-application.ims.iari.gsma-vs"
During the registration phase, the Contact header can include a feature parameter to
signal support of multimedia features. The NVS also appends feature tags to the
Contact header during replies to OPTIONS queries.
During call setup, if a P-Preferred-Service or P-Asserted-Service header with an ISCI is
sent with the INVITE request, the terminating user must also have registered his phone
with the service, otherwise the call will be rejected. If a Accept-Contact header is sent
with a service or feature tag, then the terminating SIP side must support the requested
feature or services for the call to be completed. If a Reject-Contact header is sent
instead, the terminating SIP side must not support the given features.
ICSI handling during registration
A SIP UA that supports MMTel services can include ICSI information in the Contact
header of the SIP REGISTER request during registration. While handling the
REGISTER request, the NVS stores the MMTel indicator in the Serving Profile
Database (SPD).

SIP UA

NVS

SIP REGISTER
(Contact:<SIP UA address>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel")
Contact related MMTel information
is stored in SPD
200 OK

Figure 11

Storage of MMTel tag during network registration

Handling the Alert-Info header
The Alert-Info header included in a 180 Ringing response can specify an alternative
ringback tone—for example, it can specify a call waiting tone instead of a ringback tone.
The draft-liess-dispatch-alert-info-urns-02 document specifies the following URN for
Call waiting:
urn:alert:service:call-waiting
This call waiting tone can be connected in both CMN active mode and CMN inactive
mode. In CMN active mode, the connection of the call waiting tone depends not only on
whether or not it is contained in the Alert-Info header of the 180 Ringing response, but
on MFQDN settings as well. If the CW TONE CONNECTION IN CMN MODE MFQDN
parameter is set to ALWAYS, the call waiting tone is connected to the caller whenever

22

Id:0900d80580956c35

DN0621509
Issue 10-0-1

Feature 1671: NVS Call Handling (Standalone Mode)

Feature description

the called party is engaged in a call with someone else. In CMN inactive mode, however,
the URN only needs to be set to call-waiting in the Alert-Info header and returned in a
180 Ringing response for the call waiting tone to be connected.

g

1.4.5

On SIP trunk interfaces the call waiting tone is not connected.
For more information on the Alert-Info header and how it contributes toward connecting
a call waiting tone, see section Support for call waiting tone connection of the NVS and
MSS SIP User Guide.

Files
There are no files directly visible to the operator.

1.4.6

Statistics
SIP-related statistics are collected in the NVS. For more information, see Feature 1696:
NVS Statistics, Feature Description.
MCID-related updates to statistics
The MSS Observation Report is generated for subscribers who use the MCID service.
This report contains the CS-related information for each call. If the call is SIP-based, the
SIP Observation Report is also generated. The SIP Observation Report contains information specific to SIP sessions, including the following header information:






Request-Uri
P-Asserted-Identity (x2—one for the calling party and another for the called party)
Diversion (maximum of 10 records)
History-Info (maximum of 10 records)
Referred-by

The following counter is updated when the MCID service is used:


1.4.7

MALICIOUS CALL TRACING

Parameters
Further information on the values of each paramater can be found in the PRFILE
Description document.


g

DN0621509
Issue 10-0-1

INVITE_CFNRC_TIMEOUT (052:0044)
This parameter defines how long the outgoing Access side (including ISC) SIP signaling handler should wait for a response to an INVITE request during a SIP terminated call. When the timer expires, the call fails and call forwarding on not reachable
(CFNRc) is executed.
If the called party is served by an NVS SCC AS, however, the NVS attempts to alert
the subscriber on the CS access side when the timer expires.
Alerting the subscriber on the CS access side only occurs:
• If the subscriber does not have the CFNRc service activated on the HLR
• If the subscriber has the CFNRc service activated in the HLR and CFNRc suppression is set to TRUE in the subscriber's SIP group profile.
Values for this parameter are given in milliseconds and can be any value between
0 and 30000. The default value is 5000 (5 seconds).

Id:0900d80580956c35

23

Feature description

Feature 1671: NVS Call Handling (Standalone Mode)

g

This parameter is used by the NVS in the role of an MMTel server and/or SCC AS
server (see Feature 1990: SCC AS in NVS (Standalone Mode), Feature Description).














g

If the given user did not register with the selected feature tag, the call is rejected.






24

MSC_AS_VOIP_SUPPORT (002:1089)
This parameter defines whether the S-CSCF can connect to the MSS (or the NVS)
through the ISC interface for initiating VoIP calls.
MSC_VOIP_SUPPORT (002:1078)
This parameter defines whether the subscribers can connect to the MSS through the
SIP for initiating VoIP calls.
MSC_VOIP_TCP_SUPP (002:1219)
The parameter controls whether Transmission Control Protocol (TCP) can be used
for outgoing SIP requests and responses in the NVS or not (if not, UDP is used).
OPTIONS_QUERY_TIMEOUT (052:0036)
This parameter defines how long the outgoing Access side SIP signaling handler
should wait for the response for an OPTIONS capability request during a SIP terminated call. When the timer expires, the call fails and, for example, call forwarding is
executed.
REJECT_MEDIA_CHG_W_PREPAID (010:0087)
This parameter controls whether a Media Change request is rejected if the IN
prepaid service is running. If this parameter is set to TRUE, the Media Change
request is rejected.
SIP_ADD_ICSI (052:0101)
This PRFILE parameter controls whether or not to the IMS Communication Service
Identifier (ICSI) is sent in the P-Asserted-Service header over the SIP trunk, MGCF,
and ISC interfaces.
SIP_CHK_ACCEPT_CONTACT (052:0102)
This PRFILE parameter is used to select the services, indicated in the P-AcceptContact header, that should be checked against the registered feature tags/services
at the terminating side of the SIP access interface.

SIP_CIC_USAGE (052:061)
This parameter controls whether to send and accept the Carrier Identification Code
(CIC) parameter in the Request URI of an initial INVITE request. It has no effect on
tunneling and access interfaces.
If this parameter is set to TRUE, when the initial INVITE is sent out, the Carrier Identification Code is mapped to the CIC parameter of the Request URI. When the initial
INVITE is received, the CIC parameter of the Request URI is mapped to the Carrier
Identification Code.
If this parameter is set to FALSE, the CIC parameter is ignored when the INVITE is
received, and the CIC parameter is not added when the INVITE is sent.
SIP_CONN_TCP_USED (052:0043)
This parameter defines whether outgoing requests are sent out using TCP if the
local policy (for example, transport protocol of registered contact) allows it.
SIP_CONN_TIMEOUT_ACCESS (052:0042)
This parameter determines the maximum amount of inactivity time the TCP connection is kept open toward users on the SIP access interface. If no SIP message is sent
or received during the inactivity timeout, the connection is closed. The timeout is

Id:0900d80580956c35

DN0621509
Issue 10-0-1

Feature 1671: NVS Call Handling (Standalone Mode)
















DN0621509
Issue 10-0-1

Feature description

determined in seconds. The minimum value is 10 (seconds), the maximum value is
28800 (8 hours). The default value is 60 seconds. Special value 1 indicates that the
connection can be closed only after all call handling hands terminate. On ISC interface SIP_CONN_TIMEOUT (052:0025) is used instead of this parameter.
SIP_MCID_MAPPING (052:0096)
This parameter controls the mapping of INFO request information to and from ISUP.
SIP_NPDI_USAGE (052:0062)
This parameter controls whether to send and accept the Number Portability Indicator
(NPDI) and the Routing Number (RN) parameters in the Request URI of initial
INVITE requests. It has no effect on tunneling and access interfaces.
If this parameter is set to TRUE, when initial the INVITE is sent out, the Number Portability Indicator and Routing Number are mapped to NPDI and RN parameters of
the Request URI.
When the initial INVITE is received, the RN and NPDI parameters of the Request
URI are mapped to the Number Portability Indicator and the Routing Number.
If this parameter is set to FALSE, NPDI and RN parameters are ignored when the
INVITE is received. NPDI and RN parameters are not added when the INVITE is
sent.
SIP_USE_DISPLAY_NAME (052:0059)
This parameter controls whether the Display Name defined in IETF RFC 3261 SIP:
Session Initiation Protocol. June 2002. is included in the From and/or P-AssertedIdentity SIP headers in outgoing initial INVITE requests.
SIP_USE_WILDC_EMERG_NUM (052:0104)
This parameter determines whether or not wildcard values can be used to indicate
emergency numbers.
Usually, when an initial INVITE is made, the called number/URI is checked against
the list of hard coded numbers, such as 911, 112, and so on. If the called number/URI is not found, the Emergency List is checked. If the is still unsuccessful and
the SIP_USE_WILDC_EMERG_NUM (052:0104) PRFILE parameter is set to
TRUE, then the called number/URI—found in the Request URI—is checked against
those entries in the Emergency List that use wildcards—for example, 1234*. If the
called number begins with 1234, the call is handled as an emergency.
TCP_ACTIVATED_ON_ACC_IF (052:0047)
This parameter controls whether or not TCP can be used on the access interface of
the NVS for SIP requests and responses.
TCP_ACTIVATED_ON_ISC_IF (052:0048)
This parameter controls whether or not TCP can be used on the ISC interface of the
NVS for SIP requests and responses.
TCP_ACTIVATED_ON_NET_IF (052:0049)
This parameter controls whether or not TCP can be used on the Network interface
of the NVS for SIP requests and responses.
USE_DIVERSION_HEADER (052:0060)
This parameter is used to control whether to send and accept SIP Diversion Header
in initial INVITE requests.
If this parameter is set to TRUE, when the initial INVITE is sent out, the Original
Called Party Number, Redirecting Number, Call Forwarding Counter (CFC) and Call
Forwarding Reason are mapped to the Diversion Header. When the initial INVITE is

Id:0900d80580956c35

25

Feature description

Feature 1671: NVS Call Handling (Standalone Mode)



g

This parameter is used only if the MSG - SIP video support license is OFF. See
section 1.3.1 Software for further information about licenses.


1.4.8

received, the Diversion Header is mapped to the Original Called Party Number,
Redirecting Number, CFC and Call Forwarding Reason.
If this parameter is set to FALSE, the Diversion Header is ignored when the INVITE
is received, and the Diversion Header is not added when the INVITE is sent.
VOIP_MM_SUPPORT (052:0040)
This FIFILE parameter controls whether SIP-based multimedia (video) calls are
allowed.
If this parameter is ON/'TRUE', the SDP is mapped to the call control, which can be
used for routing in extended pre-analysis and routing attribute analysis.
If this parameter is OFF/'FALSE', the calls are handled as audio calls independently
from the SDP content.

VOIP_REMOTE_PORT (052:0041)
This parameter determines which SIP port number should be used as a remote port
when a SIP request is sent out by the NVS on the SIP Trunk Network interface.

Charging
New Charging Data Records (CDRs) and CDR fields are introduced for SIP calls. For
more information, see Feature 1703: NVS Charging, Feature Description.

1.5

Capacity
The DX platform includes a variable number of SCPU units. One SCPU unit can handle
90 000 Busy Handle Call Attempts (BHCA) and 1984 simultaneous calls. The operator
can scale the NVS based on this figure, but the total amount of BHCA in an NVS cannot
exceed 1 million BHCA. If NVS is used for GSM/UMTS access as well, the operator
should balance the total capacity of the NVS between the GSM/UMTS and SIP calls.
In a normal DX platform configuration, the NVS can handle 1 000 000 BHCA.

1.6

Restrictions










26

Since the NVS works in Back-to-Back User Agent (B2BUA) mode, it does not
support full proxy mode where all the SIP headers are proxied: the NVS proxies the
relevant SIP headers only.
GSM and SIP access cannot be used by one subscriber with the same IMSI at the
same time without the Nokia Siemens Networks One Number Service solution.
At the network element level the two access methods can co-exist.
The number of TCP connections is limited to 4096 per process and per unit. If this
limit is exceeded, no new connections are accepted from the network side, and the
call setup is rejected if no existing connection can be utilized. The connections
toward the normal access interface are not closed during switchover. Network side
connections and ISC connections are re-established in the new unit
Sending the INVITE request without the SDP is not supported.
The maximum accepted SIP message size is 8KBytes.
Early answer functionality is not supported on the SIP-I interface.

Id:0900d80580956c35

DN0621509
Issue 10-0-1

Feature 1671: NVS Call Handling (Standalone Mode)



















1.7

Feature description

With parallel alerting, separate call legs are established between the alerting party
and each group member. The MCID INQUIRY message, triggered to establish the
calling/alerting party’s identification, is not transferred from the separate call legs of
the group members to the originating caller/alerter. Thus, if a group member does
not know the calling/alerting party, the response to the MCID INQUIRY is Calling
Party Information Not Available.
Once an INVITE has been sent, its From header cannot be changed.
The Calling Name Presentation (CNAP) supplementary service is available to both
calling (A-party CNAP) and called (B-party CNAP) parties when the NVS is used in
standalone mode. However, if A and B parties are located in different MSSs and the
MSSs interconnect through a non SIP-I SIP trunk, the Calling Name Presentation
(CNAP) supplementary service is only available to the called party (B-party CNAP).
Video and MSRP based media is not supported in CMN inactive mode. The only
media types supported are audio and T.38 image.
Media and service addition or removal during a call is not supported in CMN inactive
mode.
If a audio call is being performed in CMN inactive mode, the media format can be
changed to image/t.38, but an image/t.38 service cannot be modified back to audio.
Only one set of supplementary services (one of each available media) can be executed, even if the initial INVITE has multiple media/services present. The services
are bound to the mapped basic service code.
The NVS does not take into account SDP information sent to it as a result of an
OPTIONS capability query.
The NVS does not route OPTIONS requests to a target UA. Instead, it terminates
the request and sends its own capabilities in the answer, even if the Request URI
does not point to the NVS.
IN services cannot be updated with media information when the media or service is
updated during an active call.
In CMN active mode, the detection of used media and services relies only on the
SDP content, since the NVS does not control the user plane in this case. An UA
might not fully use all the media and services negotiated via the SDP. The NVS
assumes that all the negotiated media and services are used during the session,
and the CDRs and statistical reports are updated accordingly.
The CLI formatting of the calling party is ignored if the calling party has logical SIP
URI and the called party has CLIP service activated.
The calling party’s logical SIP URI is proxied to the From header of the outgoing
INVITE. Hence, irrespective of any CLI formatting of the calling party, the logical SIP
URI is displayed to the called party.

Related and interworking features
This feature interworks with the following VoIP features:


DN0621509
Issue 10-0-1

Feature 1331: Session Initiation Protocol in the MSS
The Session Initiation Protocol (SIP) is implemented in order to create and manage
multimedia sessions between two or more participants over the Internet in third generation networks. A general aim of SIP is to support Voice over IP and to ensure that
future Voice over IP services are fully Internet-based. The feature works with other
MSS features and implements the Media Gateway Control Function (MGCF) in the

Id:0900d80580956c35

27

Feature description

Feature 1671: NVS Call Handling (Standalone Mode)









MSS. Between MSSs both SIPT [Internet Engineering Task Force (IETF)] and SIPI [International Telecommunications Union (ITU-T)] can be used.
In the case of SIP-T, Integrated Services User Part (ISUP) tunneling can also be
switched off, but it is not advised since the ISUP feature’s transparency can be lost.
Feature 1630: Fax and CS Data Call detection in MSS.
This feature enables the MSS to differentiate between speech, fax and modem data
by monitoring the user plane and detecting fax and modem negotiation signals.
When a fax or modem signal is detected, the MSS performs a codec modification in
order to support the fax and modem data call. This feature also provides support for
T.38 Fax over IP. The ITU-T T.38 protocol guarantees the reliable transport of Group
3 Fax devices in non-QoS aware environments such as IP networks.
Feature 1696: NVS Statistics
The feature offers statistical support for the Mobile VoIP Server (NVS) solution.
Statistical functions for the NVS are provided through the extension of several measurements and observations that already exist and are known in the MSS network
elements, and by introducing new measurements and observations that provide
NVS-specific information.
Feature 1703: NVS Charging
This feature offers customers the basic ability to charge using CDRs on the Circuit
Switched (CS) network side for the usage of the NVS, Application Server (AS), and
other possible IP Multimedia Systems (IMSs) in cases where the user or usage is
related or interfaced to the CS network through SIP.
Feature 1760: NVS Messaging
This feature introduces Instant Messaging (IM) functionality to the MSS and enables
the handling of SIP User Agent (UA) originated and terminated messages as well as
IM-SMS interworking. With this feature, SIP subscribers can have similar services
to GSM and UMTS subscribers.

Required features:






28

Feature 906: MSRN Allocation Enhancement
The feature consists of two parts, a generic and an optional one:
1. The feature removes the former restriction that the last digit of a Mobile Station
Roaming Number (MSRN) indicates the VLR unit, which reserved the MSRN in
point. Since then all the MSRNs are available in the MSS. This part of the feature
is generic.
2. The feature provides the possibility to allocate MSRNs based on the called subscriber’s registered Location Area (LA). LA-based functionality gives you the
ability to assign an MSRN group to one or several location areas. The MSRN
group can be divided into several MSRN ranges. It affects the ELE, ELO, and
WVC MML commands. This part of the feature is optional. The new functionality
is internal in the MSS/VLR, and does not cause any changes to external network
elements.
Feature 1670: SIP Subscriber Database
This feature enables the storage of additional SIP subscriber attributes in a separate
database in much the same way that the DX HLR stores GSM subscription related
data.
Feature 1673: NVS Registration
This feature provides services for both fixed and mobile networks through a single
converged architecture. Additionally, it also makes it possible to offer Voice over IP
(VoIP) calls, message interworking between Short Message Service (SMS) and SIP

Id:0900d80580956c35

DN0621509
Issue 10-0-1

Feature 1671: NVS Call Handling (Standalone Mode)

Feature description

messaging, as well as end-to-end SIP services, for example, instant messaging
directly between terminals.
Optional features:






1.8

Feature 1448: High Capacity MSS & GCS
If feature 1448 is not activated, the HLR inquiry is never started from an SCPU. This
means that, for example, in the case of a SIP-UA - SIP-UA call, the call is originated
in an SCPU unit but the HLR inquiry is performed in a CCSU/SIGU and the terminating side is also handled in an SCPU. As a result, the message bus will be used
twice when internal end-to-end call control messages (such as setup or bearer
establishment) are sent. Moreover, as the terminating SCPU is selected in a roundrobin fashion, as in the case above, it is highly probable that the incoming and
outgoing sides will be handled by different SCPUs, which again increases the load
on the message bus because of the direct message exchange between SIP signaling processes.
However, if feature 1448 is activated, the HLR inquiry can be started from the SCPU.
This means that if the call originates in an SCPU, the HLR inquiry can be started
from the same SCPU instead of the CCSU/SIGU and, in this way, the usage of the
message bus will be optimized. For example, in a SIP-UA - SIP-UA case, every call
leg will reside within the same SCPU.
Feature 1541: Same CLI for Multiple Subscribers
This feature makes it possible for several International Mobile Subscriber Identities
(IMSIs) to use a common Mobile Station International ISDN Number (MSISDN)
when originating calls (voice or data) or sending short messages. The mobile
stations can belong to one or more users.
Feature 1844: SIP Call Transfer Support
The NVS supports Call Transfer using the SIP REFER method.

Compliance
This feature is compliant with the following standards:
3GPP standards:
3GPP TS 24.229 Internet Protocol (IP) multimedia call control protocol based on
Session Initiation Protocol (SIP) and Session Description Protocol (SDP), Stage 3, v5.40, March 2003.
IETF standards:
IETF RFC 2327 SDP: Session Description Protocol. M. Handley, V. Jacobson. April
1998.
IETF RFC 3261 SIP: Session Initiation Protocol. J. Rosenberg, H. Schulzrinne, G.
Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E.
Schooler. June 2002.
IETF RFC 3262 Reliability of Provisional Responses in Session Initiation Protocol (SIP).
J. Rosenberg, H. Schulzrinne. June 2002.
IETF RFC 3311 The Session Initiation Protocol (SIP) UPDATE Method. J.Rosenberg.
October 2002.
IETF RFC 3312 Integration of Resource Management and Session Initiation Protocol
(SIP). G. Camarillo, Ed., W. Marshall, Ed., J. Rosenberg. October 2002.

DN0621509
Issue 10-0-1

Id:0900d80580956c35

29

Feature description

Feature 1671: NVS Call Handling (Standalone Mode)

IETF RFC 3323 A Privacy Mechanism for the Session Initiation Protocol (SIP). J. Peterson. November 2002.
IETF RFC 3325 Private Extensions to the Session Initiation Protocol (SIP) for Asserted
Identity within Trusted Networks. C. Jennings, J. Peterson, M. Watson. November 2002.
IETF RFC 3428 Session Initiation Protocol (SIP) Extension for Instant Messaging. B.
Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, D. Gurle. December 2002.
IETF RFC 3455 Private Header (P-Header) Extensions to the Session Initiation
Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP). M. Garcia-Martin, E.
Henrikson, D. Mills. January 2003.
ETSI standards:
ETSI EN 383 001 Interworking between Session Initiation Protocol (SIP) and Bearer
Independent Call Control (BICC) Protocol or ISDN User Part (ISUP), Ver. 1.1.1
IMS-CS interworking on ISC interface is compliant with:
3GPP TS 24.229 Internet Protocol (IP) multimedia call control protocol based on
Session Initiation Protocol (SIP) and Session Description Protocol (SDP), Stage 3, v5.40, March 2003
3GPP TS 29.163 Interworking between the IM CN subsystem and CS networks, v6.0-0,
September 2003, as far as standardisation status permits
ITU-T Q.1912.5 Interworking between Session Initiation Protocol (SIP) and the Bearer
Independent Call Control protocol or ISDN User Part
The following interface specifications contain detailed compliance information on the
corresponding interfaces:



1.9
1.9.1

Nokia Siemens Networks Mobile VoIP Server SIP Interface Description, Standalone
SIP Interface in MSS, Interface Specification

Operator interfaces
MMLs
This feature requires the configuration described in the feature description of Feature
1673: NVS Registration. In addition, the following MML commands are related to this
feature.
Extended Preanalysis Handling, CW Command Group
With the help of the CW command group, you can develop and maintain the extended
preanalysis.
The following command is relevant to this feature:


CWC - CREATE SUBANALYSIS

Use this command to create a subanalysis of an extended preanalysis or to create a
copy of a existing subanalysis.
The following input parameter is relevant to the feature:


Call Bearer Type (CBTYPE)

For more information on the commands and their parameters, see the Extended Preanalysis Handling, CW Command Group, Command Reference Manual.

30

Id:0900d80580956c35

DN0621509
Issue 10-0-1

Feature 1671: NVS Call Handling (Standalone Mode)

Feature description

SIP Parameters Configuration Handling, JH Command Group
With the help of the JH command group, it is possible to handle group profiles, generic
SIP parameters and configure different types of configuration lists.
The relevant commands are:
JHA

ADD SIP GROUP PROFILE

In addition to the configuration described in the feature description of Feature 1673: NVS
Registration, the operator can use this feature to modify the authentication of calls.
JHK

GENERAL SIP CONFIGURATION PARAMETER

Use this command to set the NETWORK DOMAIN parameter. This parameter is used
to convert a calling party telephone number to a SIP URI on access interfaces. If the
caller is a mobile subscriber, the SIP URI is constructed in the following way:
telephone_number@NETWORKDOMAIN;user=phone.
The PRIVATE FQDN FOR SIP TRUNK parameter is used for routing between NVSs.
Use this parameter to configure the private address of the network element. This FQDN
is resolved by the preceding network element.
JHP

ADD ENTRY TO THE LIST

Use this command to add entries to the following:




Emergency List
Home Domain List
Denied Domain List

For more information on the commands and their parameters, see the SIP Parameters
Configuration Handling, JH Command Group, Command Reference Manual.
Extra FQDN Configuration Commands, JN Command Group
With the commands of the JN command group, you can:









Add additional hosts to the given Fully Qualified Domain Name (FQDN)
Remove additional hosts
Inquire additional hosts
Delete all added hosts and parameters
List all FQDNs that have additional host
Modify the route of FQDN level parameters
Create and copy the route of FQDN parameters
Configure SCTP connections

The additional hosts are used as an alternative to selecting the SIP Circuit Group (CGR)
in incoming requests. Normally, with the help of an FQDN given at SIP CGR creation, it
is possible to identify which SIP CGR to use. The additional hosts can be either IPv4 or
IPv6 based. By configuring FQDN level parameters, you can influence how SIP
messages are handled.

g

The number of FQDNs is limited to 1500. In addition, no more than 2048 hosts can be
attached an FQDN.
For more information on the commands and their parameters, see the Extra FQDN level
SIP Parameter Handling, JN Command Group, Command Reference Manual.

DN0621509
Issue 10-0-1

Id:0900d80580956c35

31

Feature description

Feature 1671: NVS Call Handling (Standalone Mode)

Serving Profile Database Subscriber Handling, JO Command Group
WIth the help of the JO command group, you can create, delete and search a subscriber
in the Serving Profile Database (SPD).
The relevant command is:


JOI - INTERROGATE SIP SUBSCRIBER IN SPD

Use this command to search for subscribers in the SPD using either IMSI or SIP URI.
The following result parameter is relevant to this feature:


Supported multimedia services

For more information on the commands and their parameters, see the Serving Profile
Database Subscriber Handling, JO Command Group, Command Reference Manual.
User Plane Analysis Handling, JU Command Group
With the help of the JU command group, you can create, modify, delete and inquire a
subanalysis or a final result from a user plane analysis.
The relevant commands are:


JUC - CREATE SUBANALYSIS

Use this command to create a subanalysis of the user plane analysis or a copy of an
existing subanalysis.


JUM - MODIFY SUBANALYSIS

Use this command to modify a subanalysis of the user plane analysis.


JUI - INTERROGATE SUBANALYSIS

Use this command to interrogate the subanalyses of the user plane analysis.
The parameter supported in this feature is the following:


User Plane Bearer Requirement (UBPREQ)

For more information on these commands and their parameters, see the User Plane
Analysis Handling, JU Command Group, Command Reference Manual.
Circuit Group Handling, RC Command Group
With the help of the RC command group, it is possible to create a circuit group, add
circuits to a circuit group, modify the features of circuits or circuit groups, delete circuit
groups or circuits from a circuit group, and interrogate the features of circuit groups or
circuits.

g

The number of circuit groups is limited to 1500.
The relevant commands are:
RCA

ADD CIRCUITS TO CIRCUIT GROUP

Use this command to add circuit(s) to a circuit group.
RCC

CREATE CIRCUIT GROUP

Use this command to create different types of circuit groups: CCS, CAS, DCS, SIP, IPT,
and special circuit groups.
The parameters used in this feature are the following:



32

FQDN of the adjacent Network Element (NE)
CNTROL index (Line Signaling Index (LSI))

Id:0900d80580956c35

DN0621509
Issue 10-0-1

Feature 1671: NVS Call Handling (Standalone Mode)




Feature description

Auxiliary Signaling Index (ASI)
Circuit Group (CGR) type (SIP)

For more information on these commands and their parameters, see the Circuit Group
Handling, RC Command Group, Command Reference Manual.
GSM Special Route Handling, RP Command Group
With the help of the RP command group, it is possible to manage different types of
special routes.
RPS

CREATE SPECIAL ROUTE FOR SIP END

Use this command to create a SIP END special route.
Input parameters are the following:







OUSIGN index
sending of numbers start point
call control parameter set index
CLI formatting set index
timer set index
User Plane Destination Reference (UPDR)

For more information on these commands and their parameters, see the GSM Special
Route Handling, RP Command Group, Command Reference Manual.
Attribute Analysis Handling, RQ Command Group
With the help of the RQ command group, you can implement customer-specific routing
and charging services, and define more specific routing and charging cases for certain
call situations.
With regards the Malicious Call Identification service, each of the MML commands
below have been updated with the MCID parameter. This parameter indicates whether
or not subscribers have the MCID service activated.




Create service attribute analysis result
Modify service attribute analysis result
Interrogate final result

As regards MMTel support, the following Service Attribute Analysis input parameters are
enabled by this feature:











Startpoint of the Analysis (STARTP)
Basic Service Code from VLR (BSCODE)
Call Bearer Type (CBTYPE)
Calling Party Additional Routing Support (AADDRC)
Exact Calling Party Category (AEXCAT)
Calling Party Routing Category (AROUTC)
Called Party Additional Routing Category (BADDRC)
Exact Called Party Category (BEXCAT)
Called Party Routing Category (BROUTC)
PLMN Specific SS Core (OSSS)

The following Service Attribute Analysis result parameter is relevant to the feature:


MMTel Service Type (SERVT)

The following IN Attribute Analysis result parameter is relevant to the feature:

DN0621509
Issue 10-0-1

Id:0900d80580956c35

33

Feature description

Feature 1671: NVS Call Handling (Standalone Mode)



Prepaid Service is Running (PREPRUN)

For more information on these commands and their parameters, see the Attribute
Analysis Handling, RQ Command Group, Command Reference Manual.
For an example of how these commands are used with the Malicious Call Identification
service, see section Malicious call identification of the NVS and MSS SIP User Guide.

1.9.2

Alarms
There are no alarms related to this feature.

1.9.3

Cause Codes
The cause code media_or_service_not_supp is used to indicate media or service
related errors. It is used in the following cases:





1.10

A licence is not active for a requested media or service
There is no subscription for a requested media or service
An unsupported media change is requested
The media list has become empty

Subscriber interfaces
This feature enables SIP users to initiate SIP calls toward the NVS.
For more information about the subscriber interface, see Nokia Siemens Networks
Mobile VoIP Server SIP Interface Description, Standalone.

1.11

Network elements


34

SDB/LDAP server
SDB data can be managed and maintained by LDAP solutions, such as, NPS, OneNDS or OpenLDAP. The SDB database is an LDAP directory. The SDB data,
residing in the LDAP directory, is accessed and queried by the LDAP client processes of the MSS/NVS. The client processes are located in the signalling units of
the MSS/NVS.
The MSS/NVS supports both the two-site and the three-site LDAP client-server
model, that is, LDAP server deployment on two or three sites. The optional high
availability model offers a more flexible management of the LDAP databases in
primary, secondary and tertiary servers. The high availability three-site model is an
optional functionality and is controlled by license.
If both the primary and secondary servers fail, the tertiary server can continue
serving LDAP requests. Read failure measurement functionality provides an opti-

Id:0900d80580956c35

DN0621509
Issue 10-0-1

Feature 1671: NVS Call Handling (Standalone Mode)

Feature description

mized solution to manage client-side high availability. Read failure measurement is
an optional functionality and is controlled by license.
For more information, see Feature 1670: SIP Subscriber Database, Feature
Description.
For more information on LDAP database and LDAP server configuration, see LDAP
User Guide for NVS and MSS.
For more information on the configuration of LDAP client processes, see Subscriber
Profile Database Configuration Administration Handling, JD Command Group.
For more information on the high availability three-site model and Read failure measurement functionality, see the respective sections of the LDAP User Guide for NVS
and MSS.
For more information on option control, see sections LDAP model and LDAP client
applications of the LDAP User Guide for NVS and MSS.

1.12

External interfaces
This feature operates on the following SIP signaling interfaces:



SIP interface toward other SIP-capable network elements—the SIP Network interface
ISC interfaces toward the S-CSCF

A description of these interfaces can be found in Nokia Siemens Networks Mobile VoIP
Server ISC Interface Description, Application Server Solution and Nokia Siemens
Networks Mobile VoIP Server SIP Interface Description, Standalone.
Charging-related changes are described in Feature 1703: NVS Charging, Feature
Description.
Statistics-related changes are described in Feature 1696: NVS Statistics, Feature
Description.

g

DN0621509
Issue 10-0-1

This feature has no effect on Mobile Application Part (MAP) interfaces.

Id:0900d80580956c35

35

Main changes in Feature 1671: NVS Call Handling
(Standalone Mode)

Feature 1671: NVS Call Handling (Standalone Mode)

2 Main changes in Feature 1671: NVS Call
Handling (Standalone Mode)
2.1

Changes in the feature
Changes in the feature between releases M16.1 and M15.1
Support for Multimedia Telecommunications (MMTel) has been added. This refers specifically to the ability to request voice, video and Message Session Relay Protocol
(MSRP) services during a call. MSRP provides messaging, image and file transfer
services during calls.
A short section explaining the handling of History-Info headers has been added. HistoryInfo allows Call and Communications Diversion services that expand on the base SIP
behavior.
Changes in the feature between releases M15.1 and M15.0
Functionality relevant to emergency call handling using wildcards has been added.
Changes in the feature between releases M15.0 and M14.6
A short section on support for out of band DTMF in SIP INFO messages has been
added. This allows SIP INFO messages and requests with application/dtmf-relay MIME
types to be handled by the MSS across all incoming and outgoing SIP interfaces.
The Malicious Call Identification (MCID) service has been added. This service enables
SIP subscribers’ incoming session-related information to be stored by the NVS, allowing
the source of malicious calls to be identified and investigated by the appropriate authorities.
The Calling Name Presentation supplementary service has been extended to include
NVS/SIP subscribers. This service enables NVS subscribers to have their display name
presented in the From header of outgoing INVITEs and all subsequent MESSAGEs.
Support for OneVoice compliant MMTel services has been added. This refers specifically to support for the handling of ICSI information in SIP messages and support for a
call waiting tone instead of a ringback tone in CMN active and inactive modes through
the help of the Alert-Info header, contained in 180 Ringing responses.
Changes in the feature between releases M14.6 and M14.5
The number of CGR records has been extended to 1500. The number of hosts that can
be assigned to FQDNs has been increased to 2048.
Changes in the feature between releases M14.5 and M14.4
No changes
Changes in the feature between releases M14.4 and M14.3
Early answer and Ringback tone connection in CMN mode functionality has been
added.
Changes in the feature between releases M14.3 and M14.2
This feature interworks with Feature 1448: High Capacity MSS & GCS, which optimizes
the message bus usage of call control legs in the NVS.

36

Id:0900d80580956c37

DN0621509
Issue 10-0-1

Feature 1671: NVS Call Handling (Standalone Mode)

Main changes in Feature 1671: NVS Call Handling
(Standalone Mode)

During anonymous call setup and instant messaging on the SIP Access interface, the
NVS can make the user agent send his/her user identity.
Changes in the feature between releases M14.2 and M14.1
Support for Feature 1844: Call Transfer Support on SIP has been added.
Changes in the feature between releases M14.1 and M14.0
Anonymous Call Rejection functionality has been added.
Support for ETSI EN 383 001 compliance has been added. The enhancement includes
better interworking of FCI (Forward Call Indicator) and BCI (Backward Call Indicator)
ISUP parameters in cases of UDI (CLEARMODE) calls and mapping between ISUP
cause code 24 and 433 (Anonymity Disallowed) SIP response messages.

2.2

Changes in the document
Changes made between issues 10-0-1 and 10-0-0
VOIP_SCTP_ON_SIP_ACCESS (052:0071) PRFILE parameter has been removed.
Changes made between issues 10-0-0 and 9-0-0
The following sections have been updated:







Restrictions has been updated with information on CLI formatting and limitations on
the usage of Multimedia Telephony (MMTel) features.
Software has been updated with additional required licences to use MMTel and
History-Info features.
Services has been updated with details of Communications Diversion (CDIV)
support using History-Info headers.
NVS support for GSMA IR.92 compliant multimedia telephony (MMTel) services has
been updated with a section detailing suport for multimedia tags in SIP headers.
Parameters has been updated with the REJECT_MEDIA_CHG_W_PREPAID,
SIP_CHK_ACCEPT_CONTACT and SKIP_FAX_SUBS_CHK PRFILE parameters.
MMLs has been updated with new information for the following command groups:
CW, JO, RQ.

The following section has been added:


Cause Codes

Changes made between issues 9-0-0 and 8-0-1
The following sections have been updated:




Regulatory services, Emergency calls
The subsection has been updated to take into account further checking of the Emergency List for entries that use wildcards when the SIP_USE_WILDC_EMERG_NUM
(052:0104) PRFILE parameter is set to TRUE.
Parameters
The section has been updated with the SIP_USE_WILDC_EMERG_NUM
(052:0104) PRFILE parameter.

The following section has been added:


DN0621509
Issue 10-0-1

Network elements

Id:0900d80580956c37

37

Main changes in Feature 1671: NVS Call Handling
(Standalone Mode)

Feature 1671: NVS Call Handling (Standalone Mode)

Changes made between issues 8-0-1 and 8-0-0
The term One Voice was removed from the title of section NVS support for One Voice
compliant multimedia telephony (MMTel) services and replaced by the term GSMA
IR.92.
Changes made between issues 8-0-0 and 7-0-0
The following sections have been updated:





Requirements for using the feature, Software
Functionality, Statistics
Functionality, Parameters
Restrictions

The following sections have been added:






Functionality, Services, Dual-Tone Multifrequency (DTMF) support
Functionality, Services, Malicious call identification
Functionality, Services, Calling name presentation service for NVS/SIP subscribers
Functionality, Services, NVS support for GSMA IR.92 compliant multimedia telephony (MMTel) services
Operator Interfaces, MMLs, Attribute Analysis Handling, RQ Command Group

Changes made between issues 7-0-0 and 6-0
The following sections have been updated to incorporate the changes specified above:



Operator interfaces-MMLs-JN
Operator interfaces-MMLs-JR

Changes made between issues 6-0 and 5-0
Feature 1451: BICC-SIP Interworking has been renamed to Feature 1451: IMS-CS
Interworking.
Changes made between issues 5-0 and 4-2
Changes incurred by Early answer and Ringback tone connection in CMN mode functionality have been made to the following sections:





Requirements - products
Functionality - services
Parameters
Restrictions

Editorial changes have also been made.
Changes made between issues 4-2 and 4-1
Feature names have been corrected according to the approved feature names.
Changes made between issues 4-1 and 4-0
Editorial changes have been made.
Changes made between issues 4-0 and 3-0
Feature 1448: High Capacity MSS & GCS has been added to section Related and interworking features.

38

Id:0900d80580956c37

DN0621509
Issue 10-0-1

Feature 1671: NVS Call Handling (Standalone Mode)

Main changes in Feature 1671: NVS Call Handling
(Standalone Mode)

Section Anonymous call setup and instant messaging on the SIP Access interface has
been added.
The company and product names have been changed according to the official Nokia
Siemens Networks portfolio.

DN0621509
Issue 10-0-1

Id:0900d80580956c37

39

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close