JP5518954B2 - Persisting session connections - Google Patents

Description

  The described techniques generally relate to data network communications, and more particularly to session connection sustaining.

  A user of a computing device sometimes uses that computing device to communicate with other users. As one example, a user communicates with another user using a computing device, such as by using a MICROSOFT MESSENGER (“MESSENGER”) instant messaging product, to send or receive typed messages. be able to. In another example, a user speaks into a microphone, such as using a Voice over Internet Protocol (“VoIP”) application, and talks to other users on a speaker or handset. By listening, you can communicate with another user. Such users can use various computing devices such as personal computers, personal digital assistants, mobile phones, VoIP compatible phones, and the like.

  Applications that provide these types of communication services to users may also need to provide presence information. Presence information conveys the ability or willingness of a user to communicate using a computing device. Presence information can be automatically detected by the computing device or actively selected by the user. The computing device can automatically observe and communicate presence information such as the user's “status”. As an example, if a user is not logged on to any computing device, or is not using (or logged on to) an application that observes and communicates presence information, the user's situation is “off-line” Can be pointed automatically. When a user starts or logs on to an application that observes and communicates presence information, such as MESSENGER, the user status can be automatically indicated as “on-line”. If the user does not perform an operation on the computing device for a period of time, the application can automatically indicate that the user is “absent”. The user can also actively select that state. For example, a user may indicate “out for lunch” or “busy”, which may immediately respond to messages from other users. It can be an indication of what cannot be done.

  A “watcher”, an application that wants to determine the state of a user, can determine meaningful presence information by querying or subscribing to a registration server to automatically receive presence information. A plurality of computing devices can register presence information with a registration server computing device so that it can. As an example, MESSENGER may indicate to the registration server that the user's presence information may be “away” because the user has not operated on the computing device for a certain amount of time. it can. A VoIP enabled phone can indicate to the registration server that the user has made a call and therefore the user's presence information may be “on the telephone”. When the watcher receives this presence information from the registration server, the user status may determine that the user status is “calling and cannot respond to messages on the computing device”. However, if the user begins to perform an action on the computing device, the watcher can determine that the user status is “along with a phone call but can respond to messages on the computing device”. If the user indicates that the user status is “away” and actively indicates on the computing device that he / she is using a VoIP enabled phone, the watcher will indicate that the user status is “roaming”. Can be determined.

  Communication applications sometimes need to establish and manage sessions between computing devices. A session is a set of interactions between computing devices that occur over a period of time. As an example, real-time communication applications such as MESSENGER and VoIP establish a session between communication devices on behalf of a user. Such applications can use various mechanisms for establishing a session, such as a “Session Initiation Protocol” (“SIP”). SIP is an application layer control protocol that computing devices can use to discover each other, establish, modify, and terminate sessions between computing devices.

  An application can use SIP with another protocol to send or receive information. By using SIP with other protocols, applications can create and manage sessions and exchange information during sessions. The protocol used with SIP to exchange information can segment the information into messages. As an example, a VoIP application can segment a long story into shorter messages. Message exchange during a session is referred to as a “dialog”. SIP can use lower level communication layers, such as Transmission Control Protocol / Internet Protocol (“TCP / IP”), to transport dialog messages. TCP / IP is a commonly used transport and network layer protocol.

  The transmission control protocol (“TCP”) is a connection-oriented reliable delivery transport layer protocol. TCP is generally described as a transport layer, which provides an interface between an application layer (such as an application that uses SIP) and a network layer. The application layer generally communicates with the TCP layer when sending or receiving a stream of data (such as multiple bytes of data). TCP organizes this data stream into segments that can be carried by protocols used at the network layer, such as the Internet Protocol ("IP"). Such data segments are commonly referred to as “packets”, “frames” or “messages”. Each message typically includes a header and a payload. The header contains the data necessary to route and interpret the message. The payload contains the actual data that is sent or received. Together with the other layers, the application layer, transport layer and network layer are collectively referred to as the data communication stack.

  Messages in a connection can pass through an intermediate computing device. When the transport or network layer of the data communication stack of the sending computing device establishes a connection with the corresponding layer of the data communication stack in the receiving computing device, the messages exchanged by the computing device are multiple May pass through other intermediate computing devices. For example, the message may pass through a proxy server, network address translator, or gateway. Such intermediate computing devices receive, process and forward messages. As an example, a proxy server can be an intermediary between a computing device connected to an intranet and a computing device connected to the Internet. The proxy server may attempt to make the intranet more secure, for example, by ignoring connection requests from outside the intranet.

  An intermediate computing device may terminate an idle connection between two computing devices in order to efficiently use network resources. As an example, a MESSENGER or VoIP application running on a user computing device connected to an intranet (“Computing Device A”) may be another computing device connected to the Internet (“Computing Device B”). A SIP-based session can be established with the application running above. This session can use a TCP / IP connection between computing devices A and B, and messages exchanged by the computing device will pass through the proxy server. If a message is not exchanged within the connection for some time, the proxy server can close the connection between it and computing device B in order to save network resources. However, computing device A may not recognize that the connection is closed because the connection with the proxy server is open. As a result, an application running on computing device B may mistakenly determine that the application (or user) of computing device A is no longer online or using a connection. In addition, to make the intranet to which the proxy server is connected more secure, the proxy server should ignore connection requests from devices that are not connected to the intranet, such as computing devices connected to the Internet. Can do. Thus, an application running on computing device B connected to the Internet is not able to query the application running on computing device A for its status or to request session re-establishment. May be possible.

  An intermediate computing device may close the connection even if the computing device uses a “keep alive” mechanism. Some computing devices use a keep-alive mechanism to keep the connection alive despite the absence of a message. This mechanism involves sending a “keep alive” message to indicate that the sender has not closed the connection. However, an efficient intermediate computing device can recognize the keep alive message and keep the connection between the sending computing device and the intermediate computing device in a keep alive message. There is a possibility that the connection with the receiving side (such as a computing device connected to the Internet) shown in FIG.

  The connection can be sustained by sending a valid message at the application layer. As an example, a SIP application using transport layer TCP can periodically send a valid SIP message, such as a REGISTER message. The REGISTER message may be used to allow the SIP server to associate a message sender's uniform resource identifier (“URI”) with the computing device used by the sender. If a valid SIP message cannot be sent or received, the SIP application can detect that the TCP connection is unavailable.

  SIP is an Internet proposed standard. Its specification, “RFC3261”, is available in Non-Patent Document 1. “RFC3265”, a specification related to SIP extension related to event notification, is available in NPL 2. A specification relating to presence information in an instant messaging system, “RFC2778”, is available in Non-Patent Document 3. A draft of the proposed specification regarding presence information in SIP is available in Non-Patent Document 4. The entire specification of all four is incorporated herein by reference.

http://www.ietf.org/rfc/rfc3261.txt http://www.ietf.org/rfc/rfc3265.txt http://www.ietf.org/rfc/rfc2778.txt ttp: //www.ietf.org/internet-drafts/draft-ietf-simple-presence-l0.txt

  The problem with sending a REGISTER, or any valid SIP message that actually contains valid data, is sent when multiple clients and servers need to send to persist the connection This can be computationally intensive. In the case of a REGISTER message, the server receiving such a message may require parsing the message to determine the URI and ID of the sending computing device, and possibly in a database on another server. May require further storage of data.

  Thus, an effective approach to persisting session connections that rely on TCP keep alives or does not require intensive computational processing on messages is very useful.

  Techniques for persisting session connections are provided in certain embodiments. This technique sends a heartbeat message when a timeout condition can cause a session connection to be closed due to a time-out condition. A heartbeat message is a valid transport layer message that will be ignored by higher level protocols in the data communication stack. As an example, the technique may send a TCP message that includes only a carriage return and line feed (“CRLF”) in the payload. Since the TCP layer considers a message containing only CRLF to be a valid TCP message, an intermediate computing device such as a proxy server may not interpret the heartbeat message as a “keep alive” message, Connection can be maintained.

1 is a block diagram illustrating one embodiment of a system for maintaining a session connection. FIG. FIG. 2 is a block diagram illustrating an embodiment of the network of FIG. 1 is a block diagram illustrating one embodiment of a data communication stack used by a computing device. FIG. 6 is a flow diagram illustrating one embodiment of a send_message routine. 6 is a flow diagram illustrating one embodiment of a sustain_connection routine. 6 is a flow diagram illustrating one embodiment of a send_heartbeat subroutine. 6 is a flow diagram illustrating one embodiment of a receive_message sub-routine. 2 is a message flow diagram illustrating a message flow in an embodiment. 2 is a message flow diagram illustrating a message flow in an embodiment. FIG. 3 is a block diagram illustrating a message flow in an embodiment.

Techniques for persisting session connections are provided in certain embodiments. This technology
Send a heartbeat message when a timeout condition can cause a session connection to close due to a timeout condition. A heartbeat message is a valid transport layer message that contains a non-empty payload that will be ignored by higher level protocols in the data communications stack. As an example, this technique can send a TCP message that contains only a carriage return and a line feed (“CRLF”) in the payload. Since the TCP layer considers a message containing only CRLF to be a valid TCP message, an intermediate computing device, such as a proxy server, resets the message clock for the connection on which the message was sent or received. I can do this. The message clock indicates the amount of time that has elapsed since the message was last sent or received in the connection. If the message clock for a connection indicates that a threshold amount of time has elapsed (eg, indicating that a time-out condition has occurred), the intermediate computing device may close the connection. Since the message clock is reset when a message is sent or received, the connection is not allowed unless another message is sent or received before the threshold amount of time has elapsed. It cannot be closed. After the receiving computing device's TCP layer forwards the received heartbeat message to a higher layer of the data communication stack, the upper layer can ignore the heartbeat message. As another example, in another example, SIP can ignore valid SIP messages that contain only white spaces such as spaces, tabs, carriage returns, line breaks, or CRLF. If the upper layer receives a message containing information other than CRLF, it can attempt to interpret such a message as containing information that cannot be ignored. In various embodiments, the heartbeat can only contain any data that is valid at the carriage return, line feed, or transport layer, but is ignored by higher layer protocols in the data communication stack. . Thus, by sending valid transport layer messages, such as heartbeat messages that are ignored by SIP, this technology does not exchange information between computing devices in the data communication stack layer above the transport layer. In some cases, the session connection can be maintained. The types of messages that are ignored but valid can be defined in the protocol specification or definition.

  In some embodiments, messages ignored by layers above the transport layer can generally include carriage returns, newlines, spaces, tabs, or any white space characters. In some embodiments, such messages that contain only white space can be terminated with a carriage return or a line feed. Characters that can be used in messages to sustain a connection without incurring excessive computational burden are analyzed by analyzing protocols used above protocols that can close the connection (such as TCP) Can be determined.

  Turning now to the drawings, FIG. 1 is a block diagram illustrating one embodiment of a system for maintaining a session connection. The system may include one or more clients 102, one or more networks 104, and a network for connecting clients to the networks, eg, the Internet 114. A client can connect to the Internet via a network connection 108. The network 104 can connect to the Internet using various forms of data communication links 110. The client can be a computer, a mobile phone, or other device connected to the Internet. The network can be an intranet or the like. Clients can also be connected directly to the network using private data communications links 112. Similarly, the network can connect directly to other networks using the private data communication link 112. The Internet can also be connected to a variety of other computing devices (not shown). The connections described herein can be physical connections, wireless connections, or indeed any form of data communication network connection.

  FIG. 2 is a block diagram illustrating one embodiment of the network of FIG. The network 200 includes one or more clients 202, a server 204 and an edge proxy server 212. This network may also include other devices (not shown). The illustrated devices (and devices not shown) of this network can be interconnected via a data communication network (not shown) associated with this network. Client 202 and server 204 can perform various operations, including exchanging SIP messages. Edge proxy server 212 is connected to both network 200 (an “internal” network) and an “external” network such as the Internet (not shown). If the client wishes to open a session with a server outside this network, the edge proxy can determine, for example, whether the session should be opened and which communication link should be used.

  FIG. 3 is a block diagram illustrating one embodiment of a data communication stack used by the computing devices of FIGS. Computing devices can use one or more data communication stacks to communicate with each other. In the illustrated example, computing device 300 communicates with computing device 303 using a data communication stack associated with such computing device. Computing devices 301 and 302 can receive and forward messages between computing devices 300 and 303 using their associated data communication stacks.

  The computing device 300 has a data communication stack that includes an application layer 304, a transport layer 306, a network layer 308, a data link layer 310 and a physical layer 312. The application layer can include SIP applications and other applications. SIP applications can include components or layers that communicate with the transport layer. This communication layer belonging to the SIP application can send or receive heartbeat messages. Computing devices 301, 302 and 303 will have similar data communication stacks. Specifically, the computing device 303 will have a data communication stack that includes an application layer 314, a transport layer 316, a network layer 318, a data link layer 320 and a physical layer 322. Some or all of these application layers may further include SIP applications.

  When two computing devices are connected, each layer of the data communication stack can have a logical or physical connection between them. As an example, when computing device 300 is connected to computing device 303 via computing devices 301 and 302, physical layer 312 is connected to the physical layer of computing device 301 via physical connection 324. The computing device 301 can be connected to the physical layer of the computing device 302 via a physical connection, and the computing device 302 can be connected to the physical layer of the computing device 303 via a physical connection. Can be connected to. Each computing device can be connected to each other via other connections such as a modem, a network interface card, or the Internet, for example. The Internet consists of various physical connections, such as telephone lines, microwave links, and other forms of wired and wireless connections that together form multiple routes for messages. In fact, the initial goal of the Internet was to allow senders to communicate with recipients despite network failures. When the computing device 300 sends data to the computing device 303, the data can travel different physical routes via the Internet.

  Higher layers of the data communication stack, such as data link layers 310 and 320, network layers 308 and 318, transport layers 306 and 316, and application layers 304 and 314 are connected by logical connections such as logical connections 326, 328, 330, and 332 Can be connected. When two layers of a data communication stack have logical connections and exchange data, the data is sent “down” the data communication stack of the sending computing device, to the physical layer of the data communication stack, Cross the connection and then send the data communication stack of the receiving computing device “information”. As an example, when the SIP application 304 of the computing device 300 communicates with the SIP application 314 of the computing device 303, the SIP application 304 communicates data to the transport layer 306, which transports data to the network layer 308. The network layer communicates data to the data link layer 310, and the data link layer communicates data to the physical layer 312. The physical layer 312 can communicate data via the physical connection 324, and ultimately communicates data to the physical layer 322. The physical layer 322 communicates the data it receives to the data link layer 320, which communicates data to the network layer 318, which communicates data to the transport layer 316, which Eventually, the data can be transmitted to the SIP application 314.

  When computing devices 301 and 302 receive data on their physical connections, they will send data up the data communications stack. A level below the application layer of the data communication stack may be able to process the received data without sending it to the layer above it. As an example, when the SIP application 304 sends a SIP message to the SIP application 314, the data corresponding to the SIP message will be sent to the transport layer 306. The data communication stacks of computing devices 301 and 302 that both receive data at the physical layer will pass the received data from the bottom to the top of the data communication stack to its respective transport layer. A transport layer that recognizes from the received data that the destination indicated in the data is the computing device 303 would simply transfer the data to the transport layer 316 (via its corresponding lower level). Thus, the application / SIP layer of computing devices 301 and 302 will not need to process the message or even view the message.

  If data is not received by the transport layer of computing device 301 or 302 for a period of time, the computing device will close the connection corresponding to the SIP session between computing devices 300 and 303. As an example, if computing device 301 does not receive a message about a connection from computing device 300 or computing device 302, it considers that the connection is no longer needed and will close the connection. Thus, further SIP messages between the computing devices 301 and 303 will not be able to pass the connection through the previously opened computing devices 301 and 302.

  FIG. 4 is a flow diagram illustrating one embodiment of the send_message routine. This routine will be implemented by an application layer component, such as a component of a SIP application that sends a message. The send_message routine may be used when sending a message to a SIP application that runs on another computing device, such as by a SIP application running on one computing device. The routine begins at block 402 and receives a message indication as a parameter. At block 404, the routine resets the clock value, such as by setting it to zero. The clock value is an indication of the time that has elapsed since the message was last received. This value can be checked by the system components to determine if the connection should be closed. At block 406, the message received at block 402 is sent to the transport layer. This routine can use the application program interface exposed by the transport layer sending the message. At block 408, the routine returns to its caller.

  FIG. 5 is a flow diagram illustrating one embodiment of a sustain_connection routine. This routine is implemented by an application layer component, such as a component of a SIP application, to persist the connection. The connection will need to be sustained, such as when the clock value indicating the amount of time that has elapsed since the message was last received exceeds the timeout value. The appropriate timeout value can be determined, such as by determining transport layer attributes using the transport layer API, or can be defined by the administrator of the system. The routine begins at block 502. At block 504, the routine determines whether the clock value is approximately the timeout value. If the clock value exceeds the timeout value, the connection may already be closed. As a result, a certain time period before the time-out value should be selected. If the clock value is approximately the timeout value, the routine continues at block 506. Otherwise, the routine continues to block 508. At block 506, the routine calls the send_heartbeat sub-routine, which sends a message that can persist the connection. The send_heartbeat sub-routine is described further below with respect to FIG. At block 508, the routine returns to its caller.

  The sustain_connection routine will be called repeatedly in a loop of a thread separate from the thread sending or receiving the message. Alternatively, the sustain_connection routine can be called in response to a clock event triggered at a specified time interval before timing out.

  Alternatively, the sustain_connection routine can simply send heartbeat messages at an interval that is smaller than the timeout value, regardless of the clock value. As an example, if the proxy server times out after 1 minute of inactivity, this routine will send a heartbeat message every 30 seconds, even if the message was sent or received just a few seconds ago. Can be sent.

  FIG. 6 is a flow diagram illustrating one embodiment of the send_heartbeat subroutine. This sub-routine is implemented by an application layer component, such as a component of a SIP application, that sends a heartbeat message. Heartbeat messages can be sent to persist a connection that may be closed if no message is sent in the connection for some time. The sub-routine begins at block 602 and receives a session indication as a parameter. In box 604, the sub-routine creates a heartbeat message. A heartbeat message is a message that can be ignored by one layer of the data communication stack, but is not ignored by another layer of the data communication stack. As an example, a heartbeat message can be used when a TCP connection may be closed by another computing device (such as a proxy server) that processes the message between two computing devices that have an open SIP session. It can be sent by a SIP application to persist a TCP connection. The heartbeat message can contain only CRLF characters, for example. Alternatively, the heartbeat message can include one or more spaces and tabs that end with a CRLF. Heartbeat messages can use carriage return or newline characters instead of using CRLF. For the TCP layer, such a message would be a valid message that resets the clock value when the message is sent or received. However, SIP applications can ignore such messages. Thus, by sending such a heartbeat message, the TCP connection can be kept open, so the SIP presence information remains accurate and unusable information is presented to the SIP application. Never happen. In an alternative embodiment, a carriage return or newline character will simply be sent in the heartbeat message.

  At block 606, the sub-routine calls the send_message sub-routine and passes the created heartbeat message as a parameter. The send_message sub-routine is described above in connection with FIG. At block 608, the sub-routine returns to its caller.

  FIG. 7 is a flow diagram illustrating one embodiment of a receive_message sub-routine. This sub-routine will be implemented by an application layer component of the receiving computing device, such as a SIP application. The sub-routine begins at block 702 and receives a message indication as a parameter. At block 704, the sub-routine determines whether the received message is a heartbeat message. The sub-routine will attempt to determine whether the received message is a heartbeat message by simply checking whether the message content is a carriage return, a newline, or both. Alternatively, the receive_message sub-routine can be customized to look for any other information in the message that is known to identify the heartbeat message. If the received message is a heartbeat message, the sub-routine continues to block 706. Otherwise, the sub-routine continues to block 708. At block 706, the sub-routine can acknowledge the message. In general, the transport layer acknowledges the message. However, in some cases, the application layer component layer may need to acknowledge the message. Since this step can be optional depending on the application layer component implementing the sub-routine, block 706 is shown with a dashed line. At block 708, the sub-routine will forward the message to a SIP application or the like. At block 710, the sub-routine returns to its caller.

  Upon receipt of the message, the sub-routine will reset the clock value (not shown). This clock value can be used to determine whether a heartbeat message needs to be sent in order to persist the connection.

  FIG. 8 is a message flow diagram illustrating message flow in an embodiment. In the illustrated embodiment, computing device 1 has established a SIP session with computing device 2. Messages exchanged within the session pass through the proxy server. As an example, when computing device 1 sends message 1 at t = 0, the message passes through the proxy server, and at t = 1, computing device 2 receives the message. Similarly, when computing device 2 sends message 2 at t = 2, the message passes through the proxy server before computing device 1 receives it at t =. The proxy server can reset the clock whenever it forwards or receives a message. As an example, the proxy server resets the clock value to 0 when forwarding message 1. Similarly, when the proxy server receives message 2, it resets the clock value to zero. The clock value will be automatically incremented, for example, in response to the system clock. If the clock value exceeds the timeout value, the proxy server will close the connection associated with that session. In the illustrated example, the computing device 1 will not be able to transmit the message 3 after the clock value exceeds the time-out value.

  FIG. 9 is a message flow diagram illustrating message flow in an embodiment. In the illustrated embodiment, computing devices 1 and 2 are exchanging messages 1 and 2 between times 0 and 3, as shown in FIG. 8 and described above. When t = 4, computing device 1 recognizes that it will soon time out (indicated by the dashed line in the figure), it will give heartbeat to computing device 2 before the time out shown as t = 5. -A message will be sent. When sending a heartbeat message, the proxy server can reset the clock value, so the computing device 1 sends message 3 at time 6 because the proxy server has not closed the connection. It will be possible. By sending a heartbeat message before the proxy server times out, the system can maintain a connection between the computing devices 1 and 2. A computing device that sends a heartbeat message must attempt to send a heartbeat message while there is still enough time for the clock value of the heartbeat message receiver to also exceed the timeout value. There will be.

  FIG. 10 is a block diagram illustrating message flow in an embodiment. In the illustrated embodiment, the sending computing device 1000 opens a SIP session with the receiving computing device 1002. When the sending computing device sends a SIP message 1 via its application / SIP layer 1004, the transport layer 1006 may segment the message into two segments S1 and S2. To avoid timeout, the sending computing device can send a heartbeat message S3. The heartbeat message can include a carriage return, a new line, both, or other information indicating a heartbeat message that can be ignored by the application. The receiving computing device can then send SIP message 2 segmented by transport layer 1016 as transport messages S4, S5 and S6. Segmented messages can be of various sizes.

  In some embodiments, the computing device can send a heartbeat message on some connections and use another mechanism, including other connections, to persist that connection. As an example, when a computing device sends a message to its own “home” server, or other computing device connected to it, it makes the home server a heartbeat connection to the computing device connection. Since it is possible to associate messages and store an indication of the association, heartbeat messages can be used. By doing so, the server may be able to efficiently update the presence information of the computing device if the connection is later lost. The computing device may send a REGISTER message on other connections if it may be advantageous to do so. As an example, the computing device can send a REGISTER message if the intermediate device does not forward the heartbeat message.

  Although the specific examples discussed herein refer to using SIP and TCP, alternative embodiments may use other equivalent or similar protocols.

  Computing devices that implement techniques for persisting session connections include central processing units, memory, input devices (such as keyboards and pointing devices), output devices (such as display devices), and storage devices (such as disk drives). Can be included. Memory and storage devices are computer-readable media that can contain instructions for implementing a security system. Further, the data structure and message structure can be stored or transmitted over a data transmission medium such as a signal on a communication link. Various communication links can be used, such as the Internet, local area networks, wide area networks or point-to-point dial-up connections.

  FIG. 1 shows an example of a suitable operating environment in which techniques for persisting session connections can be implemented. This operating environment is only one example of a suitable operating environment and is not intended to suggest any limitation as to the scope of use or functionality of the system. Other well known computing systems, environments and configurations that may be suitable for use include personal computers, server computers, handheld or laptop devices including “smart” mobile phones, multi-processor systems, Processor based systems, programmable consumer electronics, network PCs, mini computers, mainframe computers, distributed computing environments including any of the above systems or devices, and the like.

  Techniques for persisting session connections can be described in the general context of computer-executable instructions, such as program modules, being executed by one or more computers or other devices. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. In general, the functionality of program modules may be combined or distributed as desired in various embodiments.

  While specific embodiments of the invention have been described herein for purposes of illustration, it will be appreciated that various modifications can be made from the foregoing without departing from the spirit and scope of the invention. Accordingly, the invention is not limited except as by the appended claims.

102 Client 104 Network 108 Network Connection 110 Data Communication Link 112 Private Data Communication Link 114 Internet 200 Network 202 Client 204 Server 212 Proxy 300-303 Computing Device 304 Application / SIP
306 Transport 308 Network 310 Data link 312 Physical 314 Application / SIP
316 Transport 318 Network 320 Data link 322 Physical 1000 Sending computing device 1002 Receiving computing device 1004, 1014 Application / SIP (layer)
1006, 1016 transport (layer)
1008, 1018 network (layer)
1010, 1020 Data link (layer)
1012, 1022 Physical (layer)

Claims (16)

A method performed by a proxy computing device for maintaining a session connection between a client computing device and a server computing device, comprising:
Receiving a heartbeat message from the client computing device at the proxy computing device, wherein the client computing device and the server computing device have an open session using a session initiation protocol, and the heartbeat message Is a transport layer protocol valid message and is ignored by the session initiation protocol; and
Resetting the message clock of the session connection between the client computing device and the server computing device;
Sending the heartbeat message from the proxy computing device to the server computing device, whereby sending the heartbeat message maintains the session connection between the client computing device and the server computing device; A method comprising the steps of:   The method according to claim 1, wherein the step of resetting the message clock is performed after transmitting the heartbeat message from the proxy computing device to the server computing device.   The method of claim 1, wherein the heartbeat message includes a space character including one or more of a line feed and a carriage return.   The method of claim 1, wherein the transport layer protocol is TCP / IP.   The method of claim 1, wherein the message clock measures a time elapsed since a previous message was transmitted or received.   The method of claim 1, wherein the message clock relates to a message transmitted or received by a transport layer of a data communication stack.   The method of claim 1, wherein the proxy computing device is an edge proxy server.   8. The method of claim 7, wherein the client computing device is external to the network and the server computing device is within the network. Receiving a second heartbeat message at the proxy computing device from the client computing device after a predetermined period after receiving the heartbeat message;
2. The method of claim 1, further comprising: determining whether a time-out period between the step of receiving the heartbeat message and the step of receiving the second heartbeat message exceeds the predetermined period. The method described in 1. If it is determined that the certain period of time exceeds the timeout period between the step of receiving the heartbeat message and the step of receiving the second heartbeat message , the client computing device and the server computing device The method of claim 9, further comprising dropping the session connection between. If it is determined that the timeout period does not exceed the timeout period between receiving the heartbeat message and receiving the second heartbeat message , the message clock is reset, thereby The method of claim 9, further comprising maintaining a session connection. A proxy computing device that is communicably connected between a client computing device and a server computing device and is configured to maintain a session connection between the client computing device and the server computing device,
A first component executable on the proxy computing device that receives messages through a connection with the client computing device;
A second component executable on the proxy computing device for transmitting the received message to the server computing device;
The proxy computing device for determining whether the received message is a heartbeat message, wherein the heartbeat message is a valid message of a transport layer protocol, ignored by a session initiation protocol, and the reception If it is determined that the received message is a heartbeat message, the message clock of the session connection between the client computing device and the server computing device is reset, and thereby, between the client computing device and the server computing device. And a third component executable on the proxy computing device that maintains the session connection of the proxy computing device.   The proxy calculation apparatus according to claim 12, wherein the proxy calculation apparatus is an edge proxy server. A method performed by a server computing device for persisting a session connection comprising:
Establishing a session with a client computing device using a session initiation protocol, the session having a session connection;
Receiving a heartbeat message from the client computing device using a transport layer protocol via a proxy computing device, the session initiation protocol having a higher data communication stack than the transport layer protocol; And the heartbeat message is a valid message of the transport layer protocol and ignored by the session initiation protocol, and receiving the heartbeat message is performed by the server computing device at the session Stay connected, step, and
Including
The session is established and maintained between the client computing device and the server computing device through the proxy computing device and receiving the heartbeat message from the client computing device at the server computing device; And the step of resetting the message clock later.   The method of claim 14, wherein the heartbeat message is received when a predetermined period has elapsed since the session initiation protocol message was received, and the predetermined period is shorter than a timeout value.   The method of claim 14, wherein the message clock is reset by the proxy computing device.

Images