ETSI EG 201 988-1 V1.1.1 (2002-05)

Services and Protocols for Advanced Networks (SPAN); Service Provider Access Requirements (SPAR); Open Service Access for API requirements; Part 1: Version 1

DEG/SPAN-141606-1

Storitve in protokoli za napredna omrežja (SPAN) - Zahteve dostopa ponudnika storitve (SPAR) - Odprt dostop do storitve za zahteve API - 1. del: Različica 1

General Information

• Status: Published
• Publication Date: 26-May-2002
• Technical Committee: SPAN 14 - SPAN Overall Network and System Architecture (ONSA)
• Current Stage: 12 - Completion
• Due Date: 31-May-2002
• Completion Date: 27-May-2002
• Ref Project: SIST-V ETSI/EG 201 988-1 V1.1.1:2003 - Services and Protocols for Advanced Networks (SPAN) - Service Provider Access Requirements (SPAR) - Open Service Access for API requirements - Part 1: Version 1

Standards Content (Sample)

SLOVENSKI STANDARD
SIST-V ETSI/EG 201 988-1 V1.1.1:2003
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
SIST-V ETSI/EG 201 988-1 V1.1.1:2003 en
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

---------------------- Page: 1 ----------------------

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

---------------------- Page: 2 ----------------------

SIST-V ETSI/EG 201 988-1 V1.1.1:2003
ETSI EG 201 988-1 V1.1.1 (2002-05)
ETSI Guide
Services and Protocols for Advanced Networks (SPAN);
Service Provider Access Requirements (SPAR);
Open Service Access for API requirements;
Part 1: Version 1

---------------------- Page: 3 ----------------------

SIST-V ETSI/EG 201 988-1 V1.1.1:2003
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.:[phone] Fax:[phone]
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:
[e-mail]
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

---------------------- Page: 4 ----------------------

SIST-V ETSI/EG 201 988-1 V1.1.1:2003
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

---------------------- Page: 5 ----------------------

SIST-V ETSI/EG 201 988-1 V1.1.1:2003
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

---------------------- Page: 6 ----------------------

SIST-V ETSI/EG 201 988-1 V1.1.1:2003
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

---------------------- Page: 7 ----------------------

SIST-V ETSI/EG 201 988-1 V1.1.1:2003
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

---------------------- Page: 8 ----------------------

SIST-V ETSI/EG 201 988-1 V1.1.1:2003
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

---------------------- Page: 9 ----------------------

SIST-V ETSI/EG 201 988-1 V1.1.1:2003
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

---------------------- Page: 10 ----------------------

SIST-V ETSI/EG 201 988-1 V1.1.1:2003
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

---------------------- Page: 11 ----------------------

SIST-V ETSI/EG 201 988-1 V1.1.1:2003
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

---------------------- Page: 12 ----------------------

SIST-V ETSI/EG 201 988-1 V1.1.1:2003
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 fu
...