Subject: Re: MGC failure

From: Natarajan Kalpathy <[email-masked]>
Date: Tue, 24 Aug 1999 18:21:24 -0500

Brian ,
 What  will  happen  if  there  is  a  burst  of  calls  (Only  applicable  to
a  large  MG) .  By  the  time  we  detect  a  MGC  failure (Timeout  for  a
single NOTIFY) we  may  drop  some  calls  or  user   may  hang up . Wont
periodic  polling reduce  the  chances  of  this  happening ??

Natarajan

Brian Rosen <[email-masked]> on 08/24/99 03:06:24 PM

Please respond to Brian Rosen <[email-masked]>

Sent by:  Brian Rosen <[email-masked]>

To:   [email-masked]
cc:    (Natarajan Kalpathy/MW/US/3Com)
Subject:  Re: MGC Failure

A single failure of an MGC to respond to a notify should be sufficient
grounds to contact back-up MGCs in many cases == certainly if the Notify
is something like off-hook it is.

There will (probably) be a package that implements a heartbeat event,
which would give you notice of failure (or at least failure of
communications, which is the same thing in this case).  Since both MG and
MGC have to be up and communicating for the event and it's acknowledgement
to complete, both would know about failure.

Brian

> -----Original Message-----
> From: Ashok Khuntia [mailto:[email-masked]]
> Sent: Tuesday, August 24, 1999 2:06 PM
> To: [email-masked]
> Subject: Re: MGC Failure
>
>
> What if the application is such that the MG does not send any
> Notify (or sends very infrequently) to the MGC. All the
> commands are issued by the MGC and the MG just responds. How
> does the MG detect MGC failure in such cases?
>
> Any comments will be appreciated.
>
> Ashok
>
> ----- Begin Included Message -----
>
> From [email-masked] Tue Aug 24
> 12:23:55 1999
> MIME-Version: 1.0
> Date:         Tue, 24 Aug 1999 13:33:12 -0400
> From: Brian Rosen <[email-masked]>
> Subject:      Re: MGC Failure
> To: [email-masked]
>
> > > Does the protocol say anything about this?
> >         [[TomT]]
> >         Notify is ACKed -- this was an oversight which will
> > be corrected in
> > the next issue of the protocol document.  The protocol has
> no explicit
> > provision for detection of MGC failure.  The most likely
> > scenario is that a
> > backup MGC will actually take over by issuing a ServiceChange
> > to the MG.
> There is no takeover, there is handoff, but not takeover.
> MGC failure is detected by lack of ack.
>
> >         I expect lots of comment on this one because it is an
> > area which may
> > need more work..
> Let's not go there.  We need more experience before we invent more
> mechanism in this area, I think.
>
>
> > > 2. The H.GCPMEGACO/H.248 document says the following:
> > >
> > >
> > > Page 62
> > > -------
> > >
> > > If a new Media Gateway Controller is detected, the Media
> > Gateway starts
> > > transmitting outstanding commands to that new agent.
> > Responses to commands
> > > are still transmitted to the source address of the command.
> This is leftover MGCP stuff, and will be deleted.
>
> > >
> > > Page 70
> > > -------
> > >
> > > When the MGC initiates a Handoff, the handover should be
> > transparent to
> > > Operations on the Media Gateway. Commands in progress continue,
> > > transaction replies are sent to the new MGC, ...
> This is the behavior we want.
>
>
> ----- End Included Message -----
>

---

From: Matt Holdrege <[email-masked]>
Date: Wed, 25 Aug 1999 06:12:38 -0700

What is stopping any MG from employing it's own scheme, any scheme, of
determining MGC availability? If you wish to do polling, go ahead! Anytime
you want the MG can initiate a session with the backup MGC.