Subject: Re: Preconditions

From: "Rosen, Brian" <[email-masked]>
Date: Sun, 23 Jan 2000 18:56:54 -0500

Let's be careful.  I believe all of these items are defined
in packages.  I don't think there is anything like this in
the base package.  In general, we have talked about defining
events such as hook state as "edge detect", rather than state
detect.  Would it solve the problem to make such events, in
the packages, explicitly defined as change-of-state detected.
Something like "detects the transition...".

Brian

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Saturday, January 22, 2000 3:22 PM
> To: Rosen, Brian
> Cc: [email-masked]
> Subject: Preconditions
>
>
>
>
>
> Rosen, Brian writes:
>  > 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.
>
>    That's a very big "unless".
>
>  > 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,
>
>    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: Abdallah Rayhan <[email-masked]>
Date: Mon, 24 Jan 2000 10:34:21 -0500

I agree with you that caution should be exerted when introducing
this feature. The main problem is syncing MGC and MG. If there is
one state that the MGC and MG could agree upon then it should be
used to sync the two. Why look for keypad events if the phone is onhook
?
Other events are dropped. Such an event is very much related to the
application and the package(s) the termination implements. But defining
application interaction is outside the scope of the protocol (IMO).

How do we resolve this ? Allow manual provisioning of Notify.
This would allow the application to exert flexibility in its interaction

with the protocol.

Abdallah