Feature 1671- NVS Call Handling (Application Server Mode).pdf
-
Upload
david-godoy -
Category
Documents
-
view
63 -
download
0
Transcript of 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.
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 2/57
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.
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 3/57
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
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 4/57
4 DN0621512
Issue 11-0-0
Feature 1671: NVS Call Handling (Application Server Mode)
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
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 5/57
DN0621512
Issue 11-0-0
5
Feature 1671: NVS Call Handling (Application ServerMode)
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
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 6/57
6 DN0621512
Issue 11-0-0
Feature 1671: NVS Call Handling (Application Server Mode)
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
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 7/57
DN0621512
Issue 11-0-0
7
Feature 1671: NVS Call Handling (Application ServerMode)
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.
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 8/57
8 DN0621512
Issue 11-0-0
Feature 1671: NVS Call Handling (Application Server Mode)
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.
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 9/57
DN0621512
Issue 11-0-0
9
Feature 1671: NVS Call Handling (Application ServerMode)
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)
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 10/57
10 DN0621512
Issue 11-0-0
Feature 1671: NVS Call Handling (Application Server Mode)
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.
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 11/57
DN0621512
Issue 11-0-0
11
Feature 1671: NVS Call Handling (Application ServerMode)
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
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 12/57
12 DN0621512
Issue 11-0-0
Feature 1671: NVS Call Handling (Application Server Mode)
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
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 13/57
DN0621512
Issue 11-0-0
13
Feature 1671: NVS Call Handling (Application ServerMode)
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
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 14/57
14 DN0621512
Issue 11-0-0
Feature 1671: NVS Call Handling (Application Server Mode)
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
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 15/57
DN0621512
Issue 11-0-0
15
Feature 1671: NVS Call Handling (Application ServerMode)
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
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 16/57
16 DN0621512
Issue 11-0-0
Feature 1671: NVS Call Handling (Application Server Mode)
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
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 17/57
DN0621512
Issue 11-0-0
17
Feature 1671: NVS Call Handling (Application ServerMode)
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-
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 18/57
18 DN0621512
Issue 11-0-0
Feature 1671: NVS Call Handling (Application Server Mode)
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.
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 19/57
DN0621512
Issue 11-0-0
19
Feature 1671: NVS Call Handling (Application ServerMode)
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
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 20/57
20 DN0621512
Issue 11-0-0
Feature 1671: NVS Call Handling (Application Server Mode)
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-
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 21/57
DN0621512
Issue 11-0-0
21
Feature 1671: NVS Call Handling (Application ServerMode)
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
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 22/57
22 DN0621512
Issue 11-0-0
Feature 1671: NVS Call Handling (Application Server Mode)
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.
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 23/57
DN0621512
Issue 11-0-0
23
Feature 1671: NVS Call Handling (Application ServerMode)
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.
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 24/57
24 DN0621512
Issue 11-0-0
Feature 1671: NVS Call Handling (Application Server Mode)
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.
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 25/57
DN0621512
Issue 11-0-0
25
Feature 1671: NVS Call Handling (Application ServerMode)
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
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 26/57
26 DN0621512
Issue 11-0-0
Feature 1671: NVS Call Handling (Application Server Mode)
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
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 27/57
DN0621512
Issue 11-0-0
27
Feature 1671: NVS Call Handling (Application ServerMode)
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
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 28/57
28 DN0621512
Issue 11-0-0
Feature 1671: NVS Call Handling (Application Server Mode)
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
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 29/57
DN0621512
Issue 11-0-0
29
Feature 1671: NVS Call Handling (Application ServerMode)
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
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 30/57
30 DN0621512
Issue 11-0-0
Feature 1671: NVS Call Handling (Application Server Mode)
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
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 31/57
DN0621512
Issue 11-0-0
31
Feature 1671: NVS Call Handling (Application ServerMode)
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
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 32/57
32 DN0621512
Issue 11-0-0
Feature 1671: NVS Call Handling (Application Server Mode)
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
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 33/57
DN0621512
Issue 11-0-0
33
Feature 1671: NVS Call Handling (Application ServerMode)
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
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 34/57
34 DN0621512
Issue 11-0-0
Feature 1671: NVS Call Handling (Application Server Mode)
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
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 35/57
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 36/57
36 DN0621512
Issue 11-0-0
Feature 1671: NVS Call Handling (Application Server Mode)
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.
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 37/57
DN0621512
Issue 11-0-0
37
Feature 1671: NVS Call Handling (Application ServerMode)
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.
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 38/57
38 DN0621512
Issue 11-0-0
Feature 1671: NVS Call Handling (Application Server Mode)
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:
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 39/57
DN0621512
Issue 11-0-0
39
Feature 1671: NVS Call Handling (Application ServerMode)
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).
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 40/57
40 DN0621512
Issue 11-0-0
Feature 1671: NVS Call Handling (Application Server Mode)
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
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 41/57
DN0621512
Issue 11-0-0
41
Feature 1671: NVS Call Handling (Application ServerMode)
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.
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 42/57
42 DN0621512
Issue 11-0-0
Feature 1671: NVS Call Handling (Application Server Mode)
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.
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 43/57
DN0621512
Issue 11-0-0
43
Feature 1671: NVS Call Handling (Application ServerMode)
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.
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 44/57
44 DN0621512
Issue 11-0-0
Feature 1671: NVS Call Handling (Application Server Mode)
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.
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 45/57
DN0621512
Issue 11-0-0
45
Feature 1671: NVS Call Handling (Application ServerMode)
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.
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 46/57
46 DN0621512
Issue 11-0-0
Feature 1671: NVS Call Handling (Application Server Mode)
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.
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 47/57
DN0621512
Issue 11-0-0
47
Feature 1671: NVS Call Handling (Application ServerMode)
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:
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 48/57
48 DN0621512
Issue 11-0-0
Feature 1671: NVS Call Handling (Application Server Mode)
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
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 49/57
DN0621512
Issue 11-0-0
49
Feature 1671: NVS Call Handling (Application ServerMode)
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.
The relevant commands are:
• JUC - CREATE SUBANALYSIS
Use this command to create a subanalysis of the user plane analysis or a copy of an
existing subanalysis.
• JUM - MODIFY SUBANALYSIS
Use this command to modify a subanalysis of the user plane analysis.
• JUI - INTERROGATE SUBANALYSIS
Use this command to interrogate the subanalyses of the user plane analysis.
The parameter 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.
The relevant commands are:
• RCA - ADD CIRCUITS TO CIRCUIT GROUP
Use this command to add circuit(s) to a circuit group.
• RCC - CREATE CIRCUIT GROUP
Use this command to create different types of circuit groups: CCS, CAS, DCS, SIP, IPT,
and special circuit groups.
The parameters used in this feature are the following:
• 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
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 50/57
50 DN0621512
Issue 11-0-0
Feature 1671: NVS Call Handling (Application Server Mode)
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)
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 51/57
DN0621512
Issue 11-0-0
51
Feature 1671: NVS Call Handling (Application ServerMode)
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-
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 52/57
52 DN0621512
Issue 11-0-0
Feature 1671: NVS Call Handling (Application Server Mode)
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.
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 53/57
DN0621512
Issue 11-0-0
53
Feature 1671: NVS Call Handling (Application ServerMode)
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.
Changes in the feature between releases M15.1 and M15.0
Functionality relevant to emergency call handling using wildcards has been added.
Changes in the feature between releases M15.0 and M14.6
A short section on support for out of band DTMF in SIP INFO messages has been
added. This allows SIP INFO messages and requests with application/dtmf-relay MIME
types to be handled by the MSS across all incoming and outgoing SIP interfaces.
The Malicious Call Identification (MCID) service has been added. This service enables
SIP subscribers’ incoming session-related information to be stored by the NVS, allowing
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 54/57
54 DN0621512
Issue 11-0-0
Feature 1671: NVS Call Handling (Application Server Mode)
Id:0900d805809ae0f9
Main changes in Feature 1671: NVS Call Handling (Ap-plication Server Mode)
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.
Changes in the feature between releases M14.6 and M14.5
The number of CGR records has been extended to 1500. The number of hosts that can
be assigned to FQDNs has been increased to 2048.
Changes in the feature between releases M14.5 and M14.4
No changes
Changes in the feature between releases M14.4 and M14.3
Early answer and Ringback tone connection in CMN mode functionality has been
added.
Changes in the feature between releases M14.3 and M14.2
This feature interworks with Feature 1448: High Capacity MSS & GCS, which optimizes
the message bus usage of call control legs in the NVS.
Changes in the feature between releases M14.2 and M14.1
Support for Feature 1844: Call Transfer Support on SIP has been added.
Changes in the feature between releases M14.1 and M14.0
Anonymous Call Rejection functionality has been added.
Support for ETSI EN 383 001 compliance has been added. The enhancement includes
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.
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 55/57
DN0621512
Issue 11-0-0
55
Feature 1671: NVS Call Handling (Application ServerMode)
Main changes in Feature 1671: NVS Call Handling (Ap-plication Server Mode)
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.
Changes made between issues 10-1-0 and 10-0-1
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.
Changes made between issues 10-0-1 and 10-0-0
VOIP_SCTP_ON_SIP_ACCESS (052:0071) PRFILE parameter has been removed.
Changes made between issues 10-0-0 and 9-0-0
The following sections have been updated:
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 56/57
56 DN0621512
Issue 11-0-0
Feature 1671: NVS Call Handling (Application Server Mode)
Id:0900d805809ae0f9
Main changes in Feature 1671: NVS Call Handling (Ap-plication Server Mode)
• 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
Changes made between issues 9-0-0 and 8-0-1
The following sections have been updated:
• Regulatory services, Emergency calls
The subsection has been updated to take into account further checking of the 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
Changes made between issues 8-0-1 and 8-0-0
The term One Voice was removed from the title of section NVS support for One Voice
compliant multimedia telephony (MMTel) services and replaced by the term GSMA
IR.92 .
Changes made between issues 8-0-0 and 7-0-0
The following sections have been updated:
• Requirements for using the feature, Software
• Functionality, Statistics • Functionality, Parameters
• Restrictions
The following sections have been added:
• Functionality, Services, Dual-Tone 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
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 57/57
Feature 1671: NVS Call Handling (Application ServerMode)
Main changes in Feature 1671: NVS Call Handling (Ap-plication Server Mode)
Changes made between issues 7-0-0 and 6-0
The following sections have been updated to incorporate the changes specified above:
• Operator interfaces-MMLs-JN
• Operator interfaces-MMLs-JR
Changes made between issues 6-0 and 5-0
Feature 1451: BICC-SIP Interworking has been renamed to Feature 1451: IMS-CS
Interworking .
Changes made between issues 5-0 and 4-2
Changes incurred by Early answer and Ringback tone connection in CMN mode func-
tionality have been made to the following sections:
• Requirements - products
• Functionality - services
• Parameters
• Restrictions
Editorial changes have also been made.
Changes made between issues 4-2 and 4-1
Referenced feature names have been corrected according to the Nokia Siemens
Networks portfolio.
Changes made between issues 4-1 and 4-0
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.