Subject: Re: ServiceChangeMethod = failover

From: "Taylor, Tom-PT [NORSE:B901:EXCH]" <[email-masked]>
Date: Wed, 22 Nov 2000 10:29:36 -0500

You have managed to place yourself into a debate some of my colleagues have
been having on the list, regarding the Megaco/H.248 control session
management model.  The intent of the failover method is that it be issued by
the failing party BEFORE cessation of communications, to indicate that a new
control session has to be established to replace the old one.  It is then up
to the MG to initiate this new session.

The case you describe, involving failure of a NIC, would most simply be
solved by allowing the MGC to indicate that it is still available, but with
a new address.  This is not allowed in the current Megaco model.  Instead,
it is up to the MG to detect the communications failure and find the
alternate address, either through provisioning or through other means such
as DNS.

This situation actually seems made to order for the use of SCTP, as
permitted by the newly approved H.248 Annex H.

> -----Original Message-----
> From: Terry L Anderson [mailto:[email-masked]]
> Sent: Tuesday, November 21, 2000 4:59 PM
> To: [email-masked]
> Subject: ServiceChangeMethod = failover
>
>
> 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: Terry L Anderson <[email-masked]>
Date: Wed, 22 Nov 2000 14:56:48 -0500

Thanks Tom and Brian
I now see that "failover" is similar to "handoff" but initiated from the MG
end.  I guess I find the name confusing in that this procedure seems more gentle
than a "failure" - "handoff" is better but used for the MGC initiated case.  If
the MG can anticipate its need to "fail" this works but I think of "failover" as
recovery from an unanticipated failure.  But I now understand the intent.
Perhaps this should be clarified/explained in the Implementors Guide.

And I agree with Tom that SCTP could handle this without any support from H.248,
but it could also handle the "failover" and "handoff" cases.  Not all of use may
be able to use STCP immediately.  I would still like to see mechanisms to handle
unanticipated failures of either MGC or MG, although I realize that allowing a
message from an entity that it is taking over for some other entity can have
security concerns.

---

From: Hsien-Chuen Yu <[email-masked]>
Date: Mon, 27 Nov 2000 14:59:57 -0600

All,

I have several comments and questions:

1. The description of Failover in Item 6, Section 7.2.8 needs to
be expanded to include the case described in the 1st paragraph of
Section 11.5: "If the MG detects a failure of its controlling
MGC, it attempts to.... It sends a ServiceChange message with a
"Failover" method and a "MGC Impending Failure" reason".

2. The description of "notifyCompletion" in Section 7.1.11 is
confusing. It appears that if notifyCompletion is included in
the signalsDescriptor, MGC will be notified even if it does
not specify an eventsDescriptor. It also appears that if
notifyCompletion is not included in the signalDescriptor,
notification is generated only via eventsDescriptor. However,
the description of Signal Completion event in Annex E.1.2 says
this event is for the case where the notifyCompletion parameter
is set to "ON". If this description is correct, then why duplicate
the same mechanism in notifyCompletion?

3. The returned parameter in Section 7.2.8 should be
ServiceChangeReplyDescriptor instead of
ServiceChangeDescriptor.

4. The description in Section 7.2.8 allows a MGC to send a
ServiceChange message to MG to put a Termination out of
service (with ServcieChangeMethod = graceful or forced)
or to put a Termination in service (with ServiceChangeMethod
= Restart). This obviously is one way that the MGC can affect the
value of serviceStates in the terminationStateDescriptor. My
question: Is this the only mechanism allowed for MGC to modify
serviceStates of a Termination? If so, should it be clearly stated
that serviceStates is read-only by MGC?

5. The Mux Properties in Annex C.2 are already covered in
Annex A and Annex B. Why are they repeated here? In any case,
they are not part of MediaDescriptors and therefore should not
belong to Annex C.

Regards,

Hsien Yu