WO2014015776A1

WO2014015776A1 - Service parsing method flexibly adapted to ims system service tag

Info

Publication number: WO2014015776A1
Application number: PCT/CN2013/079808
Authority: WO
Inventors: 覃洪清; 王功乾
Original assignee: 烽火通信科技股份有限公司
Priority date: 2012-07-25
Filing date: 2013-07-22
Publication date: 2014-01-30
Also published as: RU2604983C2; RU2014146752A; CN102752315B; CN102752315A

Abstract

The present invention relates to a service parsing method flexibly adapted to an IMS system service tag, comprising the steps of: defining a multi-service tag template; defining an initial multi-service tag template instance set in a device pre-configuration file; importing the pre-configuration file into a runtime IMS SIP terminal, appending a matching rule, generating a runtime multi-service tag set, and storing same; and the IMS SIP terminal using a subscription message mechanism to subscribe to a service, and in accordance with a Notify notification message received, performing matching according to the matching rule corresponding to a service tag instance set to accomplish the parsing processing of a service. The service parsing method flexibly adapted to an IMS system service tag of the present invention makes an IMS SIP terminal capable of adapting to different service presentation methods of a plurality of IMS server manufacturers simultaneously, thus being effectively compatible with the ambiguity during service parsing, and improving the adaptive ability and application range of an IMS SIP terminal.

Description

Technical field

The present invention relates to the field of an IMS system and an IMS SIP terminal, and more specifically to a service analysis method for an IMS SIP terminal that flexibly adapts to an IMS system service tag. In particular, the IMS SIP terminal cooperates with the application server in the IMS system to implement related services in the IMS system by adaptively and flexibly parsing the NOTIFY message sent by the network side in the IMS system. Background technique

IMS (IP Multimedia Subsystem) is a SIP (Session Initiation Protocol)-based system that provides a complete set of standard architectures for multimedia services. As an increasingly mature standard system, IETF, 3GPP, OMA (Open Mobile Alliance, Open Mobile Alliance) and other international standards organizations are defining and improving the IMS standard. IMS technology allows operators to better control the business layer, integrate and implement IMS multimedia services faster, and reduce network investment and operational expenses, so operators pay great attention to IMS technology. At the same time, IMS technology can also bring a unified user experience to users, and users will get more IMS services with guaranteed quality and security. The proposal of IMS conforms to the trend of communication network technology convergence and service convergence development, and it will play an important role in the future communication network.

As the end user, the IMS SIP terminal is the most direct carrier for various services in the IMS system, and cooperates with other devices in the IMS system to provide various services for users. The implementation of the PSTN (Public Switched Telephone Network) emulation service in the IMS network can be implemented in a loosely coupled manner by the IMS SIP terminal, the application server AS, and the user data center HSS. The IMS SIP terminal needs to perceive the service customized and registered by the user, and completes the terminal-related service function implementation, including converting the hook flash action and the subsequent dialing event into corresponding SIP messages. The IMS SIP terminal uses the subscription notification mechanism of the service to sense the services customized and registered by the user. Figure 1 depicts the subscription notification mechanism in the IMS network: After the registration (REGISTER) is successful, the IMS SIP terminal sends a subscription (SUBSCRIBE) message to the IMS system to initiate a subscription request, requesting to inform the user of the registered service information; After the corresponding request information is obtained, the service registration information corresponding to the IMS SIP terminal user in the user data center HSS is queried, and the IMS SIP terminal is notified of the service registration information corresponding to the user by using a NOTIFY message (also referred to as a service notification message). . The NOTIFY message specifically describes the service registration information corresponding to the IMS SIP terminal user in the XMLCExtensible Markup Language) document information format. A typical XML document in a NOTIFY message is as follows:

<?xml version ^=/ l. 0"encoding="UTF - 8"?>

<dial- tone-management >

<dial-tone-pattern>special-condition-tone</ dial- tone-pat tern>

</ dial-tone-management >

<no-dialling-behaviour>immediateCallSetup</no-dial ling-behaviour > <mcid-service>mcid-service-provisioned</mcid-service>

<three-pty-service>three-pty-service-provisioned</ three - pty - service) <cw-service>cw-service-provisioned</ cw-service>

</simservs>

The various types of service information registered or cancelled by the IMS SIP terminal user appear in the XML document in the form of a label (service tag), such as <cw-service> cw—service—proved </cw-service> is the call waiting service tag, including The service tag name cw_service, the service tag value cw_service_provisioned and the like, so the identification and parsing of the service tag in the dish document is the key to the NOTIFY message processing.

However, in practical applications, because the IMS server manufacturers support different types of services, the contents of the service tags often appear inconsistent, which makes the IMS SIP terminal encounter certain difficulties in identifying and parsing the service tags. It is often the case that a NOTIFY message sent by one IMS server manufacturer can be identified and parsed, but the NOTIFY message of another IMS server manufacturer cannot be identified and resolved. Due to the difference of the business label Righteousness, when new IMS server vendors (IMS platform vendors) are introduced, IMS SIP terminals often need to adapt and adjust accordingly to match related service tags, which will greatly affect and limit the overall promotion and use of IMS services.

Summary of the invention

In view of the deficiencies in the prior art, the object of the present invention is to provide a service parsing method that flexibly adapts to the service tag of the IMS system, so that the IMS SIP terminal can simultaneously adapt to different service representation methods of multiple IMS server manufacturers, thereby being effectively compatible. The ambiguity in business analysis improves the adaptive capabilities and application scope of IMS SIP terminals.

In order to achieve the above object, the technical solution adopted by the present invention is:

A service parsing method for flexibly adapting to a service tag of an IMS system, characterized in that the method includes the following steps:

Step 1: Defining a multi-service tag template: In a configuration file of an IMS SIP terminal, defining a format of a plurality of service tags that are accepted and recognized by the system for a service, and the format of the multi-service tag template is as follows, including the identifier and the content. :

Templates<Service [i] > = Pattern [i] [ 1] | Pattern [ i] [2] ... I Pattern [i] [n]

Where Templates<Service [i] > is the identifier of the multi-service template defined by the IMS SIP terminal for the service type i,

Pattern [i] [ 1] , Pattern [i] [2] , ..., Pattern [i] [n] Each represents a service tag that identifies the service type i as an IMS SIP terminal, via the "I" symbol string Then, the content of the multi-service label template is formed;

Step 2: Generate a multi-service tag instance set by using a multi-service tag template: According to the characteristics of the IMS system accessed by the IMS SIP terminal, the service tag Pattern [i] [m] corresponding to the service type i will be determinable. m>=0 & m<=n, denoted as pattern [i] [m]; Store the specific service tags corresponding to different services in the configuration file according to the format defined by the multi-service tag template to form multiple services in the configuration file. The set of tag instances is as follows:

Templates<Service [0] >= pattern [0] [ 1] | pattern [0] [2] '· I pattern [0] [n]

Templates<Service [1] >= pattern [l] [1] | pattern [l] [2] '· I pattern [1] [n] templates<Service [i] >= pattern [i] [1] | pattern [i] [2] ... I pattern [i] [n]

One row corresponds to one multi-service tag instance, and multiple service template instances between different service types are segmented by a carriage return and line-feed method to form a multi-service tag instance set;

During the actual operation, the IMS SIP terminal learns the multi-service tag instance set in the configuration file, and adds the service tag matching operation rule of various services to generate a multi-service tag instance set at the runtime, so that the subsequent service tag matches. jobs;

Step 3: After receiving the NOTIFY message, the IMS SIP terminal obtains a service label of various services corresponding to the IMS SIP terminal user from the XML document information carried in the NOTIFY message.

Step 4: Perform the operation on the service label of each service corresponding to the IMS SIP terminal user and the multi-service label instance set at the runtime according to a series of related service label matching operation rules, that is, complete the XML Identification and parsing of service tags in the document: Parsing the subscribed service capabilities of the IMS SIP terminal users. On the basis of the foregoing technical solution, after the service subscription message SUBSCRIBE reaches the IMS platform, the platform sends a NOTIFY notification message to inform the user of the service capability. After receiving the NOTIFY, the IMS SIP terminal performs the matching of the service tags according to the matching by successive means and the triggering by successive means. Analytical processing:

After obtaining the XML document describing the subscribed service capability of the user, the IMS SIP terminal performs the one-by-one matching according to the service tag matching operation rule covered by the multi-service tag instance set at the running time, and the matching result is true. To the user;

The specific service tag matching operation rule is determined by the specific implementation. Once the operation is performed according to the operation rule, the IMS SIP terminal user is considered to have the service capability. On the basis of the foregoing technical solution, when the multi-service tag instance set is generated and stored, the control logic module invokes the multi-service tag instance set generation module and the instance storage module to implement control of the entire multi-service tag instance. On the basis of the foregoing technical solution, the multi-service tag instance set generating module generates a multi-service tag instance set according to the multi-service tag template and the specific IMS system service tag; the control logic module can at least increase the specific content of the multi-service tag instance set. , hold and delete operations. On the basis of the foregoing technical solution, the runtime multi-service tag instance set storage module is mainly used to import a multi-service tag instance set in the configuration file in the IMS SIP terminal, and attach matching rules of various service tags to form an operational A manageable set of instances, where the matching rule is the basis for tag matching and parsing. Based on the above technical solution, in step 4, when receiving the NOTIFY message, the IMS SIP terminal performs the following processing:

According to the matching rule, the service label pattern [i] [m] in the XML document and the first priority service label pattern in the multi-service tag instance 6111 1&168<36:^:^6 [:[]> [i] [0], perform the operation: the result is true, indicating a match; if it does not match, the multi-service tag instance templates<Service [i] ^ other service tags pattern [i] [k] are operated; k>0 &k<=n;

If it matches, the user is considered to have registered the service, and the matching process of the next service tag pattern [j] [m] is performed;

When all the service tags of a multi-service tag instance templates<Service[i]> cannot be matched, it is considered that the user does not register the service, and then the next service pattern [j] [m] is processed;

The above steps are repeated until the service tag resolution in all xml documents is completed. The service parsing method for adapting the service tag of the IMS system according to the present invention enables the IMS SIP terminal to adapt to different service representation methods of multiple IMS server manufacturers at the same time, thereby effectively complicating the ambiguity in the service parsing and improving the IMS SIP. The adaptive capabilities and application range of the terminal. DRAWINGS

The invention has the following figures:

Figure 1 is a subscription notification mechanism in an IMS network.

Figure 2 is a schematic diagram of the generation and storage of a multi-service tag instance.

Figure 3 shows the business matching process.

detailed description

The present invention will be further described in detail below with reference to the accompanying drawings and embodiments. The specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

The core idea of the present invention is: defining a multi-service tag template, generating a multi-service tag instance through a multi-service tag template, and parsing the service tag in the received XML document according to the generated multi-service tag instance to obtain an IMS SIP terminal User's business registration information.

The service parsing method for flexibly adapting the service tag of the IMS system according to the present invention includes the following steps:

Templates<Service [i] > = Pattern [i] [1] | Pattern [i] [2] ... I Pattern [i] [n]

Where Templates<Service [i]> is the IMS SIP terminal for the service type i (eg Call waiting, three-way calling, etc.) Identification of the defined multi-service template, i=l, 2, 3, 4, ...

Pattern [i] [ 1] , Pattern [i] [2] , ···, Pattern [i] [η] each represents a service tag that can be used as an IMS SIP terminal to identify the service type i, via "I" The symbols are concatenated to form the content of the multi-service tag template; n is an integer, and the maximum value is the total number of service tag types of the service type i, the same below;

Step 2: Generate a multi-service tag instance set by using a multi-service tag template: According to the characteristics of the IMS system accessed by the IMS SIP terminal, the service tag corresponding to the service type i may be [P] [m] [m] (m>=0 & m<=n) will be determinable, denoted as pattern [i] [m]; store the specific service tags corresponding to different services in the configuration file according to the format defined by the multi-service tag template, forming more in the configuration file. The business tag instance set is as follows:

Templates<Service [0] >= pattern [0] [ 1] | pattern [0] [2] ... I pattern [0] [n]

Templates<Service [ 1] >= pattern [ l] [ 1] | pattern [ l] [2] ... I pattern [ 1] [n] templates<Service [i] >= pattern [ i] [ 1] | pattern [ i] [2] ... I pattern [i] [n]

Step 3: After receiving the NOTIFY message, the IMS SIP terminal obtains the service label of the service corresponding to the IMS SIP terminal user from the XML document information carried in the NOTIFY message; for example:

Pattern [i] [k] (k>=0 & k<=n)

Pattern [j] [m] (m>=0 & m<=n)

Step 4: The service tags of various services corresponding to the acquired IMS SIP terminal users, The multi-service tag instance set with the runtime, according to the related series of service tag matching operation rules, performs the operation, that is, the identification and parsing of the service tag in the XML document is completed: parsing the subscribed IMS SIP terminal user's subscription Service Capability; The service matching resolution process is shown in Figure 3. On the basis of the foregoing technical solution, after the service subscription message SUBSCRIBE reaches the IMS platform, the platform sends a NOTIFY notification message to inform the user of the service capability. After receiving the NOTIFY, the IMS SIP terminal performs the matching of the service tags according to the matching by successive means and the triggering by successive means. Analytical processing:

After obtaining the XML document describing the subscribed service capability of the user, the IMS SIP terminal performs matching one by one according to the service tag matching operation rule|J, which is covered by the multi-service tag instance set at the running time, and matches the result to be true. Business capabilities are assigned to the user;

The specific service tag matching operation rule can be determined by a specific implementation. Generally, the service tag name, the service tag value, and the like need to be checked. Once the operation is performed according to the operation rule, the IMS SIP terminal user is considered to have the service capability. Based on the above technical solution, FIG. 2 is a schematic diagram of generation and storage of the multi-service tag instance set described in step 2. When the multi-service tag instance set is generated and stored, the control logic module invokes the multi-service tag instance set generation module and the instance storage module to implement control of the entire multi-service tag instance. On the basis of the foregoing technical solution, the multi-service tag instance set generating module generates a multi-service tag instance set according to the multi-service tag template and the specific IMS system service tag; the same IMS SIP terminal accesses different IMS systems, and the multi-service tag instance set It may be inconsistent or consistent. The control logic module can at least (such as: through the command line, etc.) add, retain, and delete the specific content of the multi-service tag instance set. Based on the foregoing technical solution, the runtime multi-service tag instance set storage module is mainly used to import a multi-service tag instance set in the configuration file in the IMS SIP terminal, and The matching rules of various service tags are added to form an operable and manageable set of instances, wherein the matching rules are the basis for tag matching and parsing. On the basis of the above technical solution, as shown in FIG. 3, in step 4, when receiving the NOTIFY message, the IMS SIP terminal performs the following processing:

According to the matching rule, the service label pattern [i] [m] in the XML document and the first priority service label pattern in the multi-service tag instance 6111 1&168<36:^:^6 [:[]> [i] [0], perform the operation: the result is true, indicating a match; if it does not match, the multi-service tag instance templates<Service [i] ^ other service tags pattern [i] [k] (k>0 & k <=n) to perform an operation;

The above steps are repeated until the service tag resolution in all xml documents is completed. As described above, the service parsing method for flexibly adapting the service tag of the IMS system according to the present invention includes the following steps:

Define a multi-service label template;

Define the initial set of multi-service tag template instances in the device pre-configuration file

At runtime, the IMS SIP terminal imports the pre-configuration file and attaches a matching rule to generate a runtime multi-service tag set for storage.

The IMS SIP terminal subscribes to the service by using the subscription message mechanism, and performs matching according to the matching rule of the service tag instance set according to the received Notify notification message to complete the service analysis processing.

The service matching parsing process is performed by the IMS SIP terminal to send a service to the application server AS by sending a SUBSCRIBE message. After receiving the service subscription request, the application server AS notifies the IMS SIP terminal of the user service capability by using a NOTIFY message. The IMS SIP terminal performs rule matching on the service tags in the received xml document according to the service tag instance, and finally parses out the service capability of the user. The contents not described in detail in the present specification belong to the prior art well known to those skilled in the art.

Claims

Claim

A service parsing method that flexibly adapts to a service tag of an IMS system, and is characterized by the following steps:

Templates<Service [i] > = Pattern[i] [1] | Pattern[i] [2] ... I Pattern [i] [n]

Where Templates<Service[i]> is the identifier of the multi-service template defined by the IMS SIP terminal for the service type i.

Pattern[i] [1] , Pattern[i] [2] , ..., Pattern [i] [n] Each represents a service tag that can identify the service type i as an IMS SIP terminal, via the "I" symbol string Then, the content of the multi-service label template is formed;

Step 2: Generate a multi-service tag instance set by using a multi-service tag template: According to the characteristics of the IMS system accessed by the IMS SIP terminal, the service tag Pattern[i][m] that the service type i may correspond to is determinable. m>=0&m<=n, denoted as pattern[i] [m]; The specific service tags corresponding to different services are stored in the configuration file according to the format defined by the multi-service tag template to form a multi-service tag instance in the configuration file. The set is as follows:

Templates<Service [0] >= pattern[0] [1] | pattern [0] [2] ... I pattern [0] [n]

Templates<Service [1] >= pattern[l] [1] | pattern[l] [2] ... I pattern [1] [n] templates<Service [i] >= pattern[i] [1] | pattern[ i] [2] ... I pattern [i] [n]

One row corresponds to one multi-service tag instance, and multiple service template instances between different service types are segmented by a carriage return line-wrapping method to form a multi-service tag instance set; During the actual operation, the IMS SIP terminal learns the multi-service tag instance set in the configuration file, and adds the service tag matching operation rule of various services to generate a multi-service tag instance set at the runtime, so that the subsequent service tag matches. jobs;

Step 4: Perform the operation on the service label of each service corresponding to the IMS SIP terminal user and the multi-service label instance set at the runtime according to a series of related service label matching operation rules, that is, complete the XML Identification and parsing of service tags in the document: Parsing the subscribed service capabilities of the IMS SIP terminal users.

2. The service parsing method for flexibly adapting an IMS system service tag according to claim 1, wherein: after the service subscription message SUBSCRIBE reaches the IMS platform, the platform sends a NOTIFY notification message to inform the user of the service capability, and the IMS SIP terminal receives the service capability. After NOTIFY, the matching and parsing of the service tags are performed in a manner of successive matching and successive triggering:

The specific service tag matching operation rule is determined by the specific implementation. Once the operation is performed according to the operation rule, the IMS SIP terminal user is considered to have the service capability.

3. The service parsing method for flexibly adapting an IMS system service tag according to claim 1, wherein: when the multi-service tag instance set is generated and stored, the multi-service tag instance set generation module and the instance are invoked by the control logic module. A storage module that implements control of an entire multi-service tag instance.

The service parsing method for flexibly adapting the IMS system service tag according to claim 3, wherein: the multi-service tag instance set generating module generates a multi-service tag instance set according to the multi-service tag template and the specific IMS system service tag;

The control logic module can at least add, retain, and delete specific content of the multi-service tag instance set.

The service parsing method for flexibly adapting the service tag of the IMS system according to claim 3, wherein: the multi-service tag instance set storage module is used to import the multi-service tag instance in the configuration file in the IMS SIP terminal. The set, and the matching rules of various service tags are added to form an operable and manageable set of instances, wherein the matching rule is the basis for tag matching and parsing.

The service parsing method for flexibly adapting the service tag of the IMS system according to claim 1, wherein: in step 4, when receiving the NOTIFY message, the IMS SIP terminal performs the following processing:

The above steps are repeated until the service tag resolution in all xml documents is completed.