Subject: [Megaco] Multiple factors affecting a termination's service state

From: Raphael Tryster <[email-masked]>
Date: Thu, 22 Nov 2001 20:34:10 +0200

In some protocols, there is a concept of a primary service state
(in-service/out-of-service) and a secondary service state (basically the
reason why the entity is OOS).  The primary service state is IS only when
none of the secondary OOS states apply.  In Megaco, there seems to be only a
primary service state for terminations.  Suppose the MGC sets a termination
OOS for administrative reasons, and subsequently the MG discovers a physical
problem requiring that termination to be OOS.  If we had a secondary service
state, we could ensure that the termination stays OOS until the LAST of
these conditions clears.  Without it, it seems behaviour is
non-deterministic as the FIRST condition to clear will attempt to return to
service.  For example, if the MG discovers that the physical problem has
cleared, will it:
*	Tell the MGC the termination is going IS?  Will the MGC then have to
issue a new command overruling the MG? or
*	Do nothing and wait for the MGC?  The MG can only make this decision
if it remembers there is an MGC OOS to wait for, i.e. it keeps a secondary
state.

In general, without a secondary state, either side wishing to change the
service state can override any previous history.

What is the correct way to handle such situations in Megaco?

Raphael Tryster