WO2007068194A1 - A method for realizing batch update in subscribing mechanism, subscriber and notifier terminal - Google Patents

Abstract

A method for realizing batch update in subscribing mechanism, for interacting between notifier and subscriber, comprises: the subscriber establishing head area of the first list information, and adding the head area in batch update information, the first list information comprising identifier of subscribing example of activity status in local; the notifier extracting the identifier of subscribing example step by step from the head area of list information, and comparing the identifier of subscribing example with the identifier of local subscribing example, and establishing a head area of second list information, and updating the subscribing example corresponding to the identifier. By using batch update manner, the method of the present invention increases the efficiency of updating example, and reduces the information amount of updating subscribing, and reduces the cost for network bandwidth. The present invention also comprises a subscriber terminal and a notifier terminal.

Description

 Method for implementing batch refresh in subscription mechanism and subscriber and notifier terminal This application is submitted to the Chinese Patent Office on December 16, 2005, and the application number is 200510120883.0. The invention name is "a method for implementing batch refresh in a subscription mechanism". Priority of the Chinese Patent Application, the entire contents of which is incorporated herein by reference.

TECHNICAL FIELD Embodiments of the present invention relate to a resource subscription method of a core network, and in particular, to a method for implementing batch refresh in a subscription mechanism, and a subscriber and a notifier terminal.

Background technique

 In the prior art, SIP (Session Initiation Protocol, SIP) is one of the multimedia communication system framework protocols developed by the IETF. It is a text-based application layer control protocol, independent of the underlying protocol. Establish, modify, and terminate two or more multimedia sessions on the IP network.

 SIP implements a subscription/notification framework and introduces subscription ( SUBSCRIBE ) and notification ( NOTIFY ) methods. The SUBSCRIBE method is used for subscriptions, while the NOTIFY method is used to pass notifications of any changes to an event. A subscription notification is when a user or resource initiates a subscription to another resource. Since the latter has an event of interest to the former, the former will receive notifications about the status of the event and any changes. The simple process is shown in Figure 1, which includes the following steps:

 Step (1): Subscriber sends a subscription (SUBSCRIBE) message to the Notifier (resource owner) requesting subscription to the resource status of interest;

 Step (2): The Notifier allows the Subscriber to subscribe, sends a 200 OK response confirmation to the Subscriber, establishes a subscribed dialog dialog between the Subscriber and the Notifier, and creates a subscription instance on the Subscriber and the Notifier respectively;

 Step (3): The Notifier sends a NOTIFY message to the Subscriber, and carries the resource status of the Subscriber subscription in the message body of the NOTIFY message; - Step (4): After receiving the NOTIFY message, the Subscriber sends a 200 OK response to the Notifier. , indicating that the NOTIFY message was successfully received.

The prior art SIP subscription notification mechanism creates a dialog, and the so-called dialog is also The words are a SIP relationship between the communicating parties, which provides the necessary state information on which to route and message between the communicating parties. And a dialog can associate multiple subscribed instances, that is, Subscriber initiates multiple subscription requests to Notifier, respectively subscribe to different event packages, and these different subscription requests will be created on Subscriber and Notifier respectively - corresponding subscriptions Instance, all instances of these subscriptions are associated with a dialog „ When multiple subscription instances are associated with a dialog, each subscription instance is identified by a unique id value that is generated by the Subscriber initiating each initial subscription request, and The Notifier is passed to the id parameter of the Event header field in the subscription request.

 Similar to the SIP registration mechanism, the subscription uses a soft state and therefore needs to be refreshed. The subscription refresh is achieved by sending a SUBSCRIBE request within the subscription period and setting the value of its Expires header field to a value other than zero. Subscriber needs to send a SUBSCRIBE request for each subscribed instance to refresh the subscription.

 When there are multiple subscription instances on the Subscriber, in order to refresh these subscription instances, a large number of SUBSCRIBE requests are frequently sent, which consumes a large amount of bandwidth, which is not only low in refresh efficiency, but also wastes bandwidth resources.

Summary of the invention

 An object of the embodiments of the present invention is to provide a method for implementing batch refresh in four subscription mechanisms, which implements batch refreshing of multiple subscription instances to solve the inefficiency and bandwidth waste caused by separately refreshing each subscription instance. problem.

 Another object of the embodiments of the present invention is to provide a subscriber terminal and a notifier terminal. The technical solution of the embodiment of the present invention includes:

 A method for implementing batch refresh in a subscription mechanism, which is used for interaction between a notifier and a subscriber, and includes the steps of:

 A. The subscriber creates the first list information and sends the information to the notifier.

B. The notifier refreshes the subscription instance local to the notifier according to the received first list information, and carries the second list information created by the notifier by using the response message;

C. The subscriber refreshes the subscription instance local to the subscriber according to the received second list information. A method for implementing batch refresh in a subscription mechanism, for an interaction between a notifier and a subscriber, comprising the steps of:

 Al, the subscriber creates a header field of the first list information, and adds the header field to the batch refresh message, where the first list information includes an identification number of all active subscription instances that are locally associated with the same session. ;

 Bl, the notifier receives the batch refresh message with the first list information header field, and according to the batch refresh message, matches the local conversation, and extracts the subscription instance identification number and the local matching conversation one by one from the list information header field. The associated subscription instance identification number is compared, and a second list information header field is created, and the different identification numbers are added to the comparison, and the subscription instance corresponding to the same identification number is refreshed.

 A method for implementing batch refresh in a subscription mechanism, which is used for interaction between a notifier and a subscriber, and includes the steps of:

 A2. The subscriber creates a header field of the first list information, and adds the header field to the batch refresh message, where the first list information includes call identifiers of all active subscription instances that are locally associated with multiple conversations. number;

 B2. The notifier receives the batch refresh message with the first list information header field, matches the local call number according to the call identification number in the batch refresh message, and refreshes all the matched multiple sessions. The subscription instance adds the call identification number of the session that cannot be matched to the second list information header field, and sends the response message to the subscriber, and the subscriber refreshes the local subscription instance.

 A method for implementing batch refresh in a subscription mechanism, which is used for interaction between a notifier and a subscriber, and includes the steps of:

 A3. The subscriber puts the subscription instance identification number that needs to be batch refreshed and the call identification number of its associated conversation into a message body, and saves the list locally, and records it as the first list information;

B3. The notifier extracts the call identification number one by one from the message body, matches the local conversation, and if yes, saves the corresponding call identification number to the second list information, and retrieves the call identifier one by one from the message body. The identification number of the associated subscription instance is compared with the matching instance identification number associated with the matching notifier local conversation. If they are equal, the subscription instance corresponding to the identification number is refreshed. Otherwise, the subscription instance identification number is saved to the second list information;

 C3. The notifier puts the second list information into the message body of the response message and sends the message to the subscriber for refreshing each subscription instance.

 A subscriber terminal, comprising: a receiving and sending unit, a creating unit, and a refreshing unit, wherein the creating unit is configured to create first list information, and transmit the first list information to a receiving and sending unit, where the receiving and sending unit is configured to Receiving the first list information is sent to the notifier; receiving the second list information created by the notifier, and transmitting the information to the refreshing unit;

 The refresh unit refreshes the local subscription instance according to the received second list information. A notifier terminal, comprising: a receiving and sending unit, a refreshing and creating unit, wherein the receiving and sending unit is configured to receive the first list information, and transmit the information to the refreshing unit; and send the received second list information to subscriber;

 The refresh creation unit refreshes the local subscription instance according to the received first list information, creates second list information, and transmits the created second list information to the receiving and transmitting unit.

 The method for implementing batch refresh in a subscription mechanism provided by the present invention improves the efficiency of refreshing the subscription instance by using the batch refresh mode, reduces the number of messages for refreshing subscriptions, and reduces the consumption of network bandwidth. The present invention also discloses a subscriber terminal and a notifier terminal to facilitate application of the method of the present invention.

DRAWINGS

 FIG. 1 is a schematic flowchart of a subscription and refresh process of the prior art;

 2 is a schematic flow chart of a first embodiment of a batch refresh according to a method of an embodiment of the present invention;

 3 is a flow chart showing a second embodiment of a batch refresh of a method in accordance with an embodiment of the present invention.

detailed description

 The preferred embodiments of the present invention will be described in detail below with reference to the accompanying drawings. A method for implementing batch refresh in a subscription mechanism according to an embodiment of the present invention implements a mechanism for batch refreshing multiple subscription instances.

A method based on the embodiment of the present invention is to newly extend a header field, which is used to deliver an identifier number of a subscription instance that needs to be refreshed or a call identification number Call-ID of a plurality of dialog dialogs, For example, if you name it SubJDList, its format definition can be, but is not limited to, the following:

 Sub_IDList = ("Sub_IDList") HCOLON (sub-idparam * (COMMA sub-idparam))

 Sub-idparam = sub-id I sub-idset/callid

 Sub-id - token

 Sub-idset = idmin "|" idmax

 Idmin = 1*DIGIT

 Idmax = 1 *DIGIT

 Token = l*(alp anum I "-" I "." I "!" I "%" I "*"

 J !T tl J,,+,' I,,", I,,", I,,~,, )

 Multiple sub-idparams are defined in the Sub-IDList, each sub-idparam is separated by a comma, sub-idparam represents a sub-id or sub-idset or callid, sub-id is a string, and the id of the subscription instance The definition is the same, sub-idset represents the range of a number, the two numbers are separated by a vertical number T, and the value of idmin must be less than the value of idmax, such as: 6 to 21, expressed as "6|21". Callid represents the value of the Call-ID that matches a dialog, as defined by the RJFC3261 standard. Based on the above expansion scheme, the identification number ID and the Call-ID of the subscription instance cannot exist in the Sub-IDList at the same time, that is, the identification number ID of the same dialog dialog or the call identification number Call-ID of the different dialog dialog.

 In order for the subscriber and the notifier to negotiate the use of the batch refresh mechanism of the subscription, it is also necessary to extend a SIP option-tag, such as the name "sub-batch-update", for the bulk refresh message initiated by the subscriber; Require The header field carries, indicating that the subscriber needs the notifier to support the batch refresh of the subscription.

The above method does not limit the SIP message that can carry the Sub-IDList header field. Such a message may be an existing message or a new message that is extended for batch refresh subscription. For refreshing the subscription instance associated with the same dialog, use the message in the dialog (that is, the message associated with the dialog); for refreshing the subscription instance associated with different dialo, use the message outside the dialog (that is, the message that is not associated with any dialog). As a message describing the embodiment, an UPDATE message may be used for refreshing a subscription instance associated with the same dialog; for refreshing a subscription instance associated with a different dialo, a SUBSCRIBE message outside the dialog may be used. The following uses the UPDATE message as a carrier carrying the Sub-IDList header field as an example to describe the processing of the Sub__IDList header field in the above method:

 The Subscriber creates a first list information header field, which is recorded as a Sub-IDList, and adds the header field to the UPDATE message, and adds the id of all active subscription instances of the same association to the same dialog to the Sub-IDList header field. , and keep the Sub-IDList header field locally, which is recorded as the local Sub_IDList. For the consecutive numeric form of the subscription instance id, the range representation can be used. See the definition of the Sub-IDList header field. .

 The Notifier receives the UPDATE message with the Sub-IDList header field, and matches the UPDATE message to the local dialog, and compares the subscription instance id from the Sub-IDList header field with the subscription instance id associated with the local matching dialog, and Create a new Sub-IDList header field, which is the second list information header field, denoted as Sub_IDList', add the different ids after comparison, and refresh the subscription instances corresponding to the same id, for consecutive numbers. The id of the form can be expressed in terms of scope.

 The Notifier creates an UPDATE response message, and adds the generated Sub-IDList as a new Sub-IDList header field to the UPDATE response message; the Subscriber receives the UPDATE response message, and extracts the subscription instance id one by one from the SubJDLisf header field. Compared with the local Sub-IDList, if they are the same, the local subscription instance corresponding to the id is released, and the corresponding id in the local Sub-IDList is deleted. After processing the id in the SubJDList' header field in the response message, the subscription instances associated with the remaining ids in the local Sub-IDList are refreshed one by one.

 The following uses a specific embodiment to illustrate the use of the newly extended two header fields in the batch refresh of the subscription, and the principle of the batch refresh mechanism to clearly illustrate the beneficial effects of the method of the present invention.

In this embodiment of the present invention, it is assumed that the Subscriber sends a plurality of subscription requests associated with the same dialog to the Notifier, and respectively generates a corresponding number of subscription instances on the Subscriber and the Notifier, and the id values of the instances are some characters in pure numbers. Strings, some are alphanumeric strings, between Subscriber and Notifier - corresponding. After a period of time, due to network anomalies, etc., the subscription instance id on Subscriber and Notifier does not correspond. The subscription instance id on Subscriber is {1|50, 55, 60, 68, 80 (200, al, Wwug, qerr}; The subscription instance id on Notifier is {20|50, 68, 80, 90|190, al, qerr}. The Notifier initiates a batch refresh of the subscription, uses UPDATE as the batch refresh message, and refreshes all IDs in two steps.

 As shown in FIG. 2, the batch refresh process based on the same dialog of the method of the present invention includes the following steps:

 (1), the Subscriber initiates a batch refresh of the subscription, and puts part of the local ID to be refreshed {1|50, 55, 60, 68} into the first list information Sub-IDList header field, and saves a copy locally. , recorded as a local Sub-IDList, carried by the UPDATE message, sent to the Notifier;

 (2) The Notifier receives the batch refresh request of the subscription initiated by the Subscriber, and extracts the id from the Sub-IDList header field one by one to compare with the local. If they are equal, the subscription instance of the id is updated; if not, the The ID is saved to a second list information Sub-IDList header field, which is recorded as Sub_IDList. After all the ids are processed, the Sub_IDList is obtained, and the header field is {1|19, 55, 60}, and the Sub-IDLisf header field is passed to the Subscriber through the 200 OK; after the Subscriber receives the 200 OK, the Sub from the The IDList' header field fetches the id one by one and compares the id in the local Sub_IDList in the Subscriber. If they are equal, the subscription instance corresponding to the id is released, and the corresponding id in the local Sub_IDList is deleted. Finally, the local Sub_IDList {20150, The subscription instance associated with the remaining id in 68} is refreshed.

 (3), Subscriber puts the ID {80|200, al, wwug, qerr} that needs to be refreshed in the rest of the local area into the Sub-IDList header field, and saves a copy locally, recorded as local Sub-IDList, by UPDATE message. Carry, send to Notifier;

 (4) The Notifier receives the batch refresh request of the subscription initiated by the Subscriber, and extracts the id from the Sub-IDList header field one by one to compare with the local. If they are equal, the subscription instance corresponding to the id is refreshed; if not, the id is saved. Go to a new Sub-IDList header field and record it as Sub-IDList. After processing all the ids, get a Sub-IDList, the header field is {81|89, 191)200, wwug}, and the Sub-IDList, the header field is passed to the Subscriber through the 200 OK; the Subscriber receives 200 ΟΚ^, The Sub-IDLisf header field is extracted one by one and compared with the id in the local Sub-IDList in the Subscriber. If they are equal, the subscription instance corresponding to the id is released, and the corresponding ID in the local SubjDList is deleted; finally, the local Sub_IDList{80 is successively changed. , 90|190, al, qerr} The remaining id associated subscription instance is refreshed.

The refresh subscription process based on different dialogs is shown in Figure 3, assuming Subscriber to Notifier Four subscription requests are sent, each subscription request is associated with a dialog, and four subscription instances are generated on Subscriber and Notifier respectively, and four different dialogs are associated. The Call-ID of the four dialogs is {843817637684230@998sdasdh09, Wwre42gd30@9943gdh09, 84381ffjj5i4230@23drtasdh09, adf54684230@55hdasdre}. Subscriber initiates a batch refresh of the subscription to Notifier, using SUBSCRIBE without any dialog as a batch refresh message. The basic steps include:

 (1) The Subscriber initiates a batch refresh of the subscription. The SUBSCRIBE message that associates multiple dialogs without being associated with any dialog carries the header field of the first list information SubJDList, and the Call-ID of the dailog corresponding to the subscription instance that needs to be refreshed locally. {843817637684230@998sdasdh09 , wwre42gd30@9943gdh09 , 84381 f3⁄4 5i4230@23drtasdh09 , adf54684230@55Masdre} , put the Sub-IDList header field, and save a copy locally, denoted as LocallDList, sent to Notifier;

 (2) The Notifier receives the batch refresh request of the subscription initiated by the Subscriber, and removes the call identification number Call-ID from the SubjDList header field to match the local dialog, and refreshes all the subscription instances associated with the matching dialog, which cannot match the dialog. The Call-ID is placed in the second list information Sub-IDList header field, which is recorded as LocallDList'. The four Call-IDs shown in Figure 3 can be matched to the local dialog, SubJDList, and the header field is empty. Send to Subscriber; Subscriber takes out the Sub-IDLisf header field carried by 200 OK and finds it is null. Therefore, the Call-ID in the local LocallDList is directly taken out, matched to the local dialog, and all subscription instances associated with the dialog are refreshed.

One of the key points of the above method is to perform Subscriber and Notifier localization by using a header field carrying a subscription instance ID based on the same dialog or a Call-ID based on different dialogs in the request message and its response message to interact between Subscriber and Notifier. A refresh of the subscription instance. Since the message body of the SIP request message and the response message can be used to transfer any data, another existing technical solution is to carry the id of the subscription instance and/or the Call of the dialog through the message body of the request message and the response message. ID. The encoding format of the message body can be in various ways such as text and XML. Here, the key point is that the content of the message body includes the subscription instance identifier. The call ID and/or the Call-ID of the dialog, as shown in Figure 2 (1) to (4), use the content carried in the Sub-IDList header field, and the message body in the XML-encoded format includes the following steps:

 Al, the subscriber will put the batch instance ID of the batch refresh and the Call-ID of the dialog associated with these IDs into a defined message body format, and adopt the above-mentioned XML subscription instance ID list message format, through a non- A message associated with any dialog is sent to the notifier, and the list is saved locally, recorded as LocallDLisL

 Bl, the notifier first takes out the Call-ID one by one from the message body, matches the local dialog, and if yes, saves the Call-ID, and then retrieves the ID of the subscription instance associated with the Call-ID one by one from the message body. And comparing the extracted ID with the subscription instance ID associated with the matching dialog. If they are equal, the subscription instance corresponding to the ID is refreshed, and if they are not equal, the subscription instance ID is saved.

 Cl, as above, repeatedly process all Call-IDs and subscription instance IDs in the message body, take out the Call-ID and subscription instance ID saved in the process, construct a new list of subscription instance IDs, record it as RemoteDDList, put 200 In the message body of OK, it is sent to the subscriber.

 Dl, the subscriber receives 200 O, firstly takes out the Call-ID one by one from the locally saved LocallDList, and compares it with the Call-ID in the RemoteDDList carried in the response message body. If they are equal, the Call-ID corresponding dialog and its association are released. If there is no equality, the subscription instance ID associated with the Call-ID is retrieved from the RemoteDDList one by one, and the subscription instance ID associated with the locally saved LocallDList is compared with the subscription ID of the Call-ID. If they are equal, the corresponding subscription is released. Instance, and delete the subscription instance ID in LocallDLis.

 El. After processing all the subscription instance IDs associated with the Call-ID in the RemotelDList, refresh the subscription instances corresponding to all the remaining subscription IDs associated with the Call-ID in the LocallDList. Repeatedly processing all Call-IDs in the locally saved LocallDList as above.

 The method of the present invention uses XML encoding to define a message format for a list of subscription instance IDs, as described below:

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

 <Subidlist xmlns=''um:ietf:params:xml:ns:subidlst"

 Xmlns:xsi="litt :〃 www.w3.org 2001/XMLSchema-instance"> <dialog callid= >

<id></id> <idset start= end= />

</dialog>

</Subidlist>

 The <Subidlist> element represents the root element, which is the starting point of the list of subscription instances, and may contain at least one <dialog> element under the root element; the <diak>g> element represents the dialog associated with the subscription instance, and has an attribute value callid, Indicates the Call-ID of the dialog, which can be matched to a dialog based on the attribute. The <dialog> element can contain at least one <1<1> or <3⁄4186{>, indicating the ID of the subscription instance associated with the dialog; the <id> element represents The ID of a subscription instance; the <idset> element represents the range of the ID of the subscription instance, and the value of the interval range must be a continuous positive integer with a step size of 1.

 An example of each message body in the embodiment will be described below, wherein the first message body of the subscription instance message associated with a dialog is as follows:

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

 <Subidlist mlns="urn:ietf:params:xml:ns:subidlst"

 Xmlns:xsi="http ://www.w3. org/2001 /XMLSchema-instance"> <dialog callid="wwre42gd30@9943 gdh09">

 <id> 55 </id>

 <id> 60 </id>

 <id> 68 </id>

 <idset start=l end=50 />

 </dialog>

 </Subidlist>

 The meaning of the above message body is: The subscriber sends a SIP message to the notifier to perform a batch refresh on the subscription, and the message body carries the subscription instance numbers 55, 60, 68, 1 to 50, and the subscription instance label that need to be batch refreshed. Associated session identification number wwre42gd30@9943gdh09;

The first 200 0K message body is: <?xml version-"1.0"encoding="UTF-8"?>

 <Subidlist xnilns="urn:ietf:params:xml:ns:subidlst"

 Xmlns:xsi="http:〃 www.w3.org/2001/XMLSchema-instance"> <dialog callid="wwre42gd30@9943gdh09 ">

 <id> 55 </id>

 <id> 60 </id>

 <idset start- 1 end=19 />

 </dialog>

 </Subidlist>

 The meaning of the above message body is: The notifier performs processing according to the session identification number and the subscription instance number carried in the batch refresh SIP message, and carries the processing result in the message body of the 200 OK response message, where the session identification number wwre42gd30@9943gdh09 indicates The session identifier of the locally matched activity of the notifier, the subscription instance number 55, 60, 1 to 19 indicates that the notifier has not matched the subscription instance locally;

 The second example of a message body that refreshes a subscribed instance message associated with a dialog is:

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

 <Subidlist xmlns="urn:ietf:params:xml".ns:subidlst"

 <dialog callid="wwre42gd30@9943gd 09">

 <id> al </id>

 <id> wwug </id>

 <id> qerr </id>

 <idset start=80 end=200 />

 </dialog>

 </Subidlist>

The meaning of the above message body is: The subscriber sends a SIP message carrying the local unrefreshed subscription instance identification number to the notifier to batch refresh the subscription, and the message body carries the subscription instance label a, wwug , qerr, 80 to 200, the session identification number associated with the subscription instance label wwre42gd30@9943gdh09; The second 200 OK message body is:

 <?腿1 version="1.0" encoding="UTF-8"?>

<Subidlist xmlns=''urn:ietf:params:xinl:ns:subidlst' ¹

Xmlns:xsi ^=, 'http://\vww.w3.org/200 l/XMLSchema-instance"><dialogcallid="wwre42gd30@9943gdh09">

 <id> wwug </id>

 <idset start=81 end=89 />

 <idset start=191 end=200 />

 </dialog>

 </Subidlist>

 The notifier performs the processing according to the session identification number and the subscription instance identifier carried in the batch refresh SIP message, and carries the processing result in the message body of the 200 OK response message, where the session identification number wwre42gd30@9943gdh09 represents the active session that matches the notifier locally. The identifier, the subscription instance label wwug, 81 to 89, and 191 to 200 indicate that the notifier has not matched the subscription instance locally;

 An example of refreshing a message body associated with multiple dialog subscription instances is:

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

 <Subidlist xmlns="urn:ietf:params:xml:ns:subidlst"

 Xmlns:xsi="http://www.w3.org/200 l/XMLSchema-instance"> <dialog callid="843817637684230@998sdasdh09">

 <id> 80 </id>

 </dialog>

 <dialog callid="wwre42gd30@9943gdh09">

 <id> aawe </id>

 </dialog>

 <dialog callid="84381f3⁄45i4230@23drtasdh09">

 <id> g5623 </id>

 </dialog>

<dialog callid="adf54684230@55hdasdre"> <id> 2311 </id>

 </dialog>

 </Subidlist>

 The meaning of the above message body is: The subscriber sends a SIP message to the notifier to perform a batch refresh on the subscription, and the message body carries the subscription instance number 80 and the associated session identification number 843817637684230@998sdasdh09, which are required to be batch refreshed, and the subscription instance number Aawe and the associated session identification number wwre42gd30@9943gd 09, subscription instance number g5623 and associated session identification number 84381f3⁄4j5i4230@23drtasdh09, subscription instance number 2311 and associated session identification number adf54684230@55hdasdre;

 The message body of its 200 OK response message is

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

 <Subidlist xmlns="urn:ietf:params:xml:ns:subidlst''

Xmlns:xsi= ^, 'http://www.w3.org/2001/XMLSchema-instance"><dialogcallid="843817637684230@998sdasd)9"></dialog>

 <dialog callid="wwre42gd30@9943gdh09">

 </dialog>

 <dialog callid="84381fgj5i4230@23drtasdh09">

 </dialog>

 <dialog callid="adf54684230@55hdasdre">

 <id> 2311 </id>

 </dialog>

 </Subidlist>

The meaning of the above message body is: The notifier performs processing according to the session identification number and the subscription instance number carried in the batch refresh SIP message, and carries the processing result in the message body of the 200 OK response message, where the session identification number is 843817637684230@998sdasdh09, wwre42gd30 @9943gdh09 , 84381f3⁄45i4230@23drtasdh09 , adf54684230@55Masdre indicates the session ID of the activity that matches the notifier locally. The first three session IDs above have no associated subscription instance ID, indicating that the subscriber needs to refresh the local and All instances of the subscription ID associated with the session identifier are associated with the instance, and 2311 indicates that the notifier has no matching subscription instance locally; that is, by the identification number 2311, this embodiment indicates that for the second list information, it can also be set to include only The conversation call identification number that matches the subscriber or/and the subscription instance identification number that does not match the subscriber corresponding to each of the conversations.

 In the above process, the processing flow of the subscriber and the notifier differs from the foregoing embodiment in that only the Call-ID of the dialog can be obtained from the list header field (determined by the technical solution), and therefore can only be based on the Call-ID. All subscription instances that match the dialog are refreshed. In the scheme of the message body, the Call-ID and the subscription instance ID of the dialog can be carried through the message body, so some subscription instances in the dialog can be selected to be refreshed.

 Of course, as a complete embodiment, it is also necessary to define a Type of Content-Type for the new message body format. For example, according to the syntax requirements of SIP, it can be defined as: application/sub-idlist+xml.

 Different from the foregoing solution of the first embodiment, the solution of the present invention can carry the subscription instance id and the Call-ID of the dialog through the message body, and can unify the two situations of the previous solution, and the size of the message body is not Restricted, it is a better solution than the previous one.

 Certainly, the body content of the method in the method of the present invention may only include the subscription instance id, so that all the subscription instance ids are associated with the same dialog, and may be delivered through a message associated with the dialog, such as UPDATE, which is the same as the foregoing scheme. Not to repeat. Similarly, the message body may also include only Call-IDs of different dialogs, which are transmitted through a message that is not associated with any dialog, which is the same as the foregoing scheme, and will not be described again.

 In summary, the method of the present invention improves the efficiency of refreshing a subscription instance, reduces the number of messages for refreshing subscriptions, and reduces the consumption of network bandwidth, especially when a proxy (Proxy) server subscribes to the same Notifier as a proxy of multiple Subscribers. This effect is especially noticeable. It can be understood that the subscriber and the notifier can be one terminal, and therefore, the present invention also provides a new subscriber terminal and notifier terminal.

 The embodiment of the invention discloses a subscriber terminal, which includes: a receiving and sending unit, a creating unit and a refreshing unit, where

The creating unit is configured to create the first list information and transmit it to the receiving and sending unit; The receiving and transmitting unit is configured to send the received first list information to the notifier; receive the second list information created by the notifier, and transmit the information to the refreshing unit;

 The refresh unit is configured to refresh the local subscription instance according to the received second list information.

 The first and second list information includes a subscription instance identification number corresponding to the subscriber or the notifier; or the first and second list information includes a conversation call identifier corresponding to the subscriber or the notifier. The number and the subscription instance identification number of each conversation, or only the conversation call identification number.

 The embodiment of the present invention further discloses a notifier terminal, which includes: a receiving and sending unit, and a refreshing unit, where

 The receiving and transmitting unit is configured to receive the first list information, and transmit the information to the refreshing unit; and send the received second list information to the subscriber;

 The refresh creation unit is configured to refresh the local subscription instance according to the received first list information, create second list information, and transmit the created second list information to the receiving and sending unit.

 The first and second list information includes a subscription instance identification number corresponding to the subscriber or the notifier; or the first and second list information includes a conversation call corresponding to the subscriber or the notifier. The identification number and the subscription instance identification number of each conversation, or only the conversation call identification number.

 The processing procedures of the subscriber terminal and the notifier terminal are the same as those described above, and are not described herein again.

 It should be understood that the above description of the specific embodiments is not to be construed as limiting the scope of the invention.

Claims

Rights request

 A method for implementing batch refresh in a subscription mechanism, which is used for interaction between a notifier and a subscriber, and includes the steps of:

 A. The subscriber creates the first list information and sends the information to the notifier.

B. The notifier refreshes the subscription instance local to the notifier according to the received first list information, and carries the second list information created by the notifier by using the response message;

 C. The subscriber refreshes the subscription instance local to the subscriber according to the received second list information.

 2. The method according to claim 1, wherein the first list information of the subscriber is transmitted through a header field or a message body of the batch refresh message.

 3. The method according to claim 2, wherein the batch refresh message is an existing session initiation protocol message or a new session initiation protocol message extended for batch refresh.

 The method according to claim 1, wherein the second list information of the notifier is transmitted through a header field or a message body of the response message.

 The method according to claim 1, wherein, when the same session is based, the first list information and the second list information include a subscription instance identifier corresponding to the subscriber or the notifier. number.

 The method according to claim 1, wherein, when the different dialogs are based, the first list information and the second list information include a conversation call corresponding to the subscriber or the notifier. The identification number and the subscription instance identification number of each conversation, or only the conversation call identification number.

 The method according to claim 5 or 6, wherein the second list information is further configured to include only the conversation call identification number that matches the subscriber or/and the corresponding location of each of the conversations. The subscriber does not match the subscription instance identification number.

 8. A method for implementing batch refresh in a subscription mechanism, used for interaction between a notifier and a subscriber, comprising the steps of:

Al, the subscriber creates a header field of the first list information, and adds the header field to the batch refresh message, where the first list information includes all the activities associated with the same session locally. The identification number of the subscription instance of the state;

 Bl, the notifier receives the batch refresh message with the first list information header field, and according to the batch refresh message, matches the local conversation, and extracts the subscription instance identification number and the local matching conversation one by one from the list information header field. The associated subscription instance identification number is compared, and a second list information header field is created, and the different identification numbers are added to the comparison, and the subscription instance corresponding to the same identification number is refreshed.

 The method according to claim 8, wherein the method further comprises:

Cl, the notifier creates a response message, and adds the generated second list information header field to the response message;

 Dl, the subscriber receives the response message, and compares the subscription instance identification numbers in the locally saved first list information one by one with the subscription instance identification number in the second list information header field in the response message, if the same, The local subscription instance corresponding to the identification number is released by the subscriber, and if not, the local subscription instance corresponding to the identification number is refreshed.

 10. A method for implementing batch refresh in a subscription mechanism, used for interaction between a notifier and a subscriber, comprising the steps of:

 A2, the subscriber creates a header field of the first list information, and adds the header field to the batch refresh message, where the first list information includes call identifiers of all active subscription instances that are locally associated with multiple conversations. number;

 B2. The notifier receives the batch refresh message with the first list information header field, matches the local call number according to the call identification number in the batch refresh message, and refreshes all the matched multiple sessions. The subscription instance adds the call identification number of the session that cannot be matched to the second list information header field, and sends the response message to the subscriber, and the subscriber refreshes the local subscription instance.

 The method according to claim 10, wherein the method further comprises: C2, the subscriber receiving the second list information header field in the response message, and parsing the call identification number corresponding thereto The dialog releases the subscription instances corresponding to the conversations, and refreshes the subscription instances corresponding to the other conversations in the first list information that are not equal to the second list information.

12. A method for implementing batch refresh in a subscription mechanism, used for interaction between a notifier and a subscriber, comprising the steps of: A3. The subscriber puts the subscription instance identification number that needs to be batch refreshed and the call identification number of the associated conversation into a message body, and saves the list locally, and records it as the first list information;

 B3. The notifier extracts the call identification number one by one from the message body, matches the local conversation, and if yes, saves the corresponding call identification number to the second list information, and retrieves the call identification number one by one from the message body. The identification number of the associated subscription instance is compared with the matching subscription instance identification number associated with the matched informant local conversation. If they are equal, the subscription instance corresponding to the identification number is refreshed, otherwise the subscription instance identification number is saved to the second list information;

 C3. The notifier puts the second list information into the message body of the response message, and sends the message to the subscriber for refreshing each subscription instance.

 The method according to claim 12, wherein the refreshing process further comprises: D3, the subscriber receives the response message, and extracts the call identification number and the response one by one from the locally saved first list information. Comparing call identification numbers in the second list information carried in the message body of the message;

 E3. If not equal, release the conversation corresponding to the call identification number and its associated subscription instance; if equal, then retrieve the subscription instance associated with the call identification number from the second list information one by one, and save the first one locally. The corresponding subscription instance identification number associated with the call identification number in the list information is compared;

 F3. If they are equal, the corresponding subscription instance is released, and the identification number of the subscription instance in the first list information is deleted;

 G3. After processing the second list information, refresh the subscription instance corresponding to all the subscription instance identification numbers remaining in the first list information.

 A subscriber terminal, comprising: a receiving and sending unit, a creating unit, and a refreshing unit, where

 The creating unit is configured to: create a first list information, and send the first list information to the receiving and sending unit; the receiving and sending unit, configured to send the received first list information to the notifier; and receive the second created by the notifier List information, transmitted to the refresh unit;

 The refresh unit refreshes the local subscription instance according to the received second list information.

15. A subscriber terminal according to claim 14 wherein: The first list information and the second list information include a subscription instance identification number corresponding to the subscriber or the notifier; or

 The first list information and the second list information include a conversation call identification number corresponding to the subscriber or the notifier and a subscription instance identification number of each conversation, or only a conversation call identification number.

 A notifier terminal, comprising: a receiving and sending unit, and a refresh creating unit, wherein

 The receiving and sending unit is configured to receive the first list information, and transmit the information to the refreshing unit; and send the received second list information to the subscriber;

 The refresh creation unit refreshes the local subscription instance according to the received first list information, creates second list information, and transmits the created second list information to the receiving and transmitting unit.

 17. The notifier terminal according to claim 16, wherein

 The first list information and the second list information include a subscription instance identification number corresponding to the subscriber or the notifier; or

 The first list information and the second list information include a conversation call identification number corresponding to the subscriber or the notifier and a subscription instance identification number of each conversation, or only a conversation call identification number.