Subject: RE: MGC failure

From: Dan Elbert <[email-masked]>
Date: Fri, 4 May 2001 12:08:20 -0500

What would be an MG ServiceChange that doesn't change the state ?
Using an "extension" ServiceChangeMethod ?
Maybe this has to be defined in the protocol as there is a risk of causing
interoperability problems if the MGC doesn't interpret the MG SVC rigth.

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Thursday, May 03, 2001 9:26 AM
To: 'Groom, William'; 'Dan Elbert'; [email-masked]'
Subject: RE: MGC failure

Heartbeats have been discussed for some time.

Any message sent from one end to the other gets a reply, so
any message can be a heartbeat message.  It doesn't
require any special package or protocol feature.

Suppose the MGC wants to know if MGs are alive
	Periodically send a message to it that doesn't do anything (NOP)
Same idea for the MG - periodically send the MGC a message.
Smart implementations would have a timer that is reset by any
transaction request or reply from the other side.

For the MGC, there are a plethora of nops.  Empty Audit is
an obvious one.

For the MG, there are fewer choices, but you CAN send a service
change that doesn't change any state.

Brian

> -----Original Message-----
> From: Groom, William [mailto:[email-masked]]
> Sent: Thursday, May 03, 2001 8:47 AM
> To: 'Dan Elbert'; [email-masked]'
> Subject: RE: MGC failure
> 
> 
> Dan,
> 
> With regards to the first part of your question. I hope the 
> following helps.
> 
> Clarification Of Problem:
> 
> When the MGC restarts (including O/S) all associations to the 
> MG are lost.
> No messages can be sent from the MGC to the MG until the MG 
> has sent a SC
> (restart message on root).
> 
> If the connection is TCP, then the MG will get to know about 
> the MGC restart
> (eventually) and can go through its normal restart processing to
> re-establisg MGC connections. 
> 
> If UDP, then the MG is oblivious to the MGC restart.  The 
> action taken by
> the MG will depend upon the state of the MG at the time of 
> the MGC restart.
> I.E.
> 
> 1. MG is active carrying traffic. In this state the MG will 
> timeout the MGC,
> break existing MGC associations and reconnect. This is fine.
> 
> 2. MG is already trying to connect. This is also fine.
> 
> 3. MG is Down (offline). This is fine since it will establish 
> connection
> upon restart.
> 
> 4. MG is Idle (No calls in progress). A trunking MG will 
> remain in this
> state forever, until some manual intervention takes place. 
> This is the main
> concern we are trying to address. Other gateway's (E.G. 
> Residential) will
> detect signals that will eventually lead to a timeout of the MGC and
> connection re-establishment taking place.
> 
> Two Possible Proposals (there maybe others)
> 
> 1. Heartbeat Message
> 
> I believe a package has been proposed where the MG heartbeats the MGC
> (signal on root). I have not seen any proposal nor do I know 
> of the status
> of such a proposal. Perhaps someone (Brian) could comment on this.
> 
> 2. Using Service Change Message
> 
> I have not seen this proposal, but cannot see why it would not work.
> 
> Upon startup of the MGC, a UDP SC message could be sent to 
> each MG with the
> ServiceChangeMgcId set to the MGC IP address. To the MG, this 
> message will
> look like a handover of the MGC to itself. 
> 
> Note this message is not a connection request, just a message 
> to inform the
> MG to re-establish new MGC connections.
> 
> 
> 
> The first option is preferred (but none standard) as it caters for the
> problem where the MGC goes down and stays down.
> 
> 
> Regards
> Bill Groom
> Siemens
> 
> -----Original Message-----
> From: Dan Elbert [mailto:[email-masked]]
> Sent: Thursday, April 26, 2001 5:06 PM
> To: [email-masked]'
> Subject: MGC failure
> 
> 
> Assume that the MGC goes down and up again.
> Is there any way for the MGC to indicate the MGs that they 
> need to send a
> SVC, or is only the MGs responsibility to have some sort or 
> "keep alive"
> (e.g. by sending a noop SVC if nothing is coming from the MGC 
> in a long
> time). ?
> Note that the MGC doesn't know what port the MG is using.
> Related to this, what is the standard response if the MGC 
> receives a Notify
> from an MG that is not registered ? ( Because it was 
> registered and then MGC
> went down and up again) . Should it send a reply with an 
> error so the MG
> knows that it must send a SVC, or just ignore it ?
> 
> Thanks,
> Dan Elbert
> RADVISION
>