STATUSES

FIELD OF THE INVENTION

[0001] The present invention relates to the field of internet technology, and in particular to the technology of obtaining HTTP message statuses.

BACKGROUND OF THE FNVENTATION

[0002] In the HTTP protocol, POST and GET are two most commonly used methods for performing request-response between clients and servers. Specifically, POST refers to posting to-be-processed data to a designated resource, while GET refers to requesting data from a designated resource.

[0003] In the current HTTP, the Conversation API is to provide easy access to IMS services and capabilities. As OMA RESTful Network Audio Call API defined, the application server can send a POST message to the corresponding side, so as to play a voice message (audio/video/text/VXML) to the participant at the corresponding side. To retrieve the message status, such as Pending, Playing, Played, Terminated or Error, the application sever need to periodically send a GET message with the resource ID, which is created for message playing and corresponding to the message.

[0004] The flaw of this method is obvious - the application server can't get the latest message status in real time.

[0005] For scenarios that need to perform further actions based on the latest message status, the application server can't achieve getting the latest message status in real time based on current specifications.

[0006] For example, the application server wants to play a message to the calling participant and route the call to another participant after the message played. The application server sends a POST message to play the message. To know whether the message is played or not, the application server needs to send a GET message often to get the message status. The application server doesn't know the duration for message playing. For example, as shown in Figure 1, suppose that the message lasts 2.5 minutes and application server sends a GET message every 1 minute. Then the application server can get the message status Played in third time (that is the 3rd minute), which is 0.5 minute later than the Played. The application server can't do anything to the calling participant in that 0.5 minute duration.

[0007] Therefore, it's unlikely for the application server to get the message status change in real time, which causes some kind of delay for some scenarios that need to perform further actions right after message status changed (such as Played). Then it's not friendly to end users.

SUMMARY OF THE INVENTION

[0008] An object of the invention is providing methods, devices and system for obtaining HTTP message statuses.

[0009] According to one aspect of the invention, a method, at a first device, for obtaining an HTTP message status is provided, wherein, the method comprises:

[0010] - sending a message status subscription notification to one or more second devices, wherein the message status subscription notification includes a notification identifier, a session identifier of a session between the first device and the second device, and one or more subscription message statuses;

[0011] - obtaining subscription response information sent by the second device, wherein the subscription response information includes one or more resource identifiers, the resource identifier corresponding to the session identifier;

[0012] wherein, the method further comprises:

[0013] - sending an execution message to the second device, wherein the execution message is corresponding to the resource identifier;

[0014] - obtaining a message status notification sent by the second device, wherein the message status notification matches the subscription message status.

[0015] According to another aspect of the invention, a method, at a second device, for obtaining an HTTP message status is provided, wherein, the method comprises:

[0016] - obtaining a message status subscription notification sent by a first device, wherein the message status subscription notification includes a notification identifier, a session identifier of a session between the first device and the second device, and one or more subscription message statuses;

[0017] - sending subscription response information to the first device, wherein the subscription response information includes one or more resource identifiers, the resource identifier corresponding to the session identifier;

[0018] wherein, the method further comprises:

[0019] - obtaining an execution message sent by the first device, wherein the execution message is corresponding to the resource identifier;

[0020] - checking whether the current message status matches the subscription message status;

[0021] - sending the message status notification to the first device when the message status matches the subscription message status.

[0022] According to another aspect of the invention, a first device for obtaining an HTTP message status is provided, wherein, the device comprises:

[0023] a subscription sending module configured to send a message status subscription notification to one or more second devices, wherein the message status subscription notification includes a notification identifier, a session identifier of a session between the first device and the second device, and one or more subscription message statuses;

[0024] a response obtaining module configured to obtain subscription response information sent by the second device, wherein the subscription response information includes one or more resource identifiers, the resource identifier corresponding to the session identifier;

[0025] wherein, the device further comprises:

[0026] an execution sending module configured to send an execution message to the second device, wherein the execution message is corresponding to the resource identifier;

[0027] a status obtaining module configured to obtain a message status notification sent by the second device, wherein the message status notification matches the subscription message status.

[0028] According to another aspect of the invention, a second device for obtaining an HTTP message status is provided, wherein, the device comprises:

[0029] a subscription obtaining module configured to obtain a message status subscription notification sent by a first device, wherein the message status subscription notification includes a notification identifier, a session identifier of a session between the first device and the second device, and one or more subscription message statuses;

[0030] a response sending module configured to send subscription response information to the first device, wherein the subscription response information includes one or more resource identifiers, the resource identifier corresponding to the session identifier;

[0031] wherein, the device further comprises:

[0032] an execution obtaining module configured to obtain an execution message sent by the first device, wherein the execution message is corresponding to the resource identifier;

[0033] a checking module configured to check whether the current message status matches the subscription message status;

[0034] a status sending module configured to send the message status notification to the first device when the message status matches the subscription message status.

[0035] According to another aspect of the invention, a system for obtaining an HTTP message status is provided, comprising a first device as aforesaid and a second device as aforesaid.

[0036] Compared with the prior art, in the present invention, a first device sends a message status subscription notification to one or more second devices, and obtains subscription response information sent by the second device; then, based on a resource identifier in the subscription response information, sends an execution message to the second device; when a message status notification matches the subscription message status, obtains the message status notification sent by the second device. Therefore, the present invention achieves that a first device obtains in real-time a message status of a second device, which avoids delay of the message status, enhances information processing efficiency, reduces resource waste, and enhances user experience.

[0037] Moreover, the present invention may also achieve that the first device sends a subscription check message to the second device, thereby checking whether the message status has been subscribed, which guarantees subsequent processing of the message status subscription.

[0038] Moreover, the present invention may also achieve that the first device sends a subscription deletion message to the second device, thereby deleting the message status subscription and completing a full processing procedure. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] Other features, purposes and advantages of the invention will become more explicit by means of reading the detailed statement of the non-restrictive embodiments made with reference to the accompanying drawings.

[0040] Fig. 1 shows a flow diagram of playing an HTTP audio message and checking a message status in the prior art;

[0041] Fig. 2 shows a schematic diagram of a first device and a second device for obtaining HTTP message statuses according to one aspect of the present invention;

[0042] Fig. 3 shows a flow diagram of a method for obtaining HTTP message statuses by cooperation of a first device and a second device according to another aspect of the present invention;

[0043] Fig. 4 shows a flow diagram of playing an HTTP audio message and checking a message status according to one preferred embodiment of the present invention.

[0044] The same or similar reference signs in the drawings represent the same or similar component parts. DETAILED DESCRIPTION OF THE INVENTION

[0045] Before discussing example embodiments in more detail, it is noted that some example embodiments are described as processes or methods depicted as flowcharts. Although the flowcharts describe the operations as sequential processes, many of the operations may be performed in parallel, concurrently or simultaneously. In addition, the order of operations may be re-arranged. The processes may be terminated when their operations are completed, but may also have additional steps not included in the figures. The processes may correspond to methods, functions, procedures, subroutines, subprograms, etc.

[0046] The "first device" or "second device" herein comprises any computer device that can perform information processing. Here, the "computer device" (or called "computer") refers to an intelligent electronic device that performs predetermined processing processes such as numerical value calculations and/or logical calculations by running predetermined programs or instructions, which may comprise a processor and a memory. The predetermined processing process is executed by the processor through executing program instructions pre-stored in a memory, or the predetermined processing process is executed by hardware such as ASIC, FPGA, DSP, etc., or the predetermined processing process is executed by a combination of both. The computer device includes, but not limited to, server, personal computer, lab top, tablet personal computer, smartphone, etc...

[0047] The computer device includes network device(s) and user device(s), that is, the first device or the second device described in the present invention includes such as application server(s) or user device(s). Here, the user device includes, but not limited to, personal computers, smart phones, PDAs and son on. The network device includes, but not limited to, single network server, a server group formed by a set of multiple network servers or a cloud network formed by multiple servers, herein, the cloud network is formed by a large number of computers or network servers based on Cloud Computing, wherein, the cloud computing is a kind of distributed computing, which is a virtual supercomputer consisting of a group of loosely coupled computers set. Wherein, the computer device may run separately to implement the present invention, or implement the present invention through interaction operations with other computer devices in the network by accessing the network. The network of the computer device includes, but not limited to, the Internet, Wide Area Network, Metropolitan Area Network, LAN, VPN, wireless self-organizing, etc.

[0048] It should be noted that the user device, network device, and network are only examples, and other existing or future possibly emerging computer device or network, if applicable to the present invention, should also be included within the protection scope of the present invention and is incorporated here by reference.

[0049] Specific structural and functional details disclosed herein are merely representative for purposes of describing example embodiments of the present invention. This invention may, however, be embodied in many alternate forms and should not be construed as limited to only the embodiments set forth herein.

[0050] It should also be noted that in some alternative implementations, the functions/acts noted may occur out of the order noted in the figures. For example, two figures shown in succession may in fact be executed concurrently or may sometimes be executed in the reverse order, depending upon the functionality/acts involved.

[0051] Below, details of the invention will be further provided in combination with the accompanying drawings.

[0052] Fig. 2 shows a schematic diagram of a first device and a second device for obtaining HTTP message statuses according to one aspect of the present invention; wherein, the first device 1 comprises a subscription sending module 11, a response obtaining module 12, an execution sending module 13, a status obtaining module 14, the second device 2 comprises a subscription obtaining module 21, a response sending module 22, an execution obtaining module 23, a checking module 24, a status sending module 25.

[0053] Specifically, the subscription sending module 11 of the first device 1 sends a message status subscription notification to one or more second devices, wherein the message status subscription notification includes a notification identifier, a session identifier of a session between the first device and the second device, and one or more subscription message statuses; correspondingly, the subscription obtaining module 21 of the second device 2 obtains a message status subscription notification sent by the first device, wherein the message status subscription notification includes a notification identifier, a session identifier of a session between the first device and the second device, and one or more subscription message statuses; then, the response sending module 22 sends subscription response information to the first device, wherein the subscription response information includes one or more resource identifiers, the resource identifier corresponding to the session identifier; correspondingly, the response obtaining module 12 of the first device 1 obtains subscription response information sent by the second device, wherein the subscription response information includes one or more resource identifiers, the resource identifier corresponding to the session identifier; the execution sending module 13 sends an execution message to the second device, wherein the execution message is corresponding to the resource identifier; correspondingly, the execution obtaining module 23 obtains an execution message sent by the first device, wherein the execution message is corresponding to the resource identifier; the checking module 24 checks whether the current message status matches the subscription message status; when the message status matches the subscription message status, the status sending module 25 sends the message status notification to the first device 1; correspondingly, the status obtaining module 14 of the first device 1 obtains a message status notification sent by the second device, wherein the message status notification matches the subscription message status.

[0054] Here, the message status obtained by the present invention is an HTTP message status; here, the HTTP message includes, but not limited to, any kind of HTTP message that is transmitted based on the HTTP protocol and needs a certain execution time, e.g., a voice message, a video message, a picture message, a textual message, a VXML message, etc. For example, when the HTTP message is a voice message/ video message, the peer may play the voice message/ video message, which needs a certain play time; when the HTTP message is a textual message, the peer may convert it to an audio message that needs to be played and then play; when the HTTP message is a picture message, the peer may cyclically show one or more pictures, which needs a certain presentation time, etc.

[0055] Preferably, the HTTP message is a RESTful network message; more preferably, the HTTP message is a RESTful network voice message.

[0056] The subscription sending module 11 of the first device 1 sends a message status subscription notification to one or more second devices; correspondingly, the subscription obtaining module 21 of the second device 2 obtains a message status subscription notification sent by the first device, wherein the message status subscription notification includes a notification identifier, a session identifier of a session between the first device and the second device, and one or more subscription message statuses.

[0057] Specifically, the subscription sending module 11 first sends a message status subscription notification to the second device before sending an execution message based on the method of sending a message in the HTTP protocol, e.g., the POST method so as to complete a message status subscription between the first device and the second device. Here, the message status subscription notification includes a notification identifier, a session identifier of a session between the first device and the second device, and one or more subscription message statuses.

[0058] Here, the notification identifier is an identifier which is used for uniquely identifying the notification, e.g., notification URL. The session identifier is an identifier which is used for uniquely identifying the session between two or more devices. Here, the session may be a session between one or more first devices and one or more second devices; the session identifier may be defined through for example a call session identifier or defined according to resource identification (e.g., resource URL).

[0059] Here, the subscription message status includes, but not limited to, one or more message statuses the first device desires to obtain, e.g., pending, executing, executed, error, terminated, etc. Preferably, with the example of playing a voice message, the subscription message status includes, but not limited to, at least any one of the following: pending, playing, played, error, terminated. If the subscription message status is not designated, a default status (e.g., any of the above message statuses) may be used as the subscription message status.

[0060] Here, those skilled in the art should understand that, the message status subscription notifications above are only exemplary, not intended to limit the present invention. Other notification identifiers, session identifiers or subscription message statuses, if applicable to the present invention, are likewise included within the protection scope of the present invention.

[0061] Preferably, the message status subscription notification may also comprise at least any one of the following:

[0062] - Type of subscribed messages, e.g., text, audio, video, picture, VXML, etc. If the subscribed message type is not designated, a default message type (any of the above messages) may be used as the subscribed message type.

[0063] - Session address of the session, e.g., SIP URL, TEL URL, ACR URL and the like of one or more parties participating in the session; if the session address is not designated, the transmitted message will be provided to all participants in the session.

[0064] - Resource recovery identifier of the resource. Here, the resource includes, but not limited to, any voice, video, text, picture, VXMAL, etc.; the resource recovery identifier allows the user to recover from a communication failure during the resource creation period, thereby avoiding twice identical subscription in the case of communication failure, as an example.

[0065] - Self referring resource identifier, e.g., self referring URL. Based on the self referring resource identifier, a full resource may be returned based on any HTTP method.

[0066] Then, the response sending module 22 sends subscription response information to the first device; correspondingly, the response obtaining module 12 of the first device 1 obtains subscription response information sent by the second device, wherein the subscription response information includes one or more resource identifiers, the resource identifier corresponding to the session identifier.

[0067] Specifically, the response sending module 22 sends subscription response information to the response obtaining module 12 of the first device based on a corresponding HTTP protocol, the response indicating that a request from the first device 1 has been fulfilled and a new resource has been established based on the message status subscription notification, e.g., 201 Created Response. Here, the subscription response information includes one or more resource identifiers, e.g., resource URL. The resource identifier corresponds to the session identifier of the first device and second device, which indicating that the resource identifier is a resource in the session. [0068] The execution sending module 13 sends an execution message to the second device; correspondingly, the execution obtaining module 23 obtains an execution message sent by the first device, wherein the execution message is corresponding to the resource identifier.

[0069] Specifically, the execution sending module 13 sends the execution message to the execution obtaining module 23 of the second device based on the corresponding HTTP protocol. Here, the execution message includes, but not limited to, any kind of operations for executing the resource corresponding to the resource identifier. For example, when the message is a voice message, the "execution" is a play operation; when the message is a non-voice message, the "execution" is other operation that activates playing/running the message. Here, the resource identifier is the resource identifier sent in the response sending module 22.

[0070] When the execution obtaining module 23 obtains the execution message, the resource identified by the resource identifier may be executed based on information such as the execution operation and/or execution time sent in the execution message, e.g., playing the voice message.

[0071] The checking module 24 checks whether the current message status matches the subscription message status; when the message status matches the subscription message status, the status sending module 25 sends the message status notification to the first device 1; correspondingly, the status obtaining module 14 of the first device 1 obtains a message status notification sent by the second device.

[0072] Specifically, the checking module 24 checks a message status of a resource corresponding to the resource identifier based on the subscription message status. Once the message status matches the subscription message status, e.g., from pending to playing, and from playing to played, then the status sending module 25 will notify, based on the subscription message status, the corresponding message status to the status obtaining module of the first device based on the corresponding HTTP protocol, wherein the message status notification includes a current message status of the message; in this way, the first device can obtain in real-time the latest message status notification.

[0073] Preferably, the message status notification further comprises at least any one of the following:

[0074] - a status which triggers the message status notification, e.g., when the message changes from "playing" to "played," the status in the message status notification is "played," thereby the status which triggers the message status notification is "playing."

[0075] - a message type corresponding to the message status notification, e.g., text, audio, video, picture, VXML, etc.

[0076] - a session identifier of the session between the first and the second devices, e.g., defined for example through a call session identifier or defined according to the resource identifier (e.g., resource URL).

[0077] - other associated resources associated with the resource identifier, e.g., other resources (e.g., associated subscriptions, associated call sessions) associated with the current resource. [0078] - a session address associated with the message status, e.g., SIP URL, TEL URL, ACR URL, and the like of one or more parties participating in the session; if the session address is not designated, the transmitted message is provided to all participants in the session.

[0079] - callback data, i.e., when a message status subscription notification is created, the callback data may be transmitted through an application.

[0080] Preferably, the first device further comprises a check sending module(not shown); correspondingly, the second device further comprises a check obtaining module(not shown), a subscription check module(not shown). Specifically, the check sending module sends a subscription check message to the second device, wherein the subscription check message includes the resource identifier; correspondingly, the check obtaining module obtains a subscription check message sent by the first device, wherein the subscription check message includes the resource identifier; the subscription check module checks whether the resource corresponding to the resource identifier has been subscribed based on the subscription check message.

[0081] Specifically, the check sending module may send a subscription check message to the second device based on the corresponding HTTP protocol, e.g., through the GET method, the subscription check message including the resource identifier sent by the response sending module 22. In this way, after the check obtaining module obtains the subscription check message, it is checked whether the resource corresponding to the resource identifier has been subscribed, thereby sending a corresponding notification to the first device; the first device may perform subsequent operations; for example, in the case of no subscription, then a subscription notification will be re-sent.

[0082] Preferably, the first device further comprises a deletion sending module (not shown); correspondingly, the second device further comprises a deletion obtaining module (not shown) and a deleting module (not shown). Specifically, the deletion sending module sends a subscription deletion message to the second device, wherein the subscription deletion message includes the resource identifier and/or the session identifier; correspondingly, the deletion obtaining module obtains a subscription deletion message sent by the first device, wherein the subscription deletion message includes the resource identifier and/or the session identifier; the deleting module deletes, based on the subscription deletion message, the message status subscription notification corresponding to the resource identifier and/or the session identifier, the resource identifier and/or the session identifier corresponding to the subscription deletion message.

[0083] Specifically, the deletion sending module may send a subscription deletion message to the second device based on a corresponding HTTP protocol, e.g., through the DELETE method; here, if the first device wishes to cancel a subscription to a certain resource, the resource identifier will be included in the subscription deletion message; after the deletion obtaining module obtains the subscription deletion message, the deletion module cancels the subscription to the message status of the resource; if the first device wishes to cancel a subscription to a certain session, the session identifier is included in the subscription deletion message; after the deletion obtaining module obtains the subscription deletion message, the deletion module cancels the subscription to the message status of the session.

[0084] Here, those skilled in the art should understand that one session may include one or more resources; if a message status subscription for a session is deleted, the message status subscription will not be executed for the entire session; if a message status subscription for a resource is deleted, the message status subscription is continued to execute for other resources of the session, and the first device can still obtain the message status notification of other resources in the session.

[0085] Fig. 3 shows a flow diagram of a method for obtaining HTTP message statuses by cooperation of a first device and a second device according to another aspect of the present invention. Specifically, in the step SI, the first device 1 sends a message status subscription notification to one or more second devices, wherein the message status subscription notification includes a notification identifier, a session identifier of a session between the first device and the second device, and one or more subscription message statuses; correspondingly, in the step SI, the second device 2 obtains a message status subscription notification sent by the first device, wherein the message status subscription notification includes a notification identifier, a session identifier of a session between the first device and the second device, and one or more subscription message statuses; then, in the step S2, the second device 2 sends subscription response information to the first device, wherein the subscription response information includes one or more resource identifiers, the resource identifier corresponding to the session identifier; correspondingly, in the step S2, the first device 1 obtains subscription response information sent by the second device, wherein the subscription response information includes one or more resource identifiers, the resource identifier corresponding to the session identifier; in the step S3, the first device 1 sends an execution message to the second device, wherein the execution message is corresponding to the resource identifier; correspondingly, in the step S3, the second device 2 obtains an execution message sent by the first device, wherein the execution message is corresponding to the resource identifier; in the step S4, the second device 2 checks whether the current message status matches the subscription message status; when the message status matches the subscription message status, in the step S5, the second device 2 sends the message status notification to the first device 1; correspondingly, in the step S5, the first device 1 obtains a message status notification sent by the second device, wherein the message status notification matches the subscription message status.

[0086] Here, the message status obtained by the present invention is an HTTP message status; here, the HTTP message includes, but not limited to, any kind of HTTP message that is transmitted based on the HTTP protocol and needs a certain execution time, e.g., a voice message, a video message, a picture message, a textual message, a VXML message, etc. For example, when the HTTP message is a voice message/ video message, the peer may play the voice message/ video message, which needs a certain play time; when the HTTP message is a textual message, the peer may convert it to an audio message that needs to be played and then play; when the HTTP message is a picture message, the peer may cyclically show one or more pictures, which needs a certain presentation time, etc.

[0087] Preferably, the HTTP message is a RESTful network message; more preferably, the HTTP message is a RESTful network voice message.

[0088] In the step SI, the first device 1 sends a message status subscription notification to one or more second devices; correspondingly, in the step SI, the second device 2 obtains a message status subscription notification sent by the first device, wherein the message status subscription notification includes a notification identifier, a session identifier of a session between the first device and the second device, and one or more subscription message statuses.

[0089] Specifically, in the step SI, the first device 1 first sends a message status subscription notification to the second device before sending an execution message based on the method of sending a message in the HTTP protocol, e.g., the POST method so as to complete a message status subscription between the first device and the second device. Here, the message status subscription notification includes a notification identifier, a session identifier of a session between the first device and the second device, and one or more subscription message statuses.

[0090] Here, the notification identifier is an identifier which is used for uniquely identifying the notification, e.g., notification URL. The session identifier is an identifier which is used for uniquely identifying the session between two or more devices. Here, the session may be a session between one or more first devices and one or more second devices; the session identifier may be defined through for example a call session identifier or defined according to resource identification (e.g., resource URL).

[0091] Here, the subscription message status includes, but not limited to, one or more message statuses the first device desires to obtain, e.g., pending, executing, executed, error, terminated, etc. Preferably, with the example of playing a voice message, the subscription message status includes, but not limited to, at least any one of the following: pending, playing, played, error, terminated. If the subscription message status is not designated, a default status (e.g., any of the above message statuses) may be used as the subscription message status.

[0092] Here, those skilled in the art should understand that, the message status subscription notifications above are only exemplary, not intended to limit the present invention. Other notification identifiers, session identifiers or subscription message statuses, if applicable to the present invention, are likewise included within the protection scope of the present invention.

[0093] Preferably, the message status subscription notification may also comprise at least any one of the following:

[0094] - Type of subscribed messages, e.g., text, audio, video, picture, VXML, etc. If the subscribed message type is not designated, a default message type (any of the above messages) may be used as the subscribed message type.

[0095] - Session address of the session, e.g., SIP URL, TEL URL, ACR URL and the like of one or more parties participating in the session; if the session address is not designated, the transmitted message will be provided to all participants in the session.

[0096] - Resource recovery identifier of the resource. Here, the resource includes, but not limited to, any voice, video, text, picture, VXMAL, etc.; the resource recovery identifier allows the user to recover from a communication failure during the resource creation period, thereby avoiding twice identical subscription in the case of communication failure, as an example.

[0097] - Self referring resource identifier, e.g., self referring URL. Based on the self referring resource identifier, a full resource may be returned based on any HTTP method.

[0098] Then, in the step S2, the second device 2 sends subscription response information to the first device; correspondingly, in the step S2, the first device 1 obtains subscription response information sent by the second device, wherein the subscription response information includes one or more resource identifiers, the resource identifier corresponding to the session identifier.

[0099] Specifically, in the step S2, the second device 2 sends subscription response information to the first device based on a corresponding HTTP protocol, the response indicating that a request from the first device 1 has been fulfilled and a new resource has been established based on the message status subscription notification, e.g., 201 Created Response. Here, the subscription response information includes one or more resource identifiers, e.g., resource URL. The resource identifier corresponds to the session identifier of the first device and second device, which indicating that the resource identifier is a resource in the session.

[00100] In the step S3, the first device 1 sends an execution message to the second device; correspondingly, in the step S3, the second device 2 obtains an execution message sent by the first device, wherein the execution message is corresponding to the resource identifier.

[00101] Specifically, in the step S3, the first device 1 sends the execution message to the second device based on the corresponding HTTP protocol. Here, the execution message includes, but not limited to, any kind of operations for executing the resource corresponding to the resource identifier. For example, when the message is a voice message, the "execution" is a play operation; when the message is a non-voice message, the "execution" is other operation that activates playing/running the message. Here, the resource identifier is the resource identifier sent in the step S2.

[00102] When the second device 2 obtains the execution message, the resource identified by the resource identifier may be executed based on information such as the execution operation and/or execution time sent in the execution message, e.g., playing the voice message.

[00103] In the step S4, the second device 2 checks whether the current message status matches the subscription message status; when the message status matches the subscription message status, in the step S5, the second device 2 sends the message status notification to the first device 1; correspondingly, in the step S5, the first device 1 obtains a message status notification sent by the second device.

[00104] Specifically, in the step S4, the second device 2 checks a message status of a resource corresponding to the resource identifier based on the subscription message status. Once the message status matches the subscription message status, e.g., from pending to playing, and from playing to played, then in the step S5, the second device 2 will notify, based on the subscription message status, the corresponding message status to the first device based on the corresponding HTTP protocol, wherein the message status notification includes a current message status of the message; in this way, the first device can obtain in real-time the latest message status notification.

[00105] Preferably, the message status notification further comprises at least any one of the following:

[00106] - a status which triggers the message status notification, e.g., when the message changes from "playing" to "played," the status in the message status notification is "played," thereby the status which triggers the message status notification is "playing."

[00107] - a message type corresponding to the message status notification, e.g., text, audio, video, picture, VXML, etc.

[00108] - a session identifier of the session between the first and the second devices, e.g., defined for example through a call session identifier or defined according to the resource identifier (e.g., resource URL).

[00109] - other associated resources associated with the resource identifier, e.g., other resources (e.g., associated subscriptions, associated call sessions) associated with the current resource.

[00110] - a session address associated with the message status, e.g., SIP URL, TEL URL, ACR URL, and the like of one or more parties participating in the session; if the session address is not designated, the transmitted message is provided to all participants in the session.

[00111] - callback data, i.e., when a message status subscription notification is created, the callback data may be transmitted through an application.

[00112] Preferably, the method further comprises a step S6(not shown) and a step S7(not shown). Specifically, in the step S6, the first device 1 sends a subscription check message to the second device, wherein the subscription check message includes the resource identifier; correspondingly, in the step S6, the second device 2 obtains a subscription check message sent by the first device, wherein the subscription check message includes the resource identifier; in the step S7, the second device checks whether the resource corresponding to the resource identifier has been subscribed based on the subscription check message.

[00113] Specifically, the first device 1 may send a subscription check message to the second device based on the corresponding HTTP protocol, e.g., through the GET method, the subscription check message including the resource identifier sent by the step S2. In this way, after the second device 2 obtains the subscription check message, it is checked whether the resource corresponding to the resource identifier has been subscribed, thereby sending a corresponding notification to the first device; the first device may perform subsequent operations; for example, in the case of no subscription, then a subscription notification will be re-sent.

[00114] Preferably, the method further comprises a step S8 (not shown) and a step S9 (not shown). Specifically, in the step S8, the first device 1 sends a subscription deletion message to the second device, wherein the subscription deletion message includes the resource identifier and/or the session identifier; correspondingly, in the step S8, the second device 2 obtains a subscription deletion message sent by the first device, wherein the subscription deletion message includes the resource identifier and/or the session identifier; in the step S9, the second device deletes, based on the subscription deletion message, the message status subscription notification corresponding to the resource identifier and/or the session identifier, the resource identifier and/or the session identifier corresponding to the subscription deletion message.

[00115] Specifically, in the step S8, the first device 1 may send a subscription deletion message to the second device based on a corresponding HTTP protocol, e.g., through the DELETE method; here, if the first device wishes to cancel a subscription to a certain resource, the resource identifier will be included in the subscription deletion message; after the second device 2 obtains the subscription deletion message, the second device 2 cancels the subscription to the message status of the resource; if the first device wishes to cancel a subscription to a certain session, the session identifier is included in the subscription deletion message; after the second device 2 obtains the subscription deletion message, the second device 2 cancels the subscription to the message status of the session.

[00116] Here, those skilled in the art should understand that one session may include one or more resources; if a message status subscription for a session is deleted, the message status subscription will not be executed for the entire session; if a message status subscription for a resource is deleted, the message status subscription is continued to execute for other resources of the session, and the first device can still obtain the message status notification of other resources in the session.

[00117] Fig. 4 shows a flow diagram of playing an HTTP audio message and checking a message status according to one preferred embodiment of the present invention.

[00118] Here, Fig. 4 performs execution based on the HTTP protocol, and preferably, based on the RESTful Network Audio Call API. The first device may be an application server or other device, and the second device may be other device participating in the session. At the ease of depiction, the HTTP message transmitted here is an audio message. Those skilled in the art should understand that other HTTP messages are likewise applicable to the present invention, which will not be detailed here, but incorporated here by reference.

[00119] In the step S41, the first device sends a message status subscription notification to the second device; here, the sending method may be a POST method. The format of the sent message status subscription notification may be shown as follows:

[00120] POST/ {serverRoot}/callnotificaiton/ {apiVersion}/subscriptions/messageStat us HTTP/ {version}

[00121] That is "POST/ root directory of the server/call notification/API version/subscriptions/type of the HTTP message status/content"

[00122] The message status subscription notification includes a header and a body; the body includes a notification identifier (e.g., notification URL), a session identifier of a session between the first device and the second device, and one or more subscription message statuses. Preferably, the body may also comprise one or more of the following: the type of subscribed messages, the session address of the session, the resource recovery identifier of the resource, and the self referring resource identifier.

[00123] Here, the contents above are identical or similar to that in Fig.2 or Fig. 3, which will not be detailed here.

[00124] In the step S42, the second device performs response based on the created resource (i.e., audio); for example, it may send a 201 Created Response that carriers the corresponding created resource URL. With the URL, the first device may manage the message status subscription, e.g., sending a subscription check message using the GET method, and sending a subscription deletion message using the DELETE.

[00125] The transmitted response format may be shown as follows:

[00126] / {serverRoot}/callnotificaiton/ {apiVersion}/subscriptions/messageStatus/msO 1 )

[00127] That is "root directory of the server/call notification/API version/subscriptions/message status/resource identifier"

[00128] In the step S43, the first device sends a POST message to play the audio message. Correspondingly, in the step S44, the second device performs response based on the created resource, i.e., playing the message.

[00129] In the step S45, the second device sends a message status notification (i.e., playing) to the first device through a POST method based on the current message status; correspondingly, in the step S46, the first device sends a 204 No Content Response to the second device, i.e., notifying the second device that the current request has succeeded.

[00130] Here, the POST message format for the message status notification may be shown as follows:

[00131] POST {MessageStatusNotificationURL}

[00132] That is "POST {Message Status Notification URL}

[00133] The message status notification includes a header and a body. The body comprises a message status to be notified, e.g., "playing"; preferably, the body further comprises one or more of the following: the session identifier of the session between the first device and the second device, other associated resources associated with the resource identifier, the session address associated with the message status, callback data.

[00134] Here, the contents above are identical or similar to that in Fig.2 or Fig. 3, which will not be detailed here.

[00135] In the step S47, because the audio message has been played, the second device sends a message status notification (i.e., played) to the first device through the POST method based on the current message status; correspondingly, in the step S48, the first device sends 204 No Content Response to the second device, i.e., notifying the second device that the current request has succeeded.

[00136] Therefore, the first device can promptly obtain the latest message status notification.

[00137] Here, those skilled in the art should understand that the message transmission formats above are only exemplary, not intended to limit the present invention. Other message transmission formats capable of implementing the above functions are applicable to the present invention and incorporated herein by reference.

[00138] It should be noted that the present invention may be implemented in software and/or a combination of software and hardware, for example, it may be implemented by an application-specific integrated circuit (ASIC), a general purpose computer or any other similar hardware device. In one embodiment, the software program of the present invention may be executed through a processor to implement the steps or functions as mentioned above. Likewise, the software program of the present invention (including relevant data structure) may be stored in the computer-readable recording medium, for example, RAM memory, magnetic or optic driver or flappy disk or similar devices. Besides, some steps or functions of the present invention may be implemented by hardware, for example, as a circuit cooperating with the processor to execute various steps or functions.

[00139] Besides, a part of the present invention may be applied as a computer program product, e.g., computer program instructions, which, when being executed by the computer, may invoke or provide the method and/or technical solution according to the present invention through operations of the computer, while the program instructions for invoking the method of the present invention may be stored in a fixed or mobile recording medium, and/or transmitted through broadcast or a data stream in other signal carrier medium, and/or stored in a work memory of a computer device running based on the program instructions. Here, one embodiment according to the present invention comprises an apparatus, which comprising a memory for storing the computer program instructions and a processor for executing the program instructions, wherein when the computer program instructions are executed by the processor, the apparatus is triggered to run the above mentioned methods and/or technical solutions according to multiple embodiments of the present invention.

[00140] To those skilled in the art, it is apparent that the present invention is not limited to the details of above exemplary embodiments, and the present invention can be implemented with other specific embodiments without departing the spirit or basic features of the present invention. Thus, from any perspective, the embodiments should be regarded as illustrative and non-limiting. The scope of the present invention is limited by the appended claims, instead of the above description. Thus, meanings of equivalent elements falling within the claims and all variations within the scope are intended to be included within the present invention. Any reference numerals in the claims should not be regarded as limiting the involved claims. Besides, it is apparent that such terms as "comprise" and "include" do not exclude other units or steps, and a single form does not exclude a plural form. The multiple units or modules as stated in apparatus claims can also be implemented by a single unit or module through software or hardware. Terms such as first and second are used to represent names, not representing any specific sequence.

[00141] Although exemplary embodiments have been particularly shown and described above, those skilled in the art will understand that without departing from the spirit and scope of the claims, their forms and details may vary. The protections as sought here are illustrated in the appended claims. In the following numbered clauses, these and other aspects of various embodiments have been described:

[00142] 1. A method, at a first device, for obtaining an HTTP message status, wherein, the method comprises:

[00143] - sending a message status subscription notification to one or more second devices, wherein the message status subscription notification includes a notification identifier, a session identifier of a session between the first device and the second device, and one or more subscription message statuses;

[00144] - obtaining subscription response information sent by the second device, wherein the subscription response information includes one or more resource identifiers, the resource identifier corresponding to the session identifier;

[00145] wherein, the method further comprises:

[00146] - sending an execution message to the second device, wherein the execution message is corresponding to the resource identifier;

[00147] - obtaining a message status notification sent by the second device, wherein the message status notification matches the subscription message status.

[00148] 2. The method according to clause 1, wherein the method further comprises:

[00149] - sending a subscription check message to the second device, wherein the subscription check message includes the resource identifier.

[00150] 3. The method according to clause 1 or 2, wherein the method further comprises:

[00151] - sending a subscription deletion message to the second device, wherein the subscription deletion message includes the resource identifier and/or the session identifier.

[00152] 4. The method according to any one of clauses 1-3, wherein the message status subscription notification further includes at least one of the following:

[00153] - type of subscribed messages;

[00154] - session address of the session;

[00155] - resource recovery identifier of the resource;

[00156] - self referring resource identifier.

[00157] 5. The method according to any one of clauses 1-4, wherein the HTTP message is a voice message.

[00158] 6. The method according to clause 5, wherein the HTTP message is a Restful network voice message.

[00159] 7. A method, at a second device, for obtaining an HTTP message status, wherein, the method comprises:

[00160] - obtaining a message status subscription notification sent by a first device, wherein the message status subscription notification includes a notification identifier, a session identifier of a session between the first device and the second device, and one or more subscription message statuses;

[00161] - sending subscription response information to the first device, wherein the subscription response information includes one or more resource identifiers, the resource identifier corresponding to the session identifier;

[00162] wherein, the method further comprises:

[00163] - obtaining an execution message sent by the first device, wherein the execution message is corresponding to the resource identifier;

[00164] - checking whether the current message status matches the subscription message status;

[00165] - sending the message status notification to the first device when the message status matches the subscription message status.

[00166] 8. The method according to clause 7, wherein, the method further comprises:

[00167] - obtaining a subscription check message sent by the first device, wherein the subscription check message includes the resource identifier;

[00168] - checking whether the resource corresponding to the resource identifier has been subscribed based on the subscription check message.

[00169] 9. The method according to clause 7 or 8, wherein, the method further comprises:

[00170] - obtaining a subscription deletion message sent by the first device, wherein the subscription deletion message includes the resource identifier and/or the session identifier;

[00171] - deleting, based on the subscription deletion message, the message status subscription notification corresponding to the resource identifier and/or the session identifier, the resource identifier and/or the session identifier corresponding to the subscription deletion message.

[00172] 10. The method according to any one of clauses 7-9, wherein the message status notification further includes at least any one of the following:

[00173] - session identifier of the session between the first device and the second device;

[00174] - other associated resources associated with the resource identifier;

[00175] - session address associated with the message status;

[00176] - callback data.

[00177] 11. The method according to any one of clauses 7-10, wherein the HTTP message is a voice message.

[00178] 12. The method according to clause 11, wherein the HTTP message is a RESTful network voice message.

[00179] 13. A first device for obtaining an HTTP message status, wherein, the device comprises:

[00180] a subscription sending module configured to send a message status subscription notification to one or more second devices, wherein the message status subscription notification includes a notification identifier, a session identifier of a session between the first device and the second device, and one or more subscription message statuses;

[00181] a response obtaining module configured to obtain subscription response information sent by the second device, wherein the subscription response information includes one or more resource identifiers, the resource identifier corresponding to the session identifier;

[00182] wherein, the device further comprises:

[00183] an execution sending module configured to send an execution message to the second device, wherein the execution message is corresponding to the resource identifier;

[00184] a status obtaining module configured to obtain a message status notification sent by the second device, wherein the message status notification matches the subscription message status.

[00185] 14. The first device according to clause 13, wherein the device further comprises:

[00186] a check sending module configured to send a subscription check message to the second device, wherein the subscription check message includes the resource identifier.

[00187] 15. The first device according to clause 13 or 14, wherein the device further comprises:

[00188] a deletion sending module configured to send a subscription deletion message to the second device, wherein the subscription deletion message includes the resource identifier and/or the session identifier.

[00189] 16. The first device according to any one of clauses 13-15, wherein the message status subscription notification further includes at least one of the following:

[00190] - type of subscribed messages;

[00191] - session address of the session;

[00192] - resource recovery identifier of the resource;

[00193] - self referring resource identifier.

[00194] 17. The first device according to any one of clauses 13-16, wherein the HTTP message is a voice message.

[00195] 18. The method according to clause 17, wherein the HTTP message is a Restful network voice message.

[00196] 19. A second device for obtaining an HTTP message status, wherein, the device comprises:

[00197] a subscription obtaining module configured to obtain a message status subscription notification sent by a first device, wherein the message status subscription notification includes a notification identifier, a session identifier of a session between the first device and the second device, and one or more subscription message statuses;

[00198] a response sending module configured to send subscription response information to the first device, wherein the subscription response information includes one or more resource identifiers, the resource identifier corresponding to the session identifier;

[00199] wherein, the device further comprises:

[00200] an execution obtaining module configured to obtain an execution message sent by the first device, wherein the execution message is corresponding to the resource identifier;

[00201] a checking module configured to check whether the current message status matches the subscription message status;

[00202] a status sending module configured to send the message status notification to the first device when the message status matches the subscription message status.

[00203] 20. The second device according to clause 19, wherein, the device further comprises:

[00204] a check obtaining module configured to obtain a subscription check message sent by the first device, wherein the subscription check message includes the resource identifier;

[00205] a subscription check module configured to check whether the resource corresponding to the resource identifier has been subscribed based on the subscription check message.

[00206] 21. The second device according to clause 19 or 20, wherein, the device further comprises:

[00207] a deletion obtaining module configured to obtain a subscription deletion message sent by the first device, wherein the subscription deletion message includes the resource identifier and/or the session identifier;

[00208] a deleting module configured to delete, based on the subscription deletion message, the message status subscription notification corresponding to the resource identifier and/or the session identifier, the resource identifier and/or the session identifier corresponding to the subscription deletion message.

[00209] 22. The second device according to any one of clauses 19-21, wherein the message status notification further includes at least any one of the following:

[00210] - session identifier of the session between the first device and the second device;

[00211] - other associated resources associated with the resource identifier;

[00212] - session address associated with the message status;

[00213] - callback data.

[00214] 23. The second device according to any one of clauses 19-22, wherein the HTTP message is a voice message.

[00215] 24. The second device according to clause 23, wherein the HTTP message is a RESTful network voice message.

[00216] 25. A system for obtaining an HTTP message status, comprising a first device according to any one of clauses 13-18 and a second device according to any one of clauses 19-24.

List of abbreviations in the description and drawings:

HTTP HyperText Transfer Protocol

OMA Open Mobile Alliance

RESTful Representational State Transfer

VXML Voice extensible Markup Language

IMS IP Multimedia Subsystem

API Application Programming Interface

URL Uniform Resource Locator

URI Uniform Resource Identifier

SIP Session Initiation Protocol

TEL Telephone

ACR Anonymous Customer Reference