Subject: Re: MGC failure

From: Ashok Khuntia <[email-masked]>
Date: Thu, 26 Aug 1999 15:24:59 -0500

Mike,

How will you provision the MG to expect regular communication from the MGC? What kind of messages(communication) are you talking about? Are you talking about megacop messages or some other propritary messages? Would you please elaborate?

Thanks,
Ashok

> From [email-masked] Thu Aug 26 15:00:22 1999
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
>         @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
>         bUcI'1!
> Date:         Thu, 26 Aug 1999 12:56:57 -0700
> From: Michael Thomas <[email-masked]>
> Subject:      Re: MGC failure
> X-To:         Matt Holdrege <[email-masked]>
> To: [email-masked]
>
> Matt Holdrege writes:
>  > I sympathize with the concern. Especially in the residential case. But
>  > since MEGACO applies to many different scenarios, we cannot specify what
>  > you want. It really has to be a site specific configuration. Some sites
>  > will do frequent polling, some will mandate infrequent. Some will choose
>  > schemes other than polling.
>
>    As I wrote earler, that is not the case. An MG
> can be provisioned to expect communication from
> the MGC on a regular basis and deduce from a lack
> of activity on the MGC's part that it has failed.
> If we take that pragma, then we can say that the
> MG MUST NOT poll the MGC in all cases.
>
>                 Mike
>
>  >
>  >
>  > At 09:55 AM 8/26/99 -0500, Ashok Khuntia wrote:
>  > >If an MGC is handling lot MGs and all MGs do polling at a frequent
>  > >interval then it will create a lot of load on the MGC. So I think we
>  > >should not leave it to the MG to decide however it wants. A STANDARD would
>  > >be nice.
>  > >
>  > >Ashok
>  > >
>  > > > From [email-masked] Wed Aug 25 10:57:01 1999
>  > > > X-Sender: [email-masked]
>  > > > Mime-Version: 1.0
>  > > > Date:         Wed, 25 Aug 1999 06:12:38 -0700
>  > > > From: Matt Holdrege <[email-masked]>
>  > > > Subject:      Re: MGC failure
>  > > > X-To:         Natarajan Kalpathy <[email-masked]>
>  > > > To: [email-masked]
>  > > >
>  > > > 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.
>  > > >
>  > > >
>  > > > At 06:21 PM 8/24/99 -0500, Natarajan Kalpathy wrote:
>  > > > >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: Michael Thomas <[email-masked]>
Date: Thu, 26 Aug 1999 13:46:46 -0700

Ashok Khuntia writes:
 > Mike,
 >
 > How will you provision the MG to expect regular communication from
the MGC? What kind of messages(communication) are you talking about?
Are you talking about megacop messages or some other propritary
messages? Would you please elaborate?

   Out of band provisioning via either a MIB
or proprietary means.

                Mike