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

7/17/2019 Feature 1671- NVS Call Handling (Standalone Mode).pdf

http://slidepdf.com/reader/full/feature-1671-nvs-call-handling-standalone-modepdf 1/39

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

nents.

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.



2 DN0621509

Issue 10-0-1

Feature 1671: NVS Call Handling (Standalone Mode)

Id:0900d80580956c39

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 whichthe 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 respectiveowners, and they are mentioned for identification purposes only.

Copyright © Nokia Siemens Networks 2013/12/21. All rights reserved

f Important Notice on Product SafetyThis 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 ProduktsicherheitVon 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 Sicherheits-

anforderungen erfolgen.

Die Sicherheitsanforderungen finden Sie unter „Sicherheitshinweise“ im Teil „Legal,

Safety and Environmental Information“ dieses Dokuments oder dieses Dokumentations-

satzes.



DN0621509

Issue 10-0-1

3


Id:0900d80580956c39

Table of ContentsThis document has 39 pages.

1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2 Benefits for the operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3 Requirements for using the feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.3.1 Software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.3.2 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.3.3 Products. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.4 Functionality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.4.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.4.2 Basic call scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.4.3 Regulatory services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.4.4 Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.4.4.1 NVS support for GSMA IR.92 compliant multimedia telephony (MMTel)

services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

1.4.5 Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

1.4.6 Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

1.4.7 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

1.4.8 Charging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

1.5 Capacity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

1.6 Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

1.7 Related and interworking features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

1.8 Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291.9 Operator interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

1.9.1 MMLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

1.9.2 Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

1.9.3 Cause Codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

1.10 Subscriber interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

1.11 Network elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

1.12 External interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

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

2.1 Changes in the feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

2.2 Changes in the document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37



4 DN0621509

Issue 10-0-1


Id:0900d80580956c39

List of FiguresFigure 1 The network architecture of NVS working in Standalone Mode . . . . . . . . 8

Figure 2 SIP to SIP call. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Figure 3 SIP to Mobile Station (MS) call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Figure 4 MS to SIP call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Figure 5 SIP to PSTN call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Figure 6 PSTN to SIP call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Figure 7 Calling Line Identification Restriction (CLIR) . . . . . . . . . . . . . . . . . . . . . 14

Figure 8 Calling Line Identity Presentation (CLIP) . . . . . . . . . . . . . . . . . . . . . . . . 14

Figure 9 CFNR with call forwarding announcement . . . . . . . . . . . . . . . . . . . . . . . 15

Figure 10 History-Info headers with privacy parameter applied during call setup. . 20

Figure 11 Storage of MMTel tag during network registration . . . . . . . . . . . . . . . . . 22



DN0621509

Issue 10-0-1

5

Feature 1671: NVS Call Handling (Standalone Mode) Feature description

Id:0900d80580956c35

1 Feature description

1.1 IntroductionThe 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 impor-

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

ments 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-to-

end SIP services, for example, direct instant messaging between terminals.

SIP is designed to support VoIP and is the selected protocol for Third Generation Part-nership Project (3GPP) IMS networks to establish, modify, and terminate multimedia



6 DN0621509

Issue 10-0-1


Id:0900d80580956c35

Feature description

sessions or calls. It is a text-based protocol, which makes it very flexible to accommo-

date new services and implement new service ideas. SIP has excellent support for mul-

timedia, 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 Requirements for using the feature

1.3.1 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: • 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

g 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: PLMN-

Specific Services, Feature Activation Manual .

Calling name presentation (CNAP) functionality for NVS/SIP subscribers requires the

following ON/OFF license to be activated:

• MSG - CNAP to SIP access interface

g 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 Call ing 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 acti-

vated:

• MSS - Support for T.38 Fax over IP



DN0621509

Issue 10-0-1

7


Id:0900d80580956c35

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

• MSG - SIP MSRP support

1.3.2 Hardware

This feature requires a MSS and a SCPU.

SIP is a text-based protocol, which requires extra CPU capacity. For the DX platform, aCP710-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 Functionality

1.4.1 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, andSIP Network Servers.

Supported signaling protocols and interworking

NVS supports all signaling protocols supported by the MSS, for example:

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



8 DN0621509

Issue 10-0-1


Id:0900d80580956c35

Feature description

Interworking between these protocols and the new SIP protocols are possible. Inter-

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

Figure 1 The network architecture of NVS working in Standalone Mode

BSC/RNC

BTS

SIP softphones

SIP deskphones

POTS

IAD

Multiradio

terminals

SS P

IuCS R N P

/

HLR

Transit Switchansit Switch

PSTN/

Soft Switchoft Switch

Mobile

VoIP

Server

MGW

C7 (ISUP)7 ISUP

SIP-I (profile C)IP-I profi le C

H.248

MAP over IPver IP

SIGTRAN

MAP over IPver IP

(SIGTRAN)SIGTRAN

or

TDM-based MAPDM-based MAP

MGW

C7 (ISUP)7 ISUP

C7 (ISUP)7 ISUP

ATM

IP

TD M

ATM, IPM, IP

o r TDM

SIP Trunk

Network

interface

3GPP/IETF

MS

domain

S

SIGTRAN SIGTRAN.248

Mobile

VoIP

Server

SIP Access

interface

Multiaccess

3GPP/IETF

BTS

S

S

POTS

S

RTP/UDP/IP

S

LDAP DNS SMSC

SCP

MAP

P

IN P

DN S

LDAP

DSLAM



DN0621509

Issue 10-0-1

9


Id:0900d80580956c35

SIP to SIP call

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

HLRDAP

Optional MGWpt ional MGW

NVS

Optional MGWptional MGW

NV SIP UA-A SIP UA-B

IP

backbone

SIP Access SIP Access

SIP

Network interfaceetwork interface



10 DN0621509

Issue 10-0-1


Id:0900d80580956c35

Feature description

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

Figure 4 MS to SIP call

HLR

MGW

NV S

MGW

SIP UA-A

SIP Access

BSSAP/

RANAPANAP

BICC/ISUP/

SIP/SIP-I/SIP-T

GSM/UMTS

radio networkadio network

HLR

MGW MGW

NVS

SIPAccess

BSSAP/

RANAP

BICC/ISUP/

SIP/SIP I/SIP T

SIP UA A

GSM/UMTS

radio networkadio network



DN0621509

Issue 10-0-1

11


Id:0900d80580956c35

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

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

timedia (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

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

MGW

NVSIP UA A

SIP Access ISUP/SIP I/SIP T

PSTN

network

MGW

NVS SIP UA B

SIP Access

SUP/SIP I/SIP T

PSTN

network



12 DN0621509

Issue 10-0-1


Id:0900d80580956c35

Feature description

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, Func-

tional 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 thenearest 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 theSIP_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 , thewildcard 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 config-

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

nications Standards Institute (ETSI) in mobile number portability specifications) for sub-



DN0621509

Issue 10-0-1

13


Id:0900d80580956c35

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 inorder to make these features available in the VoIP environment and provides the inter-

working 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 inter-

cepted.

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

tability, 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 indepen-

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

• tel: *31#12345567

• sip: #31#[email protected]

• sip: #31#[email protected]



14 DN0621509

Issue 10-0-1


Id:0900d80580956c35

Feature description

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 ishidden. Otherwise, the called party can see the user’s identity.

Figure 8 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 Sub-

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

NVS originatingVS originating

INVITE

From: +123456rom: 123456

INVITE

From: anonymousrom: anonymous

A party has CLIRarty has CLIR

service enabledervice enabled

INVITE

From: +123456rom: 123456

INVITE

From: anonymousrom: anonymous

B party has no CLIPparty has no CLIP

service provisionedervice provisioned



DN0621509

Issue 10-0-1

15


Id:0900d80580956c35

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:

Figure 9 CFNR with call forwarding announcement

Call Forwarding Not Reachable (CFNR) is executed when there is no response from thecalled 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):

MGW

A

C

1

T

BA

MGW

B

C

2

T

TONEC

NVS

B

VS

A

NVS

C

SIP SIP

IP

network

IP

network

SIP

SIP

SIP.248 H.248



16 DN0621509

Issue 10-0-1


Id:0900d80580956c35

Feature description

• 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 PLMNCountry (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 (BIC-

Roam) (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.: Interwork-

ing 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) func-

tionalities:

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



DN0621509

Issue 10-0-1

17


Id:0900d80580956c35

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

ation 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 differ-

ently.

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

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



18 DN0621509

Issue 10-0-1


Id:0900d80580956c35

Feature description

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

nected 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 infor-

mation, 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 theevent of a SIP session).

For information concerning how to activate and configure this service, see section Mali-

cious 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 thecalling 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 P-

Asserted-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 subse-

quent messages connected with the session).

If the parameter’s value is zero, the NVS will either add the text Anonymous to the Fromheader, signifying that the CNAP license has been activated but the subscriber has



DN0621509

Issue 10-0-1

19


Id:0900d80580956c35

chosen to withhold his/her display name, or not include any display information, signify-

ing 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 Alter-

natives, 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 informa-

tion about how and why the message arrived to a device. The NVS provides Communi-

cation 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: Inter-

working 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 tosip:[email protected]:user=phone as a result, the following History-

Info 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 acause

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.



20 DN0621509

Issue 10-0-1


Id:0900d80580956c35

Feature description

Figure 10 History-Info headers with privacy parameter applied during call setup

1.4.4.1 NVS support for GSMA IR.92 compliant multimedia telephony

(MMTel) services

The One Voice Initiative aims to achieve an industry agreement on a harmonized wayto 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 supple-

mentary services defined in 3GPP MMTel Release 9 specifications. These services

include:

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

UA-C NVS- A NVS-B

INVITE

180 Call is Be ing Forwarded

INVITE

180 Call is Be ing Forwarded

Reply TimeoutThe call i s d iverted to sip:E

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

History-Info: <sip:C>;index=1History-Info: <sip:E>;index=1.1.1

History-Info is sent with thereply, but headers with thepr ivacy parameter are removed.

UA-D UA-E

INVITE

No Reply

INVITE

VoIP VoIP



DN0621509

Issue 10-0-1

21


Id:0900d80580956c35

• 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 net-works. 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 mul-

timedia 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, pres-ently, supports MMTel services through the use of the MMTel feature tag, appended to

the ICSI identifier, described in section Handling multimedia information in SIP mes-

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

vices, like MMTel. The service (or feature) tag is appended to the end of the ICSI in aUniform 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 applica-

tions 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 ser-

vices:

• audio



22 DN0621509

Issue 10-0-1


Id:0900d80580956c35

Feature description

• video

• +g.3gpp.cs-voice

Example:

Contact: <sip:1.2.3.4>;video;+g.3gpp.cs-voice;+g.3gpp.iari-

ref="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).

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

SIP REGISTER(Contact:<SIP UA address>;+g.3gpp.icsi-ref ="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel")

200 OK

Contact related MMTel informationis stored in SPD

SIP UA NVS



DN0621509

Issue 10-0-1

23


Id:0900d80580956c35

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.

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

1.4.5 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 infor-

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

• MALICIOUS CALL TRACING

1.4.7 Parameters

Further information on the values of each paramater can be found in the PRFILE

Description document.

• INVITE_CFNRC_TIMEOUT (052:0044)

This parameter defines how long the outgoing Access side (including ISC) SIP sig-naling handler should wait for a response to an INVITE request during a SIP termi-

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

g 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 sup-

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



24 DN0621509

Issue 10-0-1


Id:0900d80580956c35

Feature description

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

tion).

• 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 handlershould wait for the response for an OPTIONS capability request during a SIP termi-

nated 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-Accept-

Contact header, that should be checked against the registered feature tags/services

at the terminating side of the SIP access interface.

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

• 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 Iden-tification 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 connec-

tion is kept open toward users on the SIP access interface. If no SIP message is sentor received during the inactivity timeout, the connection is closed. The timeout is



DN0621509

Issue 10-0-1

25


Id:0900d80580956c35

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

face 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 Por-

tability 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-Asserted-

Identity 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 num-ber/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



26 DN0621509

Issue 10-0-1


Id:0900d80580956c35

Feature description

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.

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.

•

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.

1.4.8 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 operatorcan scale the NVS based on this f igure, 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

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



DN0621509

Issue 10-0-1

27


Id:0900d80580956c35

• 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 exe-

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

1.7 Related and interworking features

This feature interworks with the following VoIP features:

• 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 gen-

eration 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



28 DN0621509

Issue 10-0-1


Id:0900d80580956c35

Feature description

MSS. Between MSSs both SIPT [Internet Engineering Task Force (IETF)] and SIP-

I [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 mea-

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

• 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 sub-

scriber’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



DN0621509

Issue 10-0-1

29


Id:0900d80580956c35

messaging, as well as end-to-end SIP services, for example, instant messaging

directly between terminals.

Optional features:

• Feature 1448: High Capacity MSS & GCSIf 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 termi-

nating 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 round-

robin 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 signal-

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

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

0, March 2003.

IETF standards:

IETF RFC 2327 SDP: Session Description Protocol. M. Handley, V. Jacobson. April1998.

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.



30 DN0621509

Issue 10-0-1


Id:0900d80580956c35

Feature description

IETF RFC 3323 A Privacy Mechanism for the Session Initiation Protocol (SIP). J. Peter-

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

0, 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:

•Nokia Siemens Networks Mobile VoIP Server SIP Interface Description, Standalone

• SIP Interface in MSS, Interface Specification

1.9 Operator interfaces

1.9.1 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 GroupWith 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 Pre-analysis Handling, CW Command Group, Command Reference Manual .



DN0621509

Issue 10-0-1

31


Id:0900d80580956c35

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



32 DN0621509

Issue 10-0-1


Id:0900d80580956c35

Feature description

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.


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


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:

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



DN0621509

Issue 10-0-1

33


Id:0900d80580956c35

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



34 DN0621509

Issue 10-0-1


Id:0900d80580956c35

Feature description

• 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 Identificationservice, 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:

• 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

1.10 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

• SDB/LDAP server

SDB data can be managed and maintained by LDAP solutions, such as, NPS, One-

NDS 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 pro-

cesses 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 anoptional 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-



DN0621509

Issue 10-0-1

35


Id:0900d80580956c35

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

surement 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 interfacesThis feature operates on the following SIP signaling interfaces:

• SIP interface toward other SIP-capable network elements—the SIP Network inter-

face

• 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, FeatureDescription.

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



36 DN0621509

Issue 10-0-1


Id:0900d80580956c37

Main changes in 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 spe-

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

Info allows Call and Communications Diversion services that expand on the base SIP

behavior.


Functionality relevant to emergency call handling using wildcards has been added.


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

ities.

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

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


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.


No changes


Early answer and Ringback tone connection in CMN mode functionality has been

added.


This feature interworks with Feature 1448: High Capacity MSS & GCS, which optimizes

the message bus usage of call control legs in the NVS.



DN0621509

Issue 10-0-1

37

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

Id:0900d80580956c37

During anonymous call setup and instant messaging on the SIP Access interface, the

NVS can make the user agent send his/her user identity.


Support for Feature 1844: Call Transfer Support on SIP has been added.


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.


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



• Regulatory services, Emergency calls

The subsection has been updated to take into account further checking of the Emer-

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

• Network elements



38 DN0621509

Issue 10-0-1


Id:0900d80580956c37

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


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 .



• 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 tele-

phony (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-0Feature 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 func-

tionality have been made to the following sections:

• Requirements - products

• Functionality - services

• Parameters

• Restrictions

Editorial changes have also been made.


Feature names have been corrected according to the approved feature names.


Editorial changes have been made.


Feature 1448: High Capacity MSS & GCS has been added to section Related and inter-

working features.



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.

Documents

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