This invention relates to telephone communication systems and more particularly to the transmission of telephone calls over a packet network.
Reliability is a very important aspect of telephone systems. In voice over IP (VoIP) systems telephone calls go through network gateways. These gateways are, in general, very reliable pieces of equipment; however, they do sometime fail. Furthermore, in some cases a gateway must be intentionally taken out of service for various operational reasons.
In many systems, gateways have a backup gateway available to handle calls if a primary gateway fails or if it is taken out of service? If a telephone call is in progress over a gateway when the gateway fails or is taken out of service, it is desirable to have a mechanism that can switch the call to a backup gateway without disrupting the call.
Various techniques are known for switching calls to a backup gateway when a primary gateway fails or is otherwise taken out of service. One such known technique is called a “statefull switchover” (SSO). A system utilizing SSO must have a backup gateway that is “hot” (i.e. operating and ready to take over for the primary processor). The switchover must take place while maintaining connectivity.
With SSO, primary and the standby gateway must either both maintain the layer 2 data-link connectivity information or such data must be transferred from the primary process to the standby processor when the switchover occurs. Telephone calls can be transmitted to a network gateway using a wide variety of time division multiplex (TDM) protocols. Each such protocol has its own stack organization, and an SSO must in general be able to handle each of the protocols. The information and state information that must be transferred (or maintained) by the backup gateway using SSO includes both the call setup information and the information concerning how the call is being transmitted.
The embodiments described below provide a method and system for switching from a primary gateway to a backup gateway. Only the media path information is maintained on the backup gateway and used during the switchover. The call setup information and the history of the call (that is, the control path information) are not maintained, thereby greatly simplifying the switchover. Since the call setup information is not maintained, the calls that are switched to the backup gateway cannot be terminated in a normal manner. Instead, the calls are terminated by detecting inactivity in the media path.
Preferred embodiment of the invention are described and discussed below with reference to the drawings listed above. However, it should be understood that various other embodiments are possible. That is, this invention may be embodied in many different forms and the invention should not be construed as being limited to the embodiments set forth herein.
The drawings illustrate various aspects of various preferred embodiments of the invention and the drawings also illustrate various aspects concerning the operation of various embodiments. In the drawings, the size of the boxes is not intended to represent the size of the various physical components. The same reference numerals are used to denote the same elements throughout the drawings.
Only the parts of the various units that are relevant to an explanation of the various embodiments are shown and described herein. It should be understood that the units shown in the drawings and described herein have other conventional parts in addition to those shown and described. Many conventional parts of the embodiments, and many conventional operations performed by the embodiments, are not shown or described herein in that such parts and operations are known to those skilled in the art. However, the description given below conveys, in full, clear, and concise terms, to one skilled in the art, how to make and use the various embodiments.
In the following description and in the appended claims the terms “gateway failure” or “gateway fails” means that the gateway can no longer process calls. Thus, a gateway fails when it stops working due to a mechanical or programming problem or when a gateway is taken out of service for some other reason. Stated differently “failure” of a gateway refers to a gateway being unable to process calls for any reason, including voluntary actions by an operator.
The gateways 102 and 106 are connected to and transmit packets through network 104 and they receive packets from network 104 in a conventional manner. The connection between the telephone switch 101 and gateway 102, and the connection between switch 108 and gateway 106 can, for example, be a conventional T1 connection.
As is conventional, a relatively large number of telephones are connected to each of the switches 101 and 108. However, for convenience of illustration only two exemplary phones 100 and 110 are shown in
The system shown in
Gateway 102 includes a conventional gateway operating system 102A and gateway 109 includes a conventional gateway operating system 109A. Gateway 102 also includes a conventional failure detection mechanism 102E that provides a signal if gateway 102 fails. For convenience of reference, gateway 102 will be referred to as the primary gateway.
The T1 connection from switch 101 connects to ports on both primary gateway 102 and to backup gateway 109. It is also noted that, the backup system and technique described below does not depend upon the particular signaling protocol used to transmit calls to the gateway 102.
The following description relates to how one call is switched from the primary gateway 102 to the backup gateway 109. As is conventional, gateway 102 can simultaneously handle a large number of calls. The description that follows relates to one particular call. It will be understood by those skilled in the art, that other calls on the gateway are handled in a similar manner to that described.
The following discussion relates to an illustrative example where telephone 100 places a call to telephone 110. When a call is placed by telephone 100, a conventional call agent 102B, which is part of gateway 102, sets up the call and established a media path for the call in a conventional manner. The setup information and medial path relative to an exemplary call are shown in the
When a call is setup on gateway 102, a subset of the setup information is transferred to and stored in backup gateway 109. The only data transferred to backup gateway 109 is the data that defines the media path used by the call. This is a subset of the information generated by the call agent 102B during the call setup. The information concerning the media path, which is transferred to and stored on gateway 109, is essentially not dependent upon the signaling protocol used to transmit the call to the gateway 102. The information that defines the media path is indicated by block 109C in
For each call handled by gateway 102, the six items of information listed below, which are generated during a conventional call set up procedure by call agent 102B, and which define the media path used by the call, are stored in a call directory in the backup gateway 109.
The six items stored in the call directory on backup gateway 109 are:
The call GUID: The GUID is a unique number that is assigned to each VoIP call. In conventional VoIP systems, when a particular call is set up, the call agent that sets up the call generates a GUID number, which uniquely identifies the particular call. In the system shown in
The Codec used including any keys or encryption algorithm: When a particular call is set up, the call set up process includes deciding upon a specific codec that will be used to code and de-code packets for the call. In certain situation, keys and/or encryption algorithms are also used. In the system shown in
The DSO identification: Telephone switch 101 transmits calls to gateway 102 on a trunk line that includes a number of DSO paths. Each particular call is transmitted to the gateway on one particular DSO. The DSO identifier identifies the particular DSO on which a call was received.
The Destination IP address: IP packets include a header which identifies the destination to which the packet is directed. At call set up time the destination IP address is determined. In the system shown in
The RTP port and RTP SSRC: When a gateway establishes an RPT session, the gateway establishes a port and a unique RPT stream identifier called an RTP SSRC. This identifier identifies a particular RTP stream in the same way that a GUID identifies a particular call. In the system shown in
Local IP Address: This is the IP address of the gateway 102.
A directory 109B is formed on the backup gateway that includes the above information for each of the calls being handled by gateway 102. This directory is stored on gateway 109 at the time that the call agent in gateway 102 sets up the call. When gateway 102 fails and a call is transferred to gateway 109, it is called an orphaned call. The directory for one particular orphaned call is illustrated in
When gateway 102 fails and the transition from gateway 102 to 109 occurs, a software entity, called a session, is initiated on the backup gateway 109 for each call transferred. When the failure detection mechanism 102E detects that gateway 102 has failed, gateway 109 is activated and the media path for all calls then in progress is activated on gateway 109. Each call transferred is called an orphaned call. It is noted that the information necessary to activate the media paths on gateway 109 is transferred during call setup and is available in case gateway 102 fails and the calls must be switched to gateway 109.
For each orphaned call, a session is allocated in gateway 109. In the
Each session established in backup gateway 109 includes:
The components of a session on backup gateway 109 are illustrated in
Thus, when gateway 102 fails, backup gateway 109 begins operating and gateway 109 continues transmitting packets through the packet network to their destination. Likewise backup gateway 109 process packets received from the network and direct them to their appropriate destination.
The active DSOs on the backup gateway 109, after switchover to the backup gateway 109, are associated with a signaling-less Common Channel Signaling (CCS) trunk group. CCS treatment of the call after switchover avoids the need to have knowledge concerning the details of the signaling protocol. After the call setup is complete a call can be viewed as being signaling-less.
In the embodiment shown in
As a specific example consider an embodiment where the input to gateways 102 and 109 is a connection that includes three DSOs of E&M, ten DSOs of E1R2, and twenty-one DSOs of CCS. In such an embodiment when switchover occurs to backup gateway 109, all the DSOs on the backup gateway 109 are assigned to a single signaling-less logical group until the call ends. After calls are terminated, the DSOs are returned to the original signaling group where they were assigned. This type of group assignment does not involve any physical channel movement and it is handled in a conventional manner by the operating system. Each switched over call will have a session as described above which provides the media path for the particular call.
When an orphaned call ends, the gateway 109 does not have the call signaling information available and it cannot terminate the call in a conventional manner. Instead, a pause detector 109E in gateway 109 monitors each call to detect if a period of inactivity occurs. When a period of inactivity, of certain duration, is detected, the media path is closed. The length of the period is a matter of engineering choice. For example it can be set to a value of 2 seconds.
The call is setup by gateway 102 in a conventional manner by a call agent as indicated by block 303. The call setup process, establishes a media path in gateway 102 as indicated by block 306. At the same time the orphaned call directory is established in gateway 109 as indicated by block 307. The call then proceeds in a conventional manner as indicated by block 308.
If no fault is detected (as indicated by block 310), the call is eventually terminated by the call agent in gateway 102 in a conventional manner using the call setup information as indicated by block 315. When a particular call on gateway 102 is terminated, the orphaned call directory on gateway 109 for that particular call is deleted as indicated by block 320.
If a fault is detected (as indicated by block 310), gateway 109 is activated as indicated by block 311. A session is established in gateway 109 (see
The call then proceeds until pause detector 109E detects a pause in the transmission of information over the media path that was established (block 317). When a pause is detected, the media path is terminated as indicated by block 319. When the media path for a particular call is terminated, the orphaned call directory for that particular call is deleted.
It should be noted that the block diagram in
It is also noted that some of the blocks shown in
As is conventional the gateways report calls using conventional call detail records (CDRs). For orphaned calls, the quid of the orphan call can be used to establish the CRD. In order to avoid over billing, a stop record can be sent as soon as the call is reestablished on the backup gateway. In such a situation, the orphaned call on gateway 109 would be free of charge. Alternatively, the stop record can be sent based upon the detection of a pause in the call. In this way the time used by the orphaned call can be charged as appropriate.
It is noted that if the trunk, from telephone switch 101, uses out-of-band signaling (such as ISDN) the d-channel must be served by the backup gateway. Appropriated precautions need be taken to insure that an abnormal disconnect of a DSO running active calls does not occur when the stack on the backup gateway is coming up after a switchover. Such an abnormal disconnect can happen is the ISDN layer 2 timer expires.
The scheme described above can be extended with the use of additional signaling information if such extension is desired. Furthermore, additional layers of redundancy can be provided by the use of checkpointing. For example, the ISDN call reference number and/or the Session Initiation Protocol (SIP) or the H.313 Version 4 protocol can be checkpointed as described below.
ISDN call reference number: The ISDN call reference number is a per call based number. It can be used to map to the GUID of a call. Using the ISDN call reference number, one can handle events such as disconnect/release after switchovers to the backup sever.
Call reference number is not required in the case of ISDN Primary Rate Interface (PRI) because in this case signals are not back hauled from layer 2 to the Call Agent. In this case, the call agent maintains the correct state machine for layer 3. In other cases the orphaned call process receives the events from layer 2 of the protocol, and it handles the disconnect by comparing the checkpointed call reference numbers with the call reference numbers associated with the event. This allows for call clean up.
Session Initiation Protocol (SIP) or the H.313 Version 4 protocol: Other embodiments checkpoint the User Datagram Protocol (UDP) local port of the signaling connection. The SIP called One can also be checkpointed. With H.323 GUID is already checkpointed. The ‘BYE’ command from SIP or H.323 “Release Complete Message” can be handled by matching the call ID in SIP (or the GUID in H.323) to the active call session maintained for an orphaned call. In summary, using checkpointing a system can handle some or all of the SIP events arriving or sent on a SIP signaling port.
It is noted that in the embodiment shown herein, the telephones are connected d to the gateways through telephone switches. In other embodiments, the telephones are connected directly to the gateways. In such embodiments, the backup operation proceeds similar to that described above.
It is also noted that the above description relates to how calls are handled that are in progress when the switchover to the backup gateway occurs. Call that are placed after the switchover occurs, are handled by the backup gateway 109 in a conventional manner. Thus, backup gateway 109 includes a conventional call agent (not shown in the Figure) to handle calls that are placed after the switchover occurs.
While the invention has been shown and described with respect to preferred embodiments thereof, it will be understood by those skilled in the art that various other embodiments are possible.