Parlay / OSA API
Http://www.chinatelecom.com.cn December 19, 2002, China Telecom Group Beijing Institute of Technology Feng Jianqiang
The next generation of business is to move business applications to the network operation range, open markets to independent business vendors, and provide IP and mobile support for voice, multimedia and data. This requires a standard, open application programming interface (API) to develop this standard. There are four reasons for this standard: For network operators, as new value-added services continue to develop, they can guarantee the network Under the premise of security and integrity, improve the network's utilization, so that the original investment can play a greater value; for business operators, some basic business features that can be accessed to some extent, they A variety of new application services can be developed in a shorter time, and there is a low risk to develop a new application business, which will quickly obtain a larger income; for software developers, the underlying is shielded due to standard application programming interfaces. Heterogeneous networks and complex signaling interactions, so software developers do not need to master too many communication background knowledge, you can write applications running on different communication network platforms; and end users can enjoy a larger range More convenient communication services. I. Parlay and its architecture in March 1998, the Parlay Working Group was jointly established by BT, Ulticom, Microsoft, Nortel and Seimens, mainly studied network interface norms for internal resources to access the security network to broaden the network. Intelligent scope, promoting third-party business suppliers or telecom operators based on this interface platform, using different technologies to develop communications products on wireless, Internet or public exchange online, providing communication services, and quickly customizing personalization for specific user groups The business is supplemented as a universal business. The Parlay Working Group focuses on developing API specifications, but does not include how to implement API, based on API-based applications, underlying network software, physical components, and physical interfaces. To this end, the Parlay organization actively encourages telecommunications and IT industry as a whole to participate in the design and implementation of the API. Parlay initially published in December 1998, its writing format is a UML language. It mainly defines the interfaces of the application access business, such as call control services, multi-party call services, multimedia services, message services, conference services, and other basic business features, and the frame interface includes authentication, authentication, business search, event notification and other interfaces. They guarantee the opening, safe, flexible and easy management of business interfaces. At the same time, a "reliable call forward" demo service is launched, indicating how a company provides users with the user's intervention using the core capabilities provided by the PARLAY API specification. The first phase of the PARLAY Working Group focuses on fixed network call control, message processing, and security management. In May 1999, 6 members joined the Parlay Working Group, they were AT & T, CEGETEL, CICSO, Ericsson, IBM, and Lucent, there were 11 members. The second phase of the Parlay Working Group is focused on the core API capabilities, especially for wireless and IP services. API 2.0 published in January 2000. PARLAY API 2.0 adds the company's administrative function (such as business booking) interface to its internal users, such as business booking, allowing third parties to provide basic business functions, and add mobile service interface and set QoS Level connectivity service interface. Only 6 months, 2.1 publication, October 2000 and March 2001, 2.1 revisions were published, and the revised version did not change, in fact, mainly modified the previous version of the writing error. The Targets of the Parlay Working Group 3 include general billing, business and network management, mobile e-commerce and virtual home environment (VHE). From April 2000, the Parlay Working Group encouraged new members to join, there is a considerable impact.
In February 2001, the Parlay Working Group members list from 24 members and 13 new members. At this point, the version is 3.0. PARLAY 1.2 and Parlay 2.1 are most representative. These two versions have a large difference in call control. PARLAY 1.2 only defines a call control management service interface to manage all types of calls; in addition to the INAP protocol specially defined an extension interface to adapt to the needs of the smart network; call the call control interface in PARLAY 2.1; A unified call control model extends to multiple call control models for different types of traffic, including basic call control, multi-party call control, multimedia call control, and conference call control, and the call model has inheritance relationship, the latter model They are all extensions on the basis of the previous model, providing deeper control functions. PARLAY 3.0 specifies the interface representation, and the terminal capability is added to the version 2 (the parameters of the location and attributes of the terminal used by the user), the data session (data interaction service on the IP network), based on the content, billing, strategy Managing Policy Management: Allows the management of network structures and transmission, application protocols in the policy domain; PARLAY also organizes the PRESENT & Available in the first quarter of 2002 (Present & Available). PAM is a new service that provides information and management about the attendance information and management of users. Parlay API3.1 fixes the errors and omissions in 3.0, except for the original UML to IDL mapping, and map 3.0 from the UML language to the XML language to facilitate business vendors to develop communications services on the Internet. Given the widespread application of PaylayApi and its significant impact in the industry, many famous standardized organizations and industry organizations have announced that they have adopted or will be used in the standard or specification in their own formulation or will be used in the Parlay API specification. These organizations mainly include ITU-T, ETSI, IEEE, IETF, 3GPP, OMG, TINA-C, SOFTSWITCH forum, Jain, etc. At present, the Parlay Working Group, ETSI and 3GPP have been united to develop the Parlay protocol. The following figure shows the correspondence between the Parlay version released by three standard organizations. The Parlay API version is more influential version of 2.1 and 3.0, and the version after the Parlay Standardization has only rear compatibility with version 3.0 with backward compatibility. Parlay organization launched Parlay4.0 in the second quarter of 2002, mapping the PARLAY specification and the current underlying communication network protocol, that is, starting to define resource interfaces, such as the SIP. In addition, the PARLAY specification will also map to WSDL (network service description language) to create a PARLAY web server. At the same time, Parlay organization also realized that due to the huge and complexity of the Parlay specification, the Parlay is more difficult. At present, 80% of the Parlay business only uses a 20% Parlay API, so it starts to define Parlay X, parlay X by putting the original The Parlay API is combined and encapsulated, and each special PARLAY business component template is established on top of the Parlay API, such as PARLAY X, company server Parlay X, PDA PARLAY X, Each PARLAY X components use only less APIs to accommodate different business needs, so that third-party development services is more convenient. The application architecture constructed by PARLAY is as follows: where the Parlay client is the application server, provided by a third-party business vendor or network operator to develop various services to be used to end users.
The Parlay server is also known as Parlay Gateway, which provides support for the PARLAY client, so that the service of the Parlay client can be controlled, safe entry into each communication network. At present, the PARLAY server is provided by various network operators, but because Parlay has not specified the resource interface of each underlying network, the Parlay server and the communication network can only set the internal communication protocol by the network operator itself, if used Jain, INAP, SIP maps the API to a low-level network. The Parlay client is to access the Parlay server by calling the Parlay API, which generally communicates with distributed object technology such as CORBA. Second, PARLAY APIs are mainly composed of two parts: Server Interface: This type of application programming interface can access a series of basic business functions provided by the Parlay server, such as establishing or releasing routes, interacting with the user, sending user messages. Setting the QoS level, etc. Business vendors can call them to achieve different services in accordance with different business logic. At present, Parlay APIs include: · Call Control: Defines the ability to establish basic calls, multi-party calls to the establishment of multimedia conferences; User Interaction: Can obtain the information of the end user, play a notification, interact with the user; General User Interactive Interface and Call User Interactive Interface · Terminal Capability: Gets the location and attribute parameters of the user terminal; User Location / Status: obtains the user's network representation, location, and status, etc. Have a user position interface, user location Camel interface, user Location emergency interface and user status interface. · DATA session: Control data interaction; GENERIC Message: Access mailbox; has a mailbox interface, folder interface, and message interface. • Connectivity Management: Provides QoS guarantee; • Content based Charge: According to user data traffic or application bill; · Presence and Availability Management: In the seat and availability management. 2, framework interface: They provide required security and management support for business interfaces. Mainly include the following interface: trust and safety management - initial - certification · Business Access · Business Discovery · Business Registration · Event Notification · Integrity Management - Load Management - Fault Management - Heartbeat Management - OAM Management Framework Interface can be divided into application servers Interface between the interface between the frame, the interface between the network service capability server and the frame, the interface between business operators and the framework. I, the basic mechanism of the interface between the application and the framework is: · Authentication: Before being allowed to use any OSA interface, the application must pass authentication. · Authorization: After authentication, the application is authorized to access the determined business. · Framework and network service capability features: After the authentication is successful, the application can obtain the available framework interface and use the open interface to obtain information of the authorized network service capability. After the authentication is successful, you can use the lookup interface at any time. · Establishment of business agreement: Any business agreement must be established before any application interacts with network business capabilities. The business protocol contains offline parts and online parts. Application requires a business protocol for online part before using any network service capability. · Access network service capability features: Framework access to business capabilities or service data by specific security levels, context, domain, etc. API methods. The basic mechanism between the II, the framework and the service capability server is: • Registration of network service capability features: SCFS provided by the service capability server can be registered on the framework.
The basic mechanism of interface between III, framework and business operators is: · Business ordering function: This function represents a contract between business operators and frameworks. In ordering to order commercial models, business operators represent business users, customer app representing business users, framework representative business. Third, Parlay can provide a third-party business to the following categories: · Communication business: such as clicking dial, VoIP, click Fax, Visual Phone, Conference Phone, etc., and the location related emergency call business, roadside assistant Business, etc. · Message business: such as unified messages, short messages, voicemail, E_mail, multimedia messages, chat, etc. · Information services: such as news, sports, tourism, finance, weather, yellow pages, tickets, etc. inquiry, custom, notice, etc., as well as unknown personnel tracking, find a friend. · Payment business: such as e-commerce, mobile banking, online payment, instant sale booking, charge browsing, etc. · Entertainment business: such as games, gambling, riddles, education, advertising, etc. Various types of services can be relatively independent, or organically combined, for example, if you check the information according to the appropriate information, if you can express (short messages, email), entertainment, as a variety of entertainment The message service is combined. 4. Call Control API Call Control Interface is divided into general call control, multi-party call control, multimedia call control, and conference call control interface. 1. General call control service is a subset of the entire call model. Call is limited to both parties and cannot control calls LEG. Since the general call control service cannot handle multimedia connections, it is impossible to control the media channel. General call control consists of two interfaces on the network, i.e. IPCallControlManager, and IPCall, and two interfaces on the corporate side, i.e., IPAppCallControlManager and IPAppCall. IpCallControlManager provides a way to manage calls. The CREATECALL () method of the interface can create a new call object (that is, an object of the IPCALL interface). It also provides a way to request a notification call event to a customer. For example, a client application can call an IPCallControlManager interface request to notify the client application to a calling event to a specified phone number or a range of phone numbers, if the call notification is not performed, the customer application request call notification is not allowed. Once the call notification request is called, you can change or delete the interface. The interface also provides a load control method implemented on a series of calls and the method of canceling the previously set load limit. The IPCall interface provides a way to route the call to the destination or monitor the status of the call. For example, the client application can call the interface method, request information related to the call (for example) when the call is completed. Using the IPCall interface, the client application can also request a monitoring call, that is, after the specified time length, the status report of the call is sent to the client application and the control is handed over to the application. This is useful in prepaid applications to prevent calls from continuing when the prepaid account is zero. The IPCall interface also provides an operation of setting up call billing. The other two interfaces provided by LPCall are requesting users to provide more DTMF input and billing recommendations, which inform users about call billing information (ie, the message is sent to it. Terminal, if the terminal has the ability to display this information). IPAppCallControlManager is a correspondence interface on the IpCallControlManager business side. This interface provides the method that is called when the calling event (by the IPCallControlManager interface request) arrives. It is also provided to accept the method of receiving the underlying network call notification status (can or cannot be included) and the notification information transmitted when the network encounters the call overload.
The interface also provides a method of indicating call termination in the network, and is called by the Parlay gateway when the network detects a call (application is interested). IPAppCall is an interface corresponding to the IPCall interface. This interface provides a method for processing a response and status report for call requests. For example, the iPAppCall interface is notified of the status of the route request: routing success and called acknowledgment, or is busy, etc. The iPAppCall interface accepts the status report for all requests set by ipCall. 2, multi-party call control In Multi-party call control services: IPMultipartyCallControlManager, IPAppMultipartyCallcaontrolManager, IPMultipartyCall, LPAppMultipartyCall, IpCallleg, LPAppCallleg. Interface IPMULTIPARTYCALLCONTROLMANAGER, LPAPPMULTIPARTYCALLCONTROLMANAGER and IPAPPMULTIPARTYCALL inherits all methods from general call control and does not introduce new methods, and the IPMultipartyCall interface is an extension of IPCall. It includes an operation of explicitly accessing calls LEG. Note that in a multi-party call, a call can contain two or more call LEGs. The interface also provides a method for establishing an IPCallleg interface object. The iPCallleg interface provides a method of route call LEG to specifying the specified destination and merged or separating the media associated with the entry / call. The method of sending the request information specified by the LEG to the application when the call LEG is terminated. Although the detailed LEG event report can be requested, the method of continuous monitoring of the LEG is not provided. In the future, several access functions are provided through the ipcallleg interface. For example, find the ID of the LEG to which the LEG belongs. Note that a call can have multiple LEGs, but an LEG can only be part of a call. The ipappcallleg interface is a correspondence interface on the IpCallleg interface enterprise side. It accepts the response of the request set by the IPCallleg interface. Interface LPMULTIPARTYCALL, inheritance from lpCall, new method is: · getCallleg (), this method requests the ID of call LEG objects associated with the call object. CREATECALLLEG (), this method requests to create a new call Leg object. CreateAndrouteCalllegReq (), this asynchronous operation request creates and selection of newly created calls. Interface LPAppMultipartyCall, inheritance from lPAppCall, new method is: · CREATEANDROUTECALLEGERR (), this asynchronous method indicates that the call routing to the destination request is unsuccessful. Interface LPCallleg, inherited from LPService, calling the LEG interface with address representatives and call-related logical calls LEG. · RouteReq (), this asynchronous method requests the party to call the LEG route to the part of the destination address. · EventReportReq (), this asynchronous method setting, clear or change the event standard for LEG object monitors. · Release (), this method requests to release the call LEG. If successful, the call LEG is deleted. · GetInforeq (), this asynchronous method request provides information related to calling LEG when appropriate. GetCall (), this method requests a call related to calling LEG. • attachmedia (), this method requests call LEG to connect to its call object. · DETACHMEDIA (), this method makes call LEG separated from its call. GetLastRedirectedAddress (), this method is used to query the last address to be turned. • ContinueProcessing (), this operation continues to call the LEG process.
This is called when the call LEG processing is interrupted because the event notification of the app is detected. · Setchargeplan (), setting the billing policy for the operator to define the call. The billing policy must be set before the call LEG route to the destination. This method can also be used to change the billing strategy of current calls. · SetAdviceOfcharge (), this method allows AOC information to be sent to terminals that can receive this information. SupervisReq (), application calls this method to monitor call LEG. · Deassign (), this method requests to re-specify the relationship between the application and call LEG and related objects. Interface LPAPPCallleg, inherited from LPinterface, the application call LEG interface is used to process responses and errors related to call LEG requests. · EventReportres (), this asynchronous method reports an event to be requested. · EventReporterr (), this asynchronous method indicates unsuccessful and reason for processing call LEG event reports. GetInfores (), this asynchronous method reports all the necessary information requested by the application. GetInfoerr (), this asynchronous method reports the source request error. · Routeerr (), this method reports a routing error. · Supervisres (), this asynchronous method reports the call LEG monitoring event to the application. · Superviseerr (), this asynchronous method reports call LEG monitoring errors. · Calllegended (), this method indicates that the LEG in the application network is over. 3, the multimedia call, to the following seven interfaces: IpMultiMediaCallControlManager, IpAppMultiMediaCallControlManager, IpMultiMediaCall, IpAppMultiMediaCall, IpMultiMediaCallLeg, IpAppMultiMediaCallLeg, IpMultiMediaChannel. Interface IPMultImediaCallControlManager inherits all methods provided by IPMultiPartyCallControlManager and expand its capabilities by providing two new methods. The media channel notification capability can be activated or deactivated by these methods. When the media channel notification is activated, two standard sets are included. Two standard sets must be implemented before the channel report is applied to the customer. First, multimedia calls must match the call criteria (ie, the destination call code must be within a certain range) and the media channel indication must match. The correspondence interface of the enterprise side ipappMultiMultiacallControlManager inherits all methods of the IPAppMultipartyCallControlManager interface, which introduces a new method, that is, media channel event notification methods. For multimedia calls on behalf of the network, use an object that implements the IPMultiMediaCall interface. The interface inherits the operation of the IPMultiPartyCall interface, introduces a new method to set a call-recognized data traffic (in microsecond measurement). When a given data amount expires, the corporate side is called the correspondence interface of IPAppMultIMediaCall to receive the event notification. Interface IPMultiMediaCallleg Inherits all of IPCallleg, and customer application can monitor and affect media channels by calling this interface. Three new operations are provided. First, you can monitor the opening and closing media channels, there are two monitoring types: general monitoring (satisfying any media type) or specified monitoring (notifications only when using the specified media type). If the monitor is set to interrupt mode, the application must explicitly allow access to open this media channel. The IPMULTIMEDIACALLLEG interface provides a corresponding method. The latest method introduced by IPMultIMediaCallLegleg enters all methods of all open media channels related to this call LEG.
(Note that a call LEG can be associated with several media channels). The iPappMultiMediaCallleg interface must be implemented on the enterprise side, which inherits the method of parent IPAppCallleg. Introducing a new operation, that is, media channel notification, calls by PARLAY gateway when the detection criteria that meets or closes the request. The last interface included in the multimedia call control is an IPMultiChannel interface, which is characterized by a one-way data stream contacting the call LEG. Only one method is available, that is, close the channel. 4. The meeting call control is the highest level of call control defined by the PARLAY API. The concept of conference call control services is used to improve multimedia call control services. The difference between the meeting and multimedia, and multi-party calls is that the conference resource can be retained in advance. The sub-conference is a subset of all LEGS in the conference, only LEGS in the same sub-meeting to communicate with each other (ie, only the LEGS between the same sub-conference only has a media path). There are two conferences: there is no preferential retention of conference resources and the preferences for meeting resources. In the conference call control service, six interfaces are most important, these interfaces are as follows: IPConfCallControlManager is the interface that must be used to generate conferences and resource management. It inherits the parent class LPMULTIMEDIACALLCONTROLMANAGER, but it also adds important new members. This interface provides a new meeting to detect if there is enough resource available to reserve resources and release the allocated resources for the conference. When establishing a new meeting, the application must indicate the number of sub-confections you want. It is at least 1, and the number of conference participants and the expected meeting of conference are also provided when establishing meetings, and the network will try to assign the necessary resources in the specified time. If the resource is available, the meeting begins. The resource is no longer guaranteed when the meeting is reserved for resources, but the meeting can continue. Note If the resource needs to meet additional requests, the meeting can be ended or rejected by the network. The IPConfCallControlManager interface also provides methods that detect if there is enough resource available at a given expected time. When this method is called, you must enter the specified start and end dates and time (on behalf of the search interval), and optional expectant participants and the meeting cycle. The search algorithm returns the actual resources, the time of the meeting, and the start time. Note that this method still does not reserve resources. In order to retain resources, the IPConfCallControlManager interface provides another method. As the parameters of this method, the date and time of the start must be developed, and the number of participants and the expected time is expected. As well as the strategy designated by the meeting, whether the content is allowed to allow the entity to join. The last method provided by the IPConfCallControlManager interface is designed to release the previously retained resources. This method effectively cancels resource reservations. IPAPPConfCallControlManager provides a method that Parlay gateway calls when the conference is established by the previous appointment. It inherits the IPAppMultIMediacACallManager interface, except the methods described above, no new methods are introduced. The IPConfCall interface inherits the IPMultiMediaCall interface to manage sub-conferencing, but can also hide the sub-conference to unwanted applications without knowing multiple sub-conferenies. In addition to the inheritance method, the interface provides a new way to request a list of all sub-conferences in the conference to create new sub-conferencing and request monitoring events. IPAppConfCall is a corporate side interface relative to the IPConfCall interface. The iPappconfCall interface receives the response of the request called through the IPConfCall interface. It inherits the method of parent interface ipappmultiMediacACALL and provides two new methods.
