Subject: Re: heart beat message in the megaco protocol

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 17 Oct 2000 14:27:20 -0400

I think this is self defeating - if you are only auditing when
there is no traffic, then there is no state to worry about.  If
there are conditions where there is a lot of state, doing the audit
is expensive.

I'm not sure what "inquire about alternate MGCs" means.  The only
way I know to find out about alternate MGCs is a declined initial
registration.

Brian

> -----Original Message-----
> From: Manish Rao [mailto:[email-masked]]
> Sent: Tuesday, October 17, 2000 12:33 PM
> To: Rosen, Brian; [email-masked]
> Subject: Re: Re: heart beat message in the megaco protocol
>
>
> Well, the MGC only sends the heart beat audits out when it
> hasnt heard from
> the gateway over a specified period of time.  This is usually
> when all ports
> on the gateway are idle (in which case it really is not that
> expensive as no
> voice/H.248 traffic is going on), or all ports have active
> calls or are
> performing operations which do not need communication with
> the MGC for a
> long duration--the specified period (in which case I still
> dont think its
> that expensive).  As for the gateway, I really dont have a
> heart beat from
> the MG to the MGC.  When a message needs to be delivered from
> the MG to the
> MGC--I have a UDP implementation by the way--and my number of
> retransmits
> has reached 1/2 MAX_RETRANSMITS, I begin to inquire about
> alternate MGCs
> (from the primary MGC), so that as soon as MAX_RETRANSMITS
> has been reached,
> the message is immediately transfered over to the alternate
> MG.  This has
> seemed to work, and the result is that you have at most one
> or 2 calls that
> are delayed because of the retransmits.  What I do need to
> implement is for
> the primary MGC to detect that any one of the MGCs has
> failed, and then
> contact that MGs associated with the failed MGC to be
> transfered over to a
> new MGC.  Well, this is my implementation, and any comments would be
> appreciated.  Hope this helps,
>
> Manish Rao
> Software Engineer
> Cirilium Corporation
> [email-masked]
>
> ----- Original Message -----
> From: "Rosen, Brian" <[email-masked]>
> To: <[email-masked]>
> Sent: Tuesday, October 17, 2000 5:19 AM
> Subject: Re: heart beat message in the megaco protocol
>
>
> > This sounds like an expensive heartbeat unless the gateway is small.
> > I'd use something else.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Manish Rao [mailto:[email-masked]]
> > > Sent: Monday, October 16, 2000 12:25 PM
> > > To: [email-masked]
> > > Subject: Re: heart beat message in the megaco protocol
> > >
> > >
> > > In my current implementation, I am using audits as a means of
> > > acheiving
> > > heart beats.  The MGC audits the gateways periodically
> > > requesting connection
> > > ids.  This way, the MGC can also say if it is out of sequence
> > > perhaps, with
> > > the MG (say, the MG returns a connection id, and the MGC does
> > > not have one
> > > for that endpoint).
> > >
> > > ----- Original Message -----
> > > From: "Christian Groves" <[email-masked]>
> > > To: <[email-masked]>
> > > Sent: Sunday, October 15, 2000 10:45 PM
> > > Subject: Re: heart beat message in the megaco protocol
> > >
> > >
> > > > Hello Susumu San,
> > > >
> > > > Currently there is no mechanism for this in H.248. I
> > > thought one way to
> > > > achieve this would be to send a signal on the Root
> > > Termination of the MG
> > > > that would be an on/off signal which would generate a
> > > heartbeart message
> > > > periodically. But unfortunately we can't a signal (events are OK
> > > > though)on the root termination. This may be something we
> > > want to change.
> > > >
> > > > I guess you could always provision some mechanism outside
> > > of H.248 also.
> > > >
> > > > Cheers, Christian
> > > >
> > > > Susumu YAMAMOTO wrote:
> > > > >
> > > > > Hi all,
> > > > >
> > > > > Is there a heart beat message from MG to MGC in the megaco
> > > > > protocol?
> > > > >
> > > > > If not, how do you think about a heart beat message?
> > > > >
> > > > > I think MG always should be able to detect a failure
> of MGC and
> > > > > restore the service by failover method, because the case of
> > > > > restart of MGC, MGC may lost which MG is now in service and
> > > > > cannot send a handoff message properly.
> > > > >
> > > > > Thanks in advance,
> > > > > -*-*-*
> > > > > YAMAMOTO SUSUMU
> > > > > Mega-media Network Systems Project
> > > > > NTT Network Service Systems Laboratories
> > > > > mailto: [email-masked]
> > > > > TEL:+81 422 59 2744  FAX:+81 422 37 7467
> > >
>

---

From: Manish Rao <[email-masked]>
Date: Tue, 17 Oct 2000 12:21:57 -0700

I send audits out when I havent heard from the MG say in over 20 seconds.
Suppose my MG supports an E1 (ie 30 channels). Then, if the MGC hasnt heard
from any of the 30 channels for over 20 seconds, then it begins auditing the
gateway, requesting connection ids.  This can happen because
a) the MG (all 30 channels) has been idle for 20 seconds
b)  all channels have active calls that have been running for 20 seconds, in
which   case it is good to audit, just to make sure the status of the call
is ok.  I also need to collect RTP stats here (havent done that yet), so may
be if there are many packet losses, I can switch to a differenent
compression.
c) the MG or the LAN/WAN card between  the MG and the MGC has failed.

If case c applies, then the MGC drops its notion of all active calls and
ends any H.323/SIP sessions applicable to the 30 endpoints of the MG, and
goes into a state where it waits for a restart message from the MG.  This
needs to be done to prevent over/under-billing a call etc.  I did this coz
the Megcao spec did not have a heart beat, and I cant use pings coz the IP
interface to my MG is on separate physical card, and the coordination of
asking the IP card to send pings on behalf of me is ridiculous.  But if
Megaco did provide a heart beat mechanism, how would u make it simpler than
an audit message?  My audit messages request connection ids, which should be
maintained in any control blocks allocated (I know im going into
implementation details) for calls in the MG, and should be no extra
processing really.

As far as "inquire about alternate MGCs",  the MG sends the same message
that it sent to its originally configured MGC (maybe an off-hook), which it
thinks it probably cant reach (coz of the 1/2 MAX_RETRANSMITS), to the
primary MGC, hoping to obtain another IP address for its notified entity.
Once again, what are the other available options?  I thought of sending
empty notfies as heart beats at one time, but conecptually, a blank notify
means "I have detected nothing, although I am still looking for these list
of events you have asked me to detect" -- I dont know, seemed more like a
hack.  Anyway, sorry for this lengthy email, but once again, I would love to
receive comments.  I am really still not extremely happy with my
implementation.

Manish Rao
Software Engineer
Cirilium Corporation
[email-masked]

----- Original Message -----
From: "Rosen, Brian" <[email-masked]>
To: "'Manish Rao'" <[email-masked]>;
<[email-masked]>
Sent: Tuesday, October 17, 2000 11:27 AM
Subject: RE: Re: heart beat message in the megaco protocol