Subject: RE: [MEGACO] Question on failover

From: Steven Weisz <[email-masked]>
Date: Wed, 15 Aug 2001 13:55:27 -0400

First off Terry thanks for taking the time to help me out. However, I think
the confusion lies in what is meant by "Failover" and "Disconnected".

> 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?

This section is easily understood and I have no problems with it but it
occurs after we
have established a new association. What I'm asking about is what goes on
between the time we "suspect" a failing MGC and the establishement of a new
association. The question is, what do we do with that pesky transaction that
led us to believe the MGC is failing. We can't get rid of it because we only
"suspect" a failure. Yet we can't send it to one of the provisioned
secondary MGC because a connection has not yet been established. Should we
just suspend it?

> 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.

In my understanding of the protocol when the max number of retransmissions
has taken place we enter the disconnect procedure. Before that time we will
be in the failover procedure which seems to state, in lay mans terms, "From
you provision list of secondary MGC's, try to establish a connection, so
that you can send this pesky transaction there".

> 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.

Ths problem I'm still faced with is trying to give the failover procedure a
chance to establish a new connection before my "pesky" transaction sets off
the disconnect procedure, since at that time it will be deleted.

Thanks again,

Steve

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

---

From: Terry L Anderson <[email-masked]>
Date: Wed, 15 Aug 2001 14:35:27 -0400

> the confusion lies in what is meant by "Failover" and "Disconnected".

see below.

> that you can send this pesky transaction there".

First of all, there are a lot of gray areas in the association states and there
is a draft to appear soon that tries to be precise about association states and
transitions.  After this is discussed and agreed to, we need to change the
several spots in H.248 that relate to this to remove the ambiguities.

"disconnect" and "failover" are not procedures but ServiceChange Methods.  There
was a recent clarification (discussed on the list and to appear in the next
release of the IG) to the first paragraph of 11.5 to make it clear that in the
Failure procedure, an attempt to establish an association with a different MGC
(from the pre-provisioned list) ServiceChange is sent with method ="failover",
but if an attempt is made to re-establish the association with the original MGC
(either because there is no list of secondaries or because one has tried all of
them and is not re-trying the original), that ServiceChange is sent with method
= "disconnected".  Both of these are part of a single procedure outlined in
11.5.  11.5 also discusses an MGC directed change using method = "handoff",
which is not necessarily due to a failure.

The 11.5 failure procedure (register with a secondary or re-register with
original) will be invoked after a "failure" is detected.  This may be by
exceeding the max retransmissions (D.1.5) or some other means (eg, ICMP error,
loss of connection in TCP, etc.)

> the disconnect procedure, since at that time it will be deleted.

again, I don't think that there are two "procedures" and there is no reason to
"delete" a transaction when failure is detected - MG simply sends the
transaction to the new MGC after registering.

--
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