CenturyLink Technical Publication

Transcription

1 CenturyLink Technical Publication CENTURYLINK WHOLESALE ACCESS SERVICE CALL EVENT AND MANAGEMENT SIGNALING SERVICE Copyright 1994, 1999, 2000, 2007, 2008, 2009, CenturyLink Issue E All Rights Reserved January 2013

2 CenturyLink Tech Pub Issue E, January2013 NOTICE Notice This publication provides technical disclosure information for the Network Interfaces used with the CenturyLink Call Event and Management Signaling Service. Included are the Call Event and Service Parameter Update access interfaces for Enhanced Service providers and wholesalers. This publication supports the Qwest Network Disclosure for Call Event and Management Signaling Service # 533 originally issued in November CenturyLink Corporation reserves the right to revise this document for any reason, including but not limited to, conformity with standards promulgated by various governmental or regulatory agencies; utilization of advances in the state of the technical arts; or to reflect changes in the design of equipment, techniques or procedures described or referred to herein. Liability to anyone arising out of use or reliance upon any information set forth herein is expressly disclaimed, and no representation or warranties, expressed or implied, are made with respect to the accuracy or utility of any information set forth herein. This document is not to be construed as a suggestion to any manufacturer to modify or change any of its products, nor does this publication represent any commitment by CenturyLink, Inc. to purchase any specific products. Further, conformance to this publication does not constitute a guarantee of a given supplier's equipment and/or its associated documentation. Future issues of Technical Publication will be announced to the industry at least 15 days before the issuance date. This notice, which will come through our standard customer notification channels, will allow the customer time to comment on the proposed revisions. Ordering information for CenturyLink Publications can be obtained from the Reference Section of this document. Throughout this publication, the term CenturyLink signifies CenturyLink Corporation If further information is required, please contact: CenturyLink 700 W Mineral Ave. Littleton, CO Fax: (303) techpub@centurylink.com

3 CenturyLink Tech Pub Issue E, January2013 Comments COMMENTS on PUB PLEASE TEAR OUT AND SEND YOUR COMMENTS/SUGGESTIONS TO: CenturyLink 700 W Mineral Ave. Littleton, CO Fax: (303) techpub@centurylink.com Information from you helps us to improve our Publications. Please take a few moments to answer the following questions and return to the above address. Was this Publication valuable to you in understanding the technical parameters of our service? Was the information accurate and up-to-date? Was the information easily understood? Were the contents logically sequenced? Were the tables and figures understandable and helpful Were the pages legible? YES NO YES NO YES NO YES NO YES NO YES NO If you answered NO to any of the questions and/or if you have any other comments or suggestions, please explain: (Attach additional sheet, if necessary) Name Date Company Address Telephone Number Name Date

4 CenturyLink Tech Pub Chapter and Section Contents 1. Introduction TOC i Page 1.1 General Reason for Reissue Scope CEMSS FCC Tariffed interface and DS1/DS3 Transport Access Publication Organization Terminology Service Description General High Level Architecture Description Technical Requirements OSA/Parlay Interface Parlay Framework Parlay MPCC Parlay SCF Registration Process TUI Interworking for Parlay-based Services Service Parameter Update Gateway (SPUG) Interface SPUG CORBA Framework Access SPUG XML SOAP web service Access SPUG Application CEMSS Client Administration Service Provider Registration and Provisioning CEMSS Call Control Definitions Overview MPCC Methods Call Event Notification Call Control Physical/Low Layer Connection Call Flows Call Event Messaging and Control Flows MPCC Inbound Call Messaging MPCC Outbound Call Messaging Call Event and Control Interface Service Flow Interface Security CEMSS Service Parameter Update Gateway (SPUG) Access SPUG Interface Overview Security SPUG API SPUG Framework Access (CORBA)

5 CenturyLink Tech Pub Contents Developing a CORBA SPUG Client Application SPUG Inbound (CORBA) SPUG Outbound (CORBA) SPUG XML SOAP web service API SPUG SOAP Client Application SPUG XML SOAP Web Service Client Development SOAP Synchronous Operations SPUG Result Codes SPUG Get Transactions SPUG Update Transactions Updates and Latency Null Values SPUG Transaction Details by Service Remote Access Forwarding / Call Following Call Rejection Security Screen Selective Call Forwarding Selective Call Waiting Update Center Update Center TUI Interworking Conceptual Design DID Numbers TUI Interworking Technical Requirements General Requirements Available Service Listing DID Menu DID TUI Interworking Style Guide CEMSS Restrictions Limitations Extensions OSA/Parlay Major Exclusions Framework Multi-Party Call Control Network-Initiated Limitations and Extensions Potential Callback Deadlock SPUG Definitions References ETSI/Parlay Specifications CenturyLink Documentation Ordering Information Trademarks TOC ii

6 CenturyLink Tech Pub Contents 10. Tables TOC iii

7 CenturyLink Tech Pub Chapter 1 Introduction CONTENTS Chapter and Section Page 1. Introduction General Reason for Reissue Scope CEMSS FCC Tariffed interface and DS1/DS3 Transport Access Publication Organization Terminology i

8 CenturyLink Tech Pub Chapter 1 Introduction 1. Introduction 1.1 General This publication provides technical disclosure information for the Network Interfaces used with the CenturyLink Call Event and Management Signaling Service (CEMSS), which provides mediated OSA Parlay and Service Parameter Update Gateway (SPUG) interfaces to the CenturyLink local network for Enhanced Service Providers. The Parlay interface provides a subset of Parlay 4.2 MPCC capabilities, and the SPUG provides mediated access to CenturyLink regulated Advanced Intelligent Network (AIN) services. This publication supports the Qwest Network Disclosure for Call Event and Management Signaling Service # 533 issued in November Reason for Reissue This publication is being reissued to reflect the removal of the discontinued One Number Service in the Service Profile Update Gateway and removal of the Parlay-based CreateCall capability. Clarifications and corrections for the CEMSS TUI interworking in Chapter 6 were also supplied. 1.3 Scope This publication defines interfaces and technical requirements for the CenturyLink Call Event and Management Signaling Service. The publication provides quantitative and qualitative descriptive information along with references to other publications. Descriptions of CenturyLink Security and CenturyLink Secure Perimeter Architecture access (SPA) interfaces are also included. 1.4 CEMSS FCC Tariffed interface and DS1/DS3 Transport Access This technical publication provides interface specifications for the Call Event and Management Signaling Service which is provided under applicable state and interstate Federal Communications Commission (FCC) tariffs. Enhanced Service Provider applications connect with the CEMSS tariffed interfaces using interstate access DS1 and DS3 tariff dedicated transport between the service provider s site and designated CenturyLink Secure Perimeter Architecture access (SPA) points. The service provider's connection to the CenturyLink SPA is over the CenturyLink extranet utilizing a public IP address defined by CenturyLink at the CenturyLink designated SPA location. Details on ordering the CEMSS and SPA connection can be obtained from a designated CenturyLink wholesale account representative. 1.5 Publication Organization This publication is organized as follows: Chapter Contents General information about this document. A brief description of the CenturyLink Call Event and Management Signaling Service 1-1

9 CenturyLink Tech Pub Chapter 1 Introduction Technical requirements, service objectives, and technical descriptions of the service and its options The CEMSS call event signaling and call control interfaces and Parlay Group Standards with CenturyLink exceptions The Service Parameter Access Update Gateway (SPUG) CenturyLink proprietary interfaces and specifications. The CEMSS TUI interworking proprietary interface and specification. The CEMSS Restrictions and Limitations Definitions References, ordering and copyright information Tables of CEMSS Parlay API supported methods 1.6 Terminology In this publication, the term OSA shall mean Open Services Access defined by CenturyLink as.a Parlay-based mediated gateway. 1-2

10 CenturyLink Tech Pub Chapter 2 Service Description CONTENTS Chapter and Section Page 2. Service Description General High Level Architecture Description i

11 CenturyLink Tech Pub Chapter 2 Service Description 2. Service Description 2.1 General This chapter contains a brief description of the CenturyLink Call Event and Management Signaling Service (CEMSS) CEMSS is a service offering of CenturyLink Corporation that may be used by third party service providers to obtain call event messages, reroute calls, interwork with the CenturyLink Update Center TUI, and as a means to read and update CenturyLink Advanced Intelligent Network (AIN) service parameters associated with certain local telephone lines served from CenturyLink local switches. The service will be available to Enhanced Service Providers that offer application platform services to end users who are served via CenturyLink AIN-capable local switches. CEMSS may be used by these customers to gain access to CenturyLink local network call events, certain call control operations and management of selected AIN-based service parameter data for their end users served by AIN-capable local switches. Call events and control are supplied through an industry-standard Parlay Multi-Party Call Control (MPCC) interface, employing CORBA middleware and requires the CEMSS client application to interface via CORBA IIOP. AIN PSTN service parameter management is supplied through a separate CenturyLink customized interface called the Service Parameter Update Gateway (SPUG). SPUG is available to the client application over a choice of two interface protocols. One employs a CenturyLink customized CORBA interface and the other uses a CenturyLink custom SOAP XML web service specification. The XML SOAP web service interface provides a subset of the functionality provided by the CORBA interface. TUI interworking is also provided through a simple CenturyLink-customized interface. CEMSS is offered under applicable state and FCC interstate tariffs in selected states and CenturyLink wire centers. Please see the latest CenturyLink CEMSS Network Disclosure for deployment locations. 2.2 High Level Architecture Description CEMSS utilizes several network elements to provide third-party access to certain network events, call control operations and AIN service parameters. CenturyLink has deployed an Open Services Access (OSA) compliant gateway that provides a Parlay-based API for call control and a custom API for AIN service parameter access. The Client interfaces utilize CORBA IIOP and optional SOAP XML web service into a secure gateway. The gateway provides an interface between the CEMSS client application and the CenturyLink local telecommunications network. For Parlay, only the Framework and portions of the MPCC SCF APIs will be enabled. A highlevel view of the CEMSS architecture and interfaces supporting CEMSS is shown in Figure

12 CenturyLink Tech Pub Chapter 2 Service Description CORBA CEMSS INTERFACE LANDLINE CENTURYLINK LOCAL NETWORK (AIN / PSTN) CENTURY LINK OSA GATEWAY CORBA and SOAP XML Parlay SPUG CEMSS CLIENT l CENTURY LINK UPDATE CENTER VOICE TRAFFIC Figure 2-1 CEMSS High-Level Architecture The CenturyLink CEMSS Gateway provides an OSA/Parlay interface based upon the standards established cooperatively by the Parlay Group and ETSI. It supplies selected portions of the Parlay 4.2 Framework and Multi-Party Call Control APIs to third parties such as an Enhanced Service Provider. These APIs provide call control messaging functions to the CEMSS client. The CenturyLink CEMSS Gateway also provides a custom CORBA-based API and a custom SOAP XML web service API called the Service Parameter Update Gateway (SPUG) that enables read and update access to various parameters of CenturyLink AIN services. The CEMSS SPUG supports access to several AIN services. See section 5.9 for details CEMSS clients are provisioned in the CenturyLink network such that they may only interact with CEMSS on behalf of subscribed TNs which are assigned to their end customers. For inbound messages to the CenturyLink CEMSS gateway from service providers, service providers are authenticated at the CEMSS gateway. In addition, the subscribed TN network subscriber record contains the end customer s service provider identity. CEMSS will allow access to that end customer s data only if there is a match between the service provider identity in the network record and the CEMSS client. For outbound messages to service providers from the CenturyLink network, the service provider identity as provisioned on the end customer s network subscriber record is used to route messages to the appropriate service provider. Administrative controls provided by the CEMSS gateway provide CenturyLink the ability to add, suspend, remove, and otherwise control CEMSS client access to either or both the OSA/Parlay or SPUG interfaces. The administrative tools also control what CEMSS services are available to each individual Client. 2-2

13 CenturyLink Tech Pub Chapter 3 Technical Requirements CONTENTS Chapter and Section Page 3. Technical Requirements OSA/Parlay Interface Parlay Framework Parlay MPCC Parlay SCF Registration Process TUI Interworking for Parlay-based Services Service Parameter Update Gateway (SPUG) Interface SPUG CORBA Framework Access SPUG XML SOAP web service Access SPUG Application CEMSS Client Administration Service Provider Registration and Provisioning i

14 CenturyLink Tech Pub Chapter 3 Technical Requirements 3. Technical Requirements This chapter provides general technical requirements for CEMSS and its support for the Parlay 4.2 Framework and Multi Party Call Control APIs, as well as the Service Parameter Update Gateway (SPUG). Subsequent chapters provide detailed information on each of these interfaces. 3.1 OSA/Parlay Interface The CenturyLink implementation of Parlay in CEMSS supports subsets of the following listed portions of the ETSI OSA/Parlay 4.2 specification 1, documented in depth in Chapter 6 CEMSS Restrictions and Limitations of this document. CEMSS does not support the entire Parlay specification, nor does it support the entire Parlay Framework or Parlay Multi-Party Call Control Service Capability Feature (SCF). Only these Parlay portions are supported: Portions of Part 3: Parlay Framework Portions of Part 4: Call Control; Sub-part 3: Parlay Multi Party Call Control SCF Portions of Part 4 that are indirectly referenced by supported portions of Part 4, Sub-part Parlay Framework The initial point of contact for a client application connecting to CEMSS for Call Control is the Parlay Framework. Once provisioned in the CEMSS Gateway, the client application may access the Framework. The client can then use the Framework to authenticate with CEMSS and start performing various additional operations with the Framework, such as viewing available services and signing service agreements Parlay MPCC The CEMSS implementation of Parlay Multi Party Call Control (MPCC) is used to supply the client application with access to network event messages and provide limited call control operations. Provisioning for initial network events will be supplied by CenturyLink for the client in the CenturyLink local network elements and end customer TNs as individual orders are received on such TNs. The client application must register interest in such event notifications using the Parlay enablenotifications() method. CEMSS will deliver MPCC network call event notifications whenever a subscriber attempts to place an outbound call, or when an inbound call is about to attempt termination. Once CEMSS delivers the initial MPCC network call event via the reportnotification() method, the client may request notification of subsequent events (Busy or Answer) that may occur during that call. A specific limitation is that if the called party is the CEMSS subscriber, and that subscriber has Call Waiting service, and the call is offerable (that is, the subscriber is on the phone but unable to receive a call waiting tone), then CEMSS will not deliver a BUSY call event notification to the CEMSS client. In such cases, the call will be offered to the called party without any CEMSS client interaction. If any other requested events (such as ANSWER) are encountered, they will be sent to the CEMSS client at the appropriate time. If no other events were requested, then CEMSS will send a CallEnded message to the client immediately with a RELEASE CAUSE of UNDEFINED ETSI ES V1.3.1 ( ) documentation is available at 3-1

15 CenturyLink Tech Pub Chapter 3 Technical Requirements Parlay SCF Registration Process The SCF registration process is as follows: Client will be granted access to the Framework via an off-line service agreement with CenturyLink. CenturyLink will then create a Service Profile for the client which has the authorization information that will also be provided to the client. The profile will specify what services are visible to and available to the client. The initiateauthenticationwithversion() method must be used by the client to initiate authentication with the Framework. The Version refers to the Framework version. Once a CEMSS client is provisioned with a Service Profile in the CEMSS gateway, they may access the Framework and its services. Both the client and Framework can authenticate with each other. Client authenticates with the Framework and can discover available SCFs. Client chooses SCFs and using a RSA key signs an electronic service agreement 3.2 TUI Interworking for Parlay-based Services The service provider may choose to provide a Telephony User Interface (TUI) for subscribers of their Parlay-based services. CenturyLink provides an optional integration with the CenturyLink Update Center (QUC) TUI, which is used by CenturyLink subscribers to update AIN-based services. The Enhanced Service Provider (ESP) may choose to supply CenturyLink with two telephone numbers in each CenturyLink Local Calling Area served by the ESP in order to provide this interworking. These two numbers will be dialed by the CenturyLink Update Center to supply the functions described below. The first DID number, referred to as the Available Service Listing number, is dialed by the QUC whenever the Update Center Main Menu is played. It accomplishes two things: It determines if the subscriber has any services that can be updated via the CenturyLink Update Center. If no such services are available, the ESP communicates this to CenturyLink by disconnecting the call immediately without playing any announcements. A timer on the AIN platform detects the quick disconnect and from that point forward assumes that no ESP services are available to the subscriber. It allows the ESP to play part of the CenturyLink Update Center main menu to the subscriber to communicate what features may be updated by pressing ONE. The second DID number, referred to as the Menu number, is dialed by the CenturyLink Update Center only when ONE is pressed from the main menu after it has been established that ESP services are available. When this second number is dialed, AIN defers to the ESP to collect digits and interact with the caller. Only when the ESP disconnects the call will AIN resume control of the call at the QUC main menu. 3.3 Service Parameter Update Gateway (SPUG) Interface The SPUG can be accessed by a CORBA based interface or an XML SOAP web service interface. The CORBA interface allows full interaction with the SPUG providing an inbound API which the client may use to update and read subscribed TN service profiles for AIN services. The CORBA interface also provides an outbound interface which the client may use to 3-2

16 CenturyLink Tech Pub Chapter 3 Technical Requirements register for automatic notification of service profile changes via the Telephone User Interface (TUI). The XML SOAP web service interface is an inbound API only, providing the client with the ability to read and update subscribed TN service profiles. No outbound API is provided in the SOAP interface. The CEMSS SPUG supports access to several AIN services. See section 5.9 for details. The SPUG Framework and Application comprise the chief components of this interface SPUG CORBA Framework Access The SPUG Framework provides Client access to the CEMSS AIN service parameter access and update services. Clients will first interact with CEMSS through the SPUG Framework once they have been provisioned by CenturyLink with a client Profile. The Client will then have access to the SPUG application represented by the SPUG Service Profile SPUG XML SOAP web service Access The XML SOAP web service interface also requires a client to be provisioned in the CenturyLink CEMSS gateway. The SOAP client must first authenticate with the CEMSS gateway before gaining access to SPUG services SPUG Application The Service Parameter Update Gateway application of CEMSS provides the client with an interface that will allow them to access CenturyLink AIN service parameters of their subscribed TNs for the purposes of 1) reading existing AIN service parameters, 2) updating AIN service parameters, and 3) receiving proactive notifications of TUI-based updates to AIN service parameters (SPUG CORBA interface only). Although the CEMSS client is the party that may view and change data, it is expected that the client will build one or more applications for use by their end users (subscribed TNs) to interwork with the SPUG application. 3.4 CEMSS Client Administration Service Provider Registration and Provisioning Clients will be provisioned and identified as the Service Provider and linked to subscribed TNs by CenturyLink s provisioning systems. Once the client has been provisioned within CEMSS, they may use the Parlay Framework to discover their pre-provisioned MPCC service API per the Parlay Framework specifications. A CEMSS Service Profile must be provisioned by CenturyLink before a client can access the Parlay MPCC SCFs and SPUG interface. Initially, CenturyLink will establish Call Event and SPUG Service Profiles for general administrative use. Unique profiles will then be established for a client for use in discovering and subscribing to the services offered by the Service Profile. Profiles are configurable and will be provisioned by CenturyLink for a client after an off-line service agreement is in place. Clients will then be able to electronically subscribe to specific Framework services and Framework service agreements. The Parlay Service Profile is a set of information that defines how an entity may access the CEMSS Parlay interface. Each profile contains such basic information as the client s Domain ID, authentication method, CHAP secret, and priority during overloaded conditions. Each 3-3

17 CenturyLink Tech Pub Chapter 3 Technical Requirements Service Profile contains an Access Control List that details which Framework objects are accessible, in addition to controlling for which SCFs a client can discover and register. CenturyLink will provision the service triggering network events for the clients based on individual line service orders. Each Client will then activate the receipt of all initial network call events for all of their subscribed TNs using the enablenotifications() method of the MPCC API. A SPUG Service Profile defines the services that a client may access. Clients must have a SPUG Client Profile established before they may use CEMSS for accessing and updating AIN service parameters of the subscribed TN. The CEMSS SPUG supports access to several AIN services. See section 5.9 for details. The SPUG application for service parameter access and updating (read and write) has a different administration process than is used for Call Event service profiles. Each Client accessing SPUG is required to authenticate itself with the SPUG framework by providing credentials to be validated. This is done by creating a client Profile for every Client wishing to access SPUG. A SPUG Client Profile contains information such as Client ID, Service Provider ID and/or Client name. 3-4

18 CenturyLink Tech Pub Chapter 4 CEMSS Call Control CONTENTS Chapter and Section Page CONTENTS... i 4. CEMSS Call Control Definitions Table 4-1 Definitions Overview MPCC Methods Call Event Notification Call Control Physical/Low Layer Connection Figure 4-1 CEMSS client connectivity Call Flows Call Event Messaging and Control Flows MPCC Inbound Call Messaging MPCC Outbound Call Messaging Call Event and Control Interface Service Flow Interface Security i

19 CenturyLink Tech Pub Chapter 4 CEMSS Call Control 4. CEMSS Call Control This chapter highlights functional capabilities of the network call control interface within the CEMSS specification. Network call event signaling under CEMSS provides the means for a third party application to interface with PSTN customer call handling, such as to receive notifications of network call events. The CEMSS Network call event and control interface represents a subset of the ESTI/Parlay 4.2 Multi-Party Call Control specification with CenturyLink-specified limitations and modifications. Other Parlay call control interfaces, such as Generic Call Control (GCC), Multi-Media Call Control (MMCC) and Conference Call Control (CCC) are not supported. 4.1 Definitions Table 4-1 defines terms used elsewhere in this document: CEMSS Gateway Off-Hook Delay (OHD) Open Services Access (OSA) Parlay Public Switched Telephone Network (PSTN) Service Control Point (SCP) Service Switching Point (SSP) Subscriber Table 4-1 Definitions A CenturyLink network element that provides the messaging bridge between the CenturyLink local network and external application servers employed by the CEMSS customer. An AIN originating trigger that causes the SSP to query the SCP whenever a call is being originated from the subscriber s line, and the dialed digits have been analyzed for validity. The OHD trigger must be provisioned on the subscriber s line. The OSA system within the CenturyLink Parlay gateway supplies the Parlay Framework API and Parlay Service Capability Feature (SCF) mappings for AIN network signaling. The Framework manages CEMSS client access to services and ensures proper routing of network event and control messages to Clients. OSA uses CORBA IIOP middleware for the actual Parlay interface to the client. An Open Services Access (OSA) application-programming interface which provides a means of interacting with the telephone network using CORBA-based messaging. The collection of interconnected public telephone networks designed primarily for voice traffic. A CenturyLink network element that enables AIN functionality, manages feature interactions, and provides a conduit for signaling between the SSP and the CEMSS gateway. An AIN-enabled end-office switch that serves the subscriber s main telephone number. This office launches queries to the SCP whenever calls are placed to or from the subscriber s phone. A party that subscribes to the CEMSS service on a single PSTN line. 4-1

20 CenturyLink Tech Pub Chapter 4 CEMSS Call Control Termination Attempt Trigger (TAT) An AIN terminating trigger that causes the SSP to query the SCP whenever a call is about to be terminated to a particular POTS line, if so provisioned 4.2 Overview CEMSS supports limited call control operations on network-initiated events. Most network events are reported passively with no ability to alter call processing, but the service provider may request that a call be forwarded to another number under certain circumstances described. 4.3 MPCC Methods CEMSS permits third-party applications to use portions of the Parlay MPCC to perform a limited number of call control functions. This section lists the Parlay API methods supported by the CenturyLink implementation of this interface. callended() deassign() deassigncall() disablenotifications() enablenotifications() eventreporterr() eventreportreq() eventreportreq() eventreportres() getcalllegs() getinfoerr() getinforeq() getinfores() release() reportnotification() routeerr() routereq() routereq() superviseerr() supervisereq() superviseres() Call Event Notification If requested by the client, CEMSS will send Parlay messages corresponding to various network events for a subscribed TN to the registered CEMMS client. The subscribed TN must be provisioned by CenturyLink with AIN enablers for CEMSS. Per the OSA/Parlay specification, the client application must register interest in receiving the call event notifications using the enablenotifications() method. CenturyLink provisions AIN TAT and OHD triggers for each subscribed TN. Once interest is registered, call events in the CenturyLink network that encounter these AIN triggers on CEMSS-subscribed lines will result in corresponding reportnotification() messages being sent by the CEMSS gateway to the client application, with some exceptions as outlined later in this document. After receipt of this message, the client application may then request subsequent dynamic events associated with the call session, such as Busy and Answer, or may request that the call be forwarded to another number. CEMSS does not support requests for No Answer or Disconnect call events. Although CEMSS supports routereq() messages that alter the called party number, other AIN services that may be provisioned on the subscriber s line take precedence. In such cases, if the 4-2

21 CenturyLink Tech Pub Chapter 4 CEMSS Call Control AIN service requests that the call be blocked or forwarded, then the Parlay-based call forwarding request is ignored Call Control The CEMSS Parlay interface can be used for limited control of network-initiated calls. CEMSS permits the service provider to forward the call to other telephone numbers in the PSTN using National or E164 addressing, but only in response to the initial reportnotification() message. CEMSS does not provide the ability to forward calls after receipt of subsequent events in the eventreportres() message Physical/Low Layer Connection The CEMSS client will present connections to a CenturyLink Data Center SPA (Secure Perimeter Architecture) location through dedicated circuits via a client extranet. CORBA IIOP is used for transport for Call Events and Control messaging. The CEMSS clients circuits IP addresses will be extended to a CenturyLink CORBA proxy server and then via CenturyLink LAN to the CEMSS gateway. This represents the OSA/Parlay access connection for the CEMSS client. SPUG access for the CEMSS client is provided by a choice of two interface protocols into the CEMSS gateway. These include CORBA IIOP and SOAP XML. For SPUG access the CEMSS clients IP addresses will be extended to either a CenturyLink CORBA proxy or to an XML web service proxy as specified by the Client. Detailed ordering requirements and processes for CEMSS connections are available from the designated CenturyLink wholesale representative. 4-3

22 CenturyLink Tech Pub Chapter 4 CEMSS Call Control Figure 4-1 CEMSS client connectivity 4.4 Call Flows Call Event Messaging and Control Flows CEMSS provides two generalized types of call messaging: Network-initiated inbound calls to the subscribed Parlay TN Network-initiated outbound calls from the subscribed Parlay TN The following is a general description of network signaling and messaging events relative to operating with Parlay s Multi Party Call Control API, focusing upon the following: Parlay application, CEMSS gateway, SCP and SSP. The Parlay application is the responsibility of the service provider while the others are part of the CenturyLink local network. All messaging is generally specific to the CenturyLink Corporation CEMSS implementation. The intent of this section is to provide both an understanding of how network and Parlay events work and what exceptions to the Parlay MPCC standards may be encountered when utilizing the CEMSS implementation of Parlay MPCC. 4-4

23 CenturyLink Tech Pub Chapter 4 CEMSS Call Control Prerequisites: Client has valid OSA Service Profile. CEMSS-specific AIN triggers (Termination Attempt, Off Hook Delay) have been provisioned for subscribed TN in question. Client has activated receipt of notifications by using enablenotifications() method MPCC Inbound Call Messaging Several scenarios of inbound call messaging to a subscribed TN using CEMSS are described in the following subsections. These scenarios are not the only ones supported, but are provided as examples of CEMSS capabilities. Inbound calls to the subscribed TN cause an AIN Termination Attempt Trigger (TAT) to fire on the subscriber s end office switch (SSP). This begins a process resulting in Parlay messaging for such calls between the CEMSS gateway and the client application Example: Terminating Call Answered; No AIN Services In this flow example, an inbound call to the subscribed TN is answered by the subscribed TN. No AIN services are provisioned on the subscriber s line. The client application requests notification of Answer and Busy events. Figure 4-2 Terminating Call Answered; No AIN Services 1) SSP encounters Termination Attempt Trigger; suspends call; sends query to SCP 2) SCP passes query to CEMSS gateway. 3) CEMSS gateway sends Parlay reportnotification() to client application. 4) Client application sends Parlay createcallleg() to CEMSS gateway to allow manipulation of the terminating call leg. 5) Client application sends Parlay eventreportreq() messages for Answer and Busy events on the terminating call leg to CEMSS gateway. 6) CEMSS passes eventreportreq() to SCP. 7) Client application sends Parlay routereq() message with a NULL target address to the CEMSS gateway. 4-5

24 CenturyLink Tech Pub Chapter 4 CEMSS Call Control 8) Client application sends Parlay continueprocessing() message to the CEMSS gateway. 9) CEMSS gateway passes routereq() to SCP. 10) SCP sends AuthorizeTermination response to SSP with request for T_Answer and T_Busy AIN events. 11) Subscriber answers the telephone, resulting in the SSP sending T_Answer message to the SCP. 12) SCP passes EventReportRes(Answer,DoNotMonitor) event to CEMSS gateway. 13) CEMSS gateway sends Parlay eventreportres(answer,donotmonitor) to client application. 14) SCP passes CallEnded event to CEMSS gateway. 15) CEMSS gateway sends Parlay callended(undefined) to client application. Note that the call may not have yet been disconnected at this point, but CEMSS does not support the Disconnect event and thus considers the call ended after it is answered because no other events are possible. Undefined is sent as the callended() disposition because the ultimate disposition of the call is not known. 16) SSP sends a Close(NoMoreEvents) message to the SCP Example: Terminating Call Busy, Offerable, No Answer; No AIN services In this flow example, an inbound call to the subscribed TN encounters a busy line with Call Waiting, where the SSP reports that the call is offerable to the subscriber, is thus offered but not answered by the subscriber. No AIN services are provisioned on the subscriber s line. The client application requests notification of Answer and Busy events. The Busy event is requested in Interrupt mode. Figure 4-3 Terminating Call Busy, Offerable, No Answer, No AIN Services 1) SSP encounters Termination Attempt Trigger; suspends call; sends query to SCP 2) SCP passes query to CEMSS gateway. 3) CEMSS gateway sends Parlay reportnotification() to client application. 4-6

25 CenturyLink Tech Pub Chapter 4 CEMSS Call Control 4) Client application sends Parlay createcallleg() to CEMSS gateway to allow manipulation of the terminating call leg. 5) Client application sends Parlay eventreportreq() messages for Answer and Busy events on the terminating call leg to CEMSS gateway. 6) CEMSS passes eventreportreq() to SCP. 7) Client application sends Parlay routereq() message with a NULL target address to the CEMSS gateway. 8) Client application sends Parlay continueprocessing() message to the CEMSS gateway. 9) CEMSS gateway passes routereq()to SCP. 10) SCP sends AuthorizeTermination response to SSP with request for Answer and Busy events. 11) SSP detects that the subscriber s line is busy and sends a T_Busy(Offerable) event to the SCP. 12) SCP passes Busy event to CEMSS gateway. 13) CEMSS gateway sends Parlay eventreportres(busy) to client application. 14) Client application sends Parlay eventreportreq() messages for Answer event on the terminating call leg to CEMSS gateway. 15) CEMSS passes eventreportreq() to SCP. 16) Client application sends Parlay routereq() message with a NULL target address to the CEMSS gateway. 17) Client application sends Parlay continueprocessing() message to the CEMSS gateway. 18) CEMSS gateway passes routereq() to SCP. 19) SCP sends OfferCall response to SSP with request for Answer event. 20) Subscriber does not answer the telephone before the calling party abandons the call, resulting in the SSP sending a Close(NoAnswer) message to the SCP. 21) SCP passes CallEnded(NoAnswer) event to CEMSS gateway. 22) CEMSS gateway sends Parlay callended(noanswer) to client application Example: Terminating Call Blocked by AIN Service In this flow example, an inbound call to the subscribed TN encounters an AIN service that results in the call being screened and never alerting the subscriber s line. Figure 4-4 Terminating Call Blocked by AIN Service 1) SSP encounters Termination Attempt Trigger; suspends call; sends query to SCP 4-7

26 CenturyLink Tech Pub Chapter 4 CEMSS Call Control 2) SCP encounters AIN blocking service that ultimately results in the call being ended before alerting the subscriber. SSP-SCP messaging for the AIN service is not relevant to this discussion and thus is not considered here. 3) SCP passes query to CEMSS gateway. 4) CEMSS gateway sends Parlay reportnotification() to client application. In the notificationinfo.callnotificationreportscope.originatingaddress.name parameter, CEMSS includes information about the service that blocked the call. See section for details. NOTE: If the client does not recognize that the call is blocked by examining the Name parameter as described above, steps 5 through 10 may occur, but they will be ignored by the CenturyLink local network. 5) Client application sends Parlay createcallleg() to CEMSS gateway to allow manipulation of the terminating call leg. 6) Client application sends Parlay eventreportreq() messages for Answer and Busy events on the terminating call leg to CEMSS gateway. 7) CEMSS passes eventreportreq() to SCP. 8) Client application sends Parlay routereq() message with a NULL target address to the CEMSS gateway. 9) Client application sends Parlay continueprocessing() message to the CEMSS gateway. 10) CEMSS gateway passes routereq() to SCP. 11) SCP responds to CEMSS gateway with a message indicating that the call was ended due to restrictions on the subscriber s line. 12) CEMSS gateway sends Parlay callended(callrestricted) to client application Example: Terminating Call Forwarded; No AIN Services In this flow example, an inbound call to the subscribed TN is forwarded by request of the service provider to another number. No AIN services are provisioned on the subscriber s line. Figure 4-5 Terminating Call Forwarded by Application Server 1) SSP encounters Termination Attempt Trigger; suspends call; sends query to SCP 2) SCP passes query to CEMSS gateway. 3) CEMSS gateway sends Parlay reportnotification() to client application. 4) Client application sends Parlay createcallleg() to CEMSS gateway to allow manipulation of the terminating call leg. 5) Client application sends Parlay routereq() message with a new target address to the CEMSS gateway. 6) Client application sends Parlay continueprocessing() message to the CEMSS gateway. 4-8

27 CenturyLink Tech Pub Chapter 4 CEMSS Call Control 7) CEMSS gateway passes routereq() to SCP. 8) SCP sends ForwardCall response to SSP. 9) SSP forwards the call, resulting in the SSP sending a Close message to the SCP. 10) SCP passes CallEnded event to CEMSS gateway. 11) CEMSS gateway sends Parlay callended(noanswer) to client application. Note that the call may be ringing another telephone number at this point, but CEMSS does not provide the status of the call once it is forwarded MPCC Outbound Call Messaging Several scenarios of outbound call messaging to a subscribed TN using CEMSS are described in the following subsections. These scenarios are not the only ones supported, but are provided as examples of CEMSS capabilities. Outbound calls from the subscribed TN cause an AIN Off-Hook Delay (OHD) trigger to fire on the subscriber s end office switch (SSP). This begins a process resulting in Parlay messaging for such calls between the CEMSS gateway and the client application Example: Originating Call Answered; No AIN services In this flow example, an outbound call from the subscribed TN is answered by the called party. No AIN services are provisioned on the subscriber s line. The client application requests notification of Answer and Busy events. Figure 4-6 Originating Call Answered, No AIN Services 1) SSP encounters Off-Hook Delay trigger; suspends call; sends query to SCP 2) SCP passes query to CEMSS gateway. 3) CEMSS gateway sends Parlay reportnotification() to client application. 4) Client application sends Parlay createcallleg() to CEMSS gateway to allow manipulation of the terminating call leg. 5) Client application sends Parlay eventreportreq() messages for Answer and Busy events on the terminating call leg to CEMSS gateway. 6) Client application sends Parlay routereq() message with a NULL target address to the CEMSS gateway. 7) Client application sends Parlay continueprocessing() message to the CEMSS gateway. 4-9

28 CenturyLink Tech Pub Chapter 4 CEMSS Call Control 8) CEMSS gateway passes Parlay messages to SCP. 9) SCP sends AnalyzeRoute response to SSP with request for Answer and Busy events. 10) Subscriber answers the telephone, resulting in the SSP sending an O_Answer message to the SCP. 11) SCP passes Answer event to CEMSS gateway. 12) CEMSS gateway sends Parlay eventreportres(answer,donotmonitor) to client application. 13) SCP passes CallEnded event to CEMSS gateway. 14) CEMSS gateway sends Parlay callended(undefined) to client application. Note that the call may not have yet been disconnected at this point, but CEMSS does not support the disconnect event and thus considers the call ended after it is answered because no other events are possible. Undefined is sent as the callended() disposition because the ultimate disposition of the call is not known. 15) SSP sends a Close(NoMoreEvents) message to the SCP Example: Originating Call Busy; No AIN services In this flow example, an outbound call from the subscribed TN encounters a busy condition reported by the terminating switch. The client application requests notification of Answer and Busy events. The Busy event is requested in Interrupt mode. Note that in an originating context, there is no knowledge of Call Waiting or whether a call is offerable. Figure 4-7 Originating Call Busy, No AIN Services 1) SSP encounters Off-Hook Delay trigger; suspends call; sends query to SCP 2) SCP passes query to CEMSS gateway. 3) CEMSS gateway sends Parlay reportnotification() to client application. 4) Client application sends Parlay createcallleg() to CEMSS gateway to allow manipulation of the terminating call leg. 5) Client application sends Parlay eventreportreq() messages for Answer and Busy events on the terminating call leg to CEMSS gateway. 4-10

29 CenturyLink Tech Pub Chapter 4 CEMSS Call Control 6) Client application sends Parlay routereq() message with a NULL target address to the CEMSS gateway. 7) Client application sends Parlay continueprocessing() message to the CEMSS gateway. 8) CEMSS gateway passes Parlay messages to SCP. 9) SCP sends AnalyzeRoute response to SSP with request for Answer and Busy events. 10) SSP detects that the called party s line is busy and sends an OCalledPartyBusy() event to the SCP. 11) SCP passes Busy event to CEMSS gateway. 12) CEMSS gateway sends Parlay eventreportres(busy) to client application. 13) Client application sends Parlay routereq() message with a NULL target address to the CEMSS gateway. 14) Client application sends Parlay continueprocessing() message to the CEMSS gateway. 15) CEMSS gateway passes Parlay messages to SCP. 16) SCP sends Continue response to SSP subscriber hears busy tone. 17) SCP passes callended(busy) event to CEMSS gateway. 18) CEMSS gateway sends Parlay callended(busy) to client application Example: Originating Call Blocked by AIN Service In this flow example, an outbound call from the subscribed TN encounters an AIN service that results in the call being screened before routing the call to the called party. Figure 4-8 Originating Call Blocked by AIN Service 1) SSP encounters Off-Hook Delay trigger; suspends call; sends query to SCP 2) SCP encounters AIN blocking service that ultimately results in the call being ended before routing the call to the called party. SSP-SCP messaging for the AIN service is not relevant to this discussion and thus is not considered here. 3) SCP passes query to CEMSS gateway. 4) CEMSS gateway sends Parlay reportnotification() to client application. NOTE: If the client does not recognize that the call is blocked by examining the Name parameter as described above, steps 5 through 10 may occur, but they will be ignored by the CenturyLink local network. 4-11

30 CenturyLink Tech Pub Chapter 4 CEMSS Call Control 5) Client application sends Parlay createcallleg() to CEMSS gateway to allow manipulation of the terminating call leg. 6) Client application sends Parlay eventreportreq() messages for Answer and Busy events on the terminating call leg to CEMSS gateway. 7) Client application sends Parlay routereq() message with a NULL target address to the CEMSS gateway. 8) Client application sends Parlay continueprocessing() message to the CEMSS gateway. 9) CEMSS gateway passes Parlay messages to SCP. 10) SCP responds to CEMSS gateway with a message indicating that the call was ended due to restrictions on the subscriber s line. 11) CEMSS gateway sends Parlay callended(callrestricted) to client application Example: Originating Call Forwarded; No AIN Services In this flow example, an inbound call to the subscribed TN is forwarded by request of the service provider to another number. No AIN services are provisioned on the subscriber s line. Figure 4-9 Originating Call Forwarded by Application Server 1) SSP encounters Off-Hook Delay trigger; suspends call; sends query to SCP 2) SCP passes query to CEMSS gateway. 3) CEMSS gateway sends Parlay reportnotification() to client application. 4) Client application sends Parlay createcallleg() to CEMSS gateway to allow manipulation of the terminating call leg. 5) Client application sends Parlay routereq() message with a new target address to the CEMSS gateway. 6) Client application sends Parlay continueprocessing() message to the CEMSS gateway. 7) CEMSS gateway passes Parlay messages to SCP. 8) SCP sends AnalyzeRoute response to SSP with new target address. 9) SSP forwards the call and sends a Close message to the SCP. 10) SCP passes CallEnded event to CEMSS gateway. 11) CEMSS gateway sends Parlay callended(noanswer) to client application. Note that the call may be ringing another telephone number at this point, but CEMSS does not provide the status of the call once it is forwarded. 4-12

31 CenturyLink Tech Pub Chapter 4 CEMSS Call Control 4.5 Call Event and Control Interface Service Flow Listed below is the service flow for establishment of a client to the CEMSS call event and control interface: 1) Client establishes dedicated facilities and IP transport into CenturyLink SPA 2) CenturyLink establishes physical IP connectivity with wholesale customer 3) CenturyLink provisions wholesale customer in CEMSS gateway for MPCC service 4) Customer requests and CenturyLink activates customer specific TNs in AIN network with CEMSS Subscriber provisioning. 5) Customer application connects to Parlay framework and is authenticated via CHAP (Challenge Handshake Authentication Protocol) 6) Customer application digitally signs Service Level Agreement (SLA) with Parlay Framework 7) Parlay framework enables Parlay service for customer application 8) Customer application accesses service via Parlay service API 9) Authentication for Parlay application based on Parlay Framework 10) Authentication for SPUG application based on source IP address and trusted IP transport 11) Option to add UID/Password mechanism 4.6 Interface Security In general the steps required for the client to connect to the Parlay Framework and access the MPCC service: Initialize the ORB Connect to the CEMSS Gateway CORBA Naming Service Retrieve the IpInitial object from the Naming Service Call the intiateauthenticationwithversion method on the IpInitial object to start the authentication process Request the IpAccess object To initiate authentication, the client will call the intiateauthenticationwithversion method on the IpIntitial object. It is here that the client applications must use the CenturyLink supplied Client ID that is configured on the CEMSS Gateway. The authentication type specified must be P_OSA_AUTHENTICATION. The result from invoking this method will be an IpAPILevelAuthentication object. The IpAPILevelAuthentication object is used to specify the authentication mechanism to use. The selectauthenticationmechanism method is invoked on the IpAPILevelAuthentication object. When invoking this method, specify the use of P_OSA_HMAC_MD5_96 as the message authentication method to use. Immediately after specifying the authentication mechanism, the Client application will attempt to authenticate the Framework by calling the IpClientAPILevelAuthentication.challenge method. The challenge method passes a byte array as a parameter which contains the CHAP challenge message. The Framework should then generate a corresponding CHAP response message and return it as a byte array from the challenge method. The CHAP secret is configured in the CenturyLink CEMSS Gateway Client ID profile. CenturyLink will provide the client organization with the CHAP secret. 4-13