Subject: Re: MGC failure

From: [email-masked]
Date: Thu, 26 Aug 1999 17:12:26 +0200

All,

A point I have not seen menshioned yet is that if you have a connection-oriented transport layer, loss of connectivity should be detected as soon as you try to send a message. At least, that is my experience with TCP. I don't know about ALF or other
transports.

Marc.

Ashok Khuntia <[email-masked]> on 08/26/99 04:28:39 PM

Please respond to Ashok Khuntia <[email-masked]>

 To:      [email-masked]

 cc:      (bcc: Marc DE VRIES/BE/ALCATEL)

 Subject: Re: MGC failure

Tom,

Good point.

But how does one make the MG-MGC interoperable with a proprietary solution? If a customer is buying MGC from one vendor and MG from another vendor, they should work. With a  proprietary solution the customer will be bound to a single vendor for MG and MGC.

And if it is a large MG handling lots of calls then polling may not be a problembecause the MG will have lot of CPU power and percentage wise polling may not require much CPU time compared to the total load. It will be a problem when the MGC is handling
lots of MGs and when all MGs are polling the same MGC. In this case the MGC may be the bottleneck.

Any comments will be appreciated.

Ashok

> From [email-masked] Wed Aug 25 10:03:59 1999
> MIME-version: 1.0
> Date:         Wed, 25 Aug 1999 10:59:31 -0400
> From: Tom-PT Taylor <[email-masked]>
> Subject:      Re: MGC failure
> X-To:         Natarajan Kalpathy <[email-masked]>
> To: [email-masked]
>
> The mechanisms are there, but what would your polling interval be?  Bear in
> mind that a large MG could be handling messages pertaining to tens of calls
> a second. If you wanted to poll frequently enough to eliminate the
> possibility of losing them, you would kill the network.
>
> MGC reliability is going to have to be achieved by other means, probably
> proprietary.
>
> > -----Original Message-----
> > From: Natarajan Kalpathy [SMTP:[email-masked]]
> > Sent: Tuesday, August 24, 1999 7:21 PM
> > To:   [email-masked]
> > Subject:      Re: MGC failure
> >
> > 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 -----
> > >
>