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

From: Peter Blatherwick <[email-masked]>
Date: Sun, 12 Sep 1999 23:55:34 -0400

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: Bob Bell <[email-masked]>
Date: Tue, 14 Sep 1999 10:21:42 -0600

Brian and Peter -

One thing to note in this discussion also is that the controlling processes
for the trunk and station endpoints will in all likelyhood be separate
entities. They may reside within the same host code but they have differing
requirements since there is a difference between station side and trunk
side processing. Profiling the station side should not create a significant
problem for the trunk side process.

Bob Bell

>actually only a few technical issues remaining.

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