Subject: RE: MGC failure

From: "Groom, William" <[email-masked]>
Date: Thu, 3 May 2001 10:02:47 -0400

Ian,

I was referring to the normal guard timer when the MG sends a Notify or
Service Change request to the MGC. The transaction will be repeated a number
of times before the MG gives up.

I think Brian's response is fine. MGC could use an audit request, while MG
will use a Nop request (E.G. trunk gateway could send a SC on a DS0 with
service restored). I assume the specific heartbeat message will differ based
up the MG vendor and MG type. Provided it is allowed by the MGC then all
should be well.

To avoid un-necessary traffic flows, it is preferred that the MG should only
send the heartbeat if no communication has been received from the MGC for a
period of time.

Regards

Bill Groom

-----Original Message-----
From: Ian Leighton [mailto:[email-masked]]
Sent: Thursday, May 03, 2001 9:30 AM
To: Groom, William
Cc: 'Dan Elbert'; [email-masked]'
Subject: Re: MGC failure

Hi William

Can you explain what timeout you are referring to in problem 1.

Although my understanding of the spec is limited, I believe that
events are not a mandatory part of the spec. If this is true then
problem 1 is not  solved by the MG sending SC.

Regards
Ian

"Groom, William" wrote:

> 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