Subject: [Megaco] question on ServiceChange

From: Leis Peter <[email-masked]>
Date: Wed, 23 Jan 2002 15:54:48 +0100

hi,

back in november there was a discussion about MG accepting a ServiceChange from a MGC
currently not controlling it. I want to stress this issue once again. In addition I will provide
a delayed contribution to the SG-16 meeting in Geneva to start a discussion there. 
Here some thoughts:

Indroduction:

This contribution proposes that a MG controlled by MGC1 (primary) and MGC2 (secondary) is allowed to accept a ServiceChange with method = Handoff  from MGC2 (assuming MGC2 detects that MGC1 has failed).

Disussion:

H.248/RFC3051 describes the behavior of the MG/MGC in case of MGC Failure as follows:
'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 ServiceChange message with a "Failover" method and a " MGC Impending Failure" reason.  

In partial failure, or manual maintenance reasons, an MGC may wish to direct its controlled MGs to use a different MGC.  To do so, it sends a ServiceChange method to the MG with a "HandOff" method, and its designated replacement in ServiceChangeMgcId. The MG should send a ServiceChange message with a "Handoff" method and a "MGC directed change" reason to the designated MGC.  If it fails to get a reply, or fails to see an Audit command subsequently, it should behave as if its MGC failed, and start contacting secondary MGCs.  If the MG is unable to establish a control relationship with any MGC, it shall wait a random amount of time as described in section 9.2 and then start contacting its primary, and if necessary, its secondary MGCs again.'

In a UDP environment this leads to the following situation:
If the primary MGC1 fails without being able to send a ServiceChange method with a "HandOff"method then it will take LONG-TIMER (the recommendation suggests 30 sec) till MG will detect the death of MGC1 and sending the ServiceChange to the secondary MGC. This means that the MTBF is quite long. 

Improvement:
This behavior could be improved if the secondary MGC would be allowed to take over the control once it has detected the death of the primary MGC. It is assumed that this happens sooner than the detection by the MG. For this mechanism the MG would have to accept a ServiceChange method with a "HandOff" sent by the secondary MGC and establish the control association to this MGC. 

Use cases:
In an environment where the MGC's are 'controlled' in a centralized manner the control association MGC-MG could be maintained more efficient by the MGC's. This way the switchover from MGC1 to MGC2 can be achieved fast and a short MTBF will be possible.

Implications:
Once the MG has accepted the ServiceChange method with 'HandOff" from the secondary MGC it has to discard all call related requests from its previously controlling MGC.
Once the MG has accepted the ServiceChange method with 'HandOff' all currently outstanding Transactions to MGC1 have to be deleted.
Handling of state information between MGC1 and MGC2 is out of scope of the recommendation

Proposal:

Make the following additions in H.248v2 in section 11.5:

If a secondary MGC detects the death failure of the primary MGC (detection mechanism out of scope of this recommendation) and the transport of the protocol is done via UDP it may send a ServiceChange method to the MG with a "HandOff" method, and its own MgcId in ServiceChangeMgcId. The MG may accept the ServiceChange method Request from this MGC currently not controlling it if this MGC is contained in the MG's preconfigured MGC list and establish the control relation. To do so the MG should first send a ServiceChangeReply. Afterwards the MG should send a ServiceChange message with a "Handoff" method and a "MGC directed change" reason to the specified MGC (to be inline with the current mechanism). After the control relation is established the MGC should initiate an AuditValue command in order to retrieve the current call data from the MG.

Any comments/ideas on this???

regards,
Peter

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco