Subject: RE: [MEGACO] Question on failover

From: Steven Weisz <[email-masked]>
Date: Wed, 15 Aug 2001 12:50:41 -0400

So this is an implicit requirement stating that we continue sending the
transaction to the current (i.e. failing) MGC. Is it also implicit that we
reset the retransmission count of the offending transaction to 0 or do we
continue to increment. Keep in mind that it won't be long before we hit the
disconnect threshold discussed in D.1.5

Thanks,

Steve

-----Original Message-----
From: Terry L Anderson [mailto:[email-masked]]
Sent: Wednesday, August 15, 2001 12:43 PM
To: Steven Weisz
Cc: [email-masked]'
Subject: Re: [MEGACO] Question on failover

Steven Weisz wrote:

> Hi List,
>
> I need a little clarification on section 11.5 of RFC 3015, it states:
>
>     "If the MG detects a failure of its controlling MGC, it attempts to
>    contact the next MGC on its pre-provisioned list.  It starts its
>    attempts at the beginning (Primary MGC), unless that was the MGC that
>    failed, in which case it starts at its first Secondary MGC.  It sends
>    a ServiceChange message with a "Failover" method and a " MGC
>    Impending Failure" reason."
>
> In this statement it seems clear that a Service Change Message  with
> "Failover" method and a "MGC Impending Failure" reason, however, what do
we
> do with the transaction that caused us to notice this? Do we now attempt
to
> send it also to the next provisioned MGC or do we continue to send it to
the
> current MGC?

Read a little further in 11.5 and you will find.
"Repeated transaction requests shall be directed to the new MGC...."
This is after you have established the new control association as stated in
the
sentence previous to my quote.

>
>
> Thanks,
>
> Steven Weisz
>
> _______________________________________________
> Megaco mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/megaco

--
Waiting for the other shoe to drop but hoping its a one legged man.
------------------------------------------------------------
Terry L Anderson              mailto:[email-masked]
Tel:908.582.7013   Fax:908.582.6729
Lucent Technologies/INS/Voice Over IP Access Networks
Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

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

---

From: Terry L Anderson <[email-masked]>
Date: Wed, 15 Aug 2001 13:21:09 -0400

NO.  Not to the failing MGC.  The quote says to the NEW MGC (after control
association establishment).  Are you assuming the need to keep sending to the
failing MGC because of the delay in control association establishment?

Admittedly the quote is in a paragraph dealing with MGC directed handoff rather
than detected failure, but in the absence of another statement I assume the
same principle should apply to failure.

Failure detection may have occurred due to reaching max number of
retransmissions.  Then clearly one would not retransmit to failed MGC, but
could "start over" (reset transmission counter to 0) and send the transaction
to the new MGC after control association establishment.

Though H.248 does not indicate all the ways an MG could detect failure,
presumably MGs may be capable of detecting some failures without reaching the
retransmission count max (e.g., ICMP errors, etc.).  In these cases it futile
to continue retransmitting to the failed MGC while establishing the control
association with the new MGC but even if one did, the exponential backoff timer
described in D.1.5 would would minimize the number of retransmissions before
the new control association is established.