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:24:38 -0400

Let's continue along your line of thought.

Hmmmm.

I don't need:
        ModemDescriptor
        MuxDescriptor
        DigitMapDescriptor
        EventsDescriptor

I can make a termination that makes any noise I want,
so I don't need signals.

Notify doesn't need a RequestID.

By looking at the profile, I can tell if this is an IPPhone
so I have no use for AuditCapability. I can severely
restrict what options AuditValue can request.

I can cut 3/4s of the functionality of ServiceChange.

This is an enterprise device, and I can use my call control
for basic issues, so statistics is superfluous

I only ever have one context, so I don't need actions,
contextIDs and the like.  Also, I don't need the Move
command.  Topology and Bridging are gone, of course.

I only ever have one stream, so I don't need StreamDescriptors.  I can put
all the properties in Local
Control, so I don't need TerminationState.

Clearly we don't want SDP; too much parsing.  Use
"native" tag value.

Wildcards are clearly out

I can send one command at a time, so transactions are gone.

Couldn't possibly afford MD-5, so we don't have IPSEC
or the interim scheme.

You already cut any transport but UDP/ALF
      ........

Now, I think this probably would save quite a lot of code.

The real question is:
        Is it MEGACO?

Peter, we have a single, fundamental problem.

The words in the protocol definition don't say optional
to implement.  ALL of the above items are candidates for
being optional, because there are some gateways that
won't need them.  Each of them has just as valid of
an argument as EventDescriptor for making them optional,
yet none of them are optional.

If you want to come to the next IETF and ask for a hum
on who wants EventDescriptor to be optional to implement,
by all means come and propose.  I'll stand behind you with
the above list.  In for a penny, in for a pound.

Some detailed comments below, but we have to get through
the basic issue.

> I can buy that IP Phone is a separate standard, defining an
> application of
> MEGACO.  In a way that is actually our intent.  We would like
> to see Megaco
> IP Phone MG stand alone as a separate, application-specific
> RFC, referencing
> both MEGACO Protocol and Generic Packages.
>
> I do not, however, buy the argument that if Megaco IP Phone
> MG does not
> implement EventDescriptors its not MEGACO.
As MEGACO is currently defined, it is not MEGACO.
It's a subset of MEGACO.  It would not pass an interoperability test with a
full implementation.

>It
> uses MEGACO in
> a particular way, without modifying it.
Yes, it does modify it, quite significantly.  It changes
the way events are controlled, for example.

> Secondly, any MGC software controlling IP Phones needs to be
> able to make
> assumptions about the configuration and protocol usage of the
> devices it
> controls.  As I have pointed out before (and Tom also notes)
> the IP Phone
> application will always be specific to IP Phone control.  It
> has to be.  It
> implements user interface.  This idea that we will have some sort of
> universal MGC is a pipe dream.
I don't agree.  Any large scale call control model can,
with a suitable driver, control an IPPhone defined as you
have defined it.  That same call control could control
a very large gateway to which PBXs were connected,
a gateway to which Digital Loop Carriers were connected,
etc.

>  What we specify is how the IP Phone application on
> the MG and MGC
> sides will use the optional parameters.  It is optional for
> the MGC to use
> these parameters, and its part of the application design
> whether to do this
> or not.  To some degree, we are specifying the underlying
> assumptions of the
> particular IP Phone application design on the MGC side.
I think that it is very hard to, with a straight face,
argue that because EventDescriptors are described as
optional to include in any command that they are optional
to implement.  By that definition, all descriptors and all commands are
optional to implement, even Add -- you CAN
use Move you know, Move to Null, Move from Null.
Hmmm, include Add and Subtract to my list above :)

If they were an optional part of the protocol, they would
be clearly labeled as such. You want us to change the protocol so that they
are optional.  That is a reasonable request, even if I don't agree with it.
Claiming that they
are already optional is not true IMO.

>
> This same reasoning applies to other application types as
> well.  It may well
> be that other applications will want to specify how they are
> intended to
> work under MEGACO -- indeed I think this is both likely and desirable.
> Cable/xDSL modems, small (1-2 line) PSTN gateways are ones
> that leap to mind
> for me, but I'm sure there are many others.  They will also place
> restrictions on what they implement and what they do not, be
> it in the form
> of packages, terminations, or protocol profile.  I submit
> this is a good
> thing for MEGACO since it will improve interoperability at
> the device level
> and will allow truly useful applications of the protocol to
> get out in the
> field far more quickly.  The IP Phone is an urgently needed
> application,
> since if there are no phones there is no communication system
> (at some risk
> of igniting that old religious war again).
I tried, very hard, to make digitmaps optional.  Trunking gateways won't use
them.  I lost that argument.  They
aren't optional, they are a required element of the protocol.  Making them
optional was considered.  It was
not acceptable to the group as a whole.

In fact, there are very few optional to implement features,
and for MGCs, there are even fewer.  Options for various features have been
proposed often, even by me.  Most have failed to get consensus within the
group.  In general, options mean non-interoperable MGs and MGCs.  That is
considered harmful, and as a result, we have generally said NO to options.
Fact, like it or not, right or wrong,
good or bad.  The protocol doesn't admit options for the most part.

>
> And earlier in the thread, you said:
>       > > Except for some recent effort by the MSF, there has not
>       > > been a review of the protocol vs. its requirements.  I
>       > > am certain that we have some issues there.  When we resolve
>       > > them, we may defer some requirements to a subsequent
>       > > version, or we may modify the protocol.  We may even choose
>       > > to modify the requirements!
>
> The requirements clearly state that such profiling approaches must be
> allowed for in application-specific cases.  And the protocol
> document as
> currently written allows for this, give or take some fairly
> minor issues.
> To go back and modify the requirements to suite the way the
> protocol has
> turned out, or is understood to have turned out, is not
> progress to my way
> of thinking, its a step backward.
In every large project I've been involved with, we have ended up doing all
of those things, including changing the
requirements.  You ALWAYS take another look at your requirements when you
finish a prototype.  You almost always find that what you thought would be
straightforward was not, and you question whether it was a good goal, and
still valid or not.  I guarantee we will, in the end, change at least some
of the requirements to match reality.

>
> And on the cost thing:
>       As you note, it may be that the market doesn't like
>       lots of subsets running around.  Then you have to ask:
>       What is the price of no subsets?
>
>       Let's say that it was $.25 of ROM and $.05 of RAM, ...
>
> This trivializing of costs has gone on FAR too long!!  The
> cost figures you
> give are frankly ridiculous. I am not willing to share our
> detailed cost
> estimates here, nor is anyone else likely to do so, so lets
> look at it as
> percentage.  Our estimates show use of EventsDescriptors and
> associated
> stuff would cost on the order of 30-40% additional ROM,
> doubling or more the
> application size.  There would also be some additional RAM,
> which would be
> significant though not as high a proportion.  Processing burden would
> increase significantly.   Development effort would increase very
> significantly, not just for us but for anyone developing such
> a device, and
> this development effort affects both cost and time to market.
> Interoperability would likely be worse, not better, due to additional
> complexity for the phone applications at both MGC and MG ends
> (its just
> harder to get it right, and testing becomes far more
> difficult due to the
> number of permutations).   Reliability would suffer, since
> there would be
> cases where resource restrictions caused commands to just
> plain fail (RAM is
> always doled out parsimoniously for such devices).  So the
> message has to
> be: "KISSSSSS" (keep it simple, simple, simple, simple...)
I do not buy this argument.  I don't believe the 30-40% argument, and I
think I can show that it is wrong.
I think that we have to come up with interoperability tests.  Creating the
tests is hard.  If any MG implements a feature, we need a test for it.
Running them is easy.  It will be straightforward to try a new MG.  Fixing
bugs is difficult, granted.  KISSSS has to be the watchword for the whole
protocol, not just this one application.  If it's not simple enough, we
should fix it now, for everyone.

Brian

---

From: Kelvin Porter <[email-masked]>
Date: Tue, 14 Sep 1999 17:36:27 -0500

This is heresy I am sure, but...

Bryan Rosen wrote:

[...]
By that definition, all descriptors and all commands are
optional to implement, even Add -- you CAN
use Move you know, Move to Null, Move from Null.
[...]

This is actually a good idea.  Parameter combinations (where there is
semantic overlap) are preferable to multiple (redundant) methods.  This
technique offers improved concentration of related code in the MG, and can
simplify the code in the MGC.  This example, reduces the method count by two
(e.g., remove ADD and SUBTRACT).

Regards,

Kelvin R. Porter