Subject: ServiceChangeMethod = failover

From: Terry L Anderson <[email-masked]>
Date: Tue, 21 Nov 2000 16:58:30 -0500

The use of ServiceChangeMethod = failover is not clear in H.248.  The
definition says that it is "sent from the MG to MGC to indicate the
primary MG is out of service and a secondary MG is taking over."

1) If the primary is "out of service" presumably the message is sent by
the "secondary", but how does the message indicate what primary MG it is
taking over for?  or must the secondary use the same IPAddr/port as the
primary?

2) what properties of the primary does the MGC assume are shared by the
secondary?  Should the MGC assume that calls that were in progress are
continued by the "secondary" MG or should it audit the MG?

I am interested in a case where the H.248 signaling part of an MG has
failed, say a NIC, but it has a second NIC and can continue all calls,
but must receive future transactions from the MGC on this new address.
Should it send ServiceChange with ServiceChangeMethod = failover from
the new NIC (new ipaddr/port)?  Or is failover intended for something
different?

--
------------------------------------------------------------
Terry L Anderson              mailto:[email-masked]
Tel:908.582.7013   Fax:908.582.6729
Pager:800.759.8352 pin 1704572   [email-masked]
Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp
Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 22 Nov 2000 08:34:50 -0500

> taking over for?  or must the secondary use the same
The intention is that it is an handover, and the message comes from the
primary

> continued by the "secondary" MG or should it audit the MG?
It should assume that the state remains the same, and no audit is necessary

> the new NIC (new ipaddr/port)?  Or is failover intended for something
We don't cover this case, because the message formats all assume
the header has the "from" = old and the ServiceChangeAddress has the new.

I think we SHOULD cover this case, but it's a change to the protocol.

Brian