Computer-implemented communication techniques that use messaging services are becoming increasingly common, and are employed in many contexts, including voice communication (e.g., Voice over IP (VoIP), instant messaging, real-time communication between applications, etc.). In general, messaging services require a networking protocol to establish and manage communications between participants. These services may use various mechanisms to establish sessions, including session protocols such as a “Session Initiation Protocol” (“SIP”). SIP is an application-layer control protocol that computer systems can use to discover one another and to establish, modify, and terminate sessions. SIP is an Internet proposed standard. Its specification, “RFC 3261,” is available at <http://www.ietf.org/rfc/rfc3261.txt>. A specification for extensions to SIP relating to event notifications, “RFC 3265,” is available at <http://www.ietf.org/rfc/rfc3265.txt>.
A SIP network comprises entities that can participate in a dialog as a client, server, or both. SIP supports four types of entities: user agent, proxy server, redirect server, and registrar. User agents initiate and terminate sessions by exchanging messages with other SIP entities. A user agent can be a user agent client (“UAC”), which is a device that initiates SIP requests, or a user agent server (“UAS”), which is a device that receives SIP requests and responds to such requests. As examples, “IP-telephones,” personal digital assistants, and any other type of computing device may be user agents. A device can be a UAC in one dialog and a UAS in another, or may change roles during the dialog. A proxy server is an entity that acts as a server to clients and a client to servers. In so doing, proxy servers intercept, interpret, or forward messages between UACs and UASs. A redirect server accepts a SIP request and generates a response directing the UAC that sent the request to contact an alternate network resource. A registrar is a server that accepts registration information from user agents and informs a location service of the received registration information.
SIP supports two message types: requests, which are sent from a UAC to a UAS, and responses, which are sent from a UAS to a UAC, when responding to a request. A SIP message is composed of three parts. The first part of a SIP message is a “request line,” which includes fields to indicate a message method (e.g., INVITE) and a Request URI that identifies the user or service to which the request is being directed. The second part of a SIP message comprises headers whose values are represented as name-value pairs. The third part of a SIP message is the message's body, which is used to describe the session to be initiated or contain data that relates to the session. Message bodies may appear in requests or responses.
The RFC 3261 specification specifies that a receiving agent (e.g., UAS or UAC) must reject any SIP response messages received out of sequence. The agent (at a session protocol layer) determines whether a response message is received out of sequence by checking the CSeq header of the response message against a counter, or similar mechanism. If a response message is received out of sequence, the agent returns an error response (e.g., a 500 (Server Internal Error)).
This approach may be sufficient in the context of simple messaging frameworks. However, in more complex cases, automatically rejecting an out-of-order (or otherwise protocol non-compliant) message can pose problems with respect to speed, performance, and efficiency of systems. One example of such a case is within the context of a publisher/subscriber model, where a publisher publishes information (e.g., messages containing presence information) to a server, which results in publication messages being sent to subscribers via SIP dialogs. In the case where one subscriber subscribes to the information of multiple publishers (e.g., a via a batch subscription), the publication messages for all publishers will be sent from the server to the subscriber via the same SIP dialog. The server may dedicate a thread to sending publication messages for a single publisher. Thus, the server will have multiple threads (e.g., one for each publisher) for generating the publications messages, which includes setting the correct sequence indicator (e.g., CSeq value) for each publication message so that the subscriber, upon receipt, knows that it is receiving the messages in a correct order. For example, when the server receives a message from a first publisher, that publisher's thread looks up the next sequence number (e.g., 1) for the subscriber's dialog and stores it in the publication message to be sent to the subscriber. In the meantime, before sending the publication message from the first publisher out to the subscriber, the server may receive a message from a second publisher. That second publisher's thread looks up the next sequence number (e.g., 2) for that subscriber and stores it in the publication message to be sent to the subscriber.
If for some reason (e.g., the particular timing of thread-to-CPU allocation), the respective server threads send out the publication message for the second publisher before sending out the publication message for the first publisher, the subscriber may receive messages out of order (i.e., message with CSeq 2 is received before message with CSeq 1). Even if the server sent out the messages in the correct order, the subscriber may not receive the messages in the correct order because the underlying transport protocol may not guarantee the order of message deliveries. According to protocols such as SIP, the out-of-order message “must” be rejected and the subscriber sends an error message so that the rejected information can be resent (or other appropriate action taken, such as refreshing a subscription to an entire batch in a batch subscription case) so that information is not ultimately lost. This rejection of messages results in a high resubscribe rate, thereby overburdening the server and decreasing performance.
A method and system for handling otherwise rejectable messages (e.g., out-of-order messages) sent using a communication protocol (e.g., SIP) are provided. The method and system, where appropriate, allow for a higher layer to determine the whether to accept or reject information in the received message. For example, every received message destined to a local application may be dispatched to the application and accompanied by the corresponding CSeq value of the SIP message. The application may then be responsible for either using the provided CSeq value or for introducing and using its own sequencing scheme to determine a manner of proceeding. This SIP layer may automatically accept all messages that are rejectable for certain reasons (e.g., out-of-order).
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.
A method and system for handling otherwise rejectable messages (e.g., out-of-order or otherwise protocol non-compliant messages) sent using a communication protocol (e.g., SIP) is provided. In some embodiments, a message sent using the given protocol is received at a protocol layer of a computing device or agent. The protocol layer is ordinarily responsible for determining whether a message that does not satisfy the protocol should be accepted or rejected. For example, a SIP protocol layer is responsible for accepting or rejecting messages based on their sequence number. Instead of accepting or rejecting the message, however, the protocol layer passes the received message to a higher layer (e.g., an application layer). The higher layer then makes a decision of whether to accept or reject information in the message. In some embodiments, the protocol layer automatically acknowledges acceptance of every message it passes to the higher layer. In other embodiments, the protocol layer receives an indication from the higher layer regarding whether to positively or negatively acknowledge the message (e.g., with respect to a server from which the message is received).
For example, in some embodiments, when a session protocol layer receives an out-of-order session initiation protocol (SIP) message from a server, it forwards the message to an application layer instead of rejecting it as instructed by in the SIP specification. To illustrate, in the context of a SIP SUBSCRIBE/NOTIFY transaction relating to presence information, instead of sending a 500 error message back to the server upon receipt of the out-of-order message, the session protocol layer may, instead, send a 200 OK message to the server and pass the message information on to the application layer. The application layer then determines whether to discard the message or not (or how to otherwise proceed). For example, in the context of multiple messages originating from different sources, the application layer may refer to a table it uses to track the order of incoming messages from each source. In some embodiments, the application layer may use the CSeq number (in addition to or instead of a sequence number that the application itself provides) to determine the fate of the message (e.g., accepted, rejected, discarded, ignored, etc.).
Another example of a context in which the method and system for handling out-of-order messages sent using a session protocol (e.g., SIP) can be used includes communicating events within a Voice over IP framework that uses SIP. For example, as part of and after completing a SIP INVITE transaction, a dialog may be established that allows sending and receiving of asynchronous event messages between clients and a server. The events can be, for example, ringing, connected, disconnected, etc. If the messages indicating these events come out-of-order (e.g., such as a disconnected event being received before a connect event), then the application layer (not the session protocol layer) can decide whether the messages should be discarded.
Each of the computing devices 105 and 115 may include an application layer 120 and a session protocol layer 125. Other layers (e.g., network layer, transport layer, data link layer, physical layer, etc.) may also be present, but are not shown. The session protocol layer 125 is primarily responsible for handling SIP-based communications. However, in accordance with some embodiments, determining whether to disregard an out-of order request may be handled by the application layer 120, as illustrated and described in more detail with respect to
The instant messaging clients 250 and 275 contain a session protocol layer 252 and an instant messaging application 255. The instant messaging application 255 contains a subscribe component 260, a registration component 265, and a user interface component 270, which receive message information from the session protocol layer 252. The subscribe component 260 subscribes to the presence information of the user's contacts. The registration component 265 registers the endpoint of the user with the instant messaging service and publishes updates to the user's presence information. The user interface component 270 provides windows and other graphical elements that are presented to the user while interacting with the instant messaging application 255. In a typical scenario, the user begins using the instant messaging service by starting the instant messaging application 255 at an endpoint. The application 255 invokes the registration component 265 to register the endpoint with the user data server 210 and presence server 205 and to retrieve the user's list of contacts and provide initial presence information about the user. The application 255 invokes the subscribe component 260 to subscribe to each of the user's contacts. The presence server 205 provides an initial presence document about each of the subscribed contacts, and sends an updated presence document when the presence for any of the contacts changes.
The computing devices on which the system is implemented may include a central processing unit, memory, input devices (e.g., keyboard and pointing devices), output devices (e.g., display devices), and storage devices (e.g., disk drives). The memory and storage devices are computer-readable media that may contain instructions that implement the system. In addition, the data structures and message structures may be stored or transmitted via a data transmission medium, such as a signal on a communication link. Various communication links may be used, such as the Internet, a local area network, a wide area network, a point-to-point dial-up connection, a cell phone network, and so on.
Embodiments of the system may be implemented in various operating environments that include personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, programmable consumer electronics, digital cameras, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and so on. The computer systems may be cell phones, personal digital assistants, smart phones, personal computers, programmable consumer electronics, digital cameras, and so on.
The system may be described in the general context of computer-executable instructions, such as program modules, executed by one or more computers or other devices. Generally, program modules include routines, programs, objects, components, data structures, and so on that perform particular tasks or implement particular abstract data types. Typically, the functionality of the program modules may be combined or distributed as desired in various embodiments.
The receipt of message 425 is followed by 200 OK response 430 sent from the client session protocol layer, indicating that the message has been accepted. This notifies the server that it is acceptable to keep sending new messages. The server next sends a second NOTIFY request 435, which may include presence information for u1. In this example, the CSeq value for this message is 3, meaning that it is technically out of order (both with respect to the last message received and with respect to the messages received pertaining to u1), and the session protocol layer would ordinarily reject it. However, here in accordance with some embodiments, the session protocol layer does not automatically reject the out-of-order message 435 and, instead, passes the message information (including the CSeq value) to the client application layer. The client application layer may then use the CSeq value in the versioning table. An example of the versioning table after message 435 may be as follows:
Assuming the application layer did not reject the information associated with message 435, the receipt of message 435 is followed by 200 OK response 440 sent from the client session protocol layer, indicating that the message has been accepted. The server next sends a second NOTIFY request 445, which may include presence information for u2. In this example, the CSeq value for this message is 2. However, in accordance with some embodiments, the session protocol layer may not automatically reject (or accept) the out-of-order message 445 and, instead, may pass the message information (including the CSeq value) to the client application layer. The client application layer may then use the CSeq value in the versioning table. An example of the versioning table after message 445 may be as follows:
Assuming the application layer did not reject the information associated with message 445, the receipt of message 445 is followed by 200 OK response 450 sent from the client session protocol layer, indicating that the message has been accepted. The server next sends a second NOTIFY request 455, which may include presence information for u3. In this example, the CSeq value for this message is 5. However, in accordance with some embodiments, the session protocol layer may not automatically reject the out-of-order message 455 and, instead, may pass the message information (including the CSeq value) to the client application layer. The client application layer may then use the CSeq value in the versioning table. An example of the versioning table after message 455 may be as follows:
Assuming the application layer did not reject the information associated with message 455, the receipt of message 455 is followed by 200 OK response 460 sent from the client session protocol layer, indicating that the message has been accepted. The server next sends a second NOTIFY request 465, which may include presence information for u1. In this example, the CSeq value for this message is 6, meaning again, it is out of order because a message with a CSeq value of 4 has not yet been received. However, in accordance with some embodiments, the session protocol layer may not automatically reject the out-of-order message 465 and, instead, may pass the message information (including the CSeq value) to the client application layer. The client application layer may then use the CSeq value in the versioning table. An example of the versioning table after message 465 may be as follows:
Assuming the application layer did not reject the information associated with message 465, the receipt of message 465 is followed by 200 OK response 470 sent from the client session protocol layer, indicating that the message has been accepted. The server next sends a second NOTIFY request 475, which may include presence information for u1. In this example, the CSeq value for this message is 4, meaning again, it is out of order. In particular, the CSeq 4 is less than the last CSeq in which the client received the presence information for u1. The client application layer, in this case, may decide to drop/discard the notification. The table would remain in the previous state:
Blocks 615, 620, 625 are not included in some embodiments, and may only occur in cases where the routine does not automatically acknowledge receipt of the message (regardless of the sequence it is received in). At block 615 the routine 600 receives an indication from the application layer as to whether it has rejected the message (if so, a new message may need to be sent). If, at decision block 620, the application layer has rejected the out-of-sequence message and needs a new message sent, the routine 600 sends a negative acknowledgement back to the server, so that the server will know to resend. If, however, at decision block 620, the application layer has not rejected the message (or if blocks 615, 620, and 625 are not performed), the routine 600 continues at block 630, where the session protocol layer sends an acknowledgement of receipt of the message (e.g., a 200 OK or an ACK). The routine 600 then ends
In some cases, the message being received from a server by the protocol layer contains only partially complete information, and if the protocol layer automatically discards the partial information (e.g., because it is received out of order), then the overall information provided to the application layer may be inconsistent. For example, in the context of applications relying on presence information, a SIP NOTIFY/SUBSCRIBE request may include only partial presence information for any particular user. In such a case, a first message that a subscriber receives may include a status of “online” and a substatus of “typing,” a second message that the subscriber receives (received out of order) may include only a substatus of “gone home,” and a third message that the subscriber receives (which should have actually been received before the second message) may include a status of “offline” and a substatus of “in a meeting.” The fact that the subscriber receives the messages out of order and that the second message that was received only contains partial information may sometimes cause problems. For example, the subscriber may believe that “gone home” is associated with an “online” status since it did not receive the offline/in a meeting message first. However, instead of the protocol layer automatically rejecting the second and/or third out-of order messages, the decision of whether to use or discard the information from these messages is passed from the protocol layer to the application layer, which may, for example, have capabilities to make this determination more intelligently than the protocol layer.
In some embodiments, to assist the application layer in making decisions, in some embodiments, a message (e.g., a message possibly containing partial information as described in the preceding paragraph) may also include information relating to whether or not the message may be optionally discarded. If this information specifies that the message containing partial information can be optionally discarded, then the application layer may turn to a version number associated with the partial information to determine whether to discard it or not (instead of or prior to requesting for the information to be refreshed). For example, in the case of a system utilizing a presence agent, once a subscription is accepted and installed, the presence agent may deliver the full state of requested presence information in a first notification that contains a presence document. Thus, if the presence agent decides to send notifications that include a presence document, the presence agent may need to build the presence document according to a specified format and, when dealing with a first notification within a subscription may need to initialize a “version” attribute to a value of 1. This version counter may be scoped to the subscription. Version may be reset when the given subscription is terminated, but not reset when the subscription is refreshed.
In another example, if a received notification contains full state, indicated by the <list attribute “fullState” set to “true”, the notification may used to update the table in the application. A check is first made to ensure that the “version” attribute of the <list> attribute in the received message is greater than the local version number. If not, the received document is discarded without any further processing. Otherwise, the contents of the resource-list table are flushed, and repopulated from the contents of the document. A new row in the table is created for each “resource” element. Alternatively, if a notification contains partial state, indicated by the <list> attribute “fullState” set to “false”, a check is made to ensure that no list notifications have been lost. The value of the local version number (the “version” attribute of the <list> element) is compared to the version number of the new document. If the value in the new document is exactly one higher than the local version number, the local version number is increased by one, and the document is processed accordingly. If the version in the document is more than one higher than the local version number, the local version number is set to the value in the new document, and the document is processed accordingly. The list subscriber may then generate a refresh request to trigger a full state notification. If the version in the document is less than or equal to the local version, the document is discarded without any further processing. For each resource listed in the document, the subscriber may check to see whether a row exists for that resource. This check may be done by comparing the Resource-URI value with the URI associated with the row. If the resource doesn't exist in the table, a row is added, and its state is set to the information from that “resource” element. If the resource does exist, its state is updated to be the information from that “resource” element, as described in the definition of the event package. If a row is updated or created such that its state is “terminated,” that entry may be removed from the table.
From the foregoing, it will be appreciated that specific embodiments of the system have been described herein for purposes of illustration, but that various modifications may be made without deviating from the spirit and scope of the invention. Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims. Accordingly, the invention is not limited except as by the appended claims.