Subject: RE: [MEGACO] Re-registration of MG with MGC

From: "Stephen Mell" <[email-masked]>
Date: Wed, 19 Jul 2006 19:48:21 +0100

In the case of a re-booted primary (and only) MGC:

I think that a ServiceChange with method Disconnected could not in itself 
establish a new Control association as:

a) The version number that the MG uses in the header (from the broken 
Control Association) might not be correct (i.e. not 1)
b)  More importantly, it is not a "Registration" type Service Change, that 
establishes a Control association.

If the MGC does not have a control association with an MG (after reboot) 
and receives such a Service change (Disconnected) from the MG, would the 
proper course of action for the MGC be:

1) Discard the ServiceChange on the grounds that there is no record of a 
Control Association and the Service Change (disconnected) command received 
does not constitute a registration attempt ?
2) Return to the MG either Error 406 (if Version is incorrect) or Error 
401 / 402 / 430 (if Version correct) in response to the Service Change?

If the MGC follows procedure (2) then the MG would know in a timely manner 
that it should stop issuing a  ServiceChanges with Disconnected and 
instead attempt re-registration (ServiceChange Restart with Reason 
902-Warm or 900-ServiceRestored ?).

Additionally the MG may want to autonomously give up on the existing 
Control Association after a prolonged period of disconnection, and start 
trying to Re-register. Although if the rebooted MGC follows procedure (1) 
and has been silently discarding the ServiceChange (Disconnected) 
Commands, this might not happen until some time after the MGC has finished 
rebooting and has spent a long time waiting to accept the MG's 
registration, . 

If the MGC follows procedure (1) above then the MG would have to give up 
on the Control Association eventually and attempt re-registration, 
otherwise the MG will never re-register. In the case where the 
disconnection is actually due to a network outage rather than a rebooted 
MGC, the MGC may have missed the ServiceChange(Disconnected) commands 
altogether (network loss) and only see the ServiceChange(Retart,902). This 
is significant as there is no longer an inference with the later type of 
ServiceChange that messages have been lost and that the MG and MGC are out 
of state. An MGC that has not rebooted and just sees a SC-ROOT-Restart-902 
has no reason to believe that the MG is not just simply seeking to 
re-register, and it might not go on to recover state from the MG at that 
point. An MGC that has rebooted, on the other hand, holds no state 
information for the MG, and would realise from the 902 reason that it is 
Out-Of-State and should sync. itself with the MG's state when that MG 
registers with the warmRestart Reason.

So my guess is that the sure way to avoid these potential problems, 
ensuring that the MGC (whether rebooted or not) always recovers state from 
the MG, and that re-registration with a re-booted MGC is reasonably 
timely, is for the recently rebooted MGC to reply in error to the 
ServiceChange(Disconnected) and only then for the MG to attempt 
registration with reason WarmStart.

The other suggestion from Flextronics was that the rebooted MGC receives 
Service Change (disconnected) command, "sniffs" the version number from 
the header and forces the AGW to re-register usinga MGC control 
association Parameters that haven't really been negotiated but "taken as 
read". A pragmatic solution that may well find its way into 
implementations, but difficult to resolve with the standard

Regards,

Steve 

"Kevin Boyle" <[email-masked]>
17/07/2006 18:04

        To:     "Stephen Mell" <[email-masked]>, "pankaj.kumar" 
<[email-masked];Albrecht.Schwarz;;;;>
        cc:     <[email-masked]>
        Subject:        RE: [MEGACO] Re-registration of MG with MGC

The rebooted MGC would not have a control association, and therefore would 
require the MG to send a ServiceChange command to establish one.  This 
shouldn't be hard to detect for the MG, as the MGC would stop replying to 
commands from the MG until a new registration message (either a Restart or 
a Disconnected) arrived.
 
Kevin

From: Stephen Mell [mailto:[email-masked]] 
Sent: Friday, July 14, 2006 12:58 PM
To: pankaj.kumar
Cc: [email-masked]
Subject: Re: [MEGACO] Re-registration of MG with MGC

Hello List, 

The procedures detialed in F.3.8 and F.3.9 both need to be carried out 
under the auspices of an existing Control association. 

How then can the rebooted MGC (which is ignorant of the Parameters of the 
existing Control Association, in partcular the negotiated protocol 
version), issue a Service change with the correct Version number in the 
message header? 

The same problem exists for transparent (layer 3) MGC failover. 

This issue has been discussed before, but I don't remember it reaching a 
satisfactory conclusion. 

Steve 

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