Feature 1671- NVS Call Handling (Application Server Mode).pdf

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

http://slidepdf.com/reader/full/feature-1671-nvs-call-handling-application-server-modepdf 1/57

MSC Server, Rel. M16.2,

Feature Documentation,

version 2

Feature 1671: NVS Call Handling

(Application Server Mode)

DN0621512

Issue 11-0-0

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 DN0621512

Issue 11-0-0

Feature 1671: NVS Call Handling (Application Server Mode)

Id:0900d8058099d991

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.



DN0621512

Issue 11-0-0

3

Feature 1671: NVS Call Handling (Application ServerMode)

Id:0900d8058099d991

Table of ContentsThis document has 57 pages.

1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.2 Benefits for the operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.3 Requirements for using the feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.3.1 Software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.3.2 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.3.3 Products. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.4 Functionality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.4.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.4.2 Basic call scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.4.3 Regulatory service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.4.4 Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

1.4.5 Open TAS support for Multimedia Telephony (MMTel) services. . . . . . 25

1.4.5.1 Supported media types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

1.4.5.2 Capability check. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

1.4.6 Subscription management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

1.4.6.1 HLR as subscriber registry. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

1.4.6.2 HSS as subscriber registry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

1.4.7 Registration support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

1.4.7.1 HLR based subscription. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

1.4.7.2 HSS based subscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

1.4.8 MMTel session setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311.4.8.1 Originating side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

1.4.8.2 Terminating side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

1.4.9 MMTel media content change in an active session . . . . . . . . . . . . . . . . 34

1.4.10 MMTel supplementary service management. . . . . . . . . . . . . . . . . . . . . 35

1.4.10.1 Facility call support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

1.4.10.2 Ut/XCAP support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

1.4.10.3 Service code service dependency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

1.4.11 Interworking with audio tones and announcements. . . . . . . . . . . . . . . . 37

1.4.12 Interworking with call forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

1.4.13 Location and visited network information handling during call handling 37

1.4.14 Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

1.4.15 Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

1.4.16 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

1.4.17 Charging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

1.5 Capacity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

1.6 Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

1.7 Related and interworking features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

1.8 Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

1.9 Operator interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

1.9.1 MMLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

1.9.2 Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

1.9.3 Cause Codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51



4 DN0621512

Issue 11-0-0


Id:0900d8058099d991

1.10 Subscriber interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

1.11 Network elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

1.12 External interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Main changes in Feature 1671: NVS Call Handling (Application ServerMode) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Changes in the feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Changes in the document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54



DN0621512

Issue 11-0-0

5


Id:0900d8058099d991

List of FiguresFigure 1 Network architecture of the Open TAS . . . . . . . . . . . . . . . . . . . . . . . . . 11

Figure 2 SIP to SIP call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

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

Figure 4 MS to SIP call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Figure 5 SIP to PSTN call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Figure 6 PSTN to SIP call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

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

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



6 DN0621512

Issue 11-0-0


Id:0900d8058099d991

List of TablesTable 1 OneVoice Supplementary Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Table 2 Supported media services by media type and extension . . . . . . . . . . . . 28

Table 3 Open TAS response to SIP OPTIONS request . . . . . . . . . . . . . . . . . . . 28

Table 4 MMTel Service to HLR CS Service mapping . . . . . . . . . . . . . . . . . . . . . 29

Table 5 Media to Basic Service Code HSS mapping . . . . . . . . . . . . . . . . . . . . . 31

Table 6 Originating media services to basic service code mapping . . . . . . . . . . 32

Table 7 ISDN BC to HLR basic service code mapping . . . . . . . . . . . . . . . . . . . . 33

Table 8 MMTel Services to ISDN BC code mapping . . . . . . . . . . . . . . . . . . . . . 34



DN0621512

Issue 11-0-0

7


Feature description

Id:0900d80580a2e95f

1 Feature description

1.1 IntroductionThe Nokia Siemens Networks Open Telecom Application Server (Open TAS) / Nokia

Siemens Networks Mobile VoIP Server (NVS) provides services to IMS subscribers

including Voice over LTE (VoLTE) and Voice over IP(VoIP) users. Such services

include, for example, supplementary services, network services, and regulatory ser-

vices. The Open TAS reuses software components of the Nokia Siemens Networks

MSC Server (MSS) so it can provide the same services and features as those provided

by the MSS to CS subscribers in 2G/3G core networks.

The Open TAS/NVS provides a telecom application server (TAS) role for the IMS where

the Open TAS/NVS is controlled by the IMS Service Control (ISC) interface, enabling

IMS subscribers to use the same services currently available to GSM and Universal

Mobile Telecommunication System (UMTS) subscribers. In 3GPP IMS, ISC is based onthe SIP protocol.

The NVS is also offered as a standalone SIP server mode, which can be used as the

entry mode for VoIP services.

g For stylistic reasons, the term Open TAS, rather than Open TAS/NVS, is used through-

out the rest of this document. There is no difference in functionality between the Open

TAS and NVS operating in IMS environments. For more information on the naming con-

ventions used in this document, see the document entitled Impact of the Nokia Siemens

Networks Open Telecom Application Server (Open TAS) on Documentation.

Both modes use a standard centralized repository in order to store SIP subscriber

service related information such as Mobile Subscriber International ISDN Number

(MSISDN), Intelligent Network (IN), and supplementary service (such as MMTel) related

information. The repository is also required to provide functionalities for SIP terminating

transactions, such as VoIP calls and messaging. Both modes are able to use the Home

Location Register (HLR) product for this purpose. As an alternative, the Home Sub-

scriber Server (HSS) can be utilized via the Sh interface. In addition, to complement the

HLR data, a specific set of SIP subscriber data can be retrieved from an LDAP directory

via the LDAP interface or from a Home Subscriber Server (HSS) via the Sh interface.

This document describes the IMS application server mode.

1.2 Benefits for the operator The 3GPP defined IP Multimedia Subsystem (IMS) architecture is capable of providing

global connectivity between two Internet Protocol (IP) endpoints that are registered in

the system. To provide additional services for IMS subscribers, the Third Generation

Partnership project 3GPP defines an IP Service Control (ISC) interface, which is based

on the Third Generation Partnership Project Session Initiation Protocol (3GPP SIP).

Through this interface, the IMS service provider is able to provide a wide range of differ-

ent services for subscribers who registered on the IMS network. The service provider

can also select application servers, for example Push To Talk Over Cellular (PoC) or

Presence and Instant Messaging, which are suitable for the requirements of their

network.



8 DN0621512

Issue 11-0-0


Id:0900d80580a2e95f

Feature description

In order to successfully deploy voice or video services such as those defined by GSMA

IRD IR.92 and IR.94, similar capabilities must be available in the IMS as those existing

in traditional circuit switched networks. The Open TAS acts as a telecommunication

services related application server by providing a 3GPP standardized ISC interface

toward the network elements which act as the Serving Call State Control Function (S-

CSCF) for IMS traffic. Therefore, when an IMS subscriber registers in the IMS, the

selected S-CSCF initiates a third-party registration procedure, through the ISC interface,

toward all the needed application servers where the Open TAS is also present.

When a SIP ISC interface is used in an Open TAS that has inherited 3GPP-defined MSS

capabilities, 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, instant messaging directly between terminals). The Open TAS

can also offer the possibility to use the same IN services such as CAMEL pre-paid, or

the Virtual Private Numbering (VPN) service for SIP subscribers registered on the IMS,

in the same way as in the case of GSM/UMTS subscribers. In such cases, the Open

TAS provides flexible routing schemes to enable the use of the same national number-

ing plans when both GSM/UMTS and SIP subscribers are making calls.

The Open TAS possesses integrated support for emergency calls as well as other reg-

ulatory requirements such as lawful interception and number portability based on the

same facilities as GSM/UMTS mobile networks.

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

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

• Feature 1841: Service Attribute Analysis

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

• PLMN Specific SS-CODE Support in MSS/VLR (feature code 796)

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 (feature codes 1199-1200 and 1202-1214)

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.



DN0621512

Issue 11-0-0

9


Feature description

Id:0900d80580a2e95f

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 (feature code 1973)

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

Open TAS requires the following ON/OFF license to be activated:

• SIP History Info (feature code 3179)

T.38 fax data service support for Open TAS requires the following ON/OFF license to be

activated:

• MSS - Support for T.38 Fax over IP (feature code 1333)

Multimedia Telephony video support for Open TAS requires the following ON/OFF

license to be activated:

• MSG - SIP video support (feature code 3710)

Multimedia Telephony video share support for Open TAS requires the following ON/OFF

license to be activated:

• MSG - SIP video share support (feature code 3712)

Multimedia Telephony MSRP based services support for Open TAS requires the follow-

ing ON/OFF license to be activated:

• MSG - SIP MSRP support (feature code 3711)

Sh interface functionality for SIP subscriber data requires the following ON/OFF license

to be activated: • Sh for subscriber repository (feature code 4336)

Sh interface functionality for MMTel data requires the following license to be activated:

• Sh for mmtel repositories (feature code 4524)

When HLR is used by Open TAS for MMTel services via MAP Restore Data, the sub-

scriber data modification notifications use case requires the following license to be acti-

vated:

• Internal SCP LK (feature code 3216)



10 DN0621512

Issue 11-0-0


Id:0900d80580a2e95f

Feature description

1.3.2 Hardware

This feature requires the NVS with 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 the following products:

• Nokia Siemens Networks MSC Server (MSS) running NVS software.

1.4 Functionality

1.4.1 General

New Open TAS-related SIP interfaces

The Open TAS includes ISC interfaces. These are the following:

• ISC SIP Access interface

• ISC SIP Network interface

These interfaces are trusted, and typically reside in the private network. The Serving

Call State Control Function (S-CSCF) uses these interfaces to communicate with the

Open TAS for originating and terminating service execution.

Supported signaling protocols and interworking

The Open TAS supports several signaling protocols, for example: • Integrated Services User Part (ISUP)

• Bearer Independent Call Control (BICC)

• Session Initiation Protocol for ISDN (SIP-I)

• Session Initiation Protocol (SIP) (Media Gateway Control Function [MGCF])

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 the Open TAS. The relevant inter-

faces of the Open TAS are highlighted in the figure.

g The following figure illustrates a vendor-independent scenario. Note, however, that

Nokia Siemens Networks’ HLR and HSS use One-NDS as a back-end database server.

The HLR/HSS provides mediation between the data stored in the One-NDS and the

Open TAS requesting the data. In addition, the Open TAS has in-built front-end capabil-

ities enabling it to communicate with the One-NDS directly over the LDAP interface.



DN0621512

Issue 11-0-0

11


Feature description

Id:0900d80580a2e95f

Figure 1 Network architecture of the Open TAS

SIP to SIP

IMS

Mp MAP LDAPCx Cx

ISC SIP ISC SIP

CS coreIP-CAN(EPS, WiFi)

IP-CAN(EPS, WiFi)

CS core

I/S-CSCFP-CSCF

HSS

VoIP

Open TAS(MMTel AS / IM-SSF/ MRFC)

HSS

P-CSCFI/S-CSCF

MGW SCPHLR LDAP

ShCAP/INAP



12 DN0621512

Issue 11-0-0


Id:0900d80580a2e95f

Feature description

SIP to SIP call

Figure 2 SIP to SIP call

The figure above shows a call scenario when the originating SIP user agent places a

call to another SIP user agent and both of them have the VoIP service enabled.

The use of the Multimedia Gateways (MGWs) on the user plane is configurable within

each Open TAS, thus it is possible for the user plane passing through the MGW(s) or

the SIP User Agents (UAs) to exchange Real-Time Transport Protocol (RTP) traffic

directly through the IP backbone.

If the user agents use the logical names (for example [email protected]) to address

each other, the Open TAS uses the HSS via the Sh interface to translate between thelogical names and MSISDN. Optionally, if the Sh interface is not in use, a query can be

made to a Lightweight Directory Access Protocol (LDAP) server in order to perform the

translation.

On the terminating Open TAS, the subscriber information needed to perform the termi-

nating services can be retrieved from the IMS HSS using the Sh interface, or alterna-

tively using the HLR via the MAP interface.

SIP to CS Network

SIP to MS call

IMS

ISCNetwork Access

HSS

OriginatingS-CSCF

VoIP

Sh

ISCSIP Access

Cx

LTE

HLR IMS

TerminatingS-CSCF

MAP

ISCSIP Access

Cx

LTE

UA-A UA-B

MGW(optional)

MGW(optional)

Signalling path

User plane path with CMN active modeUser plane path with CMN inactive

OriginatingOpen TAS

TerminatingOpen TAS

Sh

HSS

VoIP

ISCNetwork Access

IP



DN0621512

Issue 11-0-0

13


Feature description

Id:0900d80580a2e95f

Figure 3 SIP to Mobile Station (MS) call

This figure shows an IMS subscriber calling a GSM/UMTS subscriber. Under basic con-

ditions, the originating Open TAS executes the originating VoIP services based on the

subscriber data retrieved from the HSS or the HLR and leaves routing to the S-CSCF

by sending the received call back to the S-CSCF. It is also possible for the originating

Open TAS logic to perform ISC->CS interworking (as shown in the dashed line). Trans-

lation of logical names into MSISDN is performed by the HSS via the Sh interface, or

optionally using an LDAP query if the Sh interface is not in use.

The access network for GSM/UMTS is not detailed in the figure.

IMS

OriginatingS-CSCF

ISCSIP Access

Cx

LTE

Nc, PSTN

UA-A MGW(optional)

MGW

Signalling path

User plane path

OriginatingOpen TAS

GCS(MGCF)

Mg

MSS

MGW

UA-B

GSM/UMTS

Nc, PSTN

Sh

HSS

VoIP



14 DN0621512

Issue 11-0-0


Id:0900d80580a2e95f

Feature description

Mobile to SIP call

Figure 4 MS to SIP call

This figure illustrates the situation when a GSM/UMTS subscriber calls an IMS sub-

scriber who has VoIP services enabled. Under basic conditions, the originating MSS

sends a call to the MGCF, which forwards the request to the IMS domain. Terminating

services are executed by the terminating Open TAS. It is also possible for the originating

MSS to send the request directly to the Open TAS; in such cases the terminating Open

TAS performs the CS->ISC interworking. The Open TAS retrieves subscriber informa-

tion for terminating services using the HSS via the Sh interface, or optionally via the

HLR.

The access network for GSM/UMTS is not detailed in the figure.

IMS

Terminating

S-CSCF

ISCSIP Access

Cx

LTE

Nc, PSTN

UA-BMGW(optional)

MGW

Signalling path

User plane path

TerminatingOpen TAS

GCS(MGCF)

Mg

MSS

MGW

UA-A

GSM/UMTS

Nc, PSTN

Sh

HSS

VoIP



DN0621512

Issue 11-0-0

15


Feature description

Id:0900d80580a2e95f

SIP to PSTN call

Figure 5 SIP to PSTN call

IMS

OriginatingS-CSCF

ISCSIP Access

Cx

LTE

PSTN

UA-A MGW(optional)

MGW Signalling path

User plane path

OriginatingOpen TAS

GCS(MGCF)

Mg

Phone-B

PSTNNetwork

PSTN

Sh

HSS

VoIP



16 DN0621512

Issue 11-0-0


Id:0900d80580a2e95f

Feature description

PSTN to SIP call

Figure 6 PSTN to SIP call

Efficient MGW resource usage

The Open TAS 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 RTP traffic

CMN mode can be used when incoming and outgoing signals are 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).

In CMN mode, it is still possible to provide services through the MGW (for example,

announcements). With these services in operation, the Open TAS 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 service

Emergency calls

Using the Open TAS, SIP subscribers can initiate VoIP calls using regulatory-definednumbers, such as 911, 112 , or some other country-specific number. SIP subscribers

IMS

TerminatingS-CSCF

ISCSIP Access

Cx

LTE

PSTN

UA-AMGW(optional)

MGW Signalling path

User plane path

TerminatingOpen TAS

GCS(MGCF)

Mg

Phone-B

PSTNNetwork

PSTN

Sh

HSS

VoIP



DN0621512

Issue 11-0-0

17


Feature description

Id:0900d80580a2e95f

can also initiate calls using operator-defined URIs, such as police. In such cases, the

Open TAS receives the called number/URI that points to an emergency service and,

based on its internal configuration, the Open TAS selects the proper routable E.164

address toward the nearest emergency center.

The Open TAS 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

(Application Server 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 Open TAS can deliver location information for the SIP subscriber based

on the subscriber’s profile data, stored in the LDAP or the HSS. However, the location

information stored in the subscriber’s profile does not contain the subscriber’s real loca-

tion, only the location information that was defined when the subscriber’s profile was ini-

tially configured. This can lead to situations where the actual location of the subscriber

is unknown.

Number portability

The Open TAS provides support for number portability (defined by the European Tele-

communications Standards Institute (ETSI) in mobile number portability specifications)for subscribers using SIP-based VoIP. Support of mobile number portability is an

optional feature of the Open TAS. For more information on mobile number portability,

see Feature 1081: ETSI Mobile Number Portability , Functional Description.

The Open TAS also 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 Open TAS, the lawful interception functionality can behandled using optional Feature 703: On-line Call Monitoring , which enables the collec-



18 DN0621512

Issue 11-0-0


Id:0900d80580a2e95f

Feature description

tion 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 Open TAS 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 Open TAS. 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 Open TAS also 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 of the access method (that is, control and user plane protocols). To enable this,

the Open TAS is connected to the S-CSCF through the ISC (SIP) interface and executes

the originating or terminating services.

g The Open TAS can co-locate an integrated Media Gateway Control Function (MGCF)

functionality as well, which is described in Feature 1331: Session Initiation Protocol in

the MSS, Feature Description.

The following sections go through the services that the Open TAS provides for S-CSCFthrough the ISC interface.

Calling Line Identification Restriction (CLIR)

CLIR is an originating service running in the originating Open TAS. It can be provisioned

and activated in the HLR or the HSS for each subscriber.

Users can overwrite 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]

Alternatively, users can overwrite both HLR and HSS settings by sending XCAP

requests as XML commands over the Ut interface. For more information about this func-

tionality, see Feature 1979: Ut/XCAP Interface Support in NVS, Feature Description.



DN0621512

Issue 11-0-0

19


Feature description

Id:0900d80580a2e95f

Figure 7 Calling Line Identification Restriction (CLIR)

Calling Line Identification Presentation (CLIP)

CLIP is a terminating service running in the terminating Open TAS. It can be configured

in the HLR or the HSS 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.

Figure 8 Calling Line Identity Presentation (CLIP)

Calling Line Identification Restriction (CLIR) Override

CLIR override is a terminating service running in the terminating Open TAS. This

function can be configured in the HLR or the HSS 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 Open TAS 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)

Originating Open TAS

INVITEFrom: +123456

INVITEFrom: anonymous

"A" party has theCLIR service enabled

Terminating Open TAS

INVITEFrom: +123456

INVITEFrom: anonymous

"B" party has no CLIPservice provisioned



20 DN0621512

Issue 11-0-0


Id:0900d80580a2e95f

Feature description

When the Open TAS is working in CMN = ACTIVE mode, the MGW resources are

reserved temporarily, and after the announcement, the resources are freed up.

Announcements in CMN = ACTIVE mode are supported before the ringing phase. In the

case of call forwarding, announcements are supported toward the forwarded numberuntil the ringing phase begins for the new leg.

Call-forwarding

Call forwarding services enable the user to divert the communication addressed to

him/her to another destination. There is no limitation to this destination, including any

number in the supported networks as well as voicemail systems.

The forwarding protocol used toward the new destination can be any kind supported by

the Open TAS (for example: SIP, SIP-I, 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.

The Open TAS 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)

For more information on call forwarding, see Feature 111: Call Forwarding, Feature

Description.

Call Transfer

The Open TAS supports Call Transfer using the SIP REFER method. For more informa-

tion, see Feature 1844, SIP Call Transfer Support, Feature Description.

Barring

The Open TAS supports the following supplementary services that belong to the call

restriction supplementary service (barring):

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

Roam) (Barring program 2)

Call waiting

The Open TAS supports the terminal-based call waiting service, meaning that the Open

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



DN0621512

Issue 11-0-0

21


Feature description

Id:0900d80580a2e95f

ing between the IP Multimedia (IM) Core Network (CN) subsystem and Circuit Switched

(CS) networks

If the Open TAS is configured to CMN Active mode, this functionality has no effect on

Open TAS, but is transparently proxied.

One Number Service

Open TAS supports the 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 1907: One Number Service.

Common SIP URI

The common 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 even group several users behind one

identity.

Intelligent network

Open TAS supports CAMEL and CoreINAP interfaces.

Dual-Tone Multi-Frequency (DTMF) support

The Open TAS and MGW support the following DTMF functionalities:

• receiving and sending DTMF in-band G.711 codec

• receiving and sending Real-time Transport Protocol (RTP)-based Dual-Tone Multi-

Frequency (DTMF)

The Open TAS can handle out-of-band DTMF signals as well. Support for out-of-band

DTMF enables the Open TAS to handle incoming SIP INFO messages and send them

using the application/dtmf-relay MIME type across all incoming and outgoing SIP inter-

faces.

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 Open TAS 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 toward call control, thus user plane and call control can route calls differ-

ently.

SCTP support

The Open TAS provides support for SCTP on all SIP interfaces:

• SIP access interface if there is some network element between the Open TAS and

the SIP subscriber (for example Session Border Controller (SBC))

• IMS Service Control (ISC) interface



22 DN0621512

Issue 11-0-0


Id:0900d80580a2e95f

Feature description

• SIP trunk interface

• MGCF interface

• SIP-I interface

• Sh 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 dif-

ferent CLI presentation statuses.

Early answer

The Open TAS 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 toward the A party to exchange

SDPs that initiate a new offer or provide an answer.

If this function is activated, Ringback tone connection in CMN mode functionality should

also be activated.

Ringback tone connection in CMN mode

The Open TAS connects the ringback tone from the MGW (Multimedia Resource

Function Processor (MRFP)) if neither the calling nor the called party has connected a

ringback tone.

In a VoLTE environment, it is always the network of subscriber B that is responsible for

providing the ringback tone for subscriber A, regardless of which domain (CS, PS) sub-

scriber A is in. The Open TAS can reserve the MRFP for this dynamically. The alert tone

for subscriber B, on the other hand, is provided by the UE, there is no impact on the

Open TAS/MRFP.

Malicious call identification

The Malicious Call Identification (MCID) service enables SIP subscribers’ incoming

session-related information to be stored by the Open TAS. 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 Open TAS checks to see whether or not the MCID

service has been provisioned for the called party. If it has, the Open TAS 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 Mali-

cious call identification of the NVS and MSS SIP User Guide.



DN0621512

Issue 11-0-0

23


Feature description

Id:0900d80580a2e95f

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 VoLTE/SIP VoIP subscribers

The Calling Name Presentation (CNAP) supplementary 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 LTE/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 Open TAS subscriber makes a call, an initial INVITE request is sent toward

the called party. During the SIP call setup process, the Open TAS checks to see whether

or not the 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 Open TAS 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 Open TAS will either add the text Anonymous to the

From header, signifying that the CNAP license has been activated but the subscriber

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

nifying that even though the CNAP license has been activated, the subscriber does not

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 LTE/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 Open TAS provides Com-

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



24 DN0621512

Issue 11-0-0


Id:0900d80580a2e95f

Feature description

The Open TAS generates new History-Info headers if diversion services occur during

the internal call routing. When adding new History-Info headers, the Open TAS 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 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 Open TAS 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 Open TAS uses the Reason parameter to perform tradi-

tional Call Forwarding (CF).

Music on Hold

The Music on Hold functionality allows a person placed on hold to hear music instead of

the standard call hold tone. For more information, see section Music on Hold of the

Feature 1451: IMS-CS Interworking, Feature Description.

gThis functionality is currently provided only for audio calls.

Selective Ringback Tone

The Selective Ringback Tone (SRBT) is a called party service that allows the calling

party to hear a customized ring tone while the called party is alerted. That is, instead of

the existing ringback tone, the calling party hears a melody or a greeting specified by

the called party while waiting for the receiver to respond to the call. The called party can

select a melody or a greeting based on the identity of the calling party, for example,

Calling Line Identity (CLI). This service requires the use of an External Ringtone Server

(ERS), provided by a third party vendor. For more information see Feature 1570: Selec-

tive Ringback Tone, Feature Description.

gThis functionality is currently provided only for audio calls.

Conferencing in NVS

The Conferencing in NVS feature is a centralized ad-hoc, or tightly coupled, conferenc-

ing solution for the Open TAS for up to 6 SIP or CS participants. In this scenario, the

Open TAS is setup via a SIP (VoLTE or VoIP) subscriber and then acts as a centralized

point, or focus, of the conference, where the remaining participants are connected via a

centralized SIP address that resides in the Open TAS. The Open TAS is able to use the

existing CS MGW functionality to establish the conference. Once the conference is set

up, the MGW performs the mixing and delivery of the conference media to each UA, with

only one voice connection used for each participant in the user plane. For more informa-

tion see Feature 1918: Conferencing in NVS, Feature Description.



DN0621512

Issue 11-0-0

25


Feature description

Id:0900d80580a2e95f

g This functionality is currently provided only for audio calls.

1.4.5 Open TAS support for Multimedia Telephony (MMTel) servicesThe 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—and a similar agreement created for video as GSMA IR.94 have been

used as the basis for implementing a group of common supplementary services defined

in 3GPP MMTel Release 9 specifications. These common supplementary services can

be mapped to the existing supplementary services in the HLR the following way:

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 MMTel AS role of the Open TAS is capable of handling several types of media, and

formats defined in both GSMA IR.92 IMS Profile for Voice and SMS and GSMA IR.94

IMS Profile for Conversational Video Service are supported. In CMN active mode the

Open TAS can differentiate between Audio, Video, T.38, Video Share and Message

Session Relay Protocol (MSRP) based services. In CMN inactive mode, only Audio and

T.38 is supported. Adding and removing media or services during a call is supported

GSMA IR.92/OneVoice-related

Supplementary Service

Basic supplementary service

for VoIP/2G/3G in HLR

Originating Identification Presentation (OIP) Calling Line Identity Presentation (CLIP)

Terminating Identification Presentation (TIP) Connected Line Identity Presentation (CLOP)

Originating Identification Restriction (OIR) Calling Line Identity Restriction (CLIR)

Terminating Identification Restriction (TIR) Connected Line Identity Restriction (COLR)

Communication Diversion Unconditional Call Forwarding Unconditional (CFU)

Communication Diversion on not Logged in Call Forwarding not Reachable (CFNRc)

Communication Diversion on Busy Call Forwarding Busy (CFB)

Communication Diversion on not Reachable Call Forwarding not Reachable (CFNRc)

Communication Diversion on No Reply Call Forwarding no Reply (CFNR)

Barring of All Incoming Calls Barring of all Incoming Calls (BAIC)

Barring of All Outgoing Calls Barring of all Outgoing Calls (BAOC)

Barring of Outgoing International Cal ls Barring of Outgoing International Calls

Communication Hold (HOLD) Call Hold (CH)

Message Waiting Indication (MWI) Requires VMS. MMTel AS role to forward the call to

VMS.

Communication Waiting (CW) Call Waiting (CW)

Ad-Hoc Multi Party Conference Conference (MPTY)

Table 1 OneVoice Supplementary Services



26 DN0621512

Issue 11-0-0


Id:0900d80580a2e95f

Feature description

when in CMN active mode. Different call handling can be configured for each type of

service and media. This allows specific routing and charging to be applied.

Open TAS support for multimedia telephony (MMTel) services, presently, provides

support for MMTel services through the use of multimedia tags, described in sectionHandling 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 ser-

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

• Accept-Contact

Example:

P-Preferred-Service: urn:urn-7:3gpp-service.ims.icsi.mmtel

On the originating side, if a P-Preferred-Service or P-Asserted-Service header includes

the ICSI, and an Accept-Contact header is also present, the Accept-Contact header

must include the ICSI, otherwise the call will be rejected.

The ICSI is also encoded in a tag value for +g.3gpp-icsi-ref and appended to the

end of the Contact header.

The IMS Application Reference Identifier (IARI) identifies additional software applica-

tions supported by a SIP UA. This information is used by the Open TAS to further estab-

lish 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 Contact header.

The Open TAS also supports the following additional feature tags for generic multimedia

services:

• audio

• 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 Open TAS also appends feature tags to the

Contact header during replies to OPTIONS queries.

During an IR.94 compliant video call (containing both audio and video), the following

service tags are present in the SIP headers:

P-Preferred-Service: urn:urn-7:3gpp-service.ims.icsi.mmtel

Contact: <Contact URI>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-

service.ims.icsi.mmtel";video



DN0621512

Issue 11-0-0

27


Feature description

Id:0900d80580a2e95f

Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-

service.ims.icsi.mmtel";video

Additionally, the RTP/AVPF SDP profile is used for the video media. This allows for

RTCP-based video feedback messages.If the called party does not support the RTP/AVPF profile, then the party can send a 488

Not Acceptable Here or a 606 Not Acceptable SIP response without the MMTel and

video feature tags in the Contact header, with the SDP field indicating that the video or

audio media has not been accepted (by setting the port number of the related media to

0). If the SIP_PROXY_MEDIA_NOT_ACC PRFILE parameter is active and the call is

handled in CMN mode, the Open TAS will comply with IR.94 and proxy the 488 Not

Acceptable or 606 Not Acceptable SIP responses toward the caller with the received

Contact header (without the MMTel and video feature tags) and SDP fields.

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

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 a180 Ringing response for the call waiting tone to be connected.

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

SIP Header Proxying

The Open TAS supports proxying of unhandled SIP headers, in addition to the standard

Back to Back User Agent (B2BUA) mode.

When an incoming SIP method is received that includes unhandled headers, theSIP_HEADER_PROXYING PRFILE parameter value controls if the headers are proxied

to the outgoing side or discarded. If an unhandled header is received and SIP Header

Proxying is disabled, a new SIP header is not recreated on the outgoing side.

g In CMN inactive mode, the proxying of unhandled SIP headers is performed only for

INVITE requests.

1.4.5.1 Supported media types

The Open TAS can differentiate the following media types:

• Audio

• Video



28 DN0621512

Issue 11-0-0


Id:0900d80580a2e95f

Feature description

• Image

• Message

This is a subset of all the IANA Internet Media Types that can appear in the m parameter

of an SDP body. The media types listed above and some specific extensions in SDP areused to indicate the following services the subscribers would like to use in their sessions:

g If a media type that is not in the list above or a media type with an extension that is not

listed appears in an SDP, the Open TAS handles that as an “other” service internally.

For example, this “other” media type can be “text” or “application”.

g A Voice service (for example, a request that uses media type Audio) is also capable to

serve as the basis for fax communication if a fax-capable codec (G.711) is selected for

this session. However, the Open TAS will still consider that session as a voice session.

g The Chat, Image Share and File Share services as defined by GSMA use MSRP. The

Open TAS does not differentiate between those sub-services.

g The MGW supports only Voice and T.38 based fax services. This means that the Video,

Video Share, MSRP and “other” services are supported by the Open TAS only in CMN

mode.

1.4.5.2 Capability check

The SIP OPTIONS request is defined by IETF and GSMA as a method to enable one

participant to interrogate the capabilities of the intended peer before the start of session

setup.

The Open TAS does not proxy SIP OPTIONS to the intended peer. Instead, the Open

TAS terminates the request and answers with its own capabilities. The following tableshows how the 200 OK reply is delivered for a SIP OPTIONS request:

Associated service Media type Extension

Voice Audio -

Video Video -

Video Share Video -

T.38 based fax Image “t.38”

MSRP Message “MSRP”

Table 2 Supported media services by media type and extension

License SDP lines Contact parameters

- (Filled based on the capabilities

of the MGW indicated by the pre-

ceding UPDR)

audio:

+g.3gpp.icsi-ref=”urn%3Aurn-7%3A3gpp-

service.ims.icsi.mmtel”

T38 in MSS m=image 0 udptl t38

Table 3 Open TAS response to SIP OPTIONS request



DN0621512

Issue 11-0-0

29


Feature description

Id:0900d80580a2e95f

g When integrated in an IMS system the OPTIONS header will be handled by the CSCF

without triggering the Open TAS, and the OPTIONS request will not reach (or be invisi-

ble) to the Open TAS.

1.4.6 Subscription management

1.4.6.1 HLR as subscriber registry

During an MMTel session initiation, when subscriber data is retrieved from the HLR via

the MAP interface, depending on operator preference, either the MAP Update Location

or MAP Restore Data procedures are called at subscriber registration time, with data

being stored in the VLR database.

In order to support and manage HLR as a subscriber registry, MMTel services are

mapped to the following CS tele- and bearer services:

g When an operator manages services for a tele- or bearer service code, those services

are applied by the Open TAS on sessions using the corresponding MMTel service.

SIP video call support m=video 0 RTP/AVP 96 99

a=rtpmap:96 H263-2000/90000

a=rtpmap:99 MP4V-ES/90000

a=rtpmap:103 H264/90000

video

SIP video share support m=video 0 RTP/AVP 96 99

a=rtpmap:96 H263-2000/90000

a=rtpmap:99 MP4V-ES/90000

a=application:com.nokia.rtvs

video;

+g.3gpp.cs-voice;

+g.3gpp.iari-ref=”urn%3Aurn-7%3A3gpp-

applications.ims.iari.gsma-vs”

SIP MSRP support m=message 0 TCP/MSRP

a=accept-types:application/*audio/* message/* model/*

text/* video/* image/*

a=file-selector

+g.3gpp.iari-ref=”urn%3Aurn-7%3A3gpp-

applications.ims.iari.gsma-is”

License SDP lines Contact parameters

Table 3 Open TAS response to SIP OPTIONS request (Cont.)

MMTel Service Basic Service Code Basic Service GroupVoice T11 TS10

Video B1F BS30

Video Share B1F BS30

T.38 Fax T61 TS60

MSRP T21, T22 TS20

Table 4 MMTel Service to HLR CS Service mapping



30 DN0621512

Issue 11-0-0


Id:0900d80580a2e95f

Feature description

1.4.6.2 HSS as subscriber registry

The implementation of Sh support in the Open TAS makes it possible to download sub-

scriber data from the HSS instead of the HLR. MMTel related subscription data is stored

in the MMTEL-Services and MMTEL-Services-Extra repositories.

MMTEL-Services contains the 3GPP defined standard MMTel data, for example, com-

munication diversion (call forwarding) related rules. MMTEL-Services-Extra contains

specific, advanced service data that is necessary for proper subscriber and service

handling (for example, operator-controlled call forwarding and barring, or carrier selec-

tion) and allows operators to deliver a seamless service experience across 2G/3G and

4G domains by providing service parity between CS and IMS domains.

MMTEL-Services and MMTEL-Services-Extra are managed through the provisioning

gateway (PGW).

1.4.7 Registration supportThe following feature tags are supported by the MMTel services:

• +g.3gpp.icsi-ref=”urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel”

• audio

• video

• +g.3gpp.cs-voice

• +g.3gpp.iari-ref=”urn%3Aurn-7%3A3gpp-application.ims.iari.gsma-mmtel

When a feature tag is received as a Contact parameter during a SIP REGISTER

request, the Open TAS saves it together with the other subscription data to the SDP.

During registration the subscriber data is downloaded from LDAP DB+HLR or from the

HSS over Sh.

1.4.7.1 HLR based subscription

The only downloaded services are those that can be carried in standard MAP operations

(Update Location, Insert Subscriber Data, Restore Data). Downloaded service data is

stored in the VLR DB, just like for CS mobile subscribers. The execution of gateway

services at terminating session setup relies then heavily on the involvement of the HLR

via the MAP SRI procedure. The execution of gateway services includes the checking

of incoming call barring, the execution of Call Forwarding Unconditional, and Gateway

IN triggering.

1.4.7.2 HSS based subscription

If the Sh interface is used toward the HSS, the Open TAS does not rely on the HSS in

service execution during session setup time, as the HSS does not have that role during

session setup. As a result, all possible services of the subscriber must be downloaded

to and executed in the Open TAS, including gateway services. To handle this, the

MMTEL-Services and the MMTEL-Services-Extra repositories that contain all supple-

mentary service data are stored in the HSS.

When the subscriber data is received from the HSS over Sh, the Open TAS stores the

information in the VLR and SPD databases. This information is split depending on which

subscriber services the VLR already includes fields for (for example, if they are mapped



DN0621512

Issue 11-0-0

31


Feature description

Id:0900d80580a2e95f

to CS supplementary services and respective service codes)—services with no fields in

the VLR are stored in the SPD.

g The repository data containers do not directly match the respective internal database

structure of the Open TAS. This means that the MMTEL-Services repository is not com-pletely stored in the VLR and the MMTEL-Services-Extra repository data is not com-

pletely stored in the SPD. For example, MMTEL-Services includes some gateway

service specific data that is stored in the SPD and MMTEL-Services-Extra has some

fields that are available and stored in the VLR.

The VLR database was designed around the CS mobile architecture and as such relies

on basic service codes. This means that, in order to store subscription information, a

basic service code must be defined for those services which can be different for the dif-

ferent media types, for example, call forwarding settings can be different for an audio or

a video call.

When data is received over the Sh interface and stored in the VLR, the media specificportions are mapped to the following basic service codes:

After being mapped, the received service data is stored to the corresponding basic

service code in the VLR. In addition, the following gateway services that are stored in

the SPD also depend on a basic service that is mapped when the service is added to

the database:

• Call Forwarding Unconditional (CFU)

• Barring of All Incoming Calls (BAIC)

• Barring of incoming calls when subscriber is roaming outside the HPLMN country

(BIRO)

1.4.8 MMTel session setup

This section describes generic call scenarios and service execution for both originating

and terminating side of a SIP call with multiple media types.

1.4.8.1 Originating side

Fetching originating side services

When the initial INVITE request is received, the Open TAS fetches the services of the

subscriber from VLR (for example, supplementary services and operator determined

barring). In order to perform this, the Open TAS has to define a tele- or bearer service

code in the request. The Open TAS performs a mapping of the requested MMTel ser-

vices, as parsed by the initial INVITE to a single tele- or bearer service code in the fol-lowing manner.

Media type Basic Service Code

Audio T11

Video B1F

Image T61

Message T21

Table 5 Media to Basic Service Code HSS mapping



32 DN0621512

Issue 11-0-0


Id:0900d80580a2e95f

Feature description

g In case of an emergency call request, the Open TAS will use T12 as a service code

toward the VLR, regardless of the requested services.

The VLR replies with the subscriber service attached to the mapped tele- or basic

service code, and the Open TAS executes those services for the originating subscriber

in this session.

Example: the calling subscriber requests a video session, consequently the initial

INVITE request contains audio and video media lines. Open TAS maps the audio+video

combination to the B1F bearer service code and uses that value toward the VLR. The

VLR then returns the B1F related services of the subscriber.

The VLR also returns all the tele- and bearer service codes of the subscriber to be usedlater during the subscription check phase.

Subscription check

The list of subscriber tele- and bearer services which were returned by the VLR in the

previous phase are mapped to MMTel services first. The mapping is configurable via the

Service Attribute Analysis (SAA), which means that the operator can configure which

tele- or bearer service code should represent which MMTel service. It is also possible to

map all MMTel services to a single tele- or bearer service code, for example T11 or B1F.

The Open TAS then compares the MMTel service list from the initial INVITE request to

the service list that is the result of the SAA. If the SAA list contains all services that were

requested in the initial INVITE, the call is accepted. If the initial INVITE contains a

service that is not in the SAA list, the call is rejected with the SIP response 488 Not

Acceptable Here.

Service execution

The Open TAS executes the services that were returned by the VLR in the previous

phase, that is, the services that are defined for the mapped tele- or bearer service code

are executed.

For originating side IN services, the Open TAS fills PLMN BCIE information in IDP as

follows:

• If video or video share media is present in the service list (with or without any other

service), Open TAS sends BCIE indicating a H.324 multimedia call.

MMTel Services Basic Service Code

Voice only T11

Video only B1F

Video Share only B1F

T.38 Fax only T61

MSRP only T21

Video or Video Share combined with another service B1F

Any combination of services not including Video or Video

Share

T11

Table 6 Originating media services to basic service code mapping



DN0621512

Issue 11-0-0

33


Feature description

Id:0900d80580a2e95f

• If only the T.38 fax is in the service list, or only T.38 and voice, Open TAS sends

BCIE indicating a fax call.

• If only voice or only MSRP is present in the service list, Open TAS sends BCIE indi-

cating a speech call. • If more than one media is present in the SDP (except in the case of T.38+voice com-

bination), Open TAS sends a multimedia BCIE in the IDP.

1.4.8.2 Terminating side

Gateway service execution when HLR is used as a subscriber data repository

On the terminating side, service execution is split between the HLR and the Open TAS.

The Open TAS first sends a MAP Send Routing Information (SRI) request to the HLR.

While processing the MAP SRI, the HLR executes some services, for example incoming

call barring or Call Forwarding Unconditional (CFU).

The HLR selects the set of services based on the tele- or bearer service code which iscreated by HLR from the ISDN BC information that is received in the MAP SRI request.

The Open TAS sends ISDN BC information in MAP SRI requests based on the

requested service as described in Originating media services to basic service code

mapping:

• If only audio is requested, the Speech ISDN BC is sent.

• If only video is requested, the H.324 Multimedia ISDN BC is sent.

• If only video share is requested, the H.324 Multimedia ISDN BC is sent.

• If only T.38 fax is requested, the Fax ISDN BC is sent.

• If only MSRP is requested, no ISDN BC is sent.

•If any combination of services is requested, no ISDN BC is sent.

The HLR then maps the received ISDN BC to the tele- or bearer service code as follows:

gWhen no ISDN BC is received in a MAP SRI request, the HLR uses the primary serviceof the subscriber, for example T11.

After processing the MAP SRI request (and executing the relevant services), the HLR

sends a MAP SRI response to the Open TAS.

g After triggering an GMSS based IN service, the Open TAS sends an ISDN BC in an IDP

based on the same rules as those of the MAP SRI request case.

Gateway service execution when Sh is used

When the Sh interface is in use, the Open TAS fetches the gateway service and other

subscriber data from the HSS at registration time and stores those in the SPD and VLR,

as described in section HSS based subscription.

ISDN BC Basic Service Code

Speech T11

H.324 Multimedia B1F

Fax ISDN T61

Table 7 ISDN BC to HLR basic service code mapping



34 DN0621512

Issue 11-0-0


Id:0900d80580a2e95f

Feature description

At session establishment time, the Open TAS creates a single tele- or bearer service

code based on the requested services, with the same logic that was used in the origi-

nating services, interrogating VLR and SPD with the same basic service code that had

been previously mapped to the HSS subscriber data. The Open TAS then executes the

gateway services using the data from the session setup request and data returned from

the VLR and SPD. This is equivalent to the MAP SRI processing logic that would be per-

formed by the HLR.

When triggering GMSS-based IN services, the Open TAS sends the ISDN BC in IDP

based on the requested services as follows:

For more information about gateway service execution when Sh is used, see section

Supplementary service execution in Feature 2027: Sh for NVS Subscriber Repository,

Feature Description.

Terminating service executionThe Open TAS fetches all the terminating services of the subscriber from the VLR.

Fetching subscriber data from the VLR happens in the same way as on the originating

side: the Open TAS creates a single tele- or bearer service code based on the requested

services and sends that code to the VLR. The VLR returns with the services correspond-

ing to that tele- or bearer service code, and all the tele- and bearer service codes the

subscriber has. The Open TAS then uses the list of tele- and bearer service codes for

subscription check. This behavior is identical to the originating side case.

g For visited terminating side IN services, the Open TAS fills the PLMN BCIE in IDP in the

same way as in the originating side case.

Interworking with circuit switched domain

The interworking point toward the CS domain is the MGCF in an IMS system. If the

MGCF receives the initial INVITE request from the IMS domain with multiple media, it

executes a fallback to one media that is supported by the CS domain, that means,

fallback to audio or T.38 will happen.

g If both audio and T.38 are on the requested service list, the first one listed in the SDP

request will be selected.

1.4.9 MMTel media content change in an active session

With the MMTel functionality, the Open TAS supports the change of media content of

active sessions. The Open TAS is capable of handling several types of media present

MMTel Services Sent ISDN BC

Audio only Speech

Video only H.324 Multimedia

Video Share only H.324 MultimediaT.38 Fax only Fax

MSRP only None

Any combination of services None

Table 8 MMTel Services to ISDN BC code mapping



36 DN0621512

Issue 11-0-0


Id:0900d80580a2e95f

Feature description

primary service, normally assigned to the T11 service code. This means that any

primary service related operations will affect those calls as well.

1.4.10.2 Ut/XCAP support

HLR based subscription management

Supplementary services related only to audio or video media can be managed over

Ut/XCAP. Audio media related service management requests are mapped to a T11

service management request by the Open TAS toward the HLR. This means that the

services of the following session types can be managed over Ut/XCAP:

– Audio only

– Video only

– Video share only

– Video or Video share with any other service type

– Any combination of services, but without Video or Video Share in the combination

g Services for MSRP-only sessions cannot be managed.

When the Open TAS does not send ISDN BC to the HLR, the HLR executes the services

related to the primary service, normally assigned to the T11 service code. This means

that if the primary service is configured as T11 or B1F, then audio or video related

service management will affect the primary service sessions as well.

HSS/Sh based subscription management

When the Sh interface is used toward the subscriber repository (HSS), service manage-

ment is supported for any media type that is possible according to the Ut/XCAP specifi-

cations (audio, video, message, image, and others). When a Ut/XCAP request is

received from the subscriber to modify the supplementary services, the Open TAS

downloads the MMTEL-Services repository from the HSS, modifies that according to the

subscriber request, and uploads the new MMTEL-Services to the HSS. The HSS then

informs the Open TAS about the subscription change over the Sh interface, and the

Open TAS parses the data from the received notification into the VLR and SPD data-

bases, using the same logic as when downloading subscriber data at registration.

1.4.10.3 Service code service dependency

The following basic CS-based services are independent from tele- and bearer services.

This means that they are not basic service code or basic service group specific and, asthe same setting applies on all basic service codes, they are applied on a session inde-

pendently from the requested service type:

• Operator Determined Barring

• CLIP, CLIR, COLP, COLR

• Call Hold

• Call Transfer

• Multiparty

• Call Deflection

g Call Waiting (CW) is service code dependent in the HLR. However, since the IR.92

standard states that CW is terminal- based and service code independent, CW underMMTel does not use the HLR parameter.



DN0621512

Issue 11-0-0

37


Feature description

Id:0900d80580a2e95f

The following services are basic service code dependent:

• SS barrings

• Call Forwardings

• Operator Controlled Call Forwarding

1.4.11 Interworking with audio tones and announcements

If the Open TAS is expected to insert an audio tone or announcement (due to the con-

figuration or an IN service instruction) during the call setup of a multimedia call, the Open

TAS can execute a fallback to audio media, insert the MGW, and connect the audio tone

or announcement. When the audio tone or announcement is over, the Open TAS

restores the original media content of the call setup and continues the call routing.

g This solution works only for the setup phase tones or announcements which are played

and finished before continuing the call setup.

g Fallback to audio is possible only if the audio is present in the requested service list. If

audio is not present, the tone/announcement is skipped and call setup continues.

1.4.12 Interworking with call forwarding

HLR based subscription management

If call forwarding is executed, video share and MSRP are removed from the service list.

This means that those services will not be used toward the forwarded-to party.

g If only MSRP or video share is present on the service list, the call is rejected when

attempting to execute call forwarding.

HSS/Sh based subscription management

It is possible to manage call forwarding for “message” and “video” media types over

Ut/XCAP when the Sh is still in use. However, when call forwarding is executed, Video

Share and MSRP services are removed from the service list. This means that those

services will not be used toward the forwarded-to party.

g If only MSRP or video share is present on the service list for the forwarded call, it is

rejected instead.

1.4.13 Location and visited network information handling during call

handling

The Open TAS manages LTE location information and visited network specific location

information for service execution purposes, and, respectively, for barring purposes,

during call handling and messaging in the IMS. With the optional feature in the Open

TAS, E-UTRAN location and visited network specific identifiers are correlated to 2G/3G

identifiers so that the existing service logic can utilize these in the existing configuration

over the existing interfaces.

The E-UTRAN location and visited network specific identifiers are obtained by the Open

TAS during registration, and are stored in the SPD. The Open TAS uses the correlated

identifiers for both originating and terminating service execution during call handling, in

IN operations, and generates the location specific data for statistical, charging andOLCM purposes.



38 DN0621512

Issue 11-0-0


Id:0900d80580a2e95f

Feature description

E-UTRAN location information

The Open TAS call handling logic is extended with the capability to retrieve E-UTRAN

location information from the P-Access-Network-Info header(s) of the following SIP

messages.Originating side SIP messages:

• INVITE

• UPDATE

• BYE

• 200 OK for BYE

Terminating side SIP messages:

• 200 OK for OPTIONS

• 200 OK for INVITE

• BYE

• 200 OK for BYE

If the SIP message contains E-UTRAN location information, the Open TAS selects a P-

Access-Network-Info (PANI) header as the source of the E-UTRAN location information,

parses the header, and correlates the retrieved information (ECGI) against the LTE to

2G/3G location mapping configuration of the E-UTRAN cell configuration. The deter-

mined 2G/3G location (mapped or static) is used by the Open TAS during originating

and terminating service execution.

Visited network specific location information

The Open TAS generates visited network specific location identifiers from the P-Visited-

Network-ID (PVNI) header of the REGISTER request. The Open TAS retrieves the PVNI

header during registration, and stores it in the SPD. In the Nokia Siemens Networkssolution, the Open TAS supports PVNI also in INVITE requests.

Upon receiving an INVITE request, the Open TAS parses the PVNI header, and vali-

dates it against the Visited NW configuration. If no PVNI header is received in the

INVITE, the Open TAS uses the PVNI header stored in the SPD to search the Visited

NW configuration. The retrieved Visited NW configuration parameters are used by the

Open TAS during originating and terminating service execution.

For more information, see Feature 2037: LTE/MBB Location Support, Feature Descrip-

tion.

1.4.14 FilesThere are no files directly visible to the operator.

1.4.15 Statistics

SIP-related statistics are collected in the Open TAS. 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:



DN0621512

Issue 11-0-0

39


Feature description

Id:0900d80580a2e95f

• 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

Multimedia Telephony updates to statistics

The MSS Observation Report includes a field that reports the media or service capabil-

ities of the VoIP session:

• USED MMTEL SERVICE

The following services in the Service Measurement Report are updated with the number

of times a given MMTel service was used during the active VoIP call:

• MMTEL AUDIO SESSION

• MMTEL VIDEO SESSION

• MMTEL VIDEO SHARE SESSION

• MMTEL MESSAGE SESSION

• MMTEL FAX/IMAGE SESSION

1.4.16 Parameters

Further information on the values of each parameter 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 Open TAS with the SCC AS role activated,

however, the Open TAS 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 in the respective

MMTel Services subscription stored in the HLR or the HSS. • If the subscriber has the CFNRc service activated in the MMTel Services sub-

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

g This parameter is used by the Open TAS in the role of a MMTel Application Server

(MMTel AS) and/or Service Centralization and Continuity Application Server (SCC

AS). For more information, see Feature 1990: SCC AS for Service Centralization

and T-ADS, Feature Description).



40 DN0621512

Issue 11-0-0


Id:0900d80580a2e95f

Feature description

• MSC_AS_VOIP_SUPPORT (002:1089)

This FIFILE parameter defines whether the S-CSCF can connect to the Open TAS

through the ISC interface for initiating VoIP calls.

•MSC_VOIP_SUPPORT (002:1078)This parameter defines whether the subscribers can connect to the Open TAS

through the SIP to initiate VoIP calls.

• MSC_VOIP_TCP_SUPP (002:1219)

The parameter controls whether TCP can be used for outgoing SIP requests and

responses in Open TAS 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 a response to an OPTIONS capability request during a SIP termi-

nated call. When the timer expires, the call fails and, for example, call forwarding is

executed.

• PRI_REPO_SOURCE (002:2056)

This parameter determines where the Open TAS should retrieve VoIP subscriber

data and supplementary service data from.

Possible values:

0 Retrieve the subscriber’s VoIP data from the SDB LDAP directory

and the subscriber’s MMTEL data from the HLR. (Default)

1 Retrieve the subscriber’s VoIP data from the HSS and the sub-

scriber’s MMTEL data from the HLR.

2 Retrieve both the subscriber’s VoIP data and MMTEL data from the

HSS.

• SIPURI_MSISDN_RES_SRC (052:0113)

This parameter determines over which interface, LDAP or Sh, SIPURI to MSISDN

resolution is performed.

Possible values:

0 Use the LDAP interface to perform SIPURI to MSISDN resolution.

(Default)

1 Use the Sh interface to perform SIPURI to MSISDN resolution.

• 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 parameter can be used to select which services indicated in P-Accept/Contact

are checked against the registered features at the terminating SIP access interface.

If the interface did not register the requested features, the call is rejected.The

parameter value is a bit structure indicating what feature tags are checked.

• SIP_CIC_USAGE (052:0061)

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



DN0621512

Issue 11-0-0

41


Feature description

Id:0900d80580a2e95f

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 sent

or received during the inactivity timeout, the connection is closed. The timeout is

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_HEADER_PROXYING (052:0096)

This parameter controls the proxying of unknown headers and forces the Open TAS

to proxy certain headers instead of the Back to Back User Agent (B2BUA) method

of rebuilding headers on the outgoing side.

If this parameter is set to TRUE, unknown headers and some additional headers are

proxied to the SIP target.

If this parameter is set to FALSE, unknown headers are not proxied, ignored on the

incoming side and not included on the outgoing side.

• 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_PROXY_MEDIA_NOT_ACC (052:0135)This parameter controls whether the SDP and SIP response code are proxied back-

wards if a 488 Not Acceptable Here or a 606 Not Acceptable SIP response is

received for an INVITE request.

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

• SKIP_SIP_FAX_SUBS_CHK (052:0107)

This parameter controls whether the T.38 subscription check is skipped when an

INVITE request is received that contains the T.38 or audio and T.38 services in the

SDP.

If this parameter is set to TRUE, the subscription check for T.38 is skipped.



42 DN0621512

Issue 11-0-0


Id:0900d80580a2e95f

Feature description

• 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 Open TAS 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

Open TAS 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 Open TAS 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

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 Software for more 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 Open TAS on the SIP Trunk Network interface.

1.4.17 Charging

New Charging Data Records (CDRs) and CDR fields are introduced for SIP calls. For

more information, see Feature 1703: NVS Charging, Feature Description.



DN0621512

Issue 11-0-0

43


Feature description

Id:0900d80580a2e95f

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 cannotexceed 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 Open TAS works in Back-to-Back User Agent (B2BUA) mode, it does not

support full proxy mode where all the SIP headers are proxied; instead the Open

TAS proxies the relevant SIP headers only. The Open TAS, however, supports

proxying of unhandled headers in addition to B2BUA mode.

• GSM and VoIP subscription cannot be used by one subscriber with the same Inter-

national Mobile Subscriber Identity (IMSI) at the same time without the Nokia

Siemens Networks One Number Service solution. In the case of GSM and VoLTE,

at the network element level, the two access methods can co-exist even without the

One Number Service solution.

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

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

• When the Open TAS is used in application server mode, the Calling Name Presen-

tation (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 an 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.



44 DN0621512

Issue 11-0-0


Id:0900d80580a2e95f

Feature description

• The Open TAS does not take into account SDP information sent to it as a result of

an OPTIONS capability query.

• The Open TAS does not route OPTIONS requests to a target UA. Instead, it termi-

nates the request and sends its own capabilities in the answer, even if the RequestURI does not point to the Open TAS.

• 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 Open TAS does not control the user plane in this case. A UA

might not fully use all the media and services negotiated via the SDP. The Open TAS

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.

• The SDP backwards proxy functionality is supported only for calls in CMN mode.

• If a call is early answered, the 488/606 SIP response will not be returned to the orig-

inating side.

1.7 Related and interworking features

This feature has interworking 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 managemultimedia 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

Open TAS features and implements the Media Gateway Control Function (MGCF)

in the Open TAS. SIP-I [International Telecommunications Union (ITU-T)] can be

used between Open TASs.

• Feature 1630: Fax and CS Data Call detection in MSS

This feature enables the Open TAS 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 Open TAS performs a codec modifica-

tion 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 trans-

port 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 Open TAS solution. Statistical functions

for the Open TAS are provided through the extension of several measurements and

observations that already exist and are known in the network elements, and by intro-

ducing new measurements and observations that provide Open TAS-specific infor-

mation.

• Feature 1703: NVS Charging

This feature offers customers the ability to charge on the Circuit Switched (CS)

network side for the usage of the Open TAS and IMS in cases where the user or

usage is related or interfaced to the CS network through SIP.



DN0621512

Issue 11-0-0

45


Feature description

Id:0900d80580a2e95f

• Feature 1760: NVS Messaging

This feature introduces Instant Messaging (IM) functionality 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 generic part of the feature lifts the former restriction that the last digit of a

Mobile Station Roaming Number (MSRN) should indicate the Visited Location

Register Unit (VLRU). However, in such a case the VLRU contained the MSRN;

now all the MSRNs are available in the Open TAS.

2. The other part of the feature provides the possibility of allocating MSRNs based

on the called subscriber’s registered Location Area (LA). LA-based functionality

provides the ability to assign an MSRN group to one or several location areas. A MSRN group can be divided into several MSRN ranges. It affects the ELE,

ELO, and WVC MML commands. This feature is optional. The functionality is

internal to the Open TAS/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 Home Location Register (HLR) stores GSM

subscription related data.

• Feature 1673: NVS Registration

This feature provides functionality related to the registration of Session InitiationPro-

tocol (SIP) clients - that is, user equipment (UE) - in IMS environments.Optional features:

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



46 DN0621512

Issue 11-0-0


Id:0900d80580a2e95f

Feature description

• Feature 1844: SIP Call Transfer Support

Open TAS supports Call Transfer using the SIP REFER method.

• Feature 1741: Facility call

Facility call allows you to manage services related to T11, B1F and T61 tele- andbearer service codes that are mapped to MMTel services.

g Facility call can be used to manage services in HLR-based deployments only.

• Feature 1979: Ut/XCAP

Supplementary services related only to audio or video media can be managed over

Ut/XCAP.

• Feature 2027: Sh for NVS Subscriber Repository

This feature enables the Open TAS to retrieve VoIP subscriber data and supplemen-

tary service data stored in the HSS.

• Feature 2037: LTE/MBB Location Support

This feature provides E-UTRAN location information and visited network specificlocation information management in the Open TAS. With this feature, E-UTRAN

location information and visited network specific location information can be used in

the existing call handling logic.

1.8 Compliance

This feature is compliant with the following standards:

3GPP standards:

3GPP TS 24.229 Intranet 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. 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.

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.



DN0621512

Issue 11-0-0

47


Feature description

Id:0900d80580a2e95f

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

son, 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 Intranet 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 standardization 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 ISC Interface Description, Application

Server Solution

• SIP Interface in MSS, Interface Specification

1.9 Operator interfaces

1.9.1 MMLs

This feature requires the configuration described in Feature 1673: NVS Registration,

Feature Description. 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 acopy 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 .

SIP Parameters Configuration Handling, JH Command Group

With the help of the JH command group, you can handle group profiles, generic SIP

parameters, and configure different type of configuration lists.

The relevant commands are:



48 DN0621512

Issue 11-0-0


Id:0900d80580a2e95f

Feature description

• JHA - ADD SIP GROUP PROFILE

In addition to the configuration described in Feature 1673: NVS Registration, Feature

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

• 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 level SIP Parameter Handling, 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 an additional host

• Modify the route of FQDN level parameters

• Create and copy the route of FQDN parameters

• Configure the SCTP connection

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. Furthermore, no more than 2048 hosts can be

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

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



DN0621512

Issue 11-0-0

49


Feature description

Id:0900d80580a2e95f

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 used 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, you can 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 Signalling Index (LSI))

• Auxiliary Signalling 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, you can manage different types of special

routes.

Use the following command to create a SIP END special route:

• RPS - CREATE SPECIAL ROUTE FOR SIP END



50 DN0621512

Issue 11-0-0


Id:0900d80580a2e95f

Feature description

Input parameters include:

• OUSIGN index

• sending of numbers start point

• call control parameter set index • CLI formatting set index

• timer set index

• User Plane Destination Reference (UPDR)

Use the following command to create a special route for an inquiry of the HSS GW

Service (for example, inquiry of SIP subscriber data from the SPD and VLR DBs):

• RPN - CREATE SPECIAL ROUTE FOR HSS GW SERVICE

Input parameters include:

• sending of numbers start point

• digit analysis tree

• charging origin

• special route record number

• implicit registration

• CS location determination

• suppress TCSI indicator

• suppress announcement indicator

• suppress incoming call barring indicator

• suppress call diversion indicator

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)



DN0621512

Issue 11-0-0

51


Feature description

Id:0900d80580a2e95f

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

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

• 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 interfacesThis feature enables SIP users to initiate SIP calls toward the Open TAS.

1.11 Network elements

• 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 Open TAS. The client processes are located in the signalling units of

the Open TAS.

The Open TAS supports both the two-site and the three-site LDAP client-servermodel, 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-



52 DN0621512

Issue 11-0-0


Id:0900d80580a2e95f

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

• HSS

SIP subscriber basic data and supplementary service data can be managed and

maintained by the HSS. The Open TAS requests information from the HSS using theSh interface and acts as a Diameter client for that purpose. For more information on

the Sh interface and the HSS see Feature 2027: Sh for NVS Subscriber Repository .

1.12 External interfaces

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

The MAP interface is used by this feature when retrieving CS subscriber data and

MMTel data from the HLR. For information on supported MAP operations, see the

HLR/EIR - MSC/VLR/SGSN/gsmSCF/GMLC Mobile Application Part, Interface Descrip-

tion.

The Sh interface is used by this feature when retrieving VoIP subscriber data and MMTel

data from the HSS. For information on supported operations, see the Sh Interface

Description.



DN0621512

Issue 11-0-0

53


Main changes in Feature 1671: NVS Call Handling (Ap-plication Server Mode)

Id:0900d805809ae0f9

Main changes in Feature 1671: NVS Call

Handling (Application Server Mode)

Changes in the feature

Changes in the feature between releases M16.2 and M16.1 EP1

Support for SIP Proxying has been added. This functionality allows MMTel call cases to

comply to IR.94 by forwarding Not Acceptable SIP responses when the RTP/AVPF

profile is not available on the terminating side.

Support for Media flow direction handling in Open TAS/MGCF has been added. This

functionality allows the Open TAS to use inactive media when the preconditions are not

fulfilled, or in the case the precondition framework is not supported.

Support for the Phase 2 implementation of the Sh interface has been added. This imple-mentation brings about the following changes:

• the possibility to retrieve MMTel data from the HSS over the Sh interface rather than

from the HLR over the MAP interface

• when the Sh interface is used as a means to download MMTel data, gateway termi-

nating service execution happens in the Open TAS via a service logic that is a rep-

lication of the related HLR functionality

• support for XCAP operations over the Sh interface

The Open TAS call handling logic has been extended with LTE location and visited

network specific location information management.

License Internal SCP LK has been added to the document.

Changes in the feature between releases M16.1 EP1 and M15.1

Support for Sh interface has been added. This implementation allows retrieving SIP

Subscriber Data from the Home Subscriber Server (HSS) via the Sh interface.

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



54 DN0621512

Issue 11-0-0


Id:0900d805809ae0f9


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


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

the better interworking of FCI (Forward Call Indicator) and BCI (Backward Call Indicator)

ISUP parameters in the case of UDI (CLEARMODE) calls and mapping between ISUP

cause code 24 and 433 (Anonymity Disallowed) SIP response messages.

Changes in the document

Changes made between issues 11-0-0 and 10-1-0

To reflect the addition of a new product to the Nokia Siemens Networks portfolio and the

resulting change in naming conventions, instances of Nokia Siemens Networks Mobile

VoIP Server (NVS) and NVS have been replaced, where appropriate, with Nokia

Siemens Networks Open Telecom Application Server (Open TAS) and Open TAS or the

appropriate role of the Open TAS product. Feature names and license names, however,

retain the term NVS. For further information, see the document entitled Impact of the

Nokia Siemens Networks Open Telecom Application Server (Open TAS) on Documen-

tation.

The following sections have been updated:

•

Introduction has been updated to indicate that MMTel related subscriber data canbe retrieved from the HSS over the Sh interface.



DN0621512

Issue 11-0-0

55



Id:0900d805809ae0f9

• Software has been updated with the Sh for mmtel repositories license.

• Calling Line Identification Restriction (CLIR), Calling Line Identification Presentation

(CLIP), and Calling Line Identification Restriction (CLIR) Override have been

updated to show that they can be provisioned and activated in the HSS as well. • Calling Line Identification Restriction (CLIR) has been updated to indicate that

service settings can be modified by users over the Ut interface too.

• Example for call-forwarding not reachable: has been updated to show that the for-

warded-to-number is retrieved from the VLR or SPD if MMTel data was obtained

from the HSS.

• Open TAS support for Multimedia Telephony (MMTel) services has been updated to

reflect the fact that supplementary service data can be stored in both the HLR and

the HSS.

• Capability check has been updated with a note detailing the proxy behavior when

the SIP_PROXY_MEDIA_NOT_ACC PRFILE parameter is enabled.

•Parameters has been updated with a new value (2) of the PRI_REPO_SOURCE PRFILE parameter and the SIP_PROXY_MEDIA_NOT_ACC PRFILE parameter.

• Related and interworking features has been updated with Feature 2027: Sh for NVS

Subscriber Repository and Feature 2037: LTE/MBB Location Support.

• GSM Special Route Handling, RP Command Group has been updated with informa-

tion on the RPN command.

• Network elements has been updated with HSS information about supplementary

service data management.

• External interfaces has been updated with information about the MAP and Sh inter-

faces.

The following sections have been added:

• HSS as subscriber registry

• HSS based subscription

• Gateway service execution when Sh is used

• HSS/Sh based subscription management

• HSS/Sh based subscription management

• Location and visited network information handling during call handling

Internal SCP LK license has been added to section Software.

Example for call-forwarding not reachable has been removed as all the relevant infor-

mation is now found in Feature 111: Call Forwarding, Feature Description.

Document has been updated with editorial changes.


Sh interface and HSS support has been added to the document.

The section Open TAS support for Multimedia Telephony (MMTel) services has been

updated with information on MMTel services and service mapping.


VOIP_SCTP_ON_SIP_ACCESS (052:0071) PRFILE parameter has been removed.





56 DN0621512

Issue 11-0-0


Id:0900d805809ae0f9


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

• Open TAS support for Multimedia Telephony (MMTel) services has been updated

with a section detailing support 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


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 Multi-Frequency (DTMF) support

• Functionality, Services, Malicious call identification

• Functionality, Services, Calling name presentation service for VoLTE/SIP VoIP sub-

scribers

• Functionality, Services, Open TAS support for 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 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.


Referenced feature names have been corrected according to the Nokia Siemens

Networks portfolio.


Editorial changes have been made.

Changes made between issues 4-0 and 3-0Feature 1448: High Capacity MSS & GCS has been added to section Related and inter-

working features.

The company and product names have been changed according to the officialNokia

Siemens Networks portfolio.

Feature 1671- NVS Call Handling (Application Server Mode).pdf

Documents

Transcript of Feature 1671- NVS Call Handling (Application Server Mode).pdf