Subject: RE: [Megaco] MGC-MG dialogue failure detection

From: Aleksandr Ryabin <[email-masked]>
Date: Mon, 08 Jul 2002 12:59:00 -0400

Hi,

         One problem that inactivity package does not solve is a service 
interruption.
That is if a primary MGC fails (crashes) such that it can not send SC 
handoff to
MG and secondary MGC takes over right away then currently there is no way for
secondary MGC to let MG know that it is an active MGC now, since SC has to be
initiated from MG before any message is sent from new MGC. Thus using 
inactivity
package even if inactivity timer set to a minimum (10 msec) there will be 
still a service
interruption delay of at least Notify time-out period which counted in 
seconds and
which is a huge delay for real time systems. That is during this time 
(seconds) an
MGC acting as soft switch will not be able to establish new calls as well 
as modify
calls currently in progress.

One way to work around is to allow any provisioned MGC (e.g. primary, 
secondary,
etc.) to send SC handoff with its own MgcIdToTry at any point of time to 
take over.

Another way could be to extend inactivity timer package and add Notify 
time-out ("nto")
parameter to "ito" event with the same attributes as "mit" parameter which 
will allow MGC
to set time-out for Notify response which is send on "mit" expiration. This 
way MGC at
least will have control of maximum service outage a secondary MGC should 
expect on
a primary MGC permanent failure. More over it could be specified if "nto" 
parameter is
set to 0 then it would direct MG to start failover process as described in 
par 11.5 right
away on "mit" expiration without sending Notify to primary MGC.

Any comments, or other ideas regarding this problem?

Thanks
         Aleks

At 03:17 AM 7/7/2002, Dan  Elbert wrote:
>Hi Rajeev
>This are exactly the problems that the package is trying to solve.
>If MGC detects that MG is not responding, just don't send any message to it
>until it registers again.
>Then when inactivity timer expires, MG send event, doesn't get a response,
>and finally registers again.
>Then same will happen to every MG when the MGC goes down and up again.
>
>Dan Elbert
>RADVISION
>
>-----Original Message-----
>From: Rajeev K R [mailto:[email-masked]]
>Sent: Saturday, July 06, 2002 4:18 AM
>To: [email-masked]; [email-masked]
>Subject: Re: [Megaco] MGC-MG dialogue failure detection
>
>
>Hi Jean-Luc,
>
>ITU-T SG16 has published a document named
>H.248 Annex M.6: Inactivity Timer Package
>which can be used by MG to detect the MGC failure.
>MG can send Notify with event=it/ito and chcek whether MGC gives a response.
>When there is no response for some number of attempts, MG can initiate
>registration procedure.
>
> From the MGC side the package suggest the use of Audit for ROOT with empty
>descriptor.
>
>But there is another problem, the standard still does not address. This is
>more from a practicality
>point of view. This is from the MGC side. Suppose the MGC detect that the MG
>is not responding and
>mark that this MG is unregistered.
>Now how can the MGC inform the MG that its registration is removed ?
>If the MG is actually down there is no problem because when the MG comes up
>again, it will register.
>If the MG is not down, it will never register again.
>When it tries to initiate a call, it will get a response that the MG is not
>registered.
>Some MGs register again when they get this response, but some MGs do not.
>
>Another scenario is where all the MGs are registered, but the MGC go down
>and come up.
>How can the MGC force the MGs to register again ?
>Is the MGC allowed to use the previous state of registation(state before it
>went down) for its MGs ?
>
>Regards,
>Rajeev
>
>
>
>
>
>----- Original Message -----
>From: <[email-masked]>
>To: <[email-masked]>
>Sent: Friday, July 05, 2002 3:57 PM
>Subject: [Megaco] MGC-MG dialogue failure detection
>
>
> >
> > I would like to point out an issue which is as far as I know is not solved
> > in RFC3015.
> >
> > I suppose that the  MG is registered to the MGC and that there is no
> > transaction on going.
> > If the MGC fails, there is no way for the MG to detect it when using UDP.
> >
> > I have already seen two mechanisms implemented by stack vendors to solve
> > this issue :
> >
> > 1- Use of ping to detect that the correspondent is no more reachable
> > 2- Use of a ServiceChange ROOT with termination = undefined as a  polling
> > mechanism
> >
> >      * on MGC side if no response to the poll, return to initial state
> > waiting for a ServiceChange
> >         from the MG. Inform the Call Control that  the terminations are no
> > more usable
> >         to establish new calls
> >
> >      * on MG side if no response to the poll, return to initial state and
> > try to retrieve the dialog
> >         by sending ServiceChange to the primary MGC  or to the secondary
> > MGC if it is provisioned.
> >
> > I think that to avoid that everyone defines it own mechanism which can
>lead
> > to interoperabilty problems
> > it should be defined in the RFC.
> >
> >
> > Jean-Luc Lecuyer
> > --------------------------------------------------------------------------
>------------------
> > Jean-Luc Lecuyer :          VND/E10 VS  BU R&D/CCPD Lannion
> > Full telephone number :                                         33 (0)2 96
>04 77 09
> > Full fax number :
>33 (0)2 96 04 72 35
> > Email :
>[email-masked]
> > --------------------------------------------------------------------------
>-------------------
> >
> >
> >
> > _______________________________________________
> > Megaco mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/megaco
> >
>
>
>
>_______________________________________________
>Megaco mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/megaco
>
>_______________________________________________
>Megaco mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: Christian Groves <[email-masked]>
Date: Tue, 09 Jul 2002 11:00:24 +1000

Hello Aleksandr,

For the problem you describe I assume that you are talking about a very large
gateway (that is highly reliable) that would have many new call attempts during
the 10sec period. 

You can address the situation below in a number of ways. 
o Design your MGC so that it hot swaps to another MGC without the MG ever
knowing. ie. use the same connection to the MG. This assumes that there would
have to be sharing of states/records between the 2 MGCs. This would eliminate
the problem completely.
o Use a reliable transport ie. SCTP and set your timers quite tightly. This
would minimise the problem.

Through the development of Megaco/H.248 we stayed clear of using it as a "hot
swap" mechanism as this would lead us to make assumptions about the
communication between MGCs which is rather out of scope of our charter.

Regards, Christian

---

From: Christian Groves <[email-masked]>
Date: Tue, 09 Jul 2002 11:00:24 +1000

Hello Aleksandr,

Regards, Christian

---

From: Christian Groves <[email-masked]>
Date: Tue, 09 Jul 2002 11:00:24 +1000

Hello Aleksandr,

Regards, Christian

---

From: Christian Groves <[email-masked]>
Date: Tue, 09 Jul 2002 11:00:24 +1000

Hello Aleksandr,

Regards, Christian

---

From: Aleksandr Ryabin <[email-masked]>
Date: Tue, 09 Jul 2002 13:07:51 -0400

Hi Christian,

         This still would not solve "software" fail over (e.g. MGC with 
different IP/port)
as it only will work for "hardware" (hot swap) fail over (e.g. MGC with 
same IP/port),
but then it has nothing to do with the protocol, since as you correctly 
pointed out
MG would not have to know about it.

         What I'm trying to find a solution for is a protocol supported way 
for such
a situation. That is if we can put into MEGACO some provisions to overcome
this bottleneck in the protocol itself.

         My proposals do not deal with "hot swap" mechanism since "hot swap"
does not have a problem as you correctly stated. The fact is that the protocol
already have a handoff mechanism which already works in most scenarios. By
allowing initiating handoff from secondary MGCs would solve the bottleneck.
         The problem with this as I understand is that generally speaking 
MG is
the one that must initiate the control connection (specifically in case of 
TCP).
This also can be worked around by allowing MG to initiate control connections
to all MGCs including secondary on startup, or some other time, before
the primary MGC failure occurs. Only one will be "active", the one to
current primary MGC thus control connection will be up by the time
secondary MGC will need to send handoff to itself.
         Of course this all can be defined as optional functionality to be
backward compatible.

         Does anybody have any strong objections on allowing secondary
MGCs to send handoff for itself and/or for MG to establish multiple control
connections?

Thanks
         Aleks

---

From: Aleksandr Ryabin <[email-masked]>
Date: Tue, 09 Jul 2002 13:07:51 -0400

Hi Christian,

Thanks
         Aleks