Subject: Preconditions

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 21 Jan 2000 23:16:52 -0500

Megacogans!

The following issue has been raised:

Issue:          The current draft text does not support the concept of
preconditions that must be established in order for a command to be
successful. For example, the MGC and the MG can get out of synch on the
hook state. Consider a MG that just cold-started. Before the gateway
generates a restart ServiceChange, the user picks up the handset. The
gateway detects the off-hook transition, but since it does not have an
EventsDescriptor, it does not generate Notify. Soon after, the gateway
generates a restart ServiceChange. After the MGC receives the message, it
generates a Modify to the gateway to request off-hook detection. However,
since the off-hook transition has happened, the gateway does not generate
Notify. Since the gateway does not play any tone to the user, the user
hangs up the phone. Since the MGC has not requested the gateway to detect
on-hook transition, the gateway does not generate Notify either. If
preconditions were defined and supported, e.g. to require that a request
for off-hook detection would only succeed if the line state was currently
on-hook, such errors could be avoided.
Proposal:       It is strongly recommended, that preconditions as described
above are added to the draft.

Frankly, I don't think it matters a whole heck of a lot what happens in
cases
like this, unless there is some possibility that the MG and the MGC will not
sync quickly.  They do in this case -- the user hangs up, and then the state
is consistent, the next time he goes off hook, the right thing happens.  If
anyone
can define a case that doesn't converge like this, please speak now, or I
recommend
we say "thanks for sharing"

---

From: Michael Thomas <[email-masked]>
Date: Sat, 22 Jan 2000 12:22:13 -0800

Rosen, Brian writes:
 > sync quickly.

   That's a very big "unless".

 > They do in this case -- the user hangs up, and then the state
 > can define a case that doesn't converge like this, please speak now,

   A device control protocol like MEGACO is utterly
   at the mercy of a shared view of the device's
   state. If the MG and MGC are out of sync and the
   MG has no way to convey that within the protocol,
   the protocol is broken. Period. Relagating such things
   to audits is even more broken, because MGC's in the
   real world have about zero incentive to do what
   amounts to device state polling -- which does
   not scale for high fanout devices like residential gateways.

 > I recommend we say "thanks for sharing"

   This is a base functionality of MGCP -- the
   only protocol which has any track record
   thus far. Is this more Anything But MGCP
   hubris again?

   I would say that the onus is on the naysayers
   to actually prove there does not exist any
   unrecoverable and non self-healing state
   mismatches. It is completely unreasonable for
   those who would like to have a more robust
   protocol to prove a negative.

                Mike

---

From: Christian Groves <[email-masked]>
Date: Sun, 23 Jan 2000 13:17:35 +0100

G'Day Mike,

I think people are thinking of applications way past the scope of MGCP
today. Megaco  was designed to be application agnostic. Pre-conditions
depend on your application. The issue has nothing to do with protocol
robustness its about application robustness.

Christian

---

From: Christian Groves <[email-masked]>
Date: Sun, 23 Jan 2000 13:13:07 +0100

G'Day Brian,

I fully agree with you. This type of information is really coupled to
different application logic. In one application this may be a problem,
in another it won't. Megaco is NOT an application protocol.

Cheers, Christian

---

From: Michael Thomas <[email-masked]>
Date: Sun, 23 Jan 2000 15:15:46 -0800

> robustness its about application robustness.

   Huh?

   You're going to have to try this again, because
   this looks like a non-sequitur to me.

            Mike