Although described below primarily in the context of the SIP signaling protocol, it is to be appreciated that principles of the present invention can be readily adapted in a straightforward manner to other types of communication protocols for facilitating establishment of communication sessions between devices.
An illustrative embodiment makes use of the SIP Replaces header described in IETF RFC 3891, “The Session Initiation Protocol (SIP) “Replaces” Header,” September 2004, which is incorporated by reference herein.
In general, as described in RFC 3891, the Replaces header field indicates that a single dialog identified by the header field is to be shut down and logically replaced by the incoming INVITE in which it is contained. Thus, the Replaces header contains information used to match an existing SIP dialog (call-id, to-tag, and from-tag) intended to be replaced with a new SIP dialog. Upon receiving an INVITE with Replaces header, the receiving device attempts to match this information with a confirmed or earlier dialog. The receiving device matches to-tag and from-tag parameters as if they were tags present in an incoming request. In other words, the to-tag parameter is compared to the local tag, and the from-tag parameter is compared to the remote tag. Assuming a successful authorization process, the receiving device attempts to accept the new INVITE, reassign the user interface and other resources of the matched dialog to the new INVITE, and shut down the replaced dialog. Conventional SIP signaling procedures utilize the Replaces header to enable certain call features such as attended call transfer, retrieve from park, and transition from locally mixed conferences to two party calls in a didtributed peer-to-peer manner.
However, in the presence of failures, such as application failures or network failures, during an ongoing call using the conventional SIP signaling protocol, if either of the calling parties tries to use call features (e.g., call hold, call transfer, multi-party call conferencing, bridged call appearance, etc.), the call may be terminated and the call path may be torn down.
As will be described below, illustrative principles of the invention overcome drawbacks of conventional SIP signaling by providing an arrangement in which the signaling path will failover to an alternate SIP proxy and call controller in the presence of a failure, so that the parties on the call can continue to use call features and when the call is finished, the call path and signaling can be gracefully torn down. That is, one party can then initiate an orderly and intended termination of the communication session, as opposed to an abrupt and unintended termination that a failure would otherwise cause.
The illustrative embodiment can be implemented in, for example, a gateway or other network processing device comprising a processor and memory (an example of which is described below in the context of
The illustrative embodiment, although described in the context of utilization of one or more of the above-noted call features, can also be used in other contexts, such as, for example, tearing down a pre-established call in a more graceful way after either the calling party or called party disconnects.
In the illustrative embodiment, when an application or network failure occurs during an active call, the end user telephone or other device sends a SIP INVITE message containing a Replaces header to an alternate SIP proxy and call controller. The INVITE message containing the Replaces header requests that a new call session be established to replace the old call session. Identifying information for the new and old call sessions are contained in the SIP INVITE message that contains the Replaces header. The format of the SIP Replaces header is described in the above-cited IETF RFC 3891.
This approach advantageously expands the use of the SIP Replaces header to failover scenarios, and provides call features and graceful teardown for calls that have already been established when an application or network failure occurs.
Assume that a failure occurs while this call is active, as indicated by the large X in the communication paths designated by numeral 1. As noted above, this failure may be associated with an application or network failure, or may be another type of failure. In the presence of the failure, the active call will failover to alternate proxy and call controller 110, as indicated generally by the communication paths designated by numeral 2. This is accomplished using the signaling shown in the signaling diagram of
The end user devices in the
Referring now to
It is to be understood that the network configurations shown in
In this embodiment, a media session is established between Phone A and Phone B as shown. That is, in accordance with SIP signaling procedures, Phone A sends an INVITE message to the proxy (301). The proxy forwards the INVITE to Phone B (302) and indicates (TRYING message) to Phone A that the INVITE is pending with Phone B (303). Phone B sends out a RINGING message (304) that is forwarded to Phone A by the proxy (step 305). Phone B accepts the INVITE by sending out an OK message (306) that is forwarded to Phone A by the proxy (step 307). Phone A sends out an ACK message (308) that is forwarded to Phone B by the proxy (step 309). The media session is thus established between Phone A and Phone B (310).
While this call (session) is in progress, assume an application or network failure occurs (311). The user at Phone A then attempts to use a call feature, in this example a hold feature, which is initiated via an associated INVITE message (312). Due to the failure, there is no response from the proxy to the INVITE message associated with the hold feature (314).
Phone A then sends an INVITE message that contains a Replaces header of the type described above to the alternate proxy and call controller (316). The alternate proxy and call controller forwards the INVITE with Replaces header to Phone B (318). Phone B accepts the INVITE with Replaces header by sending out an OK message (319) that is forwarded to Phone A by the alternate proxy and call controller (step 320). Phone A sends out an ACK message (321) that is forwarded to Phone B by the alternate proxy and call controller (step 322). The media session is thus maintained between Phone A and Phone B (323).
The user at Phone A can then utilize the hold feature, or other types of call features as desired, as the call has now advantageously failed over to the alternate proxy and call controller. More specifically, Phone A sends an INVITE (hold) message to Phone B via the alternate proxy and call controller (324 and 325). An acceptance message is sent by Phone B (326 and 327), which is acknowledged by Phone A (328 and 329). Then, communications proceed as per standard SIP “call hold” flow (330).
It should be noted that signaling similar to that shown in
The alternate proxy and call controller may be an otherwise conventional SIP proxy and call controller. The proxy and call controller may be implemented as separate devices or may be combined into a single device. The conventional aspects of the operation of such devices, as well as other system elements such as the gateway and SIP UA are well known to those skilled in the art and are therefore not described in further detail herein.
A given system element, such as one or more of the proxies, call controllers, gateways or other elements, may be implemented as one or more network devices or other types of processing devices including at least a processor and a memory. The present invention can be implemented at least in part in the form of software programs that are stored by a memory and executed by a processor in one or more system elements.
It is to be appreciated that the above-described embodiment is presented by way of example only. Numerous alternative embodiments will be readily apparent to those skilled in the art. For example, the invention can be implemented using other types of end user devices and other types of system or network elements. Also, alternative techniques may be used to convey alternate proxy or call controller information instead of the Replaces header of the illustrative embodiment.
Lastly,
In this illustrative implementation, a processor 402 for implementing at least a portion of the methodologies of the invention is operatively coupled to a memory 404.
It is to be appreciated that the term “processor” as used herein is intended to include any processing device, such as, for example, one that includes a central processing unit (CPU) and/or other processing circuitry (e.g., digital signal processor (DSP), microprocessor, etc.). Additionally, it is to be understood that the term “processor” may refer to more than one processing device, and that various elements associated with a processing device may be shared by other processing devices.
The term “memory” as used herein is intended to include memory and other computer-readable media associated with a processor or CPU, such as, for example, random access memory (RAM), read only memory (ROM), fixed storage media (e.g., hard drive), removable storage media (e.g., diskette), flash memory, etc.
Accordingly, one or more computer programs, or software components thereof, including instructions or code for performing the methodologies of the invention, as described herein, may be stored in memory 404 and, when ready to be utilized, loaded in whole or in part and executed by the processor 402.
In any case, it is to be appreciated that the techniques of the invention, described herein and shown in the appended figures, may be implemented in various forms of hardware, software, or combinations thereof, e.g., one or more operatively programmed general purpose digital computers with associated memory, implementation-specific integrated circuit(s), functional circuitry, etc. Given the techniques of the invention provided herein, one of ordinary skill in the art will be able to contemplate other implementations of the techniques of the invention.
Although illustrative embodiments of the present invention have been described herein with reference to the accompanying drawings, it is to be understood that the invention is not limited to those precise embodiments, and that various other changes and modifications may be made by one skilled in the art without departing from the scope or spirit of the invention.
This application claims priority to the U.S. provisional patent application identified by Ser. No. 60/830,961, filed on Jul. 14, 2006, and entitled “Survivable Failover Architecture for SIP Signaling,” the disclosure of which is incorporated by reference herein.
Number | Date | Country | |
---|---|---|---|
60830961 | Jul 2006 | US |