SIST-V ETSI/EG 201 988-1 V1.1.1:2003

SLOVENSKI STANDARD
01-november-2003
6WRULWYHLQSURWRNROL]DQDSUHGQDRPUHåMD63$1=DKWHYHGRVWRSDSRQXGQLND
VWRULWYH63$52GSUWGRVWRSGRVWRULWYH]D]DKWHYH$3,GHO5D]OLþLFD
Services and Protocols for Advanced Networks (SPAN) - Service Provider Access
Requirements (SPAR) - Open Service Access for API requirements - Part 1: Version 1
Ta slovenski standard je istoveten z: EG 201 988-1 Version 1.1.1
ICS:
33.040.35 Telefonska omrežja Telephone networks
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

ETSI Guide
Services and Protocols for Advanced Networks (SPAN);
Service Provider Access Requirements (SPAR);
Open Service Access for API requirements;
Part 1: Version 1
2 ETSI EG 201 988-1 V1.1.1 (2002-05)
Reference
DEG/SPAN-141606-1
Keywords
API, architecture, interface, UML
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.:+33492944200 Fax:+33 493654716
Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, send your comment to:
editor@etsi.fr
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 2002.
All rights reserved.
TM TM TM
DECT , PLUGTESTS and UMTS are Trade Marks of ETSI registered for the benefit of its Members.
TM
TIPHON and the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
ETSI
3 ETSI EG 201 988-1 V1.1.1 (2002-05)
Contents
Intellectual property rights.4
Foreword.4
1 Scope .5
2 References .5
3 Definitions and abbreviations.6
3.1 Definitions.6
3.2 Abbreviations .7
4 Background .7
5 Architecture.8
5.1 API overview.8
5.2 Description of classes.10
5.3 Interface class diagrams .10
6 An API approach to modelling the SPA requirements.10
6.1 Introduction .10
6.2 Calling party information handling capabilities .11
6.2.1 Reception of the calling line identity .11
6.2.2 Presentation of the complete CLI information to the PTN .12
6.2.3 Addition or substitution of a calling line identity .13
6.2.4 Provision of CLI information to an SP-initiated call .14
6.2.5 Relaying of the malicious call identification data of a received call.15
6.3 Basic call set-up and clear-down capabilities.16
6.3.1 Return speech path connection from the terminating PTN to the calling party .16
6.3.2 Routing of an originating or incoming call from the PTN to the SP.17
6.3.3 Indication of an originating or incoming call from the PTN to the SP .18
6.3.4 Routing of a terminating call from the PTN to the SP.18
6.3.5 Indication of a terminating call from the PTN to the SP.19
6.3.6 Reception of an indication of the cause of an unsuccessful call .20
6.3.7 Provision of information for the destination and routing of a call .21
6.3.8 Call drop-back .22
6.3.9 User interaction without service charging of the end user .23
6.3.10 Reception of the originally dialled digits.25
6.3.11 Disconnection of a call in progress.26
6.3.12 Connection of a call to an Interactive Voice Response unit in the PTN.27
6.3.13 Alternate routing of a call or the indication of a call to another "point of presence" of the SP .28
6.4 Supplementary call and data processing capabilities.29
6.4.1 Interrogation of a network termination point for data delivery.29
6.4.2 Overriding of the 'incoming call barring' supplementary service .32
6.4.3 Bypassing of the 'call diversion' supplementary service.33
6.4.4 Message waiting indication .33
6.5 Charging-related capabilities.35
6.5.1 Changes in the charging rate of a call.35
6.6 Traffic-related capabilities.36
6.6.1 Event traceability .36
6.6.2 Traffic control capabilities.40
6.6.3 Avoidance of the cyclical routing of a call .43
History .45
ETSI
4 ETSI EG 201 988-1 V1.1.1 (2002-05)
Intellectual property rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This ETSI Guide (EG) has been produced by ETSI Technical Committee Services and Protocols for Advanced
Networks (SPAN).
The present document is part 1 of a multi-part deliverable covering Service Provider Access Requirements (SPAR), as
identified below:
Part 1: "Version 1";
Part 2: "Version 2".
ETSI
5 ETSI EG 201 988-1 V1.1.1 (2002-05)
1 Scope
The present document applies to the first phase of the Service Provider Access Requirements (SPAR) work, aiming
primarily at fixed PTNs, e.g. Public Switched Telecommunications Networks (PSTNs) and Integrated Services Digital
Networks (ISDNs). This first phase is described by two documents, Service Provider Access Requirements; Enhanced
telephony services [1] and Network operator's requirements for the delivery of Service Provider Access [2]. The present
document shows how these requirements can be fulfilled using an Application Programming Interface (API) base open
Service Access, Application Programming Interface ES 201 915 Series of Specifications (12 Parts) [11]. This
specification is addressing the Multi-Party Call Control service.
2 References
The following documents contain provisions, which through reference in this text, constitute provisions of the present
document.
• References are either specific (identified by date of publication and/or edition number or version number) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• For a non-specific reference, the latest version applies.
[1] ETSI EG 201 722: "Intelligent Network (IN); Service provider access requirements; Enhanced
telephony services".
[2] ETSI EG 201 807: "Network Aspects (NA); Intelligent Network (IN); Network operators'
requirements for the delivery of Service Provider access".
[3] ISO/IEC JTC 1 Directives, Supplement 2: "Guidelines for API Standardization".
[4] ETSI ETS 300 335: "Integrated Services Digital Network (ISDN); Signalling System No.7; ISDN
User Part (ISUP) version 1; Test specification".
[5] ETSI EN 300 090: "Integrated Services Digital Network (ISDN); Calling Line Identification
Restriction (CLIR) supplementary service; Service description".
[6] ETSI ETR 322: "Intelligent network (IN); Vocabulary of terms and abbreviations for CS-1 and
CS-2".
[7] ETSI TS 123 127: "Universal Mobile Telecommunications System (UMTS); Virtual Home
Environment/Open Service Architecture (3GPP TS 23.127 version 3.2.0 Release 1999)".
[8] ITU-T Q-series Recommendations Supplement 29: "Service Modelling: Evolution to the Use of
Object Oriented Techniques".
[9] ITU-T Recommendation Q.65 (2000): "The unified functional methodology for the
characterization of services and network capabilities".
[10] ETSI ETS 300 128 (1992): "Integrated Services Digital Network (ISDN); Malicious Call
Identification (MCID) supplementary service; Service description".
[11] ETSI ES 201 915 (all parts): "Open Service Access (OSA); Application Programming Interface
(API)".
ETSI
6 ETSI EG 201 988-1 V1.1.1 (2002-05)
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
application: entity in a Service Provider's domain that provides a service (see definition of service below)
Application Programming Interface (API): boundary across which application software uses facilities of
programming languages to invoke services (see ISO/IEC JTC 1 Directives)
Calling Line Identity (CLI): number that uniquely identifies a subscriber line that is used for a call
end user: See "service user" definition.
network API gateway: API entity that provides access to the public telecommunications network
Network-Network Interface (NNI): interface at a network node which is used to interconnect the node with another
network node (see EG 201 722)
network-provided calling line identity: that is provided by the originating public telecommunications network to a
call set-up request, if the calling party has not provided any calling line identity or the user-provided calling line identity
has not passed a verification in the network (see ETS 300 335)
presentation-restricted calling line identity: calling line identity that is associated with a marking informing the
terminating local exchange not to display this calling line identity to the called party (see EN 300 090)
Public Telecommunications Network (PTN): telecommunications network which provides telecommunications
services to the general public (see ETR 322)
Public Telecommunications Network Operator (PTNO): entity which is responsible for the development,
provisioning and maintenance of telecommunications services to the general public and for operating the corresponding
networks (see ETR 322)
service: that which is offered by an administration or recognized private operating agency (i.e. a public or private
Service Provider) to its customers in order to satisfy a telecommunication requirement (see ETR 322)
Service Capability Feature (SCF): functionality offered by service capabilities that are accessible via the standardized
OSA interface (see TS 123 127)
Service Provider (SP): entity which provides services to its service subscribers on a contractual basis and who is
responsible for the services offered
NOTE: The same organization may act as a public telecommunications network operator and a Service Provider
(see ETR 322).
Service Provider Access (SPA): access facility that enables a Service Provider to access specific functionality of a
public telecommunications network (see EG 201 722)
Service Provider Access Interface (SPAI): interface between a public telecommunications network and a Service
Provider's equipment for enabling the Service Provider to access specific functionality of a public telecommunications
network (see EG 201 722)
Service Provider Access Requirement (SPAR): requirement for access by a Service Provider to specific functionality
of a public telecommunications network (see EG 201 722)
service subscriber: entity that contracts for services offered by Service Providers (see ETR 322)
service user: entity external to the network that uses the services offered by the PTNO or SP (see ETR 322)
User-Network Interface (UNI): interface between the terminal equipment and a network termination point at which
the access protocols apply (see EG 201 722)
user-provided calling line identity: network number that has been provided by the calling party (see ETS 300 335)
ETSI
7 ETSI EG 201 988-1 V1.1.1 (2002-05)
user-provided, not screened calling line identity: network number that has been provided by the calling party and has
been passed forward by the originating public telecommunications network without performing any screening function
for verification purposes (see ETS 300 335)
user-provided, verified and passed calling line identity: network number that has been provided by the calling party
and has been successfully verified in the originating public telecommunications network (see ETS 300 335)
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
3GPP Third Generation Partnership Project
API Application Programming Interface
CAMEL Customized Applications for Mobile Enhanced Logic
CAP CAMEL Application Part
CLI Calling Line Identity
CS-1 Capability Set One
IP Internet Protocol
ISDN Integrated Services Digital Network
ITU-T International Telecommunications Union - Telecommunication standardization sector
IVR Interactive Voice Response
MCID Malicious Call IDentification
NNI Network-Network Interface
NTP Network Termination Point
O-O Object Oriented
OSA Open Service Architecture
PoP Point of Presence
PTN Public Telecommunications Network
PTNO Public Telecommunications Network Operator
SCF Service Control Function
SMTP Simple Mail Transmission Protocol
SP Service Provider
SPA Service Provider Access
SPAI Service Provider Access Interface
SPAR Service Provider Access Requirement
UML Unified Modelling Language
UNI User-Network Interface
URL Universal Resource Locator
4 Background
An overview of an API is presented in clause 5, and mappings between the Service Provider access requirements and
the API methods are presented in clause 6. Sequence diagrams for example services are available in APIs for Open
Service Access ES 201 915 [11], and further information on service modelling is available in ITU-T documentation [8]
and [9].
API ES 201 915 [11] implementation issues, which are not covered in the present document, include the following:
• dimensioning and scalability of operations;
• number and efficiency of operations;
• object management;
• error control, including error detection and recovery, needs to be considered for all operations over the API.
Those error control requirements specifically defined in the Service provider access requirements; Enhanced
telephony services [1] have been addressed in the API mapping examples in the present document, but other
error control mechanisms are defined in APIs for Open Service Access service applications ES 201 915 [11];
ETSI
8 ETSI EG 201 988-1 V1.1.1 (2002-05)
• some of the requirements defined in the Service provider access requirements; Enhanced telephony services [1]
may require access to PTN hosted user profile information, e.g. incoming call barring and call diversion
information. The means of accessing such information is not defined in the present document. This is a
management plane requirement, as shown in [1];
The call leg methods for multiparty are supported in the API ES 201 915 [11].
5 Architecture
5.1 API overview
An Application Programming Interface (API) is a means of supporting the Service Provider access requirements
identified by ETSI. This API is defined using the Unified Modelling Language (UML), which is an Object Oriented
(O-O) technique [8] and [9].
Detailed descriptions of the API can be found in ES 201 915 [11], but an overview of the API architecture is shown in
figure 1.
Service Provider's Application
API
API
API
Framework
Service
Telecommunications Network
Figure 1: API Architecture
Service providers' applications (telecommunications services) and the PTN's service capability features use the API to
utilize each others resources in delivering services to end users. A contractual agreement and physical access interface
must exist between the Service Provider and network operator for the API to be used, the nature of these is dependent
upon commercial agreements between the parties involved and may be subject to national regulations.
This API, which is based on ES 201 915 [11], contains an API Framework and one or more API Service, where the API
Framework provides control of the service-surround capabilities, and API Service provide control of the real time
network capabilities.
API Framework includes the following:
• trust and security management, which is used to make initial contact with a framework provider, to authenticate
the application and framework, and to obtain access to other framework interfaces and service capability
features. This includes service capability feature selection and electronically signing service agreements;
• service discovery, which is used by the application to get the identities of the service capability features that are
available from the underlying network. The identities are used during authentication to select the required
service capability features;
• integrity management, which is used for load management, fault management, heartbeat management, heartbeat
and operation, administration and maintenance;
• service subscription, which is used to manage the contractual agreement between the parties.
ETSI
9 ETSI EG 201 988-1 V1.1.1 (2002-05)
API Service include:
• generic call control service, which is used to enable and disable call notifications, to notify call events, and to
control and manage simple calls consisting of one or two legs;
• INAP-1/2/3 call control service (INAP CS-1, CS-2, CS-3), which enhances the generic call control service by
allowing more complex call behaviour to be used;
• CAP call control service (Phases 1, 2, 3), which enhances the generic call control service to allow more control
over charging for mobile terminals;
• multi party call control service, which enhances the generic call control service with call leg control;
• multi media call control service, which enhances the enhanced call control service to allow the control of
specific media channel characteristics;
• conference call control service, which enhances the enhanced call control service to allow the creation of
sub-conferences and the ability to move legs between sub-conferences, or merge sub-conferences;
• multi media conference call service, which enhances the conference call control and multi media call control
services to allow interworking with network signalled conference protocols, manipulation of media, and the
handling of multi media conference policies;
• generic messaging service, which is used to send, store and receive electronic and voice mail;
• user location service, which is used to establish the geographic location and status of fixed, mobile and IP-based
telephony users;
• user location CAMEL service, which supplements the user location service to provide network related
information;
• user location emergency service, which supplements the user location service with specialized functionality to
handle emergency calls;
• user status service, which is used to request the current status, or the reporting of a change of status, of fixed,
mobile or IP-based telephony users;
• generic user interaction service, which is used to interact with end users;
• call user interaction service, which is used in conjunction with another service interface (only the generic call
control service at present) to send information to, or gather information from, an end user.
Detailed example sequence diagrams can be found in APIs for third party service applications ES 201 915 [11], but an
overview is given below.
When an Application starts, the following is a typical outline sequence of events:
1) application initiates client authentication;
2) mutual authentication of client and Framework Interface;
3) application discovers service capability features;
4) application selects required service capability features;
5) mutual signing of service agreement, e.g. by electronic signature.
At this point the agreed network operator service capability features become available to the Application. If the agreed
service capability features include inbound calls, the Application requests call notifications on the appropriate Service
Interface. The service capability features, and any call notifications, remain active until one of the parties chooses to
either terminate the service agreement, or disable the call notifications.
ETSI
10 ETSI EG 201 988-1 V1.1.1 (2002-05)
If call notifications have been enabled, the following is a typical outline sequence of events:
1) a call arrives in network and is identified as requiring a Service Provider;
2) a call object is created. (Other objects may also be created, e.g. call leg object);
3) a call event notification is sent to the appropriate application over the API;
4) the application sends all appropriate information for call treatment, including routing and reporting
requirements;
5) network applies the call treatment and reports outcome, if requested;
6) the application provides subsequent instructions, if required;
7) the network provides subsequent reports, if and when required.
The above sequence is repeated for each call received and an unlimited number of calls may co-exist.
If the Application initiates calls, the following is a typical outline of events:
1) the application creates a call object. (Other objects may also be created e.g. call leg object);
2) the application sends all appropriate information for call routing and reporting;
3) the network routes the call and provides requested reports;
4) the application provides subsequent instructions, if required;
5) the network provides subsequent reports, if required.
The above sequence is repeated for each call initiated and an unlimited number of calls may co-exist.
5.2 Description of classes
Framework and service interface classes are defined in the ETSI document: APIs for Open Service Access applications
ES 201 915 [11].
5.3 Interface class diagrams
Interface class diagrams are defined in the ETSI document: APIs for Open Service Access applications
ES 201 915 [11].
6 An API approach to modelling the SPA requirements
6.1 Introduction
Information flows and API mapping examples for each of the Service Provider phase 1 requirements, as defined in
Service Provider Access Requirements; Enhanced Telephony Services [1], are presented below. Only the mappings,
parameters and their values that directly relate to the individual requirements are shown in this clause. The complete
definitions of the API methods, parameters and parameter values can be found in the API Specifications for Open
Service Access applications ES 201 915 [11].
The API mapping examples may be modified by the appropriate standardization groups and the regulatory
considerations have been included for information only. The network operators' requirements, as defined in network
operators' requirements for the delivery of Service Provider access [2], have been included where appropriate. The
screening and charging aspects of the network operators document ([2], clauses 5.5.1 and 5.5.2, respectively) apply to
all the requirements and have not been shown, as these have no direct impact on the information flows between Service
Providers and network operators.
ETSI
11 ETSI EG 201 988-1 V1.1.1 (2002-05)
The circuit related and non-circuit related requirements have been combined to show the logical information flows,
which make no assumptions about the actual implementation. In all cases below, the application is assumed to have
been authenticated.
It should be noted that the API methods fall into two categories, asynchronous and synchronous. Asynchronous
methods, which are identified by the suffix 'Req' (Request), may receive explicit responses identified with the suffixes
'Err' (Error) or 'Res' (Result). Synchronous methods, which have no suffix, may receive implicit responses (return
values) when the methods terminate. These implicit responses are not shown in the API mapping examples.
PTNs will need the ability perform functions not defined in the network operators requirements [2], e.g. to monitor calls
for charging, operational and regulatory reasons, and to perform legal intercept, which are not included in the mapping
examples.
6.2 Calling party information handling capabilities
The implementation of the Service Provider functional requirements relating to the CLI should be in conformance with
the general European Commission and national regulations and with bilateral agreements where they exist.
6.2.1 Reception of the calling line identity
The Service Provider needs to receive the Calling Line Identity (CLI) from the PTN with a call or call indication, if the
CLI is available in the PTN in accordance with EG 201 722 [1], clause 5.2.1 and EG 201 807 [2], clauses 5.2.1 and
5.2.2. If the calling party is using the services of the Service Provider and national regulations and/or legislation allows
it, this requirement also applies to a CLI marked as 'presentation-restricted'. All the indicators associated with the CLI
need also to be delivered.
Information flows:
SP
PTN
New call (CLI, CLI indicators)
Figure 2: Reception of the calling line identity
API mapping example:
Pre-conditions: call event notifications have been enabled using createNotification () and CLIs are supported in the
underlying PTN.
SP
PTN
reportNotification (Notification Information)
Figure 3: Reception of the calling line identity
ETSI
12 ETSI EG 201 988-1 V1.1.1 (2002-05)
The Notification Information includes the parameters shown in table 1.
Table 1: Notification information parameters
Call Notification Destination Address (see table 2), Originating Address (see table 2), Notification call Type.
Information
Call Application Alerting mechanism, Network access type, Teleservice, Bearer service, Party category,
Information Presentation address (see table 2), Generic information, Additional address, Original
Destination Address (see table 2), Redirecting Address (see table 2).
Call Event Information Call Attempt, Call Attempt Authorized, Address information collected, Address information is
analysed, Alerting, Answer, Release, Service Code.
Regulatory considerations:
National regulatory authorities may impose restrictions on the delivery of some CLI information, therefore the PTNO
requires the ability to prevent the forwarding of restricted information.
6.2.2 Presentation of the complete CLI information to the PTN
The Service Provider needs the ability to present all the CLI information about the calling party to the PTN in
accordance with EG 201 722 [1], clause 5.2.2. This includes the original CLI together with the related status
information, as well as all the relevant indicators of the category of the call.
Information flows:
PTN SP
Route call (CLI, CLI indicators)
Figure 4: Presentation of the complete CLI information to the PTN
API mapping example:
Pre-conditions: A call object exists and the Service Provider has either received a reportNotification (Notification
Information), or is to initiate a call and associated call legs. CLIs are supported in the underlying PTN. If the routeReq
() method is to be used, a call leg object has been created using createCallLeg (), which includes address parameters
containing the elements shown in table 2. Subsequent events can be armed by means of the eventReportReq() methods.
For a user agent initiated calls either a continueProcessing() or createCallLeg()/eventReportReq()/routeReq() or
createAndRouteCallLegReq() can be sent.
SP
PTN
createCallLeg(), eventReportReq(), routeReq ()
or continueProcessing ()
or createAndRouteCallLegReq()
Figure 5: Presentation of the complete CLI information to the PTN
ETSI
13 ETSI EG 201 988-1 V1.1.1 (2002-05)
The routeReq () and createAndRouteCallLegReq () methods include address parameters, which include the elements
shown in table 2.
Table 2: Address parameter elements
Address Plan IP, Multicast, Unicast, E.164, URL, NSAP SMTP, MSMail, X400, Undefined.
Address String
Address required by the Service Provider, e.g. CLI, dialled number, destination address.
Name Name associated with Address String.
Address Presentation "Presentation allowed", "presentation restricted", "presentation address not available",
"undefined" (see note).
Address Screening
"User provided verified and passed", "user provided not verified", "user provided verified and
failed", or "application/network provided".
Subaddress String
Subaddress.
NOTE: The address parameters may be null if the address is not available.
The address parameters need to contain routing information, including selected network operator, alternate network
operator, and chained transit network selection. Actual network codes may be agreed bilaterally or centralized by
national regulatory authorities (as harmonized by groups of NRAs or the European Commission).
Regulatory considerations:
National regulatory authorities may impose restrictions on the use of CLI information supplied by Service Providers. It
is assumed that the CLI provided by the PTN will not be changed, although the CLI provided by the Service Provider
may be used for presentation to the called party. Services such as Malicious Call Identification (MCID) [10] must not
be compromised.
6.2.3 Addition or substitution of a calling line identity
The Service Provider needs the ability to add or substitute the User Provided CLI to the CLI information of a call when
passing it forward in accordance with EG 201 722 [1], clause 5.2.3.
Information flows:
PTN SP
Route call (Additional CLI, CLI indicators)
Figure 6: Addition or substitution of a calling line identity
API mapping example:
Pre-conditions: A call object exists and the Service Provider has either received a reportNotification (Notification
Information), or is to initiate a call. A second CLI can be transported through the underlying PTN and delivered to the
service user. If the routeReq () method is to be used, a call leg object has been created using createCallLeg (), which
includes address parameters containing the elements shown in table 2.
PTN SP
createCallLeg, routeReq ()
or
createAndRouteCallLegReq ()
Figure 7: Addition or substitution of a calling line identity
The routeReq () or createAndRouteCallLegReq() methods include address parameters, which include the elements
shown in table 2.
ETSI
14 ETSI EG 201 988-1 V1.1.1 (2002-05)
Regulatory considerations:
National regulatory authorities may impose restrictions on the use of CLI information supplied by Service Providers. In
general, it is assumed that the CLI provided by the PTN will not be changed, although the CLI provided by the Service
Provider may be used for presentation to the called party. Services such as Malicious Call Identification (MCID) [10]
must not be compromised.
6.2.4 Provision of CLI information to an SP-initiated call
The Service Provider needs the ability to provide CLI information to an SP-initiated call in accordance with
EG 201 722 [1], clause 5.2.4.
Information flows:
SP
PTN
Initiate call (CLI, CLI Indicators)
Figure 8: Provision of CLI information to an SP-initiated call
API mapping example:
Pre-conditions: A call object has been created and CLIs are supported in the underlying network. If the routeReq ()
method is to be used, a call leg object has been created using createCallLeg (), the routeReq() method includes address
parameters containing the elements shown in table 2.
SP
PTN
createCallLeg, routeReq ()
or
createAndRouteCallLegReq()
Figure 9: Provision of CLI information to an SP-initiated call
The routeReq () or createAndRouteCallLegReq() methods include address parameters, which include the elements
shown in table 2.
Regulatory considerations:
National regulatory authorities may impose restrictions on the use of CLI information supplied by Service Providers.
ETSI
15 ETSI EG 201 988-1 V1.1.1 (2002-05)
6.2.5 Relaying of the malicious call identification data of a received call
The Service Provider needs the ability to relay all the received call-specific information unchanged to the terminating
network, that may be used for malicious call tracing in accordance with EG 201 722 [1], clause 5.2.5 and
EG 201 807 [2], clause 5.2.1.
Information flows:
PTN SP
Request malicious call identification data
Malicious call identification
Figure 10: Relaying of the malicious call identification data of a received call
NOTE: The request information flow is only required if the data has not been supplied during the call set-up
phase.
API mapping example:
The malicious call identification data can be supplied during the call set-up phase, as shown below, but there is no
support for requesting this information.
Pre-conditions: A call object exists and the Service Provider has either received a reportNotification (Notification
Information), or is to initiate a call. The PTNO has mechanisms in place to prevent essential MCID information being
overwritten in the PTN by the SP. If the routeReq () method is to be used, a call leg object has been created using
createCallLeg (), which includes address parameters containing the elements shown in table 2.
PTN
SP
CreateCallLeg(), routeReq ()
or
createAndRouteCallLegReq()
Figure 11: Relaying of the malicious call identification data of a received call
The routeReq() or createAndRouteCallLegReq() methods include Origination Address, Redirecting Address and Call
Application Information, including a Presentation Address, parameters, which should contain sufficient addressing
information for malicious call identification when combined with information available in the network API gateway.
The address parameters include the elements shown in table 2. The Call Application Information is shown in table 1.
Regulatory considerations:
National regulatory authorities are likely to require the PTN to provide malicious call identification information for a
single call to support the malicious call identification service (MCID) [10]. In cases where a call has been routed
through a Service Provider's equipment as two separate calls, e.g. incoming and outgoing calls joined together by the
Service Provider, the malicious call identification information held by the PTN will not associate the two calls together.
ETSI
16 ETSI EG 201 988-1 V1.1.1 (2002-05)
6.3 Basic call set-up and clear-down capabilities
6.3.1 Return speech path connection from the terminating PTN to the
calling party
The Service Provider needs the ability to request the through-connection of a backward in-band message path to the
calling party immediately upon the arrival of a confirmation of the call set-up in accordance with EG 201 722 [1],
clause 5.3.1. There must be a mechanism for the support of charging between the PTNO and the Service Provider.
Information flows:
PTN SP
Call set-up confirmation
Connect backward speech path
Figure 12: Return speech path connection from the terminating PTN to the calling party
API mapping example:
Pre-conditions: A call set-up has been attempted using routeReq (responseRequested) or createCallLeg (),
eventReportReq (eventReportsRequested) and routeReq () or createAndRouteCallLegReq(). The resources to provide
the backward speech path must be available in the underlying PTN.
PTN SP
routeErr ()
or
eventReportRes ()
createUICall ()
sendInfoReq ()
Figure 13: Return speech path connection from the terminating PTN to the calling party
The sendInfoReq () includes the parameters shown in table 3.
Table 3: sendInfoReq () parameters
Information Specifies the identity of the information to send to the user.
Variable Information Defines the variable part of the information to send to the user.
Repeat Indicator Defines how many times the information should be sent to the user.
ETSI
17 ETSI EG 201 988-1 V1.1.1 (2002-05)
The route call results or event report result include the parameters shown in table 4 and table 10 respectively.
Table 4: Route call results parameters
Response Requested or These include: Alerting, Answer, Release (user not available, busy, No Answer, not
Event Reports Requested
reachable, routing failure, premature disconnect, Disconnected, call restricted,
unavailable resource), Redirected, Connection Ended, and Call Ended.
Regulatory considerations:
None identified.
6.3.2 Routing of an originating or incoming call from the PTN to the SP
On defined criteria, the Service Provider needs an originating or incoming call from a Service Provider service user to
be routed from the PTN to the SP, e.g. based on the dialled digits or CLI in accordance with EG 201 722 [1],
clause 5.3.2 and EG 201 807 [2], clause 5.2.2.
Information flows:
PTN SP
New call (Dialled digits, CLI, CLI indicators)
Route call (Service provider address)
Figure 14: Routing of an originating or incoming call from the PTN to the SP
API mapping example:
Pre-conditions: Call notifications have been created using createNotification ().
PTN SP
reportNotification (Notification Information)
<< Followed by either: >>
eventReportReq()/routeReq ()
<< or >>
createCallLeg ()
eventReportReq()/routeReq ()
<< or >>
createAndRouteCallLegReq()
<< or >>
eventReportReq()/continueProcessing()
Figure 15: Routing of an originating or incoming call from the PTN to the SP
ETSI
18 ETSI EG 201 988-1 V1.1.1 (2002-05)
The Notification Information includes the parameters shown in table 1.
The routeReq () or createAndRouteCallLegReq() methods include a Target Address parameter, which is set to route the
call to the Service Provider. The address parameters include the elements shown in table 2.
Regulatory considerations:
National regulatory authorities may impose restrictions on the delivery of some CLI and redirecting address
information, therefore the PTNO requires the ability to prevent the forwarding of restricted information.
6.3.3 Indication of an originating or incoming call from the PTN to the SP
On defined criteria, the Service Provider needs from the PTN the indication of an originating or incoming call from an
Service Provider service user e.g. based on the dialled digits or CLI in accordance with EG 201 722 [1], clause 5.3.3
and EG 201 807 [2], clause 5.2.2.
Information flows:
PTN SP
New call (Dialled digits, CLI, CLI indicators)
Figure 16: Indication of an originating or incoming call from the PTN to the SP
API mapping example:
Pre-conditions: Call notifications have been created using createNotification ().
PTN SP
rep
...