Session initiation protocol system timeout timer method

The present method provides for a session initiation protocol timing arrangement which facilitates instant communications in a packet data communication system (50). Each network server (15-25) sets a time out timer (92) which is coordinated with each of the downstream network servers. Network server (15), for example, sets a time out timer value which is selectable by the system operator. Subsequent network servers (20 and 25) then set the value of the time out timer to be that of the originating server (15) or client (10) less a fixed time such as one second. Further, a provisional message (118) is sent through the network to avoid expiration of the time out timer in upstream stages.

BACKGROUND OF THE INVENTION

The present invention pertains to packet data communications systems and more particularly to session initiation protocol time out between clients and network servers.

Internet protocol (IP) using session initiation protocol (SIP) enables modern communication networks to provide many packet data services including voice to wireless users in a dispatch environment. Session initiation protocol provides for certain methodology for timing overall communications between clients and servers and servers and other servers in a network to avoid a miscommunication or lack of communication. Such situation is called a time out period.

The session initiation protocol standard timer value is initially set at one-half second and is doubled for each successive retry. The overall transaction time out timer is set for a maximum of 32 seconds and would automatically expire prior to sending the maximum number of retries.

Typically data packets are sent through several “network hops”. A hop is a transmission of the data packet from one node to another. For example, from an originating server to a group or interconnecting server or from an interconnecting server to a terminating server. The number of network hops depends upon the particular routing of the data packet. As a data packet is transmitted from network hop to network hop, the time out timer of the originating server is constantly running and for lack of response by down stream network servers, it may time out. Between the time of initiation and time out by a network server, several retries may have been attempted by the originating server. The downstream network servers have no knowledge of the time out of the upstream servers. This results in call cancellations and drops and further a race condition exists between network servers. Some network servers may still be processing the packet data while upstream servers are attempting to cancel the packet data transmission since a time out of the upstream network server has occurred.

Further, for particular kinds of packet data uses such as dispatch and specifically push-to-talk functions, a time out time period of 30 seconds is a long time for the push-to-talk type service.

In a session initiation protocol based packet communication system, the time out timer is governed by document RFC2543BIS-09. No resolution of the above problem or recognition of the problem is expressed for the time out timers in this document.

Accordingly, it would be highly desirable to have a time out timer coordination method between successive “network hops” or network servers.

DESCRIPTION OF THE PREFERRED EMBODIMENT OF THE INVENTION

Referring toFIG. 1, a block diagram of a packet data communication system50which employs session initiation protocol (SIP) is shown. Communication system50is shown and includes an originating client10which is coupled to an originating server15which in turn is coupled to a group server20. Group server20is coupled to terminating server25. Finally, terminating server25is coupled to a terminating client30. Originating client10is attempting to connect and communicate with terminating client30. One application of communication system50may be between two clients10and30communicating in a push-to-talk service arrangement.

As an example, originating client10is attempting to communicate with terminating client30. A SIP invite request is sent by originating client10to originating server15. The message flow for this purpose of consideration is from left to right. That is, originating client10is upstream with regard to originating server15; and originating server15is downstream with respect to originating client10. Terminating client30is downstream with respect to each of the blocks ofFIG. 1, that is, originating client10, originating server15, group server20and terminating server25.

Generally, each server15-25provides for timing of messages sent to the next server downstream. For lack of acknowledgment each client and server returns an acknowledge message in response to a SIP invite message. If messages become delayed or lost a retry of the SIP invite message, for example, is attempted. The present invention resets the retry timer for each retry instead of linearly or exponentially increasing it. Further, each time a SIP response message is received from a downstream unit (response message=1XX), the retry timer is reset and the overall time out timer is set with a period of one second greater than the next node (server or client) upstream. As a result any subsequent provisional SIP responses (1XX) would reset the time out timer prior to its expiration. Further, this invention calls for the use of a provisional response code (181 forward) to be used for each node upstream to be returned to the previous downstream node. This 181 forward response code allows the time out timer to be reset and avoids canceling any retries.

Referring toFIGS. 2 and 3, a flow cart of the time out timer method60is shown. The method is started and block62is entered. Block62selects a primary contact from an associated database. That is, once a server receives a SIP invite request110from a client or an upstream server, the database is consulted to determine the next primary server or end server which may handle this invite request. The contact is either the next server downstream or the terminating client depending on the flow through the communication system50.

Next, a retry count is set equal to two. This counter keeps the count of the number of retries made by a server. The retry count may be set differently for different servers depending upon the needs of the network operator and other traffic considerations.

Next, block66sends a SIP invite to the contact obtained from the database in block62. Again, the contact is either the next server or the terminating client. For example, usingFIG. 1, since originating server15has already obtained the SIP invite from originating client10, the next contact for originating server15would be group server20. Therefore, the SIP invite would be sent from originating server15to group server20.

Next, the retry timer is set to a value of one-half second, block68. The retry timer value is also settable based upon the needs of the system operator and other traffic conditions. The server then waits for a response from the next server downstream or terminating client. If no response is received from the next downstream server, block70transfers control to block72via the no path. Block72decrements the retry counter. Remember originally the retry counter in this example was set to two. Next, block74determines whether the retry counter is zero. If the retry counter is zero, three retries of sending the SIP invite to the next server have been attempted. Block74then transfers control to block76via the yes path. Block76determines whether an alternate contact is included in the database. Remember that a contact is a next server or terminating client in the downstream flow. For terminating client an alternating contact may be a computer instead of a cell phone or telephone. If there is no alternate contact in the database, block76transfers control to block80via the no path. Block80indicates that the process has failed and ends the method.

If an alternate contact is included in the database, block76transfers control to block78via the yes path. Block78selects the alternate contact from the database. Then block78transfers control to block64which reestablishes the retry count at two. The method then sends the SIP invite to the alternate contact, block66, sets the retry timer to one-half second, block68and waits.

If the server sending the SIP invite receives a final response, for example, a SIP 200-699 message, block70transfers control to block82via the final response path. Block82sends back the final response message to the previous contact. The final response message is not sent to the originating client if that was the contact. The retry timer is canceled, block84. The process is indicated as completed successfully, block86. Then the process is ended.

If the server sending the SIP invite detected a provisional response, block70transfers control to block88via the provisional response path. Block88sends back the provisional response indication to the upstream server. Next, the retry timer is canceled, block90. Then block92sets the timeout timer value equal to 13 seconds. The value of the timeout timer is settable by the system operator depending upon the system operator's needs and other traffic conditions. Each downstream server sets the time out timer to approximately one second less than the upstream server or originating client. This prevents the cascading of SIP cancel messages.

Next, block94waits for a response. If a provisional response is received, block94transfers control to block96via the provisional response path. A provisional response is a SIP message between 100 and 199. Block96cancels the time out timer. Next, block98sends back (upstream) the provisional response, unless the upstream network node was the originator. Then block98transfers control to block92to set the time out timer and wait.

If the received response is a time out, block94transfers control to block106via the time out path. Block106sends a SIP cancel message back upstream, unless the previous upstream node was the originating client. Then the process is indicated as having failed, block108and the method is ended.

If a final response was received, block94transfers control to block100via the final response path. Block100sends the final response message back to the upstream server, unless the upstream unit is the originating client. Next, the time out timer is canceled, block102. The process is then indicated as being completed successfully, block104. The method is then ended.

FIG. 4depicts a message flow diagram which diagrammatically depicts a sample message flow for the method ofFIGS. 2 and 3. Originating client10sends a SIP invite message110to originating server15. The retry timer is initialized to one-half second (not shown). Originating server15may return a SIP 100 trying message112to originating client10. Originating server15also forwards the SIP invite message114to group server20. Two retries of the SIP invite message are shown being transmitted from originating server1to group server20.

Group server20finally responds to one of the SIP invites with a 100 trying message to upstream originating server15. This 100 trying message is not returned to the originating client10.

Group server20then sends the SIP invite116to terminating server25. Subsequently, two retries are made to again send the SIP invite to terminating server25. The SIP invite message is then alternately routed to a terminating server26and when the SIP invite message is resent a SIP 100 trying message117is returned from terminating server26to group server20.

Further, prior to sending the 100 trying message117, group server20sent a 181 forward message to originating server15indicating that the call was being routed to an alternate terminating server. Originating server15sent the 181 forward message to originating client10. This enabled originating client10to reset the time out timer prior to its expiration. In addition, the time out timer for originating server15is set to the value of the time out timer (TT) less one second. Additionally, the time out timer of group server20is set to the time out time period of originating client10, TT−2 seconds since it is two hops downstream with respect to originating client10.

Alternate terminating server26then attempts to forward the SIP invite121to the terminating client30. Again, two successive retries are made unsuccessfully. The method ofFIG. 2then selects an alternate contact or in this case terminating client from the database. This corresponds to perhaps a cell phone when the terminating client was unable to be reached at the computer.

The alternate terminating client31is then selected.

Meanwhile, the terminating server25sends a 181 forward message122to the group server20. This message is then cascaded in messages124and126back to the originating client10. As a result the time out timer is reset prior to expiration.

When the alternate terminating client31is rung on the cell phone, the resultant message 180 ring128is sent to terminating server25and cascaded back through the upstream network as 180 ring message130to originating client10.

Lastly, the terminating server25, in this example, was unable to complete the coupling to the alternate client31and as a result, time out timer131expired. The value of time out timer was the original value of timer set by originating client10minus three seconds since there were three hops between the originating server and the terminating server. As a result, terminating server25sends a cancel message132to the alternate terminating client31. Further, a 408 time out message134is sent upstream through the network back to the originating client10. This indicates the call was not complete because of time out.

As can be seen from the above explanation, the present method prevents premature time out and cascading of time outs throughout the communication system. The total response time by the system is not a fixed number but is a function of the number of “hops” made through the system and the number of alternate elements in the system. This method allows for a variable number of provisional attempts or retries. Further, this method resets upstream timers by the sending of a provisional 181 forward message to stop time out timers. This method eliminates race conditions among the various servers of the communication system. Further, this method provides for service operator selection of several parameters.

Although the preferred embodiment of the invention has been illustrated, and that form described in detail, it will be readily apparent to those skilled in the art that various modifications may be made therein without departing from the spirit of the present invention or from the scope of the appended claims.