Internet DRAFT - draft-hss-megaco-control-association-state-machine
draft-hss-megaco-control-association-state-machine
Internet Draft Vikas Bajaj
Document:draft-hss-megaco-control-association- Vivek Bansal
state-machine-00.txt
Expires: February 2002 Shiv Kumar
Prashant Jain
MEGACO Control Association State Machine
draft-hss-megaco-control-association-state-machine-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsolete by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as ôwork in progress.ö
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document captures the description and interpretation of all the
functional procedures and the related procedural parameters,
pertaining to MG-MGC control association, as described in the MEGACO
protocol.
It suggests the various states, the MG and MGC state machines goes
through, during the life cycle of such an association. It goes on to
Vikas, Vivek, Shiv, Prashant 1
INTERNET-DRAFT MEGACO Control Association
Procedures and State Machine August 2001
describe the various inputs each association state of an MG/MGC may
deal with and how the MG/MGC may react towards them.
This document should be read as the supplement to the base protocol.
Table of Contents
Status of this Memo 1
Abstract 1
1. Scope 4
2. References 4
3. Abbreviations 4
4. Conventions 4
5. Control Association Overview 5
6. Assumptions 5
7. Definitions related to Control Association 6
8. The Service Change Command 8
8.1. Usage of Service Change Method 9
9. Overview of Protocol Control Association Procedures 13
9.1. Phases in a Control Association Life Cycle 14
9.2. Control Association States Description 17
10. MG State Machine 18
10.1. INACTIVE STATE 20
10.1.1. Cold Start from MG application 21
10.1.2. Redundant Takeover at standby MG 21
10.2. RIP (RESTART IN PROGRESS) 21
10.2.1. Registration Response from Peer 22
10.2.2. Forced Shutdown from MG application 23
10.2.3. Graceful Shutdown from MG application 23
10.2.4. Failover at active MG 23
10.2.5. Peer Failure Detection at MG 23
10.2.6. Transport Parameters Change at MG 24
10.2.7. Restart from MGC 24
10.2.8. Handoff at current controlling MGC 25
10.2.9. Forced Shutdown at MGC 25
10.2.10. Protocol message from Peer 26
10.2.11. Local Activity at MG application 26
10.3. AIS (ASSOCIATION IN SERVICE) 26
10.3.1. Forced Shutdown at MG 26
10.3.2. Graceful Shutdown at MG 27
10.3.3. Failover at active MG 27
10.3.4. Peer Failure Detection at MG 28
10.3.5. Transport Parameters Change at MG 28
10.3.6. Restart from MGC 29
10.3.7. Handoff at current controlling MGC 29
10.3.8. Forced Shutdown at MGC 30
10.4. SIP (SHUTDOWN_IN_PRGS) 30
10.4.1. Forced Shutdown at MG 30
10.4.2. Graceful Shutdown At MG 30
10.4.3. Peer Failure Detection at MG 31
Vikas, Vivek, Shiv, Prashant 2
INTERNET-DRAFT MEGACO Control Association
Procedures and State Machine August 2001
10.4.4. Restart from MGC 32
10.4.5. Handoff from MGC 32
10.4.6. Forced Shutdown from MGC 33
10.5. SWIP (SWITCHOVER_IN_PRGS) 33
10.5.1. Forced Shutdown At MG 33
10.5.2. Graceful Shutdown At MG 34
10.5.3. Failover at active MG 34
10.5.4. Transport Parameters Change at MG 35
11. MGC State Machine 35
11.1. RIP (RESTART_IN_PROGRESS) 37
11.1.1. Cold Start At MG 38
11.1.2. Forced Shutdown At MG 38
11.1.3. Graceful Shutdown At MG 39
11.1.4. Failover at active MG 39
11.1.5. Redundant Takeover at standby MG 39
11.1.6. Peer Failure Detection at MGC 40
11.1.7. Handoff at Active MGC 40
11.1.8. Forced Shutdown at MGC 40
11.2. AIS (ASSOCIATION IN SERVICE) 41
11.2.1. Forced Shutdown at MG 41
11.2.2. Graceful Shutdown at MG 41
11.2.3. Failover at active MG 42
11.2.4. Transport Parameters Change at MG 42
11.2.5. Transport Parameters Change at MGC 42
11.2.6. Peer Failure Detection at MG 43
11.2.7. Handoff at Active MGC 43
11.2.8. Restart From MGC 44
11.2.9. Forced shutdown At MGC 44
11.3. SWIP (SWITCHOVER_IN_PROGRESS) 44
11.3.1. Forced Shutdown at MG 45
11.3.2. Graceful shutdown request from MG 45
11.3.3. Failover at active MG 46
11.3.4. Redundant Takeover at standby MG 46
11.3.5. Forced Shutdown at MGC 46
11.3.6. Restart From MGC 46
11.3.7. Handoff at Active MGC 47
11.3.8. Re-registration request from active or standby
MG 47
11.4. SIP (SHUTDOWN_IN_PROGRESS) 48
11.4.1. Forced Shutdown at MG 48
11.4.2. Graceful Shutdown at MG 48
11.4.3. Failover at active MG 49
11.4.4. Redundant Takeover at standby MG 49
11.4.5. Forced Shutdown At MGC 49
AuthorÆs Addresses 49
Vikas, Vivek, Shiv, Prashant 3
INTERNET-DRAFT MEGACO Control Association
Procedures and State Machine August 2001
1. Scope
This document puts into words, the interpretation the authors have,
after studying the MEGACO RFC, Implementation Guides and discussions
in the MEGACO mailing list, Annex L and the manner in which the
control association state machine of MG and MGC work while executing
the respective control association procedures.
There is still a certain amount of lack of clarity regarding the
topic of control associations in MEGACO perspective as a whole. So
to help arrive at some kind of conclusion, the authors have made
some assumptions about these unclear aspects of the protocol.
Changes in these assumptions may affect the overall interpretation
of this topic. Nevertheless the authors have tried their utmost to
preserve the existing description of the protocol. The authors have
also taken into account various converging assumptions, which were
discussed, extensively on the mailing list.
2. References
[1] F. Cuervo, N. Greene, C. Huitema, A. Rayhan, B. Rosen, J.
Segers, ôMedia Gateway Control Protocol Version 1.0ö, RFC 3015,
November 2000.
[2] H.248 Annex L û Error Codes and Service Change Reason Description
for Approval.
[3] H.248 Series ImplementersÆ Guide (09/05/2001) Ver. 7.
3. Abbreviations
This recommendation defines the following terms.
GW GateWay
IANA Internet Assigned Numbers Authority
IP Internet Protocol
MG Media Gateway
MGC Media Gateway Controller
NM Network Management
4. Conventions
The key words ôMUSTö, ôMUST NOTö, ôREQUIREDö, ôSHALLö, ôSHALL
NOTö,öSHOULDö, ôSHOULD NOTö, ôRECOMMENDEDö, ôMAYö, and ôOPTIONALö
in this document are to be interpreted as described in RFC2119.
Vikas, Vivek, Shiv, Prashant 4
INTERNET-DRAFT MEGACO Control Association
Procedures and State Machine August 2001
5. Control Association Overview
A control association can be defined as the logical session between
two key entities of the decomposed gateway architecture viz., MG and
MGC. MEGACO protocol has defined a set of control association
procedures between these two entities to achieve the distributed
call control functionality. The control association functionality
has been visualized as a disjoint set of procedures independent of
the call processing/management activity. However any change
(permanent or transient) in the state of the control association
between MG and MGC may or may not affect the call-related aspects
both at MG and MGC.
+--------------------------+ +--------------------------+
| +------------------+ | | +------------------+ |
| |Call Management | | | |Call Processing | |
| |Entity | | | |Entity | |
| +------------------+ | | +------------------+ |
| | | |
| +------------------+ | | +------------------+ |
| |Association | | | |Association | |
| |Management Entity | <------------> |Management Entity | |
| +------------------+ | | +------------------+ |
| | | |
+--------------------------+ +--------------------------+
MGC MG
6. Assumptions
(1) Peer Entities shall be identified based on the MID field in the
message header field of the protocol message.
(2) Primary and secondary MGCs may be supporting different versions and
gateway service profiles.
(3) Service Change command with method as ôRESTARTö on ROOT
terminations indicates that all terminations are in service, by
default.
(4) Synchronization between redundant MGs and that between redundant
MGCs is outside the scope of the MEGACO protocol.
(5) Since the Mid should not change during the course of the control
association, MGs running in redundant configuration must have same
MIDs.
Vikas, Vivek, Shiv, Prashant 5
INTERNET-DRAFT MEGACO Control Association
Procedures and State Machine August 2001
(6) MGCs running in redundant configuration may or may not have same
MIDs.
(7) Secondary MGCs being provisioned at MG may or may not be running in
the redundant configuration.
(8) ôService Change Reasonö parameter can be understood as the
qualifier to the information that the ômethod field conveys while
indicating the change in the control association through the
service change command.
(9) The ôService Change Addressö and ôMGCIdToTryö parameters are only
applicable on ROOT termination. When sent in a service change
command would convey the transport address to which future
communication should be made.
(10) A MG is pre-provisioned by a management mechanism outside the
scope of this protocol with a Primary and (optionally) an ordered
list of Secondary MGCs.
The pre-provisioning of MGCs at MG reveals all the transport
parameters of the specified MGCs, at which MG would initially try to
create the logical session with one of them. The MIDs of the
respective MGCs may or may not be configured along with the
transport parameters.
However, MGC need not be provisioned with the list of MGs, from
which the control associationsÆ request can be received during the
start up phase. The controlled MGs would be identified by their
MIDs, retrieved from the first service change command being received
from each of them. The MID of the respective MGs must not change
during the life cycle of the control association.
Vikas, Vivek, Shiv, Prashant 6
INTERNET-DRAFT MEGACO Control Association
Procedures and State Machine August 2001
7. Definitions related to Control Association
The terms mentioned below are important and are to be kept in mind
while reading the document. These should be referred to as and when
required.
A. Cold Start: It is defined as the fresh start of the Media Gateway.
All the terminations would be assumed to be in-service by default.
All the terminations would be present in the NULL context. In
other words, no active calls would be running over any of the
associated terminations present in the specified control
association.
B. Planned Switchover: It is defined as a planned activity being
initiated either by MG or MGC application or the NM entity, which
triggers the generation of Service Change command from the entity
which is going out-of-service and informs about the switchover to
a redundant entity.
C. Transparent Switchover: It is defined as an activity wherein the
MGC or MG does not come to know about the redundant takeover that
happened on the other entity involved in the control association,
as the transport parameters of the affected entity (MG or MGC)
have been retained.
D. Unplanned Switchover: It is defined as an unplanned activity
occurring at MG, which caused it to go abruptly out-of-service.
Moreover due this activity, redundant MG has taken over the
control and it sends the Service Change command. Here there would
not be any protocol message that was generated from the MG that
went down.
E. Warm Redundancy: It is defined as the switchover operation from an
active to a standby entity, wherein all the existing calls on the
failed entity have been lost, although a new entity (standby) has
taken over the control association. Both MG and MGC can have this
kind of implementation.
F. Hot Redundancy: It is defined as the switchover operation between
an active and a standby entity, wherein all the existing calls
have survived over the standby one, even though the new entity
(standby) has taken over the control association. All the call
states were preserved. Both MG and MGC can have this kind of
implementation.
G. Cold Boot: It is defined as the boot operation in which MG was
able to preserve the statically provisioned data by NM as well as
Vikas, Vivek, Shiv, Prashant 7
INTERNET-DRAFT MEGACO Control Association
Procedures and State Machine August 2001
the dynamic configuration data provided in NULL context by MGC,
however all the active contexts or calls were lost due to some
internal failure.
H. Warm Boot: It is defined as the boot operation in which MG was
able to preserve the static provisioned data by NM as well as the
dynamic configuration data provided by MGC in NULL context.
In Warm Boot, all the active contexts or calls were survived at
the MG, however some of the transient transactions are lost.
I. Message Identifier (MID): This field is an identifier (either the
transport address or just a logical identifier) that reveals the
identity of the entity, which is originating the protocol message.
It is the mandatory part of the every protocol message that is
exchanged between MG and MGC.
8. The Service Change Command
MEGACO protocol defines all the control association procedures using
a Service Change command on ROOT termination. Each such command
would encapsulate a set of control parameters that would be utilized
while executing the related procedures. A service change command on
ROOT governs the change in the state of the control association in
terms of the change in either the communication status between MG-
MGC or the change in the existing call states.
It is worth noting that a Service Change with termination ID as ALL
or ô*ö just means that terminations in the originating entity have
undergone a state change in the ôservice-stateö. This may impact the
existing calls that are active over the specified terminations.
However there is no change in the state of the control association.
The control parameters pertaining to a service change command are
listed below.
A. Service Change Method.
B. Service Change Reason.
C. Service Change Profile.
D. Service Change Version.
E. Service Change Address.
F. Service Change MGCIdToTry.
G. Service Change Delay.
H. Service Change Timestamp.
Vikas, Vivek, Shiv, Prashant 8
INTERNET-DRAFT MEGACO Control Association
Procedures and State Machine August 2001
Of all the above parameters, the ôservice change methodö is the main
attribute that primarily dictates the behavioral change in the state
of a control association. The other parameters, which are the part
of the service change command, help the remote entity to execute the
relevant protocol-defined procedures with respect to the state
change in the control association. For instance, in case of command
issued with ôDISCONNECTEDö method from MG, it is conveyed to MGC
that the MG was temporarily disconnected with MGC. Here MGC may
infer that there may be some synchronization problem between the two
and an AUDIT command may be issued.
The ôservice change reasonö, if specified, should be looked into to
determine the severity of change in the states of the calls being
realized by MG and then act accordingly.
The ôservice change timestampö, if specified, conveys the exact time
when the service change command was issued. This would help the
receiving entity in making decisions irrespective of the transport
delay.
8.1. Usage of Service Change Method
The ôService Change Methodö parameter on ROOT specifies the change
in the control association between MG and MGC. The change in service
may be because of either of the following functional changes.
Note that the Service Change Reason conveys the gravity of the
change in call states, as and when required.
These two aspects can be understood more clearly as one goes through
the interpretation of different methods defined in the protocol.
a. Graceful:
1. This method can only be sent from MG to MGC. It indicates that
the MG will be taken out of service after the specified Service
Change Delay.
2. The established connections or calls over the individual
terminations are not yet affected.
3. After the specified delay, all the calls would be terminated
abruptly, and all the terminations would be moved into the null
Vikas, Vivek, Shiv, Prashant 9
INTERNET-DRAFT MEGACO Control Association
Procedures and State Machine August 2001
context at MG. The controlling MGC will not send any SUBTRACT
command to MG and clear all the call contexts at its end.
4. The ôgracefulö with delay NULL means that MG would terminate
the control association AFTER all the call contexts are
cleared.
5. In either of the above cases, the MGC should refrain from
establishing new calls during the course of the graceful
shutdown and should try to clear the existing call contexts
gracefully.
b. Forced:
1. This method can either be sent from MG to MGC or vice versa.
2. It indicates that the originating entity (MG/MGC) was taken
abruptly out of service and any established connections or
calls active over the associated terminations were lost,
consequently all the terminations at its end were moved to
null context.
3. The receiving entity (MGC/MG) is responsible for cleaning up
the call contexts at its end.
c. Restart:
1. This method can be sent from MG to MGC or vice versa.
When sent from the MG to the MGC,
2. At COLD start, it indicates that the MG has already come into
service afresh. All the terminations are assumed to be in
service.
3. If non-zero delay is specified, it signifies that although the
MG is capable of communicating with the controlling MGC, the
service or the call-carrying capability would be restored on
the physical terminations, associated with ôROOTö termination,
AFTER the specified delay.
When sent from the MGC to the MG,
4. It indicates the MGC wants MG to restart.
Vikas, Vivek, Shiv, Prashant 10
INTERNET-DRAFT MEGACO Control Association
Procedures and State Machine August 2001
5. If non-zero delay is specified, it signifies that the service
or the call-carrying capability would be restored on the
physical terminations, associated with ôROOTö termination,
AFTER the specified delay.
6. In case of warm boot or cold boot, it indicates change in the
protocol version supported by the remote. In this case, the
already existing calls at MG may or may not be retained.
d. Disconnected:
1. This method can only be sent from MG to MGC.
2. This method indicates that the MG lost communication with the
controlling MGC either because of its transient failure, which
was subsequently restored or MG detects failure of its
controlling MGC and tries to contact it again.
3. The transient failure may be because of:
- Failures of the underlying transport or there was some change
in the transport parameters of MG.
- If there is some call-state loss at MG.
- Switchover (either planned or unplanned) to standby MG. Here
the standby MG generates this method.
4. In either of the above scenarios, the MGC may audit the MG to
synchronize its state.
e. Handoff:
1. This method can either be sent from MG to MGC or vice versa.
When sent from the MGC to the MG,
2. This method indicates that the MGC is going out of service and
a control association must be established with the new MGC.
However sent from the MG to the MGC,
Vikas, Vivek, Shiv, Prashant 11
INTERNET-DRAFT MEGACO Control Association
Procedures and State Machine August 2001
3. This indicates that the MG is attempting to establish a new
control association in accordance with a Handoff received from
the MGC with which it was previously associated.
4. The above operation should be transparent to the MG
application.
5. In this case, MGC must audit the requesting MG to resynchronize
its state, in the absence of which MG assumes that MGC has
failed and start trying secondary ones.
f. Failover:
1. This method can only be sent from MG to MGC.
2. When sent from the MG, which is going down, this method
indicate the primary MG is out of service and a secondary MG
would be taking over.
3. Otherwise, this method reveals that MG detects the failure of
its controlling MGC and is now trying the secondary MGC to re-
establish the control association.
4. In either of the above cases, the already existing calls at MG
may or may not be retained.
Vikas, Vivek, Shiv, Prashant 12
INTERNET-DRAFT MEGACO Control Association
Procedures and State Machine August 2001
The valid combinations of the Method vis-€-vis other Service change
parameters have been captured in the following table:
+--------+-------+--------+--------+--------+--------+------------+
|Method/ | DELAY |DIRECTION|VERSION |PROFILE |SVC ADDR| MGCIdToTry|
|Parameters | | | | | |
+--------+-------+--------+--------+--------+--------+------------+
|RESTART | A | MG->MGC| A | A | A | NA |
| | | | | | | |
+--------+-------+--------+--------+--------+--------+------------+
|FORCED | NA | MG->MGC| NA | NA | NA | NA |
| | | MGC->MG| | | | |
+--------+-------+--------+--------+--------+--------+------------+
|GRACEFUL| A | MG->MGC| NA | NA | NA | NA |
| | | | | | | |
+--------+-------+--------+--------+--------+--------+------------+
|DIS- | | | | | | |
|CONNECTED NA | MG->MGC| NA | NA | A | NA |
| | | | | | | |
+--------+-------+--------+--------+--------+--------+------------+
|FAILOVER| NA | MG->MGC| A | A | NA | NA |
| | | | | | | |
+--------+-------+--------+--------+--------+--------+------------+
|HANDOFF | NA | MGC->MG| A | A | NA | A |
| | | MG->MGC| | | | |
+--------+-------+--------+--------+--------+--------+------------+
A - Allowed
NA- Not Allowed
9. Overview of Protocol Control Association Procedures
As already mentioned, protocol has defined a set of procedures to
address the various aspects of control association between MG and
MGC. Apart from this, some guidelines have been laid for initial
provisioning of MG before the actual control association is
established between MG and MGC.
All the control association procedures that have been discussed in
the protocol cater to a set of scenarios. Hence the relevant
procedures have been categorized into different phases, depending on
the behavioral changes the control association undergoes during its
life cycle, for all the respective scenarios. This categorization
would form the basis on which the complete state machine design of
the MG-MGC control association would rely upon.
Vikas, Vivek, Shiv, Prashant 13
INTERNET-DRAFT MEGACO Control Association
Procedures and State Machine August 2001
9.1. Phases in a Control Association Life Cycle
Further based on whatever protocol has defined, the life cycle of a
control association can be divided into the following phases.
1. Association Inactive Phase.
2. Association Restart Phase.
3. Association Active Phase.
4. Association Shutdown Phase.
5. Association Switchover Phase.
1) Inactive Phase: During this phase of operation, both MG and MGC
would just have the necessary pre-provisioned data (specifically
the transport parameters) and they are waiting for a trigger from
the application to initiate the control association related
procedures.
2) Restart Phase: During this phase of operation, the control
association between MG and MGC is restarted between the concerned
MG and the MGC.
The following scenarios and the corresponding procedures can be
addressed in this phase of operation.
. A control association between the concerned MG and MGC is
initiated from MG at its Cold start. No calls are present at
the moment.
Method: RESTART from MG.
Reason: Cold Boot or Service Restored.
. MG wants to change its protocol version. The calls may or may
not get affected (call states change would be decided by
ôService Change Reasonö, if present).
Method: RESTART from MG.
Reason: Warm Boot, Cold Boot or Service Restored.
. MGC wants to change its protocol version. The calls may or may
not get affected (call states change would be conveyed to by
ôService Change Reasonö, if present).
Method: RESTART from MGC.
Reason: Warm Boot, Cold Boot or Service Restored.
Vikas, Vivek, Shiv, Prashant 14
INTERNET-DRAFT MEGACO Control Association
Procedures and State Machine August 2001
. MGC wants to initiate a reboot operation at MG due to its own
failure or in case of version change at its end. The
corresponding service change request from MGC may be generated
only if the MG was already registered with the former.
Method: RESTART from MGC.
Reason: Warm Boot, Cold Boot.
3) Active Phase: During this phase of operation, MG-MGC control
association is alive and normal protocol commands get exchanged
across the two entities as defined in the protocol. In this phase
of operation, MG may exchange the control association command
(service change on ROOT) intending to resynchronize the states of
the terminations engaged in the association or to convey about
the future behavior of the control association.
Note that the ôservice change command on ROOTö is not allowed
from MGC for the state synchronization with the peer. The
following two possibilities may arise in this phase of operation.
The following control association scenarios and the corresponding
procedures can be addressed in this phase of operation.
. If there is a transient failure at MG, either due to a problem
in the underlying transport layer, or there was a transparent
switchover at MG but it was recovered subsequently.
Method: DISCONNECTED from MG.
Reason: Cold Boot or Warm Boot.
. If there is going to be a service shutdown at MG after some
planned duration, MG may initiate a service change command to
the peer MGC to convey the same information so that the latter
may act accordingly. However, the existing association is not
affected at all.
Method: GRACEFUL from MG.
Reason: None.
. If there is a planned switchover at MG to a standby entity and
the new entity was realizing either Warm or Hot Redundancy.
Method: DISCONNECTED from MG.
Reason: Cold Boot or Warm Boot.
Vikas, Vivek, Shiv, Prashant 15
INTERNET-DRAFT MEGACO Control Association
Procedures and State Machine August 2001
4) Association Switchover Phase: This phase can be visualized as the
activity involved in bringing the control association back to the
active phase by switching over to a different entity. This
switchover to a different remote may occur either implicitly
(peer failure detection locally) or explicitly (through failure
notification from remote)
The following control association scenarios and the corresponding
procedures can be addressed in this phase of operation.
. MGC detects the failure of its controlled MG and it waits for a
service change request from MG (either it may be active or the
standby), to re-establish the control association.
Method: MGC expects either RESTART or DISCONNECTED.
Reason: Cold Boot or Warm Boot.
. MGC receives the failure indication from its controlled MG and
it waits for a re-registration request from either the active
or the standby MG afterwards.
From active MG
Method: FAILOVER.
Reason: MG Impending Failure.
Subsequently from standby MG
Method: RESTART or DISCONNECTED.
Reason: Cold Boot or Warm Boot.
. MG detects the failure of its controlling MGC and it tries the
secondary MGCs in order, to re-establish the control
association.
Method: FAILOVER from MG.
Reason: MGC Impending Failure.
. MG detects the failure of its controlling MGC and the control
association is also not established with secondary MGCs and the
failed one is attempted again.
Method: DISCONNECTED from MG.
Reason: MGC Impending Failure.
Vikas, Vivek, Shiv, Prashant 16
INTERNET-DRAFT MEGACO Control Association
Procedures and State Machine August 2001
. MG tries to register with the handed-off MGC as redirected by
its controlling MGC to re-establish the control association
with the newly specified MGC.
Method: HANDOFF from MG.
Reason: MGC Directed Change.
5) Association Shutdown Phase: This phase can be visualized as the
period during which the originating entity conveys to the remote
entity (MG or MGC) about its own failure. Additionally, the
sending entity may indicate that another entity would come up to
take up the control of the specified association.
The following control association scenarios and the corresponding
procedures can be addressed in this phase of operation.
- There is a planned switchover activity being initiated at MG
due to a local failure or for maintenance reasons and the same
is conveyed to MGC.
Method: FAILOVER from MG.
Reason: MG Impending Failure.
- There is a planned switchover activity being initiated at MGC
due to a local failure or for maintenance reasons and the same
is conveyed to MG.
Method: HANDOFF from MGC.
Reason: MGC Impending Failure.
- There is a forced shutdown at MG or MGC and the specified
entity wishes to convey this information to its peer. Both MG
and MGC would terminate all the active calls at their ends.
Method: FORCED from MGC or MG.
Reason: None.
9.2. Control Association States Description
The input triggers to the state machine would be extracted from the
identified scenarios in the above section and the different states
inside the state machine are determined from the identified phases.
Vikas, Vivek, Shiv, Prashant 17
INTERNET-DRAFT MEGACO Control Association
Procedures and State Machine August 2001
The states, which have been designed in both MG and MGC state
machines, maps one-to-one on the phases explained earlier and are
listed as follows:
1. Restart In Progress.
2. Association In Service.
3. Switchover In Progress.
4. Shutdown In Progress.
5. Inactive.
The list of various inputs to the state machine is as follows.
1. Cold Start at MG.
2. Registration Response from MGC.
3. Forced Shutdown at MG.
4. Graceful Shutdown at MG.
5. Failover at active MG.
6. Redundant Takeover at standby MG.
7. Peer Failure Detection at MG.
8. Transport Parameters Change at MG.
9. Restart From MGC.
10. Handoff at Active MGC.
11. Peer Failure Detection at MGC.
12. Forced Shutdown at MGC.
10. MG State Machine
This section gives the actual protocol procedures that must me
followed or the actual protocol commands that must be exchanged when
the expected input triggered in either of the defined states.
With every call flow we will also identify, what are the possible
inputs that can be triggered in these states.
Vikas, Vivek, Shiv, Prashant 18
INTERNET-DRAFT MEGACO Control Association
Procedures and State Machine August 2001
This table maps the service change method received from peer to the
control association states of MG.
+------------+--------+--------+-----------+----------+----------+
|Method/ | |Restart |Association|Switchover|Shutdown |
| States |Inactive|In |In |In |In |
| | |Progress|Service |Progress |Progress |
+------------+--------+--------+-----------+----------+----------+
|RESTART | NA | A | A | A | A |
| | | | | | |
+------------+--------+--------+-----------+----------+----------+
|FORCED | NA | A | A | A | A |
| | | | | | |
+------------+--------+--------+-----------+----------+----------+
|GRACEFUL | | | | | |
| | NA | NA | NA | NA | NA |
+------------+--------+--------+-----------+----------+----------+
|DISCONNECTED| NA | NA | NA | NA | NA |
| | | | | | |
+------------+--------+--------+-----------+----------+----------+
|FAILOVER | NA | NA | NA | NA | NA |
| | | | | | |
+------------+--------+--------+-----------+----------+----------+
|HANDOFF | NA | A | A | NA | A |
| | | | | | |
+------------+--------+--------+-----------+----------+----------+
A û Allowed
NA- Not Allowed
Vikas, Vivek, Shiv, Prashant 19
INTERNET-DRAFT MEGACO Control Association
Procedures and State Machine August 2001
+-------------------+
| INACTIVE |
| |
+-----+----+--+--+--+
| | | |
| | | +------------<<-----------+
Cold Start| | |
of MG | +-------<<--------+ |
| +--------------+ | |
| Redundant Take-| |
| over at Standby| |
+-----V--------------+ | | |
| RESTART IN | | | |
| PROGRESS | | | |
| | | | |
+--+----+---------+--+ | | |
| | | | | |
| | Registration | | |
+->>-------------+ | Completion and | | |
MGC Forced +>>-----------+ Restart Delay | | |
Shutdown | Timeout | | | |
| | +---------+ | | | Failover
| | | Graceful| | | | Completion
| Restart Trigger | Shutdown| V | | |
| from MG/MGC V | V V | |
| | +---V---------+---+--+ V | |
| | | ASSOCIATION IN +----+ | |
| +-----+ SERVICE | | |
+-----<<------+ | MG Forced Shutdown/ |
+-+---+--------+---+-+ Graceful Timeout |
| | | V | |
+----<<-----V | | V------------+ |
| | +----------+ |
MGC Failure| | MG Failover | |
Detected/ | +-->>------+ | |
Handoff | | New Association | |
V | is established +----V------------+ |
+----------V----+--+ | | |
| SWITCHOVER IN | | SHUTDOWN IN | |
| PROGRESS | | PROGRESS | |
+------------------+ +--------------+--+ |
V |
V------+
Figure 1: MG State Machine Transition Diagram
The procedures given below show the behavior of the state machine
when the expected input is given to it.
Vikas, Vivek, Shiv, Prashant 20
INTERNET-DRAFT MEGACO Control Association
Procedures and State Machine August 2001
10.1. INACTIVE STATE
10.1.1. Cold Start from MG application
Input parameters:
- Service change delay.
- Service Change Address.
- Service Change Version.
- Service Change Profile.
10.1.1.1. Steps
1) Start the restart avalanche timer.
2) On expiry of the restart avalanche timer, send the service
change request command with method as RESTART, reason as
SERVICE RESTORED and the other specified parameters.
3) In addition to the generation of Service Change command,
start the Restart Delay timer, if present.
10.1.1.1. New State
RIP (RESTART IN PROGRESS)
10.1.2. Redundant Takeover at standby MG
Input parameters:
- Service Change Address.
- Service Change Reason.
10.1.2.1. Steps
1) Send the service change request command with method as
DISCONNECTED and the other specified parameters.
10.1.2.1. New State
AIS (ASSOCIATION IN SERVICE)
10.2. RIP (RESTART IN PROGRESS)
Vikas, Vivek, Shiv, Prashant 21
INTERNET-DRAFT MEGACO Control Association
Procedures and State Machine August 2001
10.2.1. Registration Response from Peer
Input parameters: None
10.2.1.1. Steps
1) During the registration, if all the parameters were
accepted by MGC, it replies back with the successful
response.
a) If the delay was specified in the service change
delay, then the state remains same. On expiry of the
restart delay, the state is changed to AIS
(ASSOCIATION IN SERVICE).
b) If the delay was not specified, the state is
immediately changed to (AIS) ASSOCIATION IN SERVICE.
2) If Service change address present in the service change
command response from peer, modify the address of the
MGC to send all the subsequent requests to MGC on the
newly specified address. Association State in this case
again depends upon the service change delay parameter
sent in the request as described in step 1.
3) If the ServiceChangeMgcId is present in the service
change command response from peer. Then,
a) MG sends the service change command to MGC specified
in the ServiceChangeMgcId with the same parameters.
b) This procedure continues till the registration request
is accepted by the new MGC.
4) If the Protocol Version is present in the Service change
response.
a) If MG complies with the version received in the
service change response, state changes would be as
described in step 1.
b) If the MG is not able to comply with the version
received in the service change response, it tries the
secondary MGCs with the same service change
Vikas, Vivek, Shiv, Prashant 22
INTERNET-DRAFT MEGACO Control Association
Procedures and State Machine August 2001
parameters till the registration request is accepted
by any of the configured MGCs.
10.2.2. Forced Shutdown from MG application
Input parameters: None
10.2.2.1. Steps
1) Clear all the call contexts forcefully.
2) Send Service Change command to the controlling MGC with
method as FORCED.
10.2.2.2. New State
INACTIVE
10.2.3. Graceful Shutdown from MG application
Input parameters:
- Service Change Delay
10.2.3.1. Steps
1) If the Graceful delay is less than the Restart delay, then
stop the Restart delay timer, then send the service change
request to MGC with method as FORCED. The new state
becomes INACTIVE.
2) If the Graceful delay is more that the Restart delay, send
the service change request to MGC with method as GRACEFUL
and delay as specified in the input parameters. The state
remains unchanged.
10.2.4. Failover at active MG
The MG Failover is not expected in this state. It is assumed
that since there has been no call-related activity in this
state.
10.2.5. Peer Failure Detection at MG
Vikas, Vivek, Shiv, Prashant 23
INTERNET-DRAFT MEGACO Control Association
Procedures and State Machine August 2001
If MG detects the Failure of the MGC to which it had sent the
service change request.
10.2.5.1. Steps
1) Send the service change command to secondary MGCs, with
the same set of parameters as sent in the initial
registration message to primary MGC until registration is
completed.
10.2.5.2. New State
The state remains unchanged.
10.2.6. Transport Parameters Change at MG
Input parameters:
- Service Change Address
10.2.6.1. Steps
1) Send the service change command with method as RESTART
and the specified Service Change Address.
10.2.6.2. New State
State remains same.
10.2.7. Restart from MGC
Input parameters:
- Service Change Reason
10.2.7.1. Steps
1) Stop the Restart Delay timer if running.
2) Give the indication to the MG application to restart MG,
along with the received service change reason from MGC.
Vikas, Vivek, Shiv, Prashant 24
INTERNET-DRAFT MEGACO Control Association
Procedures and State Machine August 2001
3) Once the restart operation is finished, MG generates the
registration command to the same controlling MGC.
10.2.7.2. New State
State remains unchanged.
10.2.8. Handoff at current controlling MGC
Input parameters:
- Service Change MGCIdToTry
This input trigger could be received from MGC if the control is
transferred to a new MGC.
10.2.8.1. Steps
1) Start the restart avalanche timer to prevent the avalanche
at MGC.
2) Send the service change request to Handed-off MGC with
method as HANDOFF and reason as MGC Impending Failure.
10.2.8.2. New State
State remains unchanged.
10.2.9. Forced Shutdown at MGC
This input trigger could be received when the Restart Delay
timer is running.
10.2.9.1. Steps
1) MG attempts to contact the next MGC on its pre-provisioned
list. Implementation may start its attempts at the
beginning (that was the MGC that failed), or it attempts
the next remote in the configured list.
10.2.9.2. New State
RIP (RESTART_IN_PROGRESS)
Vikas, Vivek, Shiv, Prashant 25
INTERNET-DRAFT MEGACO Control Association
Procedures and State Machine August 2001
10.2.10. Protocol message from Peer
Input parameters: None
10.2.10.1. Steps
1) If before receiving the response from MGC, MG received the
protocol commands from MGC, it should reply back with the
error code ôCommand received before restart responseö.
2) If after receiving the response from MGC, and if the delay
timer is still running, and during this time a protocol
command from MGC is received, that command should be Audit
capability only. For any call related protocol commands
like Add, Modify, it should return back an error ôService
Unavailableö.
10.2.11. Local Activity at MG application
Input parameters: None
10.2.11.1. Steps
1) If during the execution of the restart avalanche timer, a
local activity is detected, then stop the restart avalanche
timer
2) Send the service change request command with method as
RESTART and reason as SERVICE RESTORED.
10.2.11.2. New State
State remains same.
10.3. AIS (ASSOCIATION IN SERVICE)
10.3.1. Forced Shutdown at MG
Input parameters: None
10.3.1.1. Steps
Vikas, Vivek, Shiv, Prashant 26
INTERNET-DRAFT MEGACO Control Association
Procedures and State Machine August 2001
1) Terminate all the active calls contexts on its own.
2) Send the Service Change command to the MGC with method as
FORCED.
10.3.1.2. New State
INACTIVE
10.3.2. Graceful Shutdown at MG
Input parameters:
- Service change delay
10.3.2.1. Steps
1) Start the delay timer for value specified in Service change
delay.
2) Send the request to MGC with GRACEFUL method and with the
specified service change delay.
3) Till the expiry of the service change delay, the state of
MG control association remains ASSOCIATION IN SERVICE
(AIS).
4) Delete all the call contexts abruptly after the completion
of the graceful period.
5) If the NULL delay was specified, the control association
must last for the duration of the time until all the active
call contexts are cleared by MGC.
10.3.3. Failover at active MG
Input parameters: None
10.3.3.1. Steps
1) Send the service change request to MGC with FAILOVER
method.
Vikas, Vivek, Shiv, Prashant 27
INTERNET-DRAFT MEGACO Control Association
Procedures and State Machine August 2001
2) Since the protocol mandates that the response should go to
the source address, the control association must wait for
the respective replies for all pending transaction
requests.
10.3.3.2. New State
SIP (SHUTDOWN_IN_PRGS)
10.3.4. Peer Failure Detection at MG
Input parameters: None
10.3.4.1. Steps
1) If the MG detects a failure of its controlling MGC, it
attempts to contact the next MGC on its pre-provisioned
list. It starts its attempts at the beginning (Primary
MGC), unless that was the MGC that failed, in which case
it starts at its first Secondary MGC. It sends a Service
Change message with a ôFailoverö method and reason as MGC
Impending Failure.
2) All new transaction requests and the outstanding
transaction responses must be queued till the MGC replies
back with the transaction accept.
10.3.4.2. New state
SWIP (SWITCHOVER_IN_PRGS)
10.3.5. Transport Parameters Change at MG
Input parameters:
- Service Change Address
10.3.5.1. Steps
1) Send the service change command with method as
DISCONNECTED and specify the new local address in the
Service Change Address field of the command.
New State
Vikas, Vivek, Shiv, Prashant 28
INTERNET-DRAFT MEGACO Control Association
Procedures and State Machine August 2001
State remains unchanged
10.3.6. Restart from MGC
Input parameters:
- Service Change Reason.
- Service Change Address.
10.3.6.1. Steps
1) Give the indication to the MG application to restart MG,
along with the received service change reason from MGC.
2) Once the restart operation is finished, MG generates the
registration command to the same controlling MGC on the
newly specified service change address.
10.3.6.2. New State
RIP (RESTART IN PROGRESS).
10.3.7. Handoff at current controlling MGC
Input parameters:
- Service Change MGCIdToTry
10.3.7.1. Steps
1) Start the restart avalanche timer to prevent the avalanche
at MGC.
2) Send the service change request to Handed-off MGC with
method as HANDOFF and reason as MGC Impending Failure.
3) Since this procedure must be transparent to the MG
application, all new transaction requests and the
outstanding transaction responses must be queued until the
re-registration is complete.
10.3.7.2. New State
SWIP (SWITCHOVER_IN_PRGS)
Vikas, Vivek, Shiv, Prashant 29
INTERNET-DRAFT MEGACO Control Association
Procedures and State Machine August 2001
10.3.8. Forced Shutdown at MGC
Input parameters: None
10.3.8.1. Steps
1) Give the indication to the MG application to clear all
the call contexts.
2) Once the cleanup operation is finished at MG, it
generates the registration command to either primary or
secondary MGC with method as RESTART û Implementation
specific.
10.3.8.2. New State
RIP (RESTART_IN_PROGRESS)
10.4. SIP (SHUTDOWN_IN_PRGS)
10.4.1. Forced Shutdown at MG
If during the Failover operation, the primary MG feels that the
redundant MG entity is unable to take over the control, it can
ask the primary MG to send Forced Shutdown towards its peer.
10.4.1.1. Steps
1) Terminate all the active calls contexts on its own.
2) Send the Service Change command to the MGC with method as
FORCED.
10.4.1.2. New State
INACTIVE
10.4.2. Graceful Shutdown At MG
Vikas, Vivek, Shiv, Prashant 30
INTERNET-DRAFT MEGACO Control Association
Procedures and State Machine August 2001
If during the Failover operation, the primary MG feels that the
redundant MG entity is unable to take over the control, it can
ask the primary MG to send Graceful shutdown towards its peer,
to clear all the existing calls gracefully.
Input parameters:
- Service Change Delay
10.4.2.1. Steps
1) Start the delay timer for value specified in Service change
delay.
2) Send the request to MGC with GRACEFUL method and with the
specified service change delay.
3) Till the expiry of the service change delay, the state of
MG control association becomes ASSOCIATION IN SERVICE
(AIS).
4) Delete all the call contexts abruptly after the completion
of the graceful period.
5) If the NULL delay was specified, the control association
must last for the duration of the time until all the active
call contexts are cleared by MGC.
10.4.2.2. New State
AIS (ASSOCIATION IN SERVICE).
10.4.3. Peer Failure Detection at MG
Input parameters: None
10.4.3.1. Steps
1) If during the Failover phase, if MG detects the failure of
controlling MGC, this information should be conveyed to the
standby entity (outside the scope of the protocol) so that
any further recovery action (trying secondary MGCs) would
be taken via the redundant MG.
Vikas, Vivek, Shiv, Prashant 31
INTERNET-DRAFT MEGACO Control Association
Procedures and State Machine August 2001
10.4.3.2. New State
INACTIVE
10.4.4. Restart from MGC
Input parameters:
- Service Change Reason.
- Service Change Address.
10.4.4.1. Steps
1) Give the indication to the MG application to restart MG,
along with the received service change reason from MGC.
Henceforth, the standby MG would initiate the re-
registration request to the same MGC on behalf of the
failed one.
2) Once the restart operation is finished, standby MG
generates the registration command to the same
controlling MGC on the newly specified service change
address.
10.4.4.2. New State
INACTIVE
10.4.5. Handoff from MGC
Input parameters:
- Service Change MGCIdToTry.
10.4.5.1. Steps
1) Convey this information to the standby entity (outside
the scope of the protocol) so that any further recovery
action (trying handed-off MGCs) would be taken via the
redundant MG.
2) Send the service change request to Handed-off MGC with
method as HANDOFF and reason as MGC Impending Failure.
Vikas, Vivek, Shiv, Prashant 32
INTERNET-DRAFT MEGACO Control Association
Procedures and State Machine August 2001
10.4.5.2. New State
INACTIVE
10.4.6. Forced Shutdown from MGC
Input parameters: None
10.4.6.1. Steps
1) Give the indication to the MG application to clear all
the call contexts. Further any recovery action would be
taken via the redundant MG.
2) Once the cleanup operation is finished at MG, the standby
MG generates the registration command to either primary
or secondary MGC with method as RESTART û Implementation
specific.
8.4.4.2. New State
INACTIVE
10.5. SWIP (SWITCHOVER_IN_PRGS)
10.5.1. Forced Shutdown At MG
Input parameters: None
10.5.1.1. Steps
1) The implementation may either send the service change
command to the MGC, which is being contacted at present,
immediately with method as FORCED or MG may defer this
message until the service change reply from the MGC is
received for the current pending service change request.
2) All the call contexts would be cleared at MG without
waiting for a SUBTRACT command from MGC.
Vikas, Vivek, Shiv, Prashant 33
INTERNET-DRAFT MEGACO Control Association
Procedures and State Machine August 2001
10.5.1.2. New State
INACTIVE
10.5.2. Graceful Shutdown At MG
Input parameters:
- Service Change Delay.
10.5.2.1. Steps
1) Buffer the Graceful Shutdown request until the MGC, which
is being contacted, accepts the registration request.
2) Once the registration is complete, send the service change
command with GRACEFUL method to the same MGC. If the delay
was specified in the input, then the delay in the command
should be the left-out time. New state in this case would
be AIS (ASSOCIATION_IN_SERVICE).
3) If Handoff/Failover takes more time than the Graceful
delay period, then the implementation will terminate the
control association abruptly and all the call contexts
would get cleared. New state in this case would be
INACTIVE.
10.5.3. Failover at active MG
Input parameters: None
10.5.3.1. Steps
1) Buffer the Failover request until the MGC, which is being
contacted, accepts the re-registration request.
2) Once the re-registration is complete, send the service
change command with FAILOVER method to the same MGC.
10.5.3.2. New State
Vikas, Vivek, Shiv, Prashant 34
INTERNET-DRAFT MEGACO Control Association
Procedures and State Machine August 2001
SIP (SHUTDOWN_IN_PRGS)
10.5.4. Transport Parameters Change at MG
Input parameters:
- Service Change Address.
10.5.4.1. Steps
1) Buffer the new transport parameters, until the MGC, which
is being contacted, accepts the re-registration request.
2) Once the re-registration is complete, send the service
change command with DISCONNECTED method to the same MGC
with the new transport parameters in the service change
address parameter.
10.5.4.2. New State
AIS (ASSOCIATION IN SERVICE)
11. MGC State Machine
The procedures given below show the behavior of the state machine
when given valid triggers:
Vikas, Vivek, Shiv, Prashant 35
INTERNET-DRAFT MEGACO Control Association
Procedures and State Machine August 2001
This table maps the service change method received from peer to the
control association states of MGC.
+------------+--------+--------+-----------+----------+--------+
|Method/ | |Restart |Association|Switchover|Shutdown|
| States |Inactive|In |In |In |In |
| | |Progress|Service |Progress |Progress|
+------------+--------+--------+-----------+----------+--------+
|RESTART | NA | A | A | A | A |
| | | | | | |
+------------+--------+--------+-----------+----------+--------+
|FORCED | NA | A | A | A | A |
| | | | | | |
+------------+--------+--------+-----------+----------+--------+
|GRACEFUL | | | | | |
| | NA | NA | A | A | A |
+------------+--------+--------+-----------+----------+--------+
|DISCONNECTED| NA | NA | A | A | A |
| | | | | | |
+------------+--------+--------+-----------+----------+--------+
|FAILOVER | NA | A | A | A | A |
| | | | | | |
+------------+--------+--------+-----------+----------+--------+
|HANDOFF | NA | A | A | A | A |
| | | | | | |
+------------+--------+--------+-----------+----------+--------+
A û Allowed
NA- Not Allowed
Vikas, Vivek, Shiv, Prashant 36
INTERNET-DRAFT MEGACO Control Association
Procedures and State Machine August 2001
+-------------------+
| |
| INACTIVE +----------->>-------------+
| | |
+-----+-------+--+--+ |
| | | |
| | +------------<<-----------+ |
Awaiting Restart | | |
from MG | +-------<<--------+ | |
| | | |
| | | |
| | | |
+-----V--------------+ | | |
| RESTART IN | | | |
| PROGRESS | | | |
| | | | |
+--+----+---------+--+ | | |
| | | | | |
| | Registration | | |
+->>-------------+ | Completion and | | |
MG Forced +>>-----------+ Restart Delay Timeout| | |
Shutdown / | +---------+ | | Handoff |
Graceful Timeout | | Graceful| | | Completion|
| Restart Trigger | Shutdown| V | | |
| from MG/MGC V | V | | |
| | +---V---------+---+--+ | | |
| | | ASSOCIATION IN + | | |
| +-----+ SERVICE | | | |
+-----<<------+ | MGC Forced | |
+-+---+--------+---+-+ Shutdown | V
| | | V | | V
+----<<-----V | | V------------+ | |
| | +----------+ | |
MG Failure | | Handoff at | | |
Detected/ | +-->>------+ active MGC | | |
MG Failover| | Re-registration | | |
V | from MG +----V------------+ | |
+----------V----+--+ | | | |
| SWITCHOVER IN | SHUTDOWN IN | | |
| PROGRESS | | PROGRESS | | |
| | | | | |
+---------^--------+ +--------------+--+ | |
| Redundant takeover V | |
| at Handed-off MGC V------+ |
| |
| |
+--------------------<<-----------------------------------+
Figure 2: MGC State Machine Transition Diagram
Vikas, Vivek, Shiv, Prashant 37
INTERNET-DRAFT MEGACO Control Association
Procedures and State Machine August 2001
11.1. RIP (RESTART_IN_PROGRESS)
11.1.1. Cold Start At MG
Input parameters:
- Service change delay.
- Service Change Address.
- Service Change Version.
- Service Change Profile.
11.1.1.1. Steps:
1) Examine the service change version of the received
message.
2) If the MGC is unable to comply with the suggested version
then send a Service Change Response to the MG with error
ô406 Version not supportedö. State remains same.
3) If the MGC supports the suggested or lower version, send
a Service Change Response to the MG the negotiated
Service Change Version. Start Delay Timer and the state
changes to RIP (RESTART_IN_PROGRESS). After Restart Delay
expiry, state would become ASSOCIATION_IN_SERVICE.
4) If the MGC wishes to handoff the MG to another MGC, send
a Service Change Response to the MG with Service Change
MGCIdToTry [transport address of the new MGC]. State
remains same
If the MGC wishes to change the Transport Address for
further correspondence to be used by the MG, send a
Service Change Response to the MG with Service Change
Address [containing the new transport address] along with
the other parameters. Change the state as per bullet 3.
11.1.2. Forced Shutdown At MG
Input parameters: None
11.1.2.1. Steps
1) Here there should not be any call running at MG.
2) After this, MGC shall wait for the next registration
request from the MG going down.
Vikas, Vivek, Shiv, Prashant 38
INTERNET-DRAFT MEGACO Control Association
Procedures and State Machine August 2001
11.1.2.2. New State
RIP (RESTART IN PROGRESS)
11.1.3. Graceful Shutdown At MG
Input parameters:
- Service change delay.
11.1.3.1. Steps
1) Start the delay timer for value specified in Service change
delay.
2) Till the expiry of the service change delay, the state of
MGC control association remains RESTART IN PROGRESS.
3) If MG specifies null delay or the graceful period is
shorter than the restart period earlier specified in the
restart delay, the control association would get terminated
immediately.
11.1.3.2. New State
State remains same.
11.1.4. Failover at active MG
Input parameters: None.
If the registered MG, wants to transfer the control of the
specified association to the redundant MG.
11.1.4.1. Steps
1) Simply stop restart delay timer and start waiting for a
new service change command from the standby MG with method
as DISCONNECTED and reason as SERVICE RESTORED.
11.1.4.2. New State
State remains same.
11.1.5. Redundant Takeover at standby MG
11.1.5.1. Steps
1) MGC may just do an audit if required.
Vikas, Vivek, Shiv, Prashant 39
INTERNET-DRAFT MEGACO Control Association
Procedures and State Machine August 2001
11.1.5.2. New State
ASSOCIATION_IN_SERVICE
11.1.6. Peer Failure Detection at MGC
Input parameters: None
In this state, MGC may detect the failure of its MG while doing
periodic audits during the restart phase.
11.1.6.1. Steps
1) Stop restart delay timer if running.
2) After this, MGC shall wait for the next registration
request from the MG, whose failure was detected.
11.1.6.2. New State
RIP (RESTART IN PROGRESS)
11.1.7. Handoff at Active MGC
Input parameters:
- Service Change MGCIdToTry.
11.1.7.1. Steps
1) Stop restart delay timer if running.
2) Send Service Change Request to the MG with Method as
Handoff and MGCIdToTry set to the new MGC.
11.1.7.2. New State
RIP (RESTART IN PROGRESS)
11.1.8. Forced Shutdown at MGC
Input parameters: None
Vikas, Vivek, Shiv, Prashant 40
INTERNET-DRAFT MEGACO Control Association
Procedures and State Machine August 2001
11.1.8.1. Steps
1) Stop restart delay timer if running.
2) Send Service Change Request to the MG Method as FORCED.
11.1.8.2. New State
INACTIVE
11.2. AIS (ASSOCIATION IN SERVICE)
11.2.1. Forced Shutdown at MG
Input parameters: None
11.2.1.1. Steps
1) All the call contexts would be cleared at MGC without
sending SUBTRACT commands to MG.
2) After this, MGC shall wait for the next registration
request from the MG going down.
11.2.1.2. New State
RIP (RESTART_IN_PROGRESS)
11.2.2. Graceful Shutdown at MG
Input parameters:
- Service change delay.
11.2.2.1. Steps
1) Start the delay timer for value specified in Service change
delay.
2) Till the expiry of the service change delay, the state of
MG control association becomes ASSOCIATION IN SERVICE
(AIS).
3) Delete all the call contexts abruptly after the completion
of the graceful period.
Vikas, Vivek, Shiv, Prashant 41
INTERNET-DRAFT MEGACO Control Association
Procedures and State Machine August 2001
4) If the NULL delay was specified, the control association
must last for the duration of the time until all the active
call contexts are cleared from MGC.
11.2.2.2. New State
State remains same.
11.2.3. Failover at active MG
Input parameters: None
11.2.3.1. Steps
1) The existing calls are not affected assuming that the
standby MG would come up and take over the control of the
specified association.
2) Start waiting for a new service change command from the
standby MG with method as DISCONNECTED and reason as COLD
Boot or Warm Boot.
11.2.3.2. New State
SWIP (SWITCHOVER_IN_PROGRESS)
11.2.4. Transport Parameters Change at MG
Input parameters:
- Service Change Address.
11.2.4.1. Steps
1) The existing calls are not affected. MGC may do an audit.
2) Starts sending the new protocol command request on the
new address, as specified in the service change address
parameter.
11.2.4.2. New State
State remains same.
11.2.5. Transport Parameters Change at MGC
Input parameters:
- New Transport Address.
Vikas, Vivek, Shiv, Prashant 42
INTERNET-DRAFT MEGACO Control Association
Procedures and State Machine August 2001
11.2.5.1. Steps
1) The existing calls are not affected.
2) Send Service Change Request to the MG Method as Handoff
and MGCIdToTry set to the new transport parameters.
11.2.5.2. New State
SWIP (SWITCHOVER IN PROGRESS)
11.2.6. Peer Failure Detection at MG
Input parameters: None
11.2.6.1. Steps
1) The existing calls are not affected assuming that the
standby MG may come up and take over the control of the
specified association.
2) Start waiting for a new service change command from the
standby MG with method as DISCONNECTED and reason as COLD
Boot or Warm Boot.
11.2.6.2. New State
SWIP (SWITCHOVER_IN_PROGRESS)
11.2.7. Handoff at Active MGC
Input parameters:
- Service Change MGCIdToTry.
11.2.7.1. Steps
1) Send Service Change Request to the MG Method as Handoff
and MGCIdToTry set to the new MGC.
11.2.7.2. New State
SIP (SHUTDOWN_IN_PROGRESS)
Vikas, Vivek, Shiv, Prashant 43
INTERNET-DRAFT MEGACO Control Association
Procedures and State Machine August 2001
11.2.8. Restart From MGC
Input parameters:
- Service Change Address.
- Service Change Reason.
11.2.8.1. Steps
1) Depending on the service change reason field (Cold Boot or
Warm Boot or Service Restored), call contexts would be
cleared at MGC as well as at MG.
2) Send Service Change Request to the MG with method as
RESTART and the other relevant parameters.
11.2.8.2. New State
RIP (RESTART_IN_PROGRESS)
11.2.9. Forced shutdown At MGC
Input parameters: None
11.2.9.1. Steps
1) All the call contexts would be cleared at MGC without
sending SUBTRACT commands to MG.
2) Send Service Change Request to the MG with method as
FORCED.
11.2.9.2. New State
INACTIVE_
11.3. SWIP (SWITCHOVER_IN_PROGRESS)
In this state:
- Either the active MGC is waiting for a service change command
from the standby MG in case of MG Failover that was received
earlier.
Vikas, Vivek, Shiv, Prashant 44
INTERNET-DRAFT MEGACO Control Association
Procedures and State Machine August 2001
- Or the handed-off MGC is waiting for a service change command
from the active or the standby MG in case control association
was re-directed by the active MGC.
11.3.1. Forced Shutdown at MG
Input parameters: None
11.3.1.1. Steps
1) All the call contexts would be cleared at MGC without
sending SUBTRACT commands to MG.
2) After this, MGC shall wait for the next registration
request from the MG going down.
11.3.1.2. New State
RIP (RESTART_IN_PROGRESS)
11.3.2. Graceful shutdown request from MG
11.3.2.1. Steps
1) Start the delay timer for value specified in Service change
delay.
2) Till the expiry of the service change delay, the state of
MG control association becomes ASSOCIATION IN SERVICE
(AIS).
3) Delete all the call contexts abruptly after the completion
of the graceful period.
4) If the NULL delay was specified, the control association
must last for the duration of the time until all the active
call contexts are cleared from MGC.
11.3.2.2. New State
ASSOCIATION_IN_SERVICE
Vikas, Vivek, Shiv, Prashant 45
INTERNET-DRAFT MEGACO Control Association
Procedures and State Machine August 2001
11.3.3. Failover at active MG
11.3.3.1. Steps
1) Do nothing.
11.3.3.2. New State
State remains same.
11.3.4. Redundant Takeover at standby MG
11.3.4.1. Steps
2) Depending on the service change reason field (Cold Boot
or Warm Boot or Service Restored), call contexts would
be cleared at MGC.
3) MGC may do an audit.
11.3.4.2. New State
ASSOCIATION_IN_SERVICE
11.3.5. Forced Shutdown at MGC
11.3.5.1. Steps
1) All the call contexts would be cleared at MGC without
sending SUBTRACT commands to MG.
2) Buffer the Forced shutdown request until the MG sends a
service change request to re-establish the control
association.
3) Once the association is re-established, send the service
change command with FORCED method to the same MG so that
MG could clear the call contexts at its end.
11.3.5.2. New State
INACTIVE
11.3.6. Restart From MGC
Vikas, Vivek, Shiv, Prashant 46
INTERNET-DRAFT MEGACO Control Association
Procedures and State Machine August 2001
11.3.6.1. Steps
1) All the call contexts would be cleared at MGC without
sending SUBTRACT commands to MG.
2) Buffer the Forced shutdown request until the MG sends a
service change request to re-establish the control
association.
3) Once the association is re-established, send the service
change command with FORCED method to the same MG so that
MG could clear the call contexts at its end.
11.3.6.2. New State
RIP (RESTART_IN_PROGRESS)
11.3.7. Handoff at Active MGC
11.3.7.1. Steps
1) Buffer the MGCIdToTry parameter until the MG sends a
service change request to re-establish the control
association.
2) Once the association is re-established, send the reply to
the MG with the MGCIdToTry field set to the Handed off
MGC except the case that the MG is forcefully going down.
11.3.7.2. New State
SIP (SHUTDOWN_IN_PROGRESS).
11.3.8. Re-registration request from active or standby MG
Input parameters:
- Service Change Version.
11.3.8.1. Steps:
1) Examine the service change version of the received
message, if present.
Vikas, Vivek, Shiv, Prashant 47
INTERNET-DRAFT MEGACO Control Association
Procedures and State Machine August 2001
2) If the MGC is unable to comply with the suggested version
then send a Service Change Response to the MG with error
ô406 Version not supportedö. State remains same.
3) If the MGC supports the suggested or lower version, send
a Service Change Response to the MG the negotiated
Service Change Version. The state would become
ASSOCIATION_IN_SERVICE.
4) Depending on the service change reason field (Cold Boot
or Warm Boot or Service Restored), call contexts would be
cleared at MGC. MGC should do an audit here as per the
protocol.
11.4. SIP (SHUTDOWN_IN_PROGRESS)
11.4.1. Forced Shutdown at MG
11.4.1.1. Steps
1) All the call contexts would be cleared at MGC without
sending SUBTRACT commands to MG.
11.4.1.2. New State
INACTIVE
11.4.2. Graceful Shutdown at MG
11.4.2.1. Steps
1) The MGC going down may convey this information to the
Handed-off MGC, outside the scope of the protocol.
2) Send the reply to the MG with the MGCIdToTry field set to
the Handed-off MGC.
11.4.2.2. New State
State remains same.
Vikas, Vivek, Shiv, Prashant 48
INTERNET-DRAFT MEGACO Control Association
Procedures and State Machine August 2001
11.4.3. Failover at active MG
11.4.3.1. Steps
1) Send the reply to the MG with the MGCIdToTry field set to
the Handed off MGC.
11.4.3.2. New State
State remains same.
11.4.4. Redundant Takeover at standby MG
11.4.4.1. Steps
1) Send the reply to the MG with the MGCIdToTry field set to
the Handed off MGC.
11.4.4.2. New State
State remains same.
11.4.5. Forced Shutdown At MGC
11.4.5.1. Steps
1) Send Service Change Request to the MG with method as
FORCED.
11.4.5.2. New State
INACTIVE
Vikas, Vivek, Shiv, Prashant 49
INTERNET-DRAFT MEGACO Control Association
Procedures and State Machine August 2001
AuthorÆs Addresses
Vikas Bajaj
Hughes Software Systems, Ltd.
Gurgaon,Haryana,India. 122015.
Phone: (91)-11-346666.Ex-3270
Email: vbajaj@hss.hns.com
Vivek Bansal
Hughes Software Systems, Ltd.
Gurgaon, Haryana, India. 122015.
Phone: (91)-11-346666.Ex-3616
Email: vibansal@hss.hns.com
Shiv Kumar
Hughes Software Systems, Ltd.
Gurgaon,Haryana,India. 122015.
Phone: (91)-11-346666.Ex-3281
Email: svkumar@hss.hns.com
Prashant Jain
Hughes Software Systems, Ltd.
Gurgaon,Haryana,India. 122015.
Phone: (91)-11-346666.Ex-3616
Email: prjain@hss.hns.com
Vikas, Vivek, Shiv, Prashant 50
