Subject: Re: Protocol usage in IP Phone application (RE: I-D posted: Megac o IP Phone MG 01)

From: Brian Rosen <[email-masked]>
Date: Tue, 14 Sep 1999 18:25:27 -0400

> I agree with Peter. The cost of a resource is free until you
> run out of it.
> We are designing to specific objectives, both price and
> performance. To
> make such a crass statement that the cost of something is
> $0.25 for ROM and
> $0.05 for RAM is just one more example of the tactics of
> obfuscation which
> are being used as emotional crutches for this discussion. At
> least credit
> us with a degree of professional competence. There are sound
> engineering
> reasons for this request on our part. It is not a desire to
> be different.
>
> Bob Bell
> <<<

The argument is that implementing EventDescriptors,
and several other features, is too expensive to be
included in an IPPhone.  I was trying to get to a place
where we could have a discussion on some factual basis rather than an
unsupported assertion.

If I can show you that it costs, say 40 lines of C code,
does your argument hold?

There are opensource versions of MGCP.  It would be pretty
simple to conditionally compile the code that supports
the features you are talking about and see what difference it makes.  If
it's, say 4K of code and a couple hundred bytes of RAM, what will you say?
If it's a megabyte of
ROM and 64K of RAM, what could I say?

One of the very biggest drivers on what MEGACO looks like
is the desire by the WG to make one protocol that worked
for small gateways and big gateways.  When we did that,
we KNEW that there was a price to pay, in both ends,
for having one protocol.  To those of us who made compromise after
compromise to keep MEGACO as one, worldwide, one-size-fits-all protocol,
what you propose
is sacrilege.  If you do this, you can't call it MEGACO, and if you subset
it, you open Pandora's box.
We will have dozens and dozens of profiles that cut the features this way
and that way to optimize for one kind
of gateway.  None of them will interoperate.

At a minimum, we would need to divide between big and small.  We probably
have to divide small between residential gateways and IPPhones.  We need
SOHO.  We need access trunk and core trunk.  The list goes on.

I assert that none of this is a good idea, the cost of
implementing the features you want to leave out is small enough that it does
not offer an undue burden on you.  If you want the benefits of a single
protocol, pay the price.

If it's too expensive, design a protocol that meets the need.  It can be
very small.  It's not MEGACO

---

From: Bob Bell <[email-masked]>
Date: Wed, 15 Sep 1999 09:48:57 -0600

As I said above, resources are free until you run out. I don't want to
expose internal Cisco development and engineering requirements, so let me
propose a hypothetical case which we can then discuss openly. Assume for
this discussion that the core processor for this IP Phone is a Zilog
Z89138. This chip has a ROM space of 6K for the DSP and 24K for the host
processor. Since this processor provides a "single chip" solution for the
core of the phone, it is desirable from an engineering standpoint to use
it. In addition, the clock speed is relatively low (20-29 MHz) which places
restrictions on the amount of code that can be utilized. RAM is likewise
severely restricted.  Thus the desire to minimize the portions of the
protocol which are not absolutely required for the operation of a station.
In the above scenario,  even 4K of ROM and a couple of hundred bytes of RAM
is too much, if it drives us out of the single chip solution.
<<<<

I understand the desire for a one-size-fits-all protocol. I guess my
question is whether having an absolute minimum required core with the
applications specific extensions isn't a way to accomplish this. If the
extensions are well known and are identifiable by query, the MGC can
understand the specific dialect to be spoken. This would allow for the
protocol to be optimized for the application while preserving the general
concepts and flows of the protocol. To me, this type of compromise makes
sense in an engineering environment. The one-size-fits-all solution results
in significant compromise for every application, some of which may not make
engineering sense.
<<<

>very small.  It's not MEGACO

Bob Bell
Cisco Systems Inc.
801-294-3034(v)
801-294-3023(f)