WO2007107074A1 - A method, apparatus and system for communication service processing - Google Patents

Abstract

A communication service processing method, the apparatus and the system thereof, which simplifies the service logical processing of the communication device. The said method includes: the communication device(such as SIP UA) acquires the user's profile from other network elements(201), and detects the operation event carried out by the user according to the profile, if the operation event in the profile is detected, implements the service logical processing according to the corresponding actions preset in the profile(202). The said apparatus includes: an acquiring unit, a detecting unit and a service processing unit. The said system includes the configuration delivering server and the communication device. The configuration delivering server renews the current user's profile according to the change of the service circumstance, and notifies the corresponding SIP UA of the new profile or the change part of the profile. The profile uses XML language to describe the events and the corresponding actions, thus the expandability of the service improves.

Description

 Communication service processing method, device and system The present application claims to be submitted to the Chinese Patent Office on March 17, 2006, April 26, 2006, May 19, 2006, and the application numbers are 200610067558.7, 200610077575.9, 200610084351.0, respectively. The priority of the Chinese Patent Application for "Communication Equipment Service Control Method and System" is incorporated herein by reference.

The present invention relates to the field of communications technologies, and in particular, to a communication service processing method, apparatus, and system. BACKGROUND With the development of traditional communication networks, the Internet, and mobile communication networks, integration of networks is an inevitable trend. The Next Generation Network ("NGN") is an Internet Protocol (Iirtemet Protocol). The IP") packet-switched network is the core network, and the control and bearer are separated. Various access technologies coexist, and a new generation network of existing networks is integrated to meet the needs of future broadband multimedia communications. A gateway device having a cross-network call connection capability between a packet switched network and a circuit switched-based legacy communication network, such as a relay gateway having a Media Gateway Control Function (MGGF), with an access gateway The access gateway of the Access Gateway Control Function (AGCF) is interoperable. International Telecommunication Union-Telecommunication Standardization Sector ("ITU-T") and the European Telecommunications Standards Institute (ETSI) currently use the third generation of partners The IP Multimedia Subsystem (IP Multimedia Subsystem, referred to as 'IMS) architecture defined by the Standards Organization (3GPP) is used as the core network of the NGN. As the packet technology continues to mature, session initiation is used. Session Initiation Protocol ("SIP") as one of the current technology trends in packet control signaling for packet switched networks. SIP is an NGN developed by the Internet Engineering Task Force (IETF). The important agreement in the middle is considered to be one of the core protocols of IMS, and 3GPP has also determined SIP is used as the third-generation mobile communication (The Third Generation, referred to as "3G,") all-IP stage multimedia domain session control protocol. As part of the IETF standard process, SIP is developed to help provide Internet access (Internet). Advanced telephone service, used to establish, change and terminate calls between IP network-based users. It is in the Simple Mail Transfer Protocol ("SMTP") and Hypertext Transfer Protocol (Hypertext Transfer Protocol). The tube is called 'ΉΤΤΡ') and is built on the basis of widely used protocols on the Internet.

With its advantages of simplicity, ease of expansion, and ease of implementation, SIP is increasingly favored by the industry. More and more client software and intelligent multimedia terminals supporting SIP protocol appear in the market, as well as servers and exchanges implemented by SIP. device. Specifically, there are client and server in SIP: a client is an application that establishes a connection with a server in order to send a request to a server; a server is an application that provides a service to a request sent by a client and returns a response. . Among them, SIP has four types of basic servers: User Agent ("UA") server, which contacts the user when receiving a SIP request, and returns a response on behalf of the user; the proxy server initiates a request on behalf of other clients, acting as both The server, in turn, acts as a client's media program, which can overwrite the contents of the original request message before forwarding the request; redirect the server, which receives the SIP request and maps the original address in the request to zero or more new addresses. Returned to the client; the registration server, which receives the client's registration request and completes the registration of the user's address. The user terminal program often needs to include a UA client and a UA server, and the proxy server, the redirect server, and the registration server are public network servers.

SIP messages are used for the establishment and modification of session connections. The format is similar to that of the HTTP protocol. It is divided into two types: request (REQUEST) and response (RESPONSE). Among them, the RESPONSE message has multiple codes indicating the specific response made by the session acceptor. There are six basic types of REQUEST messages: INVITE, ACK, CONNECT, BYC, CANCLE, OPTIONS, and REGISTER. In addition, the SIP protocol makers are also defining new types as needed. Specifically, INVITE and ACK are used to establish a call, complete a three-way handshake, or to change the session attributes later; BYE is used to end the session; OPTIONS Used to query server capabilities; CANCEL In order to cancel a request that has been issued but has not ended in the end; REGISTER is used for the client to log in to the registration server to register the user's location and other messages. Although this new SIP user terminal will gradually replace the traditional terminal phone, it is also the future development trend of the packet switching network. However, in the process of building the packet switching network, the operator needs to gradually adopt the public switched telephone network in the traditional communication network ( The Public Switched Telephone Network ("PSTN") / Integrated Services Digital Network ("ISDN") performs network transformation to realize the smooth evolution of the existing PSTN/ISDN network to NGN. This inevitably requires the existing PSTN/ISDN core network to retain the terminal, user network interface, service experience and the like of the existing PSTN/ISDN network after being replaced by the packet switched network. The application scenario in which the packet switched network is applied to the transformation and replacement of the PSTN/ISDN core network is sometimes referred to as PSTN/ISDN Emulation (PSTN/ISDN Emulation). In the PSTN/ISDN Emulation Subsystem (PSTN/ISDN Emulation Subsystem, referred to as "PES"), an IMS-based network architecture is also adopted. Therefore, relevant standards have been established in the ITU-T and ETSI standards for the Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN) standards organization. The project conducts research work in this area. In the TISPAN draft standard ETSI TS 02030 V<1.2.7> (2005-12) "TISPAN Functional Architecture; PSTN/ISDN Emulation Subsystem; IMS-based functional architecture (TISPAN functional architecture; PES; IMS-based functional architecture)" The functional architecture of the IMS-based PES is defined. The functional architecture is shown in Figure 1. The functional entities such as AGCF and Media Gateway (MG) are used to implement the traditional PSTN terminal to IMS network access. Adaptation, at the same time, move the PSTN service logic control up to the application server (Application Server, referred to as "AS") of the IMS network. In the TISPAN draft standard ETSI TS 183 043 V<0.1.8> ( 2006-02 ) "TISPAN NGN IMS-based PSTN/ISDN Emulation Call Control Protocols Stage 3 (TISPAN NGN IMS-based PSTN/ISDN Emulation Call Control Protocol Phase 3) » Some specific process definitions for implementing PSTN simulation services based on IMS are also given. In the IMS-based PES defined by TISPAN, the business logic processing is performed by the AGCF. example For example, the AGCF requests a dial tone management file from the PES AS, where the indication includes a standard tone or a message indication tone, and when the AGCF receives the message indication event package, the message indication tone is set according to the dial tone management file. For example, the user registers the unconditional call forwarding service. After the registration is successful, the PES AS sends a NOTIFY message to the AGCF. The AGCF parses the event packet carried in the NOTIFY message, and then according to the dialing. The tone management file sets the special dial tone to the default dial tone that the user listens after picking up the phone; for example, after the AGCF receives the flash-hook signal of the user, it needs to analyze the current call state, specifically, these The states are: one party call state, a stable two-party call state, a stable two-party call state with a hold/waiter, and the like. Then, the corresponding playback dial tone, collection number, and transmission number are processed. In practical applications, the above solutions have the following problems: The business logic processing on the AGCF is complex and does not conform to the core idea of the development of IMS-based PES. The main reason for this situation is that the business logic processing on the AGCF is complicated according to the existing practical implementation. However, in the IMS-based PES, a core idea is to move the PSTN service logic control up to the PES AS. That is, the processing of the centralized AGCF and the centralized processing of the business on the PES AS, therefore, the current implementation does not meet the requirements of the core idea of the PES. For example, in a multi-party conference service, after receiving the user's cross-signal signal, if other users listen to the conference call voice notification, the business logic processing on the AGCF will be more complicated.

In addition, PSTN/ISDN Simulation Services (PSTN/ISDN Simulation Services) is also defined in TISPAN. It also uses the IMS architecture to provide SIP terminals with analog services with PSTN/ISDN supplementary service features. In fact, most of the Simulation simulations. The service and Emulation simulation services are similar, such as the calling number display/calling number display restriction service, in the above mentioned TISPAN standard draft ETSI TS 183 043 V<0.1.8> ( 2006-02 ) appendix, Execution of the service, such as the temporary reservation OIR service requires the PES AS to insert the Privacy header field in the invitation invite message from the AGCF, and to insert the anonymous keyword operation in the From header field. In the Simulation simulation service, there is also a similar source identifier display/source identifier display restriction service. The operation of the above PES AS is not available in the Simulation simulation service AS (refer to the TISPAN standard draft ETSI TS 183 007), which can be performed by SIP. The terminal completes itself. Obviously, for the user experience, the two services are the same, but according to the current TISPAN current In the current mode, although the service is based on the IMS network, the network still needs to deploy the AS of the two types of services, resulting in waste of investment.

Summary of the invention

 The technical problem to be solved by the embodiments of the present invention is to provide a communication service processing method, device and system, which make the service logic processing of the communication device simple.

 Another technical problem solved by the embodiments of the present invention is that the network can be reused to provide an application server that provides analog service control, thereby saving investment.

 To solve the above technical problem, an embodiment of the present invention provides a communication service processing method, including the following steps:

 Obtain the user's configuration file, including the operation event;

 If the operational event is detected, the business logic processing is performed in accordance with the corresponding action in the configuration file.

 In addition, the embodiment of the present invention further provides a communication service processing apparatus, including:

 An acquiring unit, configured to acquire a configuration file of the user, where the configuration file includes an operation event, and a detecting unit, connected to the acquiring unit, configured to detect the configuration file in real time, and if detected, send the detection result;

 The service processing unit is connected to the detecting unit, configured to receive the detection result, and perform business logic processing according to a corresponding action in the preset setting of the detection result. Further, the embodiment of the present invention further provides a communication service processing system, including configuring a delivery server and a communication device; the configuration delivery server, configured to provide a configuration file of the user, including an operation event; And configured to acquire a configuration file of the user from the configuration delivery server, and if the operation event is detected, perform business logic processing according to a corresponding action in the configuration file. In the embodiment of the present invention, the user's configuration file is obtained, and the operation event performed by the user is detected according to the configuration file. If an operation event in the configuration file is detected, the service logic processing is performed according to the corresponding action in the preset configuration file. . This method of performing the corresponding action by matching the operation events in the configuration file greatly reduces the processing complexity of the SIP UA.

DRAWINGS 1 is a schematic diagram of a IMS-based PES functional architecture in the prior art;

 2 is a flowchart of a communication service processing method according to an embodiment of the present invention;

 3 is a flowchart of a communication device service control method according to a first embodiment of the present invention;

 4 is a flowchart of a communication device service control method according to a second embodiment of the present invention;

 FIG. 5 is a schematic structural diagram of a communication service processing apparatus according to an embodiment of the present invention; FIG.

 FIG. 6 is a schematic structural diagram of a communication service processing system according to an embodiment of the present invention.

detailed description

 The present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Referring to FIG. 2, it is a flowchart of a method for processing a communication service according to an embodiment of the present invention; the method includes:

 Step S11: Obtain a configuration file of the user, where the configuration file includes an operation event;

 Step S12: If the operation event is detected, the business logic processing is executed according to the corresponding action in the configuration file.

The embodiment of the present invention provides a logical description of possible operations of the user and possible network side actions caused by the operations according to the user's current business application environment by the configuration delivery server, and uses this logical description as a configuration. The file is passed to the communication device. After detecting the operation event of the user, the communication device uses the configuration file to perform matching, obtains the corresponding action described in the configuration file, and directly performs the action. The communication device may be an access device with an access gateway control function AGCF or a SIP IAD as a SIP UA, but is not limited thereto, and may be other devices. The configuration delivery server may be a PES AS. Wait. The SIP UA is taken as an example to illustrate that the SIP UA receives at least one of the following events from the user: an off-hook event, a flash event, an on-hook event, or a dial-up event. In addition, a timeout event may occur, that is, when the network side waits for the user's next operation event after the user completes an operation event, if the user does not perform the next operation within the specified time, the network side generates a timeout event, for example, After the user picks up the phone, the network side will wait for the user to dial and start a timer (such as a 10-second timer). If no operation event is received from the user within the time limit of the timer, the network side will generate a timeout event. And start timeout processing; or after the user calls into a stable state (if the call has been established), the network needs to periodically manage the user in this state, then the network side will also A timeout event is generated. For example, in the state of the user's call, the network periodically sends a charging signal to the user (for example, every 3 minutes). As a protection for the session, the timeout event triggered by the timer and its processing are in each operation event from the user and its corresponding processing action. Therefore, the timer setting mainly sets the timer duration and timeout processing action. The timeout processing action may be that the SIP UA sends an indication to the user, the SIP UA sends a message to the network side, and the SIP UA sets its own timer. The timer settings can come from the default settings of the SIP UA or from the configuration file. Obviously, the operational events from the user are limited. After the operation event performed by the user, the action that the SIP UA may perform is also fixed according to the current service application environment of the user: For the operation event of the user, the SIP UA sends an instruction to the user (you may not issue any indication, or Simultaneously issuing multiple indications, such as listening indication, reverse polarity indication, billing signal indication, display indication, etc.; SIP UA sends a message to the network side (may not send any message, but also can send multiple messages at the same time) ; SIP UA sets its own timer. Specifically, the actions performed by the SIP UA to receive an operation event from the user are as follows. The processing item corresponding to the off-hook event includes at least one of the following: a reverse polarity processing item, a billing processing item, a signal tone or a voice notification processing item, a hotline number, or an immediate hotline number processing item. The action corresponding to the reverse polarity processing item is that the SIP UA sends a reverse polarity signal to the user; the action of the charging processing item ^ is that the SIP UA sends a charging signal to the user, such as a 16K Hz pulse signal and a reverse polarity pulse signal. The action corresponding to the signal tone or the voice notification processing item is that the SIP UA sends a signal tone or a voice notification to the user, or the SIP UA initiates a call to the designated sound resource; the action corresponding to the hotline number or the immediate hotline number processing item is initiated by the SIP UA. The call, for example, sends a SIP INVITE message. The processing item corresponding to the flashing event also includes a signal tone or a voice notification processing item, and further includes a hold processing item, a recovery processing item, and the like, or any combination thereof. The corresponding action is that the SIP UA sends a Session Description Protocol (SDP) to the user, and sends an SDP to the peer to maintain the sending action, for example, sending a SIP re-INVITE message. The action corresponding to the recovery processing item is that the SIP UA sends an SDP recovery action to the user, or sends an SDP recovery action to the peer end. Similarly, for example, sending a SIP UPDATE message or SIP re-INVITE message. The processing items corresponding to the on-hook event include: a release processing item, a transfer processing item, or any combination thereof. The action corresponding to the release processing item is a SIP UA release call, for example, sending a BYE message; the action corresponding to the transfer processing item is that the SIP UA transfers two calls related to the user into one call, for example, sending a SIP REFER ( Reference News. The configuration items corresponding to the dialing event include: Dialing paradigm processing items. The processing item is further composed of a signal tone or a voice notification processing item, a number rule configuration item, and the like. The action corresponding to the number rule configuration item is a call action initiated by the SIP UA to collect the number dialed by the user. The action compares the special bead, and the number of the number dialed by the user can be collected, and the number is transmitted to the PES AS through the initiated call action, and the PES AS performs the corresponding service processing according to the number, or can be directly used by the SIP UA. The dialed number is processed accordingly. The service includes an outgoing service, a supplementary service activation, a supplementary service data operation, and the like. If the dialed number indicates a supplementary service activation or supplementary service data operation, the action corresponding to the number rule configuration item includes a request action (such as sending a SIP SUBSCRIBE message), a data operation action (such as sending an HTTP/XCAP message), a release action, Keep the action, resume the action, etc.

 Therefore, it is feasible to generate a configuration file according to the user's operation event and the corresponding processing action. After a lot of experimental summarization and verification, the present invention presents an XML Schema file that conforms to the above description. The XML Schema file can be used to define the structure of the configuration file and constrain the contents of the configuration file. The contents of the XML Schema file are as follows:

<?xml version- ¹ 1.0" encoding= ^1, UTF-8"?>

 <xs:schema xmlns- 'urn-.ietfiparamstxmliprofile" xmlns:xs="http://www.w3.org/2001 X LSchema"

targetNamespace="urn:ietf:params:xml:profiIe" elementFormDefaulfqualified" attributeFormDefault="unqualified">

 <xs: element name="profile">

 <xs:complexType>

 <xs:sequence>

 <xs: element rei=="offhook" minOccurs="0"/>

<xs:element ref= ^M hooking"minOccurs="0"/>

 <xs:element ref="dial" mmOccurs- '0"/>

 <xs:element ref="onhook" minOccurs="0"/>

<xs: element name="timer"type="tTimer"minOccurs="0'7>

 .

. 〉

Baurit Axs:ue>

Namen

<xs: attribute name="requestURI"type-"xs:anyURI"use="optionaI"/><xs: attribute

 </xs:complexType>

</xs:element>

<xs:element name= ^,, to-user">

 <xs:complexType>

 <xs:sequence>

<xs:element ref="pulse-info"minOccurs="0"/><xs: element name="FSKbody"type="xs:string"minOccurs="0"/><xs: element name="Tonetype"Type="xs:string" minOccurs ^=l, 0'7></xs:sequence>

<xs: attribute name="needed"type="xs:boolean" use- 'required"/><xs: attribute

 <xs:simpleType>

 <xs:restriction base="xs:string">

 <xs: enumeration value="tone'7>

<xs: enumeration value ^=,, FSK"/>

 <xs:enumeration value- 'xal-Ias"/>

 <xs: enumeration value="pulse'7>

 </xs:restriction>

 </xs:simpleType>

 </xs:attribute>

 <xs: attribute name="timelengh" type="xs:integer" use="optional > </xs:complexType>

</xs:element>

 <xs:complexType name="tTimer">

 <xs:sequence>

<xs:element name="timerlength"type="xs:integer"minOccurs="0'7><xs: element ref="timeoutaction" minOccurs= ⁿ 0"/> </xs:sequence>

<xs:attribute name="startup" type ^=,, xs:boolean"use="required"/>

</xs:complexType>

<xs:element name="dial-pattern">

 <xs:complexType>

 <xs:sequence>

 <xs:element name- 'flush" minOccurs="0">

 <xs:cornplexType>

 <xs:simpleContent>

 <xs: extension base- 'xs:string" >

 </xs:simpleContent>

 </xs:complexType>

 </xs:element>

 <xs: element name="regex" maxOccurs="unbounded">

<xs:complexType mixed= ^,, true">

 <xs:choice>

 <xs:element name="pre" minOccurs="0">

 <xs: complexType>

 <xs:simpleContent>

 <xs: extension base="xs:string > </xs:simpleContent>

 </xs: complexType>

 </xs:element

 </xs:choice>

 <xs: attribute name="cleanup" type="xs:boolean" use="optional'V> <xs: attribute name="method" use="optional">

 <xs:simpleType>

<xs:restriction base="xs:string"> <xs:enumeration value="invite'7>

 <xs:enumeration value~"infomation"/>

 </xs:restriction>

 </xs:simpleType>

 </xs:attribute>

 <xs: attribute name="tone" type="xs:string" use="optiona '/>

<xs:attribute name- 'newRequestURI" type- 'xs:anyURI"use="optionar7><xs:attribute name= ^: "tag"type="xs:string"use="optional"/>

<xs: attribute

 </xs:complexType>

 </xs:element>

 </xs:sequence>

 <xs: attribute name="persist" use="optional">

 <xs:simpIeType>

 <xs:restriction base="xs:string">

 <xs:enumeration value="one-shot"/>

 <xs:enumeration value="persist"/>

<xs:enumeration value="single-notify ^, 7>

 </xs:restriction>

 </xs:simpleType>

 </xs:attribute>

 <xs:attribute name^" interdigittimer" type="xs:integer" use="optiona 7>

<xs: attribute

 <xs: attribute name^'^xtradigittimer" type="xs:integer" use="optionar7>

<xs: attribute

<xs:attribute name= ^M longrepeat"type="xs:boolean"use="optional"/>

 <xs:attribute name="nopartial" t pe="xs:boolean" use="optional"/>

<xs:attribute name= ^, enterkey"type="xs:string ⁿ use="optional"/>

</xs:complexType>

〇7〇maxv- <xs:element name="Pulse-repetition-intervar'type="xs:integer'7>

<xs:element name- ' AX-PCCr ¹ type="xs: integer"/>

 <xs: element name="REPX" type="xs:integer'V>

<xs: element

 <xs: element name="PCN" type="xs:integer"/>

 <xs: element name="CI" type="xs:integer"/>

 <xs:element name- 'PD" type="xs:integer'7>

 </xs:sequence>

 </xs:complexType>

 </xs:element>

</xs: Schema> In order to facilitate the understanding of those skilled in the art, the present invention will be described below in conjunction with specific embodiments. Referring to FIG. 3, it is a flowchart of a method for processing a communication service according to a first embodiment of the present invention. The communication device uses a SIP UA as an example, and the user is a traditional terminal user. In step 301, after the user registers, the SIP UA sends a SIP SUBSCRIBE message to the configuration delivery server to request a configuration file of the current business environment of the user, including an operation event and a corresponding action. In step 302, the delivery server is configured to return the confirmation information of the request, and the configuration file of the user is generated according to the subscription data of the user and the current business application environment. In this configuration file, the SIP UA processes the network side processing action of the user's off-hook, flashing, dialing, and on-hook operations in the current service application environment of the user. Among them, the off-hook action is to send a dial tone to the user, according to the given dialing paradigm

In step 303, the configuration delivery server carries the user profile through a NOTIFY message and sends the message to the SIP UA. In step 304, the SIP UA returns an acknowledgement message that the NOTIFY message was received. In step 305, the user picks up the phone and the off-hook event is reported to the SIP UA. In step 306, the off-air event of the user detected by the SIP UA is based on an off-hook event. A configuration file is provided, and a dial tone action is played to the user according to the matching result. This method of performing corresponding actions by matching operational events in the configuration file greatly reduces the processing complexity of the SIP UA. In step 307, after the user hears the dial tone, dialing can be performed. The dialing event is also reported to the SIP UA through the terminal. In step 308, the SIP UA receives the number according to the given dialing paradigm according to the configuration file. When the user dials the dialing paradigm completely, the SIP UA performs the matching according to the dialing event after the dialing paradigm described in the configuration file is completely matched. In step 309, the SIP UA sends a message to the network side according to the indication of the configuration file, including the message type and the message destination address, for example, the message type is SEP INVITE, the message destination address is the hotline AS address, and the SIP UA sends the message to the hotline AS. Register the hotline's SIP INVITE message. In step 310, the PES AS returns a response message to the SIP UA that the registration hotline was successful. Thereafter, if the user's current business application environment changes, the configuration delivery server will generate a new configuration file. In step 311, the delivery server is configured to send a NOTIFY message of the event change to the SIP UA according to the SIP UA request for the user profile, and pass the current user's configuration file to the SIP UA through the message. For example, in the new configuration file, the current SIP UA processing user off-hook event is performed to send a dial tone to the user, and a 5-second timer is started. If the user does not dial the time, the user is stopped. Tone, and send a SIP INVITE message to the registered hotline number. For example, the registered hotline number is 86-10-88886666. In step 312, the SIP UA returns a confirmation message to the received change notification. In step 313, the user performs an off-hook operation again, and the operation event is also reported to the SIP UA. In step 314, the SIP UA performs matching of the operation events according to the updated configuration file, and according to the matching result, plays a dial tone to the user and starts a timer with a duration of 5 seconds. In step 315, if the timer has expired and the user still has not dialed, according to the configuration file, the SIP UA automatically stops sending the tone to the user, and the hotline service is enabled, and the hotline number registered to the user, for example, the registered 86-10. -88886666 to call. In the above embodiment, the method for the SIP UA to obtain the configuration file from the configuration server is that the SIP UA requests the configuration from the configuration delivery server, and the configuration delivery server carries the configuration file to the SIP UA in the event notification message (Notify). In fact, the configuration delivery server can actively notify the SIP UA of the configuration file, such as when the user service application environment changes and causes its configuration file to change, the configuration delivery server actively sends a SIP PUBLISH release message, or sends a SIP INPO message to the SIP UA, and Carrying the user's configuration file in the message; if the configuration delivery server is located in the session signaling route, the configuration delivery server may carry the user's configuration file, such as the 183 response code message, in the SIP response message to the SIP UA. , 200 response code messages, etc., the configuration delivery server can also use this way to refresh the user's configuration file to the SIP UA; for example, the SIP UA can also obtain the configuration file from the configuration delivery server through an HTTP interface or even a custom interface. Through these interfaces, the SIP UA can request a configuration file from the configuration delivery server, and the configuration delivery server can also actively notify the SIP UA of the configuration file. These methods are equally applicable to other embodiments of the present invention in which the SIP UA obtains a configuration file from a configuration delivery server. In addition, the SIP UA can also configure a batch of users as a group collection to configure the delivery server to avoid multiple requests to the configuration delivery server, which can share the same configuration file. Referring to FIG. 4, which is a flowchart of a method for processing a communication service according to a second embodiment of the present invention, as shown in FIG. 4, in step 401, the user has a message indication, and therefore, the current service application environment of the user changes, and the configuration is delivered. The server will update the current user's profile. According to the request of the configuration file of the SIP UA, the delivery server sends a NOTIFY message to the SIP UA, and carries a part of the configuration file, for example, in the current service application environment, the SIP corresponding to the off-hook event of the user. The UA action is to send a message indicating tone to the user. The configuration of the SIP UA is simplified by the configuration delivery server updating the current user profile according to changes in the business environment, and notifying the SIP UA new profile requesting the profile or only notifying the changed portion of the profile. And can adapt to changes in the business environment. In step 402, the SIP UA returns an acknowledgment message to the configuration delivery server that the OTIFY message was received. In step 403, the user picks up the phone and the off-hook event is reported to the SIP UA. In step 404, the SIP UA matches the configuration file, and directly sends a message indicating tone to the user according to the processing description of the off-hook event in the configuration file. The communication service processing method of the foregoing embodiment is applied to the PES, where the SIP UA can send a message to the network side through SIP or HTTP, and the message sent to the network side through the SIP includes a SIP INVITE message, a SIP REFER message, a SIP SUBSCRIBE message, and a SIP. UPDATE message, etc.

 FIG. 5 is a schematic structural diagram of a communication service processing apparatus according to an embodiment of the present invention. The apparatus includes: an obtaining unit 51, a detecting unit 52, and a service processing unit 53. The obtaining unit 52 is configured to acquire a configuration file of the user, where the configuration file includes an operation event, and the detecting unit 52 is connected to the obtaining unit 51, configured to detect the configuration file in real time, and send the detected configuration file. The service processing unit 53 is connected to the detecting unit 53 for receiving the detection result, and performing the business logic processing according to the corresponding action in the setting of the detection result in advance.

 The functions and functions of the various units in the device are described in detail in the above steps, and will not be described again. Referring to FIG. 6, FIG. 6 is a schematic structural diagram of a communication service processing system according to an embodiment of the present invention. As shown in FIG. 6, the method includes: a legacy terminal (ie, a user) 61, a configuration delivery server 63, and a communication device. The SIP User Agent 62 (SIP UA) is taken as an example, but is not limited thereto. The legacy terminal 61 is connected to the SIP user agent 62 via interface E1, and the SIP user agent 62 is connected to the configuration delivery server 63 via interface E2. The configuration delivery server 63 is configured to provide a configuration file of the user, where the configuration file includes an operation event, and the communication device 62 is configured to acquire a configuration file of the user from the configuration delivery server, if the detection is detected. The operation event in the configuration file performs business logic processing according to a corresponding action in the configuration file preset. Specifically, the configuration delivery server 63 provides the user's profile, including operational events, based on the user's subscription data and the business application environment.

The SIP UA 62 is configured to acquire a configuration file of the user from the configuration delivery server 63, detect an operation event performed by the user, and if an operation event in the configuration file is detected, perform business logic processing according to a corresponding action in the preset configuration file. According to the foregoing implementation method and system, the services implemented by the configuration file include: hotline service, user owed to pay off the hook to listen to the fee, after the user has a new message, pick up the phone to listen to the message indication tone, abbreviated dialing, group The user picks up the group and dials the group to listen to the secondary dial tone, the fork processing, and the like. For the immediate hotline service that the user subscribes to, for example, the hotline number is "abcd@home.com", the configuration file described in XML is:

 <?xml version="1.0" encoding="UTF-8"?>

 <profiIe xmlns="urn:ietf:params:xml:proflle" version- Ό" state="fuH">

 <offhook allow="true">

 <to-network needed="true" method^" invite" requestURI="abcd@home.com"/>

 <to-user needed="false'7>

 <timer startup="false"/>

 </offhook>

 <hooking allow="false'7>

<dial allow="false ^M />

 <onhook allow="false"/>

</profile> The configuration of this XML description is as follows: The SIP UA can only handle the user's off-hook operation before the user picks up the phone. After the user picks up the phone, the SIP INVITE message is sent to the address "abpd@home.com".

Upon receiving the confirmation message that the user is successfully registered, the SIP UA actively requests the configuration delivery server for the user's profile through the SIP SUBSCRIBE message. Configuring the delivery server to query the hotline service currently signed by the user according to the subscription data of the user. The hotline number is "abcd@home.com", and the configuration file is generated, or the service application environment changes after the user successfully registers the hotline service. The configuration delivery server carries the configuration file in a NOTIFY message sent to the SIP UA. In this configuration file, the "profile" as the "configuration ID" is the extended MIME media type, which can be defined as follows:

Media type name: application

 Media subtype name: profile+xml

Required parameters: none Encoding scheme: XML The extended event package "profile" in this definition is used to transfer the configuration file to the requesting user ( Subscriber ) in the NOTIFY message. The name of the extended event package ( event-package token name ) is: "profile" , and no other parameters are defined in the extended event package. In the extended event package, the configured SIP SUBSCRIBE message Event header field or the configured NOTIFY message Event header field is as follows: Event: profile; For the user's arrears, the off-hook hears the fee and does not allow the user For outgoing services, the configuration file described in XML is:

 <?xml version="1.0" encoding="UTF-8"?>

<profile xmlns="um:ietf:pararas:xml:profile"version="0"state="full ^,r >

 <ofihook allow="true">

 <to-network needed="true" method=" invite" requestURI="arrearage-toneMRFC@example.com'7>

 <to-user needed-' alse''^

 <timer startup="true">

 <timerlength>30000</timerlength>

 <timeoutaction>

<to-network needed- 'true ¹ 'method="bye"requestURI="arrearage-toneMRPP@example.com ^,, />

 <to-user needed="true" type="tone">

 <tonet pe>busy-tone</tonetype>

 </to-user>

<timer startup="true ⁿ >

 <timerlength>60000</timerlength>

 <timeoutaction>

 <to-network needed="false"/>

 <to-user needed="true" t pe="tone">

 <tonetype>howling-tone</tonet pe>

 </to-user>

</timeoutaction> </timer>

 </timeoutaction>

 </timer>

 </offhook>

 <hooking allow="false7>

 <dial aIlow="false"/>

 <onhook allow="false"/>

</profile> The configuration of this XML description is as follows: When the user picks up the phone, the SIP UA should send a SIP INVITE message to the media control resource to apply for the arrears tone resource. The "request-U T of the SIP INVITE message is the specified arrears. The voice resource identifier is "arrearage-toneMRPC@example.com". Then, the SIP UA plays the underpaid tone to the user. If the user has no other operations within 30 seconds, the SIP UA sends a BYE message to the media control resource to release the sound resource. The user terminal sends a busy tone to the user. The duration of the busy tone is 60 seconds, and the audible tone is changed. The user configures the delivery server to send the updated configuration file to the SIP UA through the NOTIFY message after the user picks up the audible tone. When the user hangs up, if the user hangs up, the description of releasing the audible resource is as follows:

<?xml version="1.0" encoding- ^{, ,} UTF-8"?>

 <profile xmlns="urn:ietf:params:xml:profile" version="0" state="full">

 <offhook allow="false >

 <hooking allow="false'7>

 <dial aIlo ="false"/>

 <onhook allow="true">

<to-network needed="true"method="bye" requestURI ⁼⁼ "arrearage-toneMRFP@example.com ^,, />

<to-user needed="false ^, 7>

<timer startup="false"/>

 </onhook>

</profile> For the calling service of a group (Centrex) user, the users in the group can call other users in the group, or they can make outbound calls, but the dialing rules are different. For example, if a user calls a group user, the dialing rule is 7 The first four digits, and the outbound call, the outbound prefix is 0, dial 0 to send the second dial tone, and delete the prefix; if the user dials, the number has been dialed; the user has no other services, pick up the phone Normal dial tone. The configuration file described in XML is:

<?xml version="1.0" encoding= ^M UTF-8'*?>

<profile xmlns ^=:: "urn:ietf:params:xml:profile"version="0"state="full">

<offliook allow= ^H true">

 <to-network needed- 'false"/>

 <to-user needed="true" type="tone">

 <tonetype>diaI-tone</tonetype>

 </to-user>

 <timer startup="true">

 <timerlength>60000</timerlength>

 <timeoutaction>

 <to-network needed="false"/>

 <to-user needed="true" type="tone">

 <tonetype>busy-tone</tonetype>

 </to-user>

 <timer startup=="true">

 <timerlength>60000</timerlength>

 <timeoutaction>

 <to-network needed="false"/>

 <to-user needed- 'true" type="tone">

 <tonetype>howling-tone</tonetype>

 </to-user>

 </timeoutaction>

 </titner>

 </timeoutaction>

 </timer>

</offliook> <hooking alIow="false"/>

 <dial allow="true">

 <dial-pattern enterke ="#">

 <regex tone=" second-dial-tone" tag="centrexout">0</regex>

 <regex method=" invite" tag="centrexin">7[x] [x] [x]</regex>

 </dial-pattern>

 </dial>

 <onhook allo ="false"/>

</proflle>

 The tag <offhook>† describes the action performed when the current SIP UA processes the off-hook event. The attribute allow="true" describes the current allowable handling of the off-hook action; the tag <to-user> describes the current action to send the tone to the user ( Type="tone" ), the transmission type is dial tone ( <tonetype>dial-tone</tonetype> ), send 60000ms ( <timerlength>60000</timerlength> ); in the tag <dial>, describe the current SIP UA The action performed when processing the dialing event, the attribute allow="tme" describes the current allowable dialing action; the tag <dial-pattern> describes the dialing paradigm currently allowed to dial, and the attribute enterkey="#" means that when the user dials "#" After the number has been dialed, the user can dial 0 out of the group or dial the four in-group number at the beginning of 7. When the user dials the group prefix 0, the user is given a second dial tone (tone="second-dial-tone"), and when the user dials the four-digit group number at the beginning of the 7th, the SIP INVITE is used (meth = The "invite" message sends the number to the service call session control function entity.

 For the call service in which the user has registered the abbreviated dialing, for example, when the user calls "mary@example.com", only the quota number "**11" needs to be dialed. The configuration delivery server can carry relevant information in the dialing paradigm of the user's configuration file: When using the abbreviated dialing service, the SIP UA automatically initiates a call to "mary@example.com" according to the dialing paradigm in the configuration file. request. The configuration file described in XML is:

 <?xml version="1.0" encoding="UTF-8"?>

 <profde xmlns="um:ietf:params:xml:profile" version="0" state="full">

 <ofSiook allow="true">

 <to-network needed="false"/>

<to-user needed="true"type="tone"/> Allow

 /dial <>

<

 <

< /ouster <>- </profile> where the relevant off-hook event in the tag <offhook> is the same as the description of the off-hook event in the calling service of the group (Centre) user, and will not be described here; the currently allowed in the tag <dial> In the dialing paradigm, the user can call the 8-digit local number at the beginning of 287, or use the abbreviated dialing service to call "** _n ". When the user dials the call " ** ιι", the SIP UA initiates a SIP INVITE ( method="invite" ) message with the attribute newRequestU I="mar @example.com" according to the profile dialing paradigm. For a flash event in which the user is in a session state, for example, the current user "abcd@home.com" and another user "mary@example.com" are in the session, the user can initiate a new call by the flashing operation. After the user performs the flashing operation, the SIP UA needs to send a signal tone to the opposite end to send a special dial tone to the local end. The configuration file described by ML is:

 <?xml version- ' 1.0" encoding^"UTF-8"?>

<profile xmlns="urn:ietf:params:xml:profile"version="0" state= ^,r fuH">

 <o£fhook allow="faIse'7>

 <hooking allow="true">

<to-network needed= ⁿ true"method="update ⁿ requestURJ="mary@example.com" message- 'a=inactive'7>

 <to-user needed="true" type="tone">

 <tonetype>special-dial-tone</tonetype>

 </to-user>

 <timer startup-'true">

 <timerlength>60000</timerlength>

 <timeoutaction>

<to-network needed="ti'ue"method="update', requestURI ⁼ "mary@example.c0m ^M

Message= ^=,, a=sendrecieve"/>

 <to-user needed="false"/>

 </timeoutaction>

 </timer>

 </hooking>

<dial allow="faIse ^, 7> <onhook allow="true ^,, >

 <to-network needed="true" method="bye" requestURI="mary@example.com"/>

 <to-user needed^' alse''^

 </onhook>

</profile>

In the tag <hooking>, the action performed when the current SIP UA processes the flashing event is described, the attribute allow="true" describes the current permission to handle the flashing action; the tag <to-network> describes the current flashing SIP The UA sends an UPDATE message ( method="update" ) to the network side, and holds (hold) the peer (message="a=inactive"); the tag <to-user> describes the voice to the user (type="Tone") action, the transmission type is special dial tone ( <tonetype>special dial-tone </tonetype> ), send 60000ms ( <timerlength>60000</timerlength> ) ₀ If the timeout still does not receive the user to perform call recovery Action: Send an UPDATE message to the peer to resume the call; and the tag <onhook:^ indicates that if the user performs a flashing operation, the SIP UA sends a BYE message to the peer user to end the current session. After the user shoots the fork operation, the peer sends an UPDATE message (or re- INVITE) to the peer end, and configures the delivery server to update the configuration file to the user by using the NOTIFY message, which describes that the current call recovery action is performed if the user re-crosses the fork. . The user dials in to initiate a new call. The configuration file described in XML is:

<?xml version- ' 1.0 ^H encoding="UTF-8"?>

 <profile xmlns- 'urn:ietf:params:xml:profile" version="0" state="full">

 <offhook allow=="false7>

 <hooking allow="true">

<to-network needed- 'true" method- 'update"requestURI-"mary@example.com ^M message="a=sendrecieve'7>

<to-user needed="false"/>

 <timer startup="false'7>

 </hooking>

<dial allo ="true ⁿ >

 <dial-pattern enterke ="#">

<regex method="invite"tag="local">287[x][x] [x] [x] [x]</regex> </dial-pattern>

 </dial>

 <onhook allow="true">

<to-network needed="true"method="bye ^M requestURI ^=,, mary@example.com"/>

 <to-user needed="false"/>

 </onhook>

</profile> In the tag <liooking>, describes the action of resuming the call when the current SIP UA processes the dialing event: the SIP UA sends an UPDATE message to the peer user to resume the call; in the tag <dial>, describes the current SIP The action performed by the UA when processing the dialing event. The attribute allow="true" describes the current dialing action allowed. The tag <dial-pattem> describes the dialing paradigm currently allowed to dial. The attribute enterkey="#" indicates that if the user dials, the representative number has been Dial the end. Allows the user to dial the 8-digit number at the beginning of 287. If the user dials this number, the SIP INVITE ( method="invite" ) message is used to initiate a call to that number. For the user to use the temporary reservation calling number to display the restricted service, the user picks up the phone to dial "*62 called number", and the AGCF matches the number dialed by the user with the obtained configuration file, according to the dialing paradigm processing description of the dialing event in the configuration file. , to get the action to be performed, send an invite request message according to the request, and put the "called number" dialed by the user into the Request-URI ("Qingqi-Uniform Resource Identifier" in the form of a tel URL in the invite request message. Carry the Privacy header field, set it to "header", and insert the anonymous keyword in the From header field.

The AGCF sends the invite message to the network. For the network, the invite message is like the SIP terminal device using the simulation to simulate the service, so the application server that processes the simulation service can be reused as the PES subsystem service, thereby saving investment. The configuration file described in XML is:

 <?xml version="1.0" encoding="UTF-8"?>

<profile xmlns="urn:ietf:params:xml:profile"xmlns:xsi=''http://www.w3.org/2001/XMLSchema-instance' ¹

Xsi:schemaLocation="um:ietf:params:xml:profile:\XML\profile\ppptest,xsd" state="full" version="0">

<offhook allow="true"> <to-network needed="false"/>

 <to-user needed="true" t pe="tone" timelengh- '60000">

 <tonetype>special-dial-tone</tonetype>

 </to-user>

 <timer startup="false"/>

 </offhook>

 <hooking allo ="false"/>

<dial allow^true ¹ '

 <dial-pattern>

 <regex method="invite" special='Travicy:header;From:&quot;Anonymous&quot;

&lt;sip:ationymous@anonymous.invaUd&gt;"cleanup="true ^M tag="temp-OIR"> ^:i! 62</regex>

 </dial-pattern>

 </dial>

<onhook allow= ^M false"/>

</profile> where the given dialing paradigm is "*62", when the user dials "*62", "*62" is cleared from the number buffer ( _C l _eanUP ="tme" ), and continues to accept users. Dial, insert the header field Pravicy in the user's initiated call: eader and From: "Anonymous"<sip: anonymous @anonymous . invalid>

The symbol <>" is replaced with an escape character) into the invite ( _me th.d= _V it _e " ) request.

The SIP UA sends a charging signal to the user according to the configuration file, and the related charging information carried in the configuration file sent by the delivery server to the SIP UA may be a simple number of pulse signals, and may also include more complicated charging rules. Such as Enable Meter Type, Meter Pulse Burst Type, Phased Meter Type, etc., billing rules describe time, rate, etc. Element, the SIP UA sends a charging pulse to the user according to the charging rule. The following describes an embodiment in which a SIP UA periodically sends a charging pulse after a user enters a call state. The embodiment takes the charging rule in the configuration as an example. Before the embodiment, the Automatic Meter event package (amet) is extended with reference to the ITU H.248.26 protocol. The amet packet defines the signal for transmitting the impulse accounting information. The parameters of the different charging rules are listed below: Phased Meter Type parameters for charging rules

 • PM-Pulse-repetition-interval (pulse interval, in milliseconds)

 • PM-MAX PCCI (Maximum pulse count per charge interval)

 • PM-REPX (repetition of Max PCCI, the maximum number of billing intervals)

• PM-MIN PCCI (Minimum pulse count per charge interval)

 • PM-PCN (repetition of Min PCCI, using the minimum billing pulse billing interval)

• PM-CI (charge interval, interval in seconds)

 • PM-PD (phase duration, duration of each billing period, in seconds). The above parameters correspond to the H.248amet packet EM, MBP, PM signal and signal parameters, and the meanings are the same. For details, refer to the H.248 protocol.

 Enable Meter Type parameters for the charging rule

 • EM-pulse-count (number of pulses sent per interval)

 • EM-Pulse-repetition-interval (issued EM PC event interval)

Meter Pulse Burst Type parameters for the billing rules

 • MPB-burst-pulse-count (one-time number of punches)

 • MPB-Pulse-repetition-interval. After the user is in a call steady state, the SIP UA sends a timer configuration, and the charging rule described in the timer to the traditional terminal charging pulse is described by XML. The configuration file is:

 <?xml version=" 1.0" encoding="UTF-8"?>

 <profile mlns="urn:ietf:params:xml:profile" xmlns:xsi="http://ww . w3.org/2001/XMLSchema-instance"

Xsi:scliemaLocation=' ^, um:ietf:params-.xml:profile ^, .VXML\profile\ppptest.xsd" state- 'full"version="0">

 <offlioolc allo ="false"/>

 <hooking allo ="false"/>

 <dial allow="faIse"/>

 <onhook allow="false"/>

 <timer startup="true">

<timerlength>60000</timerlength> <timeoutaction>

 <to-user needed""true" type="pulse">

 <pulse-info>

 <PM>

 <Pulse-repetition-interval>3< Pulse-repetition-interval>

 <MAX-PCCI>0</MAX-PCCI>

 <REPX>0< REPX>

 <MIN-PCCI>0</MIN-PCCI>

 <PCN>0</PCN>

 <CI>60</CI>

 <PD>60< PD>

 </P >

 </pulse-info>

 </to-user>

 <to-network needed="false'7>

 </timeoutaction>

 </timer>

</profile> Configure the delivery server to deliver the configuration file to the SIP UA through the response message (200 response code) when the user enters the call state. After the SIP UA receives and parses the XML configuration, <timerlength>60000 every 60 seconds</timerlength> ) 3 billing pulses are sent, and the billing pulse is continuously sent to the user according to this rule during the call. In the above embodiment, the SIP UA parses after receiving the configuration file, detects a timer operation event, and performs a corresponding action to start the timer. Of course, a "empty operation" can also be defined here, indicating that the corresponding action is to be performed unconditionally (no specific operational event triggering is required). In the present invention, for other embodiments, the SIP UA can also receive the configuration file. After that, the operation event that needs to be detected is parsed to match the operation event received by the user to perform the corresponding action. Generally, after receiving the configuration file, the SIP UA may not need to parse immediately, but after detecting an operation event received by the user, it matches the operation event set in the configuration file. If the matching is successful, the corresponding execution is performed. Actions. In addition, the foregoing SIP UA sends a charging signal to the user according to the configuration file, and another implementation manner, the operation event set in the configuration file is a SIP message received by the user, that is, the response message of the user entering the call state, SIP After receiving the configuration file, the UA parses the operation event to perform a corresponding action when receiving the response message; or after receiving the response message, matches the configuration file and performs a corresponding action. The actions described in the above embodiments may be preset in a configuration file or preset in a SIP UA, such as a program code. In addition, the configuration files of the services described in the embodiments of the present invention are described by using XML, and the extensibility of the XML makes the service scalable. It can be easily understood by those skilled in the art, but the configuration file of each service can also be described in other languages, and the SIP UA can interpret the received configuration file and perform event matching and action execution operations. It is within the scope of the invention. An embodiment of the present invention obtains a configuration file of a user from a network entity such as a profile delivery server through a communication device (such as SIP UA), and detects an operation event performed by the user according to the configuration file, if the configuration file is detected. In the operation event, the business logic processing is performed according to the corresponding action in the preset configuration file. This method of performing corresponding actions by matching operational events in the configuration file greatly reduces the processing complexity of the SIP UA. At the same time, the action of the SIP UA to match the configuration file to the network can be completely consistent with the action performed by the SIP terminal device to perform the same type of service, so that the SIP UA can reuse the application server that processes the analog service when processing the same type of service. The equipment, that is, the application server equipment that processes the analog service, can also serve the public switched telephone network/integrated service digital network simulation subsystem, saving network investment. The current configuration file is updated by the configuration delivery server according to the change of the business environment, and the corresponding SIP UA new configuration file is notified or only the changed part of the configuration file is notified, so that the SIP UA The processing is simplified and adaptable to changes in the business environment.

 The configuration file uses XML language to describe operational events and corresponding actions, and the business is highly scalable. Although the present invention has been illustrated and described with reference to the preferred embodiments of the present invention, those skilled in the art will understand that various changes can be made in form and detail without departing. The spirit and scope of the invention.

Claims

Rights request

 A communication service processing method, comprising the steps of:

 Obtaining a configuration file of the user, where the configuration file includes an operation event;

 If the operational event is detected, the business logic processing is performed in accordance with the corresponding action in the configuration file.

 The communication service processing method according to claim 1, wherein the corresponding action is previously set in a configuration file or a communication device.

 3. The communication service processing method according to claim 2, wherein the communication device acquires a profile of the user from a configuration delivery server on the network side.

 The communication service processing method according to claim 3, wherein the process of the communication device acquiring the user's configuration file is:

 The communication device requests the configuration file of the user from the configuration delivery server after the user registers;

 The configuration delivery server, upon receiving the request message that the communication device sends a configuration file requesting the user, sends a message carrying the configuration file to the communication device.

 The communication service processing method according to claim 4, wherein when the user's business application environment changes to cause a user configuration change, the configuration delivery server generates a new one according to the current business application environment of the user. User profile and send it to the communication device.

 The communication service processing method according to claim 5, wherein when the user's business application environment changes again to cause a user configuration change, the configuration delivery server notifies the communication device of the configuration after the last notification. The part of the file that has changed.

 The communication service processing method according to claim 3, wherein after the communication device acquires the configuration file of the user, parsing the current user configuration file; or

 After acquiring the configuration file of the user and detecting the operation event, the communication device parses the corresponding operation event in the current user profile, and performs a corresponding action.

 The communication service processing method according to claim 7, wherein the method is applied to a public switched telephone network PSTN/integrated service digital network ISDN emulation subsystem; wherein the communication device is a session initiation protocol SIP user proxy.

9. The communication service processing method according to claim 7, wherein the configuration file The operational events in the piece include at least one of the following:

 Off-hook event, dialing event, flashing event, on-hook event, timer timeout event or session initiation protocol message;

 The corresponding action of the operation event includes at least one of the following:

 Send a message to the network side, send an indication signal to the user, or set the timer.

 10. The communication service processing method according to claim 9, wherein the indication signal sent to the user comprises at least one of the following:

 Send voice to the user, send reverse signal to the user, billing signal, display signal, hold or resume.

The communication service processing method according to claim 9, wherein the communication device sends a message to the network side by using a session initiation protocol or a hypertext transfer protocol, wherein the message sent to the network side by the session initiation protocol is At least one of the following:

 "Invite Invite" message, "Submit Refer" message, "Scheduled subscribe" message, "Attachment" message, or "Update Update" message.

 12. The communication service processing method according to claim 2, wherein the service comprises:

 Hotline service, user owed to pay off the hook to listen to the fee, the user has a new message, pick up the phone to listen to the message indication tone, abbreviated dialing, group user pick up the group dialing to listen to the second dial tone, the fork processing, the network to the user The charging signal, PSTN/ISDN emulation service or PSTN/ISDN analog service is delivered.

 The communication service processing method according to claim 2, wherein the configuration file describes the operation event and its corresponding action by an extended markup language.

 A communication service processing device, comprising:

 An obtaining unit, configured to acquire a configuration file of the user, where the configuration file includes an operation event, and the detecting unit is connected to the acquiring unit, configured to detect the configuration file in real time, and send a detection result of detecting the operation event;

 The service processing unit is connected to the detecting unit, configured to receive the detection result, and perform business logic processing according to a corresponding action in the preset setting of the detection result.

 A communication service processing system, comprising: configuring a delivery server and a communication device; wherein

The configuration delivery server is configured to provide a configuration file of the user, where the configuration file includes operations Make an event;

 The communication device is configured to obtain a configuration file of the user from the configuration delivery server, and if the operation event is detected, perform business logic processing according to a corresponding action in the configuration file.

 16. The communication service processing system according to claim 15, wherein the configuration delivery server provides the user's configuration file according to the user's subscription data and the business application environment.

 17. The communication service processing system according to claim 16, wherein the communication device is a SIP user agent.

 The communication service processing system according to claim 16, wherein the SIP user agent is an access device or a SIP integrated access device having an access gateway control function.