[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-blatherwick-megaco-ipphone) 00 01 02 RFC 3054

Internet Engineering Task Force                              Robert Bell
INTERNET DRAFT                                             Cisco Systems
February 29, 2000                             Peter Blatherwick (editor)
Expires August 31, 2000                                  Nortel Networks
<draft-ietf-megaco-ipphone-02.txt>                          Phil Holland
                              Circa Communications (Chair TIA TR-41.3.4)


            Megaco IP Phone Media Gateway Application Profile



Status of this document

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that other groups
may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet- Drafts as reference material
or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.



1.  ABSTRACT

This document specifies a particular application of the Megaco/H.248
Protocol [3] for control of Internet telephones: the Megaco IP Phone
Media Gateway.  The telephone itself is a Media Gateway (MG), controlled
by the Megaco/H.248 Protocol, with application control intelligence
located in the Media Gateway Controller (MGC).  In order to achieve a
high degree of interoperability and design efficiency in such end-user
devices, a consistent architectural approach, a particular organization
of terminations and packages, and a protocol profile are described.  The
approach makes use of existing protocol features and user interface
related packages, and is thus a straight-forward application of the
Megaco/H.248 Protocol.

This document represents the current view from the TIA working group on
VoIP telephone specification [1], TIA TR-41.3.4, with the intent of
using this as part of its "whole device" specification as an optional
method of device control.


Blatherwick, Bell, Holland                                      [Page 1]

Internet Draft            Megaco IP Phone MG            29 February 2000


2.  INTRODUCTION

Industry feedback has made it clear that interoperability and acoustic
performance of Internet telephones is key to the rapid and extensive
commercialization of these products.  To facilitate this, the TIA has
established working group TR-41.3.4 to develop a standard for VoIP
telephones.  The TR-41.3.4 working group has included the "whole device"
within the scope of the standard, so a full range of requirements
including acoustic performance, protocols, methods for powering and
safety are provided.  Where possible, the requirements are based on
existing standards, which are included by reference.

The TIA TR-41.3.4 working group has also recognized that its proposed
standard must enable creative application of the equipment, encourage
the development of new capabilities and allow for high levels of product
customization.  To achieve this, peer to peer architectures that are
based on protocols such as H.323 or SIP and master/slave architectures
such as Megaco/H.248 Protocol are both necessary and complementary.

In support of the Megaco/H.248 Protocol development effort, the TR-
41.3.4 working group has considered product enabling issues and
requirements, and has developed an approach to use the Megaco/H.248
Protocol for Internet telephone device control.  This document
represents the working group's current view.

This document covers the general requirements of the Megaco IP Phone
application (section 3), architectural approach and MG organization
(section 4), details of specific termination types used and packages
supported by each (section 5), and the Megaco IP Phone protocol profile
(section 6).

[[ Editorial comments and issues are marked like this. ]]


3.  GENERAL REQUIREMENTS

The following general requirements were identified to drive the Megaco
IP Phone design [1]:

1.  The Megaco IP Phone must meet the basic needs of the business user
    from day one;

2.  Provide a path for rapid expansion to support sophisticated business
    telephony features;

3.  Flexibility to allow for a very wide range of telephones and similar
    devices to be defined, from very simple to very feature rich;

4.  Simple, minimal design;



Blatherwick, Bell, Holland                                      [Page 2]

Internet Draft            Megaco IP Phone MG            29 February 2000


5.  Allow device cost to be appropriate to capabilities provided;

6.  Packages and termination types must have characteristics that enable
    reliability;

7.  The IP Phone MG shall meet the appropriate Megaco/H.248 Protocol
    requirements as provided in the Megaco Requirements document [2] and
    be a straight-forward application of the Megaco/H.248 Protocol [3].


4.  ARCHITECTURE DESCRIPTION

The following subsections describe the general design approach and
organization of the Megaco IP Phone MG.

4.1.  Design Approach

Design intent of the Megaco IP Phone is to keep it determinedly simple
while providing required support for fully featured business telephones
and the flexibility to allow for a very wide range of telephone
configurations and similar appliances.

The approach to achieve this goal is to provide a very simple and direct
master/slave control model in which very little feature intelligence is
required in the end device.  This design intent matches the Megaco/H.248
Protocol approach well.

It is important to note that additional functionality, built-in feature
capability or system-specific optimization can easily be provided, at
the option of the manufacturer, by defining additional termination
types, event/signal packages, or providing built-in application
capability.  This document defines the minimal design.

4.2.  Termination / Package Organization

As shown in Figure 1 below, the Megaco IP Phone is organized as a Media
Gateway (MG) that consists of a User Interface termination and a set of
Audio Transducer terminations.

Each Audio Transducer termination represents an individually
controllable audio input/output element of the telephone device, such as
Handset, Handsfree, Headset, etc.  By separating each audio element as a
distinct termination, more flexible applications can be easily
implemented, such as paging, group listening, and so on.  Since this is
actually only the logical view of the device, represented by protocol,
it is also quite possible to simplify representation of the device by
hiding all available audio input/outputs behind a single Audio
Transducer termination, for example the Handset, and implement control
of multiple real input/outputs locally inside the device.



Blatherwick, Bell, Holland                                      [Page 3]

Internet Draft            Megaco IP Phone MG            29 February 2000



                            +---------------+
                            |               |
                            |      MGC      |
                            |               |
                            +---------------+
                                    ^ \ \ \
                                    |
                                    v
              +---------------------------------------------+
              |                                             |
              |   Megaco IP Phone MG                        |
              |   ==================      Audio Transducer  |
              |                           Terminations:     |
              | Audio context(s):         + - - - - - - - + |
              | +---------------------+     +-----------+   |
              | |     Context A       |   | | Handset   | | |
              | |                     |     +-----------+   |
         RTP  | |  +-----+   +-----+  |   | +-----------+ | |
     <--------+-+->| Tr  |   | Ta2 |<-+-----| Handsfree |   |
       audio  | |  +-----+   +-----+  |   | +-----------+ | |
      stream  | |                     |     +-----------+   |
              | +---------------------+   | | Headset   | | |
              |                             +-----------+   |
              |                           |               | |
              |                              ETC.           |
              |                           + - - - - - - - + |
              |                                             |
              |  +----------------------------------------+ |
              |  | User Interface Termination             | |
              |  | +--------------+      +--------------+ | |
              |  | | Text Display |      | Keypad       | | |
              |  | +--------------+      +--------------+ | |
              |  | +--------------+      +--------------+ | |
              |  | | Softkeys     |      | Indicators   | | |
              |  | +--------------+      +--------------+ | |
              |  | +--------------+                       | |
              |  | | Function Keys|      ETC.             | |
              |  | +--------------+                       | |
              |  +----------------------------------------+ |
              +---------------------------------------------+

            Figure 1) Megaco IP Phone Termination / Package Model









Blatherwick, Bell, Holland                                      [Page 4]

Internet Draft            Megaco IP Phone MG            29 February 2000


All non-audio user interface elements are associated with the User
Interface termination.  This special termination includes packages to
implement all user interaction with the telephone user interface,
including Function Keys, Indicators, the Dialpad, etc, as appropriate
for the specific device capabilities (within constraints given in the
section on User Interface Termination).  This grouping of user interface
elements behind a well-know termination greatly simplifies audits to
determine actual device configuration, and reduces the number of
terminations involved in representing user interface.

Several - potentially thousands - of Megaco IP Phone MGs may be
controlled by a single Media Gateway Controller (MGC).  This is
distinguished from the organization between traditional analog or PBX
telephones behind an IP network, where the MGC would control an MG which
in turn controls the collection of telephone devices in question.  In
the case of a Megaco IP Phone MG, the MG directly implements the media
terminations like handset, handsfree and headset, and the user
interface.  In this case, the Megaco IP Phone itself is the MG.

[[Editor's Note: Some historical background is in order here.  The
original proposal for organization of terminations (version 00 of this
I-D) placed each user interface element in a separate termination;
objections were raised to the effect of "too many terminations".  The
second proposal moved all user interface elements into the ROOT
termination; objections were raised to the effect of "that's not the
intent of ROOT".  The current proposal uses a separate termination for
all user interface and is really a compromise between the previous
proposals.  Any of the three proposals would work, and each has
advantages.]]

4.3.  Control Interaction

To provide control of audio paths, Audio Transducer terminations are
manipulated using contexts in the normal way, by sending Add, Move,
Subtract and Modify commands addressed to the specific terminations
being manipulated.  For example creating a context (Context A)
containing an RTP termination (Tr) and a Handset Audio Transducer
termination (Ta1) creates a voice connection to/from the handset.
Moving a Handsfree Audio Transducer termination (Ta2) into the context,
and removing the Handset, sets up a handsfree conversation.  This
situation is shown in Figure 1.  See the section on Audio Transducer
Termination Type for further details on specific package support.

User input elements, such as Keypad or Function Keys, generate events
through Notify commands sent from the User Interface termination of the
Megaco IP Phone MG to the controlling MGC for handling.  These events
are according to the specific set of packages supported by the User
Interface termination of the device.  See the section on User Interface
Termination for further details on specific package support.



Blatherwick, Bell, Holland                                      [Page 5]

Internet Draft            Megaco IP Phone MG            29 February 2000


User output elements such as the Text Display or Indicators are
controlled by signals sent by the MGC, addressed to the User Interface
termination of the Megaco IP Phone MG, generally as part of a Modify
command, using syntax defined in the corresponding package.  Since the
User Interface termination cannot be part of any context, Add, Move and
Subtract commands are not valid.  See the section on User Interface
Termination for further details on specific package support.

Some elements, for example Softkeys, have both user input and output
aspects, so both react to signals and generate events as above.

4.4.  Capability Discovery

At startup or service change, the Megaco IP Phone MG identifies itself
to its controlling MGC as being a Megaco IP Phone class of device by use
of the IPPhone protocol profile.  This is the first and most important
stage of capability discovery, and implicitly provides a great deal of
the necessary information in a single step.  Thereafter, the MGC can
make a large number of assumptions regarding organization and behavior
of the MG.  See the section on Protocol Profile for further details.

Device capabilities, including the list of terminations and supported
packages for each, can be queried through the AuditValue command.
Wildcarded AuditValue commands targeted at the whole MG (i.e. addressed
to ContextID=Null, TerminationID=ALL) can return the list of all
terminations including Audio Transducer terminations supported and the
User Interface termination.  Further AuditValues commands on individual
terminations provide further details of package support for each.  This
allows the MGC to directly discover both the capability of the user
interface supported by the MG, through audits addressed to the User
Interface termination, as well as specific audio input/outputs
available.

[[Editor's Note: Audit needs to mesh with naming conventions for each
termination.  See related issues in sections on User Interface
Termination and Audio Transducer Termination Type.]]

Since the structure of the Megaco IP Phone MG is well known in advance,
by virtue of the protocol profile, audits can be efficiently directed at
discovering only what additional information is required by the MGC,
generally only what User Interface elements and audio input/outputs are
available.  It is not necessary for the MGC application to attempt to
infer function from supported packages within a random collection of
terminations, and a great deal of behavior common to all Megaco IP Phone
MGs can simply be assumed.  This pre-determined organization and
behavior therefore greatly reduces design complexity of both MG and MGC,
and greatly improves interoperability.





Blatherwick, Bell, Holland                                      [Page 6]

Internet Draft            Megaco IP Phone MG            29 February 2000


5.  TERMINATION TYPES

The termination types defined for use in the Megaco IP Phone MG are:

*  User Interface (implements user interface);

*  Audio Transducer (implements audio input/output to the user, and
   potentially appears as several individual terminations corresponding
   to individual audio input/outputs on the actual device);

*  RTP (transport of audio streams over IP).

These termination types represent minimal capabilities to support fully
featured business telephones.  Additional termination types can of
course be defined to extend these capabilities.

The following subsections describe requirements and constraints on each
type in further detail.

5.1.  User Interface Termination

The User Interface termination represents the Megaco IP Phone MG user
interface elements.  Megaco IP Phone MGs MUST support exactly one User
Interface termination.

[[Editor's Note: Naming conventions need to be defined to identify the
User Interface termination for command addressing and during Audit.]]

The User Interface termination cannot be part of any context, hence Add,
Move and Subtract commands are invalid for this termination.

The User Interface termination MAY support the following packages,
defined in Megaco/H.248 Protocol Annex G "User Interface Elements and
Actions Packages for Determination" [4].
   __________________________________________________________
  | Package           | Name   | Support in User Interface   |
  |                   |        | termination                 |
  |___________________|_______ |_____________________________|
  | Text Display      | dis    | Optional                    |
  | Keypad            | kp     | Optional                    |
  | Function Key      | kf     | Optional                    |
  | Indicator         | ind    | Optional                    |
  | Softkey           | ks     | Optional                    |
  | Ancillary Input   | anci   | Optional                    |
  |___________________|________|_____________________________|







Blatherwick, Bell, Holland                                      [Page 7]

Internet Draft            Megaco IP Phone MG            29 February 2000


Note: The reasoning to make all packages optional in the User Interface
termination is to allow maximum flexibility to create a very broad range
of Internet telephones and similar devices.  For example, anything from
a simple hotel lobby phone (handset and hookswitch only), to
conferencing units (handsfree unit and one or two buttons) to fully
featured business telephones (display, rich set of keys and indicators,
both handset and handsfree, etc) could be designed.

5.2.  Audio Transducer Termination Type

The Audio Transducer terminations are used to control voicepath
input/output to/from the end user of the device.  Megaco IP Phone MGs
MUST support at least one Audio Transducer termination, which MAY be
chosen from the following well known types:
*  Handset,
*  Handsfree,
*  Headset,
*  Microphone (input only),
*  Speaker (output only).

[[Editor's Note: Naming conventions need to be defined to identify
particular Audio Transducer terminations for command addressing and
during Audit.]]

All Audio Transducer type terminations MUST support the following
packages, defined in Megaco/H.248 Protocol, Annex E [3].
   ____________________________________________________________
  | Package             | Name   | Support in Audio Transducer |
  |                     |        | terminations                |
  |_____________________|_______ |_____________________________|
  | Basic DTMF Generator| dg     | Mandatory                   |
  | Call Progress Tone  | cg     | Mandatory                   |
  |   Generator         |        |                             |
  |_____________________|________|_____________________________|


5.3.  RTP Termination Type

Megaco IP Phone MGs MUST support at least one RTP network termination in
order to support audio streams to/from the device.  Refer to
Megaco/H.248 Protocol, Annex E.12 [3] for details.











Blatherwick, Bell, Holland                                      [Page 8]

Internet Draft            Megaco IP Phone MG            29 February 2000

6.  PROTOCOL PROFILE

The following subsections provide details of the protocol profile used
between Megaco IP Phone MG and controlling MGC.  This includes
constraints on the transport and encoding methods used, constraints on
protocol usage, and an implicit application-level agreement between the
Megaco IP Phone MG and its controlling MGC on organization and behavior
of the MG.

Use of a this profile greatly simplifies assumptions necessary by the
MGC regarding MG organization, thereby reducing complexity and cost of
both MG and MGC, and improves interoperability for the specific Megaco
IP Phone application.

6.1.  Profile Descriptor and Usage

Profile name: "IPPhone"
Version: 1

The Megaco/H.248 Protocol [3] describes startup and service change
procedures in detail, including use of profiles.

In brief, the above profile name and version are supplied by the Megaco
IP Phone MG on startup or at service change, in the
ServiceChangeDescriptor parameter of the ServiceChange command, issued
to the controlling MGC as part of the registration procedure.  In
response, the MGC may 1) accept control by acknowledging the Service
Change, 2) pass control to a different MGC by replying with a new MGC to
try, or 3) refuse control entirely by rejecting the Service Change.  If
MGC control is refused, the Megaco IP Phone MG may attempt registration
with other MGCs in its list of MGCs to try.

Once the controlling MGC accepts the profile, both it and the Megaco IP
Phone MG become bound by the profile rules and protocol constraints
described in subsequent subsections as well as Megaco IP Phone
termination/package organization and behavior rules described in
previous sections of this document.  Thereafter, any protocol use
outside these rules is considered an error.

6.2.  Transport

Megaco IP Phone MGs MUST support Application Layer Framing (ALF) over
UDP transport, as specified in the Megaco/H.248 Protocol document [3].

6.3.  Message Encoding

Megaco IP Phone MGs MUST support text encoding of the protocol, as
specified in the Megaco/H.248 Protocol document [3].




Blatherwick, Bell, Holland                                      [Page 9]

Internet Draft            Megaco IP Phone MG            29 February 2000


6.4.  Protocol Usage

[[Editor's Note: Specific rules for definition of profiles of the
Megaco/H.248 Protocol are not currently defined.  This subsection
describes a subset profile of the Megaco/H.248 Protocol.  We believe
there is a very strong need for such a subset approach in minimalist
applications such as Megaco IP Phone and others, which are cost-
sensitive in the extreme.  Several features of Megaco/H.248 Protocol are
not required for operation of this application, and are not expected to
be used in practice, so it is very desirable to strip them out of the MG
side to reduce complexity/cost to an absolute minimum.  Since both MG
and MGC are bound by an application-specific protocol profile, this is
highly beneficial to interoperability of this application, and yet does
not affect interoperability of other applications.  We believe the
Megaco Requirements [2] allow for this.  This needs further discussion
and decision, which was previously deferred until after completion of
Megaco/H.248 Protocol version 1.  This subsection is included here to
provide a basis for that discussion.]]

Megaco IP Phone is intended to allow for an absolutely minimal design,
with minimum complexity in the MG.  As such, by default, it uses an
absolutely minimal subset of the Megaco/H.248 Protocol and a very
simplistic method for event passing.

It is important to note that implementers are permitted to provide more
than this minimal operation, but MGCs designed to interact with Megaco
IP Phone MGs MUST NOT assume more than the default subset operation.
However MGCs MAY query the MG (using Audits) to discover extended
capabilities.  See Extended Capability below.

The below subset profile description applies uniformly to all
terminations, packages and commands within a Megaco IP Phone MG.  Unless
specifically stated below, operation is otherwise exactly as specified
in the Megaco/H.248 Protocol documentation [3].

6.4.1.  Default Parameter Usage

By default, the following protocol parameters are not supported (i.e.
are not allowed) in all commands sent to the Megaco IP Phone MG.
*  EventsDescriptors,
*  Embedded EventsDescriptors,
*  Embedded SignalsDescriptors,
*  DigitMapDescriptors,
*  EventBufferControl property of TerminationStateDescriptors, part of
   MediaDescriptor.







Blatherwick, Bell, Holland                                     [Page 10]

Internet Draft            Megaco IP Phone MG            29 February 2000


If such a parameter is sent to a Megaco IP Phone MG which is not
extended to support that parameter, an error = 501 (Not Implemented) is
returned and the command fails as per the Megaco/H.248 Protocol [3]
section 7.3 (Command Error Codes).  If a given MG is extended to support
the parameter (as below), the command either succeeds or fails with the
appropriate error code as defined for Megaco/H.248 Protocol.

6.4.2.  Default Event Handling

By default, all events detected by the Megaco IP Phone MG are
immediately returned to the controlling MGC via a Notify command.  This
begins immediately after completion of registration with its MGC.

The effect of this is as if the Megaco IP Phone MG was sent
EventsDescriptor = ALL at initialization.  Furthermore, since the
EventBufferControl property is not used, events shall always be reported
as they occur as if a TerminationStateDescriptor containing
EventBufferControl = OFF (the default value) had been accepted at
initialization.

6.4.3.  Extended Capability

Audits MAY be used by the MGC to discover if a particular Megaco IP
Phone MG supports capabilities beyond the default parameter and state
handling described in the above subsections.

Extended capabilities, if implemented, MUST apply uniformly to all
terminations, packages and commands within the specific Megaco IP Phone
MG (e.g. if any command on any termination can accept EventsDescriptors,
for example, then all must do so).  Thus, extended capability audits are
required only at the ROOT MG level.

[[Editors Note: It is unclear how to specify parameter usage extended
beyond the profile-specific subset described above.  Use of AuditValue
at the ROOT level seems most appropriate for this, but no specific
syntax exists.]]
















Blatherwick, Bell, Holland                                     [Page 11]

Internet Draft            Megaco IP Phone MG            29 February 2000


7.  REFERENCES

1.  TIA TR41.3.4, PN-4462, Performance and Interoperability Requirements
    for Voice-over-IP (VoIP) Feature Telephones (soon to be published as
    TIA Interim Standard).

2.  Media Gateway Control Protocol Architecture and Requirements,
    draft-ietf-megaco-reqs-10.txt, Greene, Ramalho, Rosen,
    http://www.ietf.org/internet-drafts/draft-ietf-megaco-reqs-10.txt.

3.  Megaco Protocol, draft-ietf-megaco-protocol-07.txt, Cuervo, Hill, et
    al., http://www.ietf.org/internet-drafts/draft-ietf-megaco-protocol
    -07.txt

4.  ITU SG16, H.248 Annex G: User Interface Elements and Actions
    Packages for Determination




































Blatherwick, Bell, Holland                                     [Page 12]

Internet Draft            Megaco IP Phone MG            29 February 2000


8.  ADDRESS INFORMATION

             Bob Bell
             Cisco Systems Inc.
             640 N. Main St.
             Suite 2246
             North Salt Lake, Ut 84054
             USA
             Tel: (801) 294-3034
             Email: rtbell@cisco.com

             Peter Blatherwick (editor)
             Nortel Networks
             P.O. Box 3511, Stn C
             Ottawa, Ontario,
             Canada K1Y 4H7
             Tel: (613) 763-7539
             Email: blather@nortelnetworks.com

             Phil Holland
             Circa Communications Ltd.
             1000 West 14th Street
             North Vancouver, British Columbia,
             Canada V7P 3P3
             Tel: (604) 924-1742
             phil.holland@circa.ca


























Blatherwick, Bell, Holland                                     [Page 13]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/