Subject: Re: Megaco Events and Signals

From: Matt Holdrege <[email-masked]>
Date: Mon, 25 Oct 1999 20:35:13 -0700

At 03:30 PM 10/25/99 -0500, Tom-PT Taylor wrote:

>There are several ways to achieve these behavioural distinctions:
>(i)   provide limited behavioural support in the protocol and require the
>MGC to fill in the rest through additional messages
>(ii)  provide full protocol support for selection of the desired behaviour
>(iii) design the behaviour into the definition of individual signals.
>
>There was a strong voice for limiting the amount of intelligence required
>in the MG.  Accordingly, the current solution is a mixture of (i) and (iii).
>Is this what the Working Group at large is comfortable with?

This is yet another area where we have a problem with a one-size-fits-all
protocol. Some MG's will have limited intelligence and others will be quite
intelligent. Why should an implementation of an intelligent MG (or a simple
MG which happens to have a few neat feautures) suffer for lack of messages?

I'm all for allowing for control of very dumb MG's, but this protocol is
being applied to smart MG's as well. An MGC should be able to work with both.

---

From: Tom-PT Taylor <[email-masked]>
Date: Tue, 26 Oct 1999 07:35:39 -0500

Any ideas for a solution which doesn't destroy interoperability?  I have
thoughts of extensions to the basic protocol to support intelligent MGs,
with fallback to the basic version where the two sides can't agree, but this
involves some sort of negotiation.

> -----Original Message-----
> From: Matt Holdrege [SMTP:[email-masked]]
> Sent: Monday, October 25, 1999 11:35 PM
> To:   Taylor, Tom-PT [CAR:B904-I:EXCH]
> Cc:   [email-masked]
> Subject:      Re: Megaco Events and Signals
>

---

From: Matt Holdrege <[email-masked]>
Date: Tue, 26 Oct 1999 07:29:40 -0700

If that can work, fine. I'd even be happy if the MGC had to pre-
provision for smart MG's since there may likely be less of those.