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

From: Brian Rosen <[email-masked]>
Date: Mon, 13 Sep 1999 09:54:40 -0400

Happy to deal with one issue at a time.

The "Optional" issue is indeed, a good place to begin.

In the text, there are places where it clearly indicates
that an implementation may choose to implement some feature,
or it may choose not to.  Transport by TCP is an example,
which is optional at the MGC.

EventsDescriptor is not defined as optional to implement.
The parameter to the command is optional, indicating that
not every instance of Add, for example must specify
the EventsDescriptor.  This is not at all the same as
optional to implement.  I will add wording which clarifies
that in the document.

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!

At the moment, EventDescriptor is not optional.  Having a
requirement that event buffering is not required does not
imply that we will make the EventDescriptor optional.
At the moment, even event buffering is not optional,
regardless of what the requirements say. You may think it
should be, but, at the moment, it isn't.

Imagine the level of interoperability we would have if every
implementor looked at the requirements and said
"hmmm, I see we don't meet this requirement, and therefore
I will change my implementation of the protocol in the
following way so that I can meet the requirement".

On the other hand I do agree that a Profile is meant to,
among other things, define what to do about protocol items
defined as optional.  So defining a profile for an IPPhone,
and specifying that implementations meeting the requirements
of the profile would implement UDP/ALF is
a very appropriate thing to do.  If EventsDescriptors
were defined as optional to implement, then it would be
appropriate to define that they were not implemented
in the profile.

Brian

> -----Original Message-----
> From: Peter Blatherwick [mailto:[email-masked]]
> Sent: Sunday, September 12, 1999 11:56 PM
> To: 'Brian Rosen'; [email-masked]
> Subject: Protocol usage in IP Phone application (RE: I-D
> posted: Megaco
> IP Phone MG 01)
>
>
> Brian:
>
> I don't think the issues are as severe as you seem to imply.
> Our intent is to work within the Megaco Protocol to define a
> minimal profile, appropriate for the very constrained Megaco IP
> Phone application.  The protocol options we propose to not
> support by default are not required for operation of the protocol
> in simple cases. In my opinion our approach keeps the basics of
> the Megaco Protocol entirely intact.
>
> I do, however, see that we have some fundamentally different
> understandings about what is optional and what is not for
> particular applications of the protocol.  I would like to
> concentrate on that first, as this thread has gotten rather
> unwieldy.  I will respond to the other issues separately.  See
> below.
>
> > -----Original Message-----
> > From:       Brian Rosen [SMTP:[email-masked]]
> > Sent:       Tuesday, September 07, 1999 12:38
> > To: Blatherwick, Peter [CAR:AT14:EXCH];
> > [email-masked]
> > Subject:    RE: I-D posted: Megaco IP Phone MG 01
> >
> > We have a couple of really fundamental issues here.
> > I'm not sure if you intend this to be part of the
> > "basic" packages.  If not, we can carry on this
> > discussion without a time constraint.  If you do,
> > I think maybe you should reconsider.
> >
> The Megaco IP Phone MG document defines an *application* of the
> Megaco protocol, and  provides a general description of how such
> devices are meant to function, defines such aspects as
> relationships and usage of packages and terminations in that
> application, selects particular options for transport and
> encoding, and so on.  As such, it is needed by designers wanting
> to build such a device or an MGC to control them.  It is
> intended to remain as a separate application-specific document,
> referencing the Megaco Protocol and Generic Packages.
>
> As stated in the top of section 5 "Signal and Event Packages",
> it is intended that the packages we currently define be moved
> into the Generic Packages document for reuse by other
> applications (this work is already underway), and the Megaco IP
> Phone document will be updated to reflect this when the Generic
> Packages document is complete enough and posted for reference.
>
> > The first fundamental issue is whether a profile can
> > decide to eliminate some feature of the protocol which
> > is not considered optional and so labeled in the protocol
> > definition.  While nothing stops any vendor, industry
> > group or other standards bodies from defining a new
> > protocol as a subset/superset/whatever of an IETF or
> > ITU protocol, we generally don't permit subsets as being
> > considered conformant implementations (reminding everyone
> > that we are not the protocol police).
> >
> > EventDescriptors are not optional.  If you believe that
> > they should be, then you should get the document changed
> > so that they are designated optional.  If consensus exists
> > to do that, we should.  If consensus exists that we should
> > not, then you can't define a "profile" that eliminates them,
> > you have to create a new protocol.  You are free to do that,
> > but it's not MEGACO.
> >
> There certainly seem to be some big discrepancies between your
> view and what is currently written.  Please consider the
> following excerpts from the current documents.
>
> In the current MEGACO Requirements document
> "draft-ietf-megaco-reqs-05.txt":
>
> Section 11.2.2 Access Gateway
> "...
> The Protocol must:
> ...
> c.   Not require scripting mechanisms, event buffering, digit
> map storage when implementing restricted function (1-2 line)
> gateways with very limited capabilities.
> "
>
> Section 11.2.7 Restricted Capability Gateway
> "...
> The requirements here may also be applied to small analog
> gateways, and to cable/xDSL modems. See also the section on
> access gateways.
>
> The Protocol must support:
> a.   The ability to provide a scaled down version of the
> protocol. When features of the protocol are not supported, an
> appropriate error message must be sent. Appropriate default
> action must be defined. Where this is defined may be outside the
> scope of the protocol.
> b.   The ability to provide device capability information to the
> MGC with respect to the use of the protocol.
> "
>
> And in the current MEGACO Protocol document
> "MegacoH248v9Chgs.doc":
>
> 6.3.3.1 Add
> "...
> [TerminationID]
> [,MediaDescriptor]
>         Add( TerminationID
>                 [, MediaDescriptor]
>                 [, ModemDescriptor]
>                 [, MuxDescriptor]
>                 [, EventsDescriptor]
>                 [, SignalsDescriptor]
>                 [, DigitMapDescriptor]
>         )
> ... [ snip some unrelated stuff ] ...
>
> The EventsDescriptor parameter is optional.  If present, it
> provides the list of events that should be detected on the
> Termination.
>
> The SignalsDescriptor parameter is optional.  If present, it
> provides the list of signals that should be applied to the
> Termination.
>
> The DigitMapDescriptor parameter is optional.  If present,
> defines a DigitMap definition that may be used in an
> EventsDescriptor.
> "
>
> 6.3.3.2 Modify
> "...
> [TerminationID]
> [,MediaDescriptor]
>         Modify( TerminationID
>                 [, MediaDescriptor]
>                 [, ModemDescriptor]
>                 [, MuxDescriptor]
>                 [, EventsDescriptor]
>                 [, SignalsDescriptor]
>                 [, DigitMapDescriptor]
>         )
> ... [snip some unrelated stuff ] ...
> The remaining parameters to Modify are the same as those to Add.
> The Media Descriptor is optional for Modify.
> "
>
> So, it sure seems to say "optional" for all things we are
> debating (EventsDescriptors, Embedded Descriptors, DigitMaps,
> event buffering, scripting).  And it definitely is required to
> be able to define "scaled down" versions of the protocol
> outside the scope of the protocol itself.
>
> What we specify as a protocol profile is well within what is
> described by the above.  Optional means the MGC can decide, by
> design, not to send a particular parameter to the MGs it is
> interacting with.  The Megaco IP Phone MG application description
> tells the designer which ones they should not send when
> interacting with this particular type of device, and spells out
> how to deal with the side effects of this method of interaction.
> No other applications are affected, only communication between IP
> Phone MGs and their corresponding MGCs, so there is no
> interoperability issue.  This fits the restricted capability
> gateway requirements well (Requirements 11.2.7).
>
> Note that not supporting event buffers (allowed by Requirements
> 11.2.2c) implies not supporting EventsDescriptors, since the two
> go together.  Also, there is no difference that I could find in
> the text between the "optionalness" of buffering, digit maps,
> events descriptors, or embedded descriptors.
>
> So I still fail to see what you are basing your objections on.
>
> [snip]
> > > ...large MG Vs small MG.  IP Phone is definitely a very
> small MG.
> > Small gateways have been a major driving force in the design
> > of the protocol.  There have been some serious compromising done
> > by the "big gateway" folks to make the "little gateway" folks
> > happy, and vice versa.  To come along and demand further changes
> > (and still try to claim that it's MEGACO) is not a good idea IMO.
> >
> > This DOES mean some additional costs.  It should not mean
> > much, and there are quite a few people on the list who think
> > that the compromises made to try to keep one protocol have been
> > appropriate.
> >
> We are not "demanding" changes, we are simply specifying a
> minimalist way to work within the protocol for a particular
> application.  Again, I do not think the usage we specify changes
> the fundamentals of the Megaco protocol, it does not define a
> new protocol, and it certainly does not affect how any other
> applications would work.  Since this pertains to a particular
> application, and is intended to be maintained in a separate
> application-specific document, it fits the protocol requirements
> well.
>
> Lets get over this initial hurdle and move on to the technical
> issues at hand.  If we can agree that this type of profiling is
> indeed allowed for specific applications, I think there are
> actually only a few technical issues remaining.
>
> Regards,
> Peter Blatherwick
>

---

From: Nancy-M Greene <[email-masked]>
Date: Mon, 13 Sep 1999 09:08:23 -0500

Brian Rosen writes:

        <snip>
> appropriate to define that they were not implemented
If we have a profile, we need a place to put it in the protocol - it should
be part of the ServiceChange descriptor.

Nancy

--------------------------------------------------------------------------
Nancy M. Greene
Internet & Service Provider Networks, Nortel Networks
T:514-271-7221 (internal:ESN853-1077) E:[email-masked]

---

From: Tom-PT Taylor <[email-masked]>
Date: Tue, 14 Sep 1999 09:01:13 -0400

On the one hand, your are totally correct in the distinction you make
between different senses of "optional" and how they apply to the issues
under discussion.  On the other, if a generic Megaco MGC were presented with
an MG using the IP Phone profile, the two devices would in principle be
interoperable (assuming all required packages are supported).  The practical
issue, of course, is that the generic MGC would have been implemented to
take advantage of the labour-saving features of the protocol, including
event buffers.  Conclusion: an IP Phone MGC is as special a beast as an IP
Phone MG (and might not be able to grow as large as other MGCs because of
performance issues).

It may be that the IP Phone spec. and anything similar have to be viewed as
new standards, derived from Megaco/H.248 but not identical to it.  Could the
industry stand for such specialization, or is the potential market too small
for anything but generic MGs and MGCs?

> From: Brian Rosen [SMTP:[email-masked]]
> Sent: Monday, September 13, 1999 9:55 AM
> To:   [email-masked]
> 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 10:01:15 -0400

I think that it HAS to be that if an IPPhone doesn't
implement EventDescriptors then, by definition, it's
not MEGACO.  Anyone is free to define a new protocol.

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, plus
several man months of programmer effort.  Is that a
sufficiently high number that subsets are a big problem?
If IPPhones sold for $2.99 it clearly would be.

In the development of the protocol, there were lots and
lots of compromises so that small gateways and big gateways
were both accommodated, and there is no question that this
raised the cost of manufacturing both.  The question is,
by how much?

Clearly, the majority sentiment is, not too much, or there
would have been more demand for a smaller base protocol
with optional features.

Now, you may think that implementing the full protocol
as currently defined, adds $20 to the cost of an IPPhone
compared with the current proposed definition.  If that
were true, small gateways have a problem.  What we need
is a reasonable metric.

Should be possible to do estimates, as there are several
MGCP implementations out there, and the mechanisms at
issue are in MGCP.  If we get someone to estimate the RAM
and ROM required to support these features, we can have a
good engineering discussion on the cost of production.
Of course we need to decide where the threshold of pain is.
It's probably more than $.30, and it's probably less than $20.
What is reasonable today?  I'm guessing $2-4, on the
assumption that we aren't going to see $20 IPPhones real soon.
That's a fair amount of ROM and RAM.

Brian
> From: Tom-PT Taylor [mailto:[email-masked]]
> Sent: Tuesday, September 14, 1999 9:01 AM
> To: [email-masked]

---

From: Peter Blatherwick <[email-masked]>
Date: Tue, 14 Sep 1999 11:53:31 -0500

Tom:

> Phone MG (and might not be able to grow as large as other MGCs because of
Yes, the MGC and the IP Phone MG would be interoperable, since the MGC IP
Phone application would know it is talking to an IP Phone MG, and would
therefore support the appropriate packages and understand the particular
profile.  What would be generic would be the MEGACO protocol stack in the
MGC, and the particular IP Phone application would use it according to the
profile.  This would not affect other applications in the same MGC.

Yes, the IP Phone application in the MGC will, in practice, be separate from
other applications.  It has to be, and always will be.  I do not believe in
the "generic MGC" in the sense of an MGC that knows how to control
absolutely anything.  In practice there will be distinct applications in the
MGC for particular uses: trunking gateways, ATM, cable modem, phone control,
etc are all quite different from each other.  The IP Phone application is a
case of this, but certainly not the only one.

(BTW, I do not believe there will be scaling problems with the approach we
specify, but that's a separate topic.)

> for anything but generic MGs and MGCs?
If you are implying we need to look at a set of application-specific RFCs
which define particular applications of the MEGACO  Protocol, then I
whole-heartedly agree.  That is what we are trying to accomplish.  I believe
this would be a good thing for MEGACO since it would greatly improve
interoperability at the device level and allow truly useful applications of
the protocol to get out in the field far more quickly.

If you mean that IP Phone or other applications would somehow be defined as
not being MEGACO, then I disagree.  They are applications of MEGACO that may
or may not make use of all the protocol features.  See more on this in the
reply to Brian Rosen on this thread.

-- Peter Blatherwick

---

From: Peter Blatherwick <[email-masked]>
Date: Tue, 14 Sep 1999 13:15:23 -0400

Brian:

You wrote:

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.

First of all, its a separate document describing a particular application of
MEGACO.  The usage we specify has no impact on other applications, and is
kept in a separate scope from the MEGACO Protocol itself.  It uses MEGACO in
a particular way, without modifying it.

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.  What we will have is MEGACO protocol stacks
being reused to handle several distinct applications.  PSTN trunking, ATM,
phone control, etc are too different from each other to be written as one
big application.  These applications may share the same box, or come as a
bundled software load, but in practice they will need to be separately
designed.  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.

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).

        > > 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.

And on the cost thing:

        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...)

Make no mistake, the costs are very significant.  "Not much" is always
relative.

--- Peter Blatherwick

---

From: Bob Bell <[email-masked]>
Date: Tue, 14 Sep 1999 14:13:26 -0600

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
<<<

>--- Peter Blatherwick

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