One document matched: draft-ietf-megaco-ipphone-03.txt-30302.txt
Differences from 03.txt-02.txt
Internet Engineering Task Force Robert Bell
INTERNET DRAFT Cisco Systems
August 25, 2000 Peter Blatherwick (Editor)
Expires February 25, 2001 Nortel Networks
Document: draft-ietf-megaco-ipphone-03.txt Phil Holland
Category: Informational 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.
ABSTRACT
This document specifies a particular application of the Megaco/H.248
Protocol [3] for control of Internet telephones and similar appliances:
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). 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 [4], 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 25 August 2000
1. 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).
2. CONVENTIONS
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD
NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document,
are to be interpreted as described in RFC 2119 [5].
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;
Blatherwick, Bell, Holland [Page 2]
Internet Draft Megaco IP Phone MG 25 August 2000
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;
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 implementer, by defining additional Termination
types, Event/Signal Packages, or providing built-in application
capability. This document defines the minimal design only.
4.2. General Structure
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.
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
Blatherwick, Bell, Holland [Page 3]
Internet Draft Megaco IP Phone MG 25 August 2000
terminations like handset, handsfree and headset, as well as the user
interface. In this case, the Megaco IP Phone itself is the MG.
+---------------+
| |
| 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 25 August 2000
4.3. Termination / Package Organization
As shown in Figure 1, 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.
All non-audio user interface elements are associated with the User
Interface Termination. This special Termination supports 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). The User Interface Termination
cannot be placed in any Context. 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.
In addition, TerminationID naming conventions are provided to identify
specific Terminations within the Megaco IP Phone MG and group them into
related sets. These conventions use a set of well known identifier
names to specify the individual Terminations, for example the User
Interface Termination ("ui"), the Handset Audio Transducer ("at/hs"), or
the Handsfree Audio Transducer ("at/hf"). This specific naming is
important in this application, especially for the Audio Transducer
Terminations, since the real input/output elements to which they map on
the physical device have very different functional significance to the
end-user, yet they may be represented in the protocol using exactly the
same sets of Packages. Naming conventions allow the controlling MGC to
distinguish this end-user meaning without specific advance knowledge of
physical device configuration and without the requirement to provide
different Packages for each audio input/output type.
Using these same TerminationID naming conventions in combination with
wildcards, the MGC application can target commands to groups of related
Terminations, for example the collection of all Audio Transducer
Terminations ("at/*"). This is especially useful during the discover
phase, for example to efficiently Audit all available Audio Transducer
Terminations, and to efficiently send commands to a set of related
Terminations in a single command, for example to simultaneously Subtract
all Audio Transducer Terminations from a particular Context. Further
information on TerminationID naming conventions and their use can be
found under the sections on Control Interaction and Capability Discovery
(next two subsections) and under Termination Types.
Blatherwick, Bell, Holland [Page 5]
Internet Draft Megaco IP Phone MG 25 August 2000
4.4. 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 Types for further details on specific Package support
requirements.
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 Type for further details on specific Package support
requirements.
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 Packages. Since the
User Interface Termination cannot be part of any context, Add, Move and
Subtract commands sent to it are not valid. See the section on User
Interface Termination Type for further details on specific Package
support requirements.
Some elements, for example Softkeys, have both user input and output
aspects, so both react to Signals and generate Events as above.
The TerminationID naming conventions may be used to target commands to
specific Terminations by well known name, for example to Add the
Handsfree Audio Transducer Termination ("at/hf") to a Context. The
naming conventions in combination with wildcards may be used to
efficiently send commands to groups of related Terminations, for example
to simultaneously Subtract all Audio Transducer Terminations ("at/*")
from a particular Context.
4.5. 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
Blatherwick, Bell, Holland [Page 6]
Internet Draft Megaco IP Phone MG 25 August 2000
of the MG. See the section on IPPhone Protocol Profile for further
details of ServiceChange operation.
Device capabilities, including the list of all Terminations and
supported Packages for each, are queried through the AuditValue command.
Wildcarded AuditValue commands targeted at the whole MG (i.e. addressed
to ContextID=Null, TerminationID=ALL) return the list of all
Terminations, including the User Interface Termination and all supported
Audio Transducer Terminations. Since the returned TerminationIDs use
well known identifier names, the MGC can derive the specific audio
input/output elements available on the physical device, and their
intended purpose. Further AuditValues commands on individual named
Terminations provide further details of each, for example for the MGC to
query user interface support Packages available on the User Interface
Termination ("ui"). TerminationID naming conventions in combination
with wildcards can be used with AuditValues commands to query specific
Package support for the collection of all Audio Transducer Terminations
("at/*").
Since the structure of the Megaco IP Phone MG is well known in advance,
by virtue of the IPPhone Protocol Profile, audits can be efficiently
directed at discovering only what additional information is required by
the MGC. Thus the MGC is able to efficiently and unambiguously discover
both the specific user interface capabilities and the supported audio
input/outputs of the Megaco IP Phone MG, without specific advance
knowledge of physical device configuration. It is not necessary for the
MGC 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.
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 physical device);
* RTP (transport of audio streams over IP).
These Termination types represent minimal capabilities to support fully
featured business telephones. Additional Termination types can be
defined to extend these capabilities.
Blatherwick, Bell, Holland [Page 7]
Internet Draft Megaco IP Phone MG 25 August 2000
The following subsections describe requirements and constraints on each
type in further detail.
5.1. User Interface Termination Type
The User Interface Termination represents the Megaco IP Phone MG user
interface elements. Megaco IP Phone MGs MUST support exactly one User
Interface Termination.
TerminationID of the User Interface Termination MUST be "ui", used for
both command addressing and command response return. ABNF text encoding
for this MUST be as described in Megaco/H.248 Protocol Appendix B.1 [3].
Note: If ASN.1 binary encoding is used (OPTIONAL in this specification),
TerminationID for the User Interface Termination MUST be encoded as
described in Megaco/H.248 Protocol Appendix A.1 [3], with alphabetic
characters of the identifier given above mapping to the equivalent octet
string in the ASN.1 encoding.
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 H.248 Annex G: "User Interface Elements
and Actions Packages "[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 |
|___________________|________|_____________________________|
Additional Packages not listed above MAY also be provided where these
are defined to extend to additional user interface elements.
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.
Blatherwick, Bell, Holland [Page 8]
Internet Draft Megaco IP Phone MG 25 August 2000
5.2. Audio Transducer Termination Types
The Audio Transducer Terminations are used to control audio
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 (with identifier name):
* Handset ("hs") -- input/output,
* Handsfree ("hf") -- input/output,
* Headset ("ht") -- input/output,
* Microphone ("mi") -- input only,
* Speaker ("sp") -- output only.
TerminationIDs of the Audio Transducer Terminations MUST be of the form
"at/<name>", where <name> is the 2 character identifier listed above,
used for both command addressing and command response return. If more
than one Audio Transducer Termination of a particular type is
implemented, the TerminationIDs of each MUST be of the form
"at/<name>/<num>", where <num> is a 2 digit index number in hexadecimal
format beginning at 01. Examples of valid TerminationIDs include:
"at/hs" (handset), "at/mi/02" (microphone 2), "at/*" (all audio
input/outputs). ABNF text encoding for this MUST be as described in
Megaco/H.248 Protocol Appendix B.1 [3].
Note: If ASN.1 binary encoding is used (OPTIONAL in this specification),
TerminationIDs and wildcards MUST be encoded as described in
Megaco/H.248 Protocol Appendix A.1 [3], with alphabetic characters of
the identifiers given above mapping to octet sub-strings in the ASN.1
encoding and the'/' character not used.
Additional Audio Transducer Termination types MAY also be defined by the
implementer, however well know identifier names for these are outside
the scope of this specification.
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 | REQUIRED |
| Call Progress Tones | cg | REQUIRED |
| Generator | | |
|_____________________|________|_____________________________|
Additional Packages not listed above MAY also be provided where
applicable to audio input/output functions.
Blatherwick, Bell, Holland [Page 9]
Internet Draft Megaco IP Phone MG 25 August 2000
5.3. RTP Termination Type
Megaco IP Phone MGs MUST support at least one RTP Termination in order
to support audio streams to/from the device, as defined in Megaco/H.248
Protocol Annex E.12 [3].
No special TerminationID naming convention is defined for RTP
Terminations as part of this specification.
6. IPPHONE PROTOCOL PROFILE
The following subsections provide details of the IPPhone Protocol
Profile, used between Megaco IP Phone MGs and their controlling MGCs.
This includes implicit application-level agreements between the Megaco
IP Phone MG and its controlling MGC on organization and behavior of the
MG, types of Terminations used and the specific minimum Package support
for each, and specific minimum selections on the transport and encoding
methods used.
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. Since the Profile is specific to the Megaco IP
Phone MG, no other applications of Megaco/H.248 Protocol are affected.
It is important to note that the IPPhone Profile specifies minimum
functionality only, for interoperability purposes. Additional
Termination types, Package support, transport or encoding methods, or
other capabilities MAY be added at the discretion of the implementer
within the general structure described.
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.
Blatherwick, Bell, Holland [Page 10]
Internet Draft Megaco IP Phone MG 25 August 2000
Once a controlling MGC accepts the IPPhone Profile, both it and the
Megaco IP Phone MG become bound by the Profile rules and 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 Termination Organization and Package Support
Termination organization, required Termination types, and the specific
Packages supported by each MUST be as described in sections 4 - 5 of
this document.
Note that additional Termination types and Package support MAY also be
provided within the general structure described.
6.3. Transport
Megaco IP Phone MGs MUST support Application Layer Framing (ALF) over
UDP transport, as specified in the Megaco/H.248 Protocol Appendix D.1
[3].
Note that this does not imply that the Megaco IP Phone MG cannot support
other transport methods as well. TCP transport is OPTIONAL, but if used
MUST conform to Megaco/H.248 Protocol Appendix D.2 [3].
6.4. Message Encoding
Megaco IP Phone MGs MUST support ABNF text encoding of the protocol, as
specified in the Megaco/H.248 Protocol Appendix B [3].
Note that this does not imply that the Megaco IP Phone MG cannot support
ASN.1 binary encoding as well. ASN.1 binary encoding is OPTIONAL, but
if used MUST conform to Megaco/H.248 Protocol Appendix A [3].
7. SECURITY CONSIDERATIONS
The Megaco IP Phone Media Gateway Application Profile adds no new
security issues beyond those endemic to all applications of Megaco/H.248
Protocol [3].
Blatherwick, Bell, Holland [Page 11]
Internet Draft Megaco IP Phone MG 25 August 2000
8. REFERENCES
[1] TIA/EIA, IS-811, Performance and Interoperability Requirements
for Voice-over-IP (VoIP) Feature Telephones,
http://www.tiaonline.org/standards/ip/voip/tia-eia-is-811-final.pdf
[2] IETF, RFC 2805, Media Gateway Control Protocol Architecture and
Requirements, Greene, Ramalho & Rosen,
http://www.rfc-editor.org/rfc/rfc2805.txt
[3] ITU-T SG-16, Recommendation H.248, Gateway Control Protocol (to
be published), also available as draft-ietf-megaco-merged-01.txt
(to be published as RFC), Rosen et al.,
http://www.ietf.org/internet-drafts/ draft-ietf-megaco-merged-
01.txt
[4] ITU-T SG16, H.248 Annex G: User Interface Elements and Actions
Packages (currently in Pre-Decision White Document form), also
available as draft-ietf-megaco-h248g-00.txt (currently in IETF Last
Call), Brown & Blatherwick,
http://www.ietf.org/internet-drafts/draft-ietf-megaco-h248g-00.txt
[5] IETF, RFC 2119, BCP 14, Key words for use in RFCs to Indicate
Requirement Levels, Bradner,
http://www.rfc-editor.org/rfc/rfc2119.txt
Blatherwick, Bell, Holland [Page 12]
Internet Draft Megaco IP Phone MG 25 August 2000
9. 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
Email: phil.holland@circa.ca
Blatherwick, Bell, Holland [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-24 07:42:30 |