As per Relevance of the word termination, we have this rfc below:
Network Working Group P. Blatherwick (Editor
Request for Comments: 3054 Nortel
Category: Informational R.
Cisco
P.
Circa
(Chair TIA TR-41.3.4)
January 2001
Megaco IP Phone Media Gateway Application
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document specifies a particular application of the Megaco/H.248
Protocol for control of Internet telephones and similar appliances
the Megaco IP Phone Media Gateway. The telephone itself is a
Gateway (MG), controlled by the Megaco/H.248 Protocol,
application control intelligence located in the Media
Controller (MGC). To achieve a high degree of interoperability
design efficiency in such end-user devices, a
architectural approach, a particular organization of Terminations
Packages, and a Protocol Profile are described. The approach
use of existing Protocol features and user interface
Packages, and is thus a straight-forward application of
Megaco/H.248 Protocol
1.
This document represents the current view from the TIA working
on VoIP (Voice over IP) 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
Industry feedback has made it clear that interoperability
acoustic performance of Internet telephones is key to the rapid
extensive commercialization of these products. To facilitate this
the TIA has established working group TR-41.3.4 to develop a
Blatherwick, et al. Informational [Page 1]
RFC 3054 Megaco IP Phone Media GW Application Profile January 2001
for VoIP telephones. The TR-41.3.4 working group has included
"whole device" within the scope of the standard, so a full range
requirements including acoustic performance, protocols, methods
powering and safety are provided. Where possible, the
are based on existing standards, which are included by reference
The TIA TR-41.3.4 working group has also recognized that its
standard must enable creative application of the equipment,
the development of new capabilities and allow for high levels
product customization. To achieve this, peer to peer
that are based on protocols such as H.323 or SIP and master/
architectures such as Megaco/H.248 Protocol are both necessary
complementary
In support of the Megaco/H.248 Protocol development effort, the TR
41.3.4 working group has considered product enabling issues
requirements, and has developed an approach to use the Megaco/H.248
Protocol for Internet telephone device control. This
represents the working group's current view
This document covers the general requirements of the Megaco IP
application (section 3), architectural approach and MG
(section 4), details of specific Termination types used and
supported by each (section 5), and the Megaco IP Phone
Profile (section 6).
2.
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in
document, are to be interpreted as described in RFC 2119 [5].
3. General
The following general requirements were identified to drive
Megaco IP Phone design [1]:
1. The Megaco IP Phone must meet the basic needs of the business
from day one
2. Provide a path for rapid expansion to support
business telephony features
3. Flexibility to allow for a very wide range of telephones
similar devices to be defined, from very simple to very
rich
4. Simple, minimal design
Blatherwick, et al. Informational [Page 2]
RFC 3054 Megaco IP Phone Media GW Application Profile January 2001
5. Allow device cost to be appropriate to capabilities provided
6. Packages and Termination types must have characteristics
enable reliability
7. The IP Phone MG shall meet the appropriate Megaco/H.248
requirements as provided in the Megaco Requirements document [2]
and be a straight-forward application of the Megaco/H.248
[3].
4. Architecture
The following subsections describe the general design approach
organization of the Megaco IP Phone MG
4.1. Design
Design intent of the Megaco IP Phone is to keep it
simple while providing required support for fully featured
telephones and the flexibility to allow for a very wide range
telephone configurations and similar appliances
The approach to achieve this goal is to provide a very simple
direct master/slave control model in which very little
intelligence is required in the end device. This design
matches the Megaco/H.248 Protocol approach well
It is important to note that additional functionality, built-
feature capability or system-specific optimization can easily
provided, at the option of the implementer, by defining
Termination types, Event/Signal Packages, or providing built-
application capability. This document defines the minimal
only
4.2. General
As shown in Figure 1 below, the Megaco IP Phone is organized as
Media Gateway (MG) that consists of a User Interface Termination
a set of Audio Transducer Terminations
Several - potentially thousands - of Megaco IP Phone MGs may
controlled by a single Media Gateway Controller (MGC). This
distinguished from the organization between traditional analog or
telephones behind an IP network, where the MGC would control an
which in turn controls the collection of telephone devices
question. In the case of a Megaco IP Phone MG, the MG
Blatherwick, et al. Informational [Page 3]
RFC 3054 Megaco IP Phone Media GW Application Profile January 2001
implements the media terminations like handset, handsfree
headset, as well as the user interface. In this case, the Megaco
Phone itself is the MG
+---------------+
| |
| MGC |
| |
+---------------+
^ \ \ \
|
+---------------------------------------------+
| |
| 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
Blatherwick, et al. Informational [Page 4]
RFC 3054 Megaco IP Phone Media GW Application Profile January 2001
4.3. Termination / Package
As shown in Figure 1, each Audio Transducer Termination represents
individually controllable audio input/output element of the
device, such as Handset, Handsfree, Headset, etc. By separating
audio element as a distinct Termination, more flexible
can be easily implemented, such as paging, group listening, and
on. Since this is actually only the logical view of the device
represented by protocol, it is also quite possible to
representation of the device by hiding all available
input/outputs behind a single Audio Transducer Termination,
example the Handset, and implement control of multiple
input/outputs locally inside the device
All non-audio user interface elements are associated with the
Interface Termination. This special Termination supports Packages
implement all user interaction with the telephone user interface
including Function Keys, Indicators, the Dialpad, etc, as
for the specific device capabilities (within constraints given in
section on User Interface Termination). The User
Termination cannot be placed in any Context. This grouping of
interface elements behind a well-know Termination greatly
audits to determine actual device configuration, and reduces
number of Terminations involved in representing user interface
In addition, TerminationID naming conventions are provided
identify specific Terminations within the Megaco IP Phone MG
group them into related sets. These conventions use a set of
known identifier names to specify the individual Terminations,
example the User Interface Termination ("ui"), the Handset
Transducer ("at/hs"), or the Handsfree Audio Transducer ("at/hf").
This specific naming is important in this application, especially
the Audio Transducer Terminations, since the real input/
elements to which they map on the physical device have very
functional significance to the end-user, yet they may be
in the protocol using exactly the same sets of Packages.
conventions allow the controlling MGC to distinguish this end-
meaning without specific advance knowledge of physical
configuration and without the requirement to provide
Packages for each audio input/output type
Using these same TerminationID naming conventions in combination
wildcards, the MGC application can target commands to groups
related Terminations, for example the collection of all
Transducer Terminations ("at/*"). This is especially useful
the discover phase, for example to efficiently Audit all
Audio Transducer Terminations, and to efficiently send commands to
set of related Terminations in a single command, for example
Blatherwick, et al. Informational [Page 5]
RFC 3054 Megaco IP Phone Media GW Application Profile January 2001
simultaneously Subtract all Audio Transducer Terminations from
particular Context. Further information on TerminationID
conventions and their use can be found under the sections on
Interaction and Capability Discovery (next two subsections) and
Termination Types
4.4. Control
To provide control of audio paths, Audio Transducer Terminations
manipulated using Contexts in the normal way, by sending Add, Move
Subtract and Modify commands addressed to the specific
being manipulated. For example creating a Context (Context A
containing an RTP Termination (Tr) and a Handset Audio
Termination (Ta1) creates a voice connection to/from the handset
Moving a Handsfree Audio Transducer Termination (Ta2) into
Context, and removing the Handset, sets up a handsfree conversation
This situation is shown in Figure 1. See the section on
Transducer Termination Types for further details on specific
support requirements
User input elements, such as Keypad or Function Keys, generate
through Notify commands sent from the User Interface Termination
the Megaco IP Phone MG to the controlling MGC for handling.
Events are according to the specific set of Packages supported by
User Interface Termination of the device. See the section on
Interface Termination Type for further details on specific
support requirements
User output elements such as the Text Display or Indicators
controlled by Signals sent by the MGC, addressed to the
Interface Termination of the Megaco IP Phone MG, generally as part
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
section on User Interface Termination Type for further details
specific Package support requirements
Some elements, for example Softkeys, have both user input and
aspects, so both react to Signals and generate Events as above
The TerminationID naming conventions may be used to target
to specific Terminations by well known name, for example to Add
Handsfree Audio Transducer Termination ("at/hf") to a Context.
naming conventions in combination with wildcards may be used
efficiently send commands to groups of related Terminations,
example to simultaneously Subtract all Audio Transducer
("at/*") from a particular Context
Blatherwick, et al. Informational [Page 6]
RFC 3054 Megaco IP Phone Media GW Application Profile January 2001
4.5. Capability
At startup or service change, the Megaco IP Phone MG
itself to its controlling MGC as being a Megaco IP Phone class
device by use of the IPPhone Protocol Profile. This is the first
most important stage of capability discovery, and implicitly
a great deal of the necessary information in a single step
Thereafter, the MGC can make a large number of assumptions
organization and behavior of the MG. See the section on
Protocol Profile for further details of ServiceChange operation
Device capabilities, including the list of all Terminations
supported Packages for each, are queried through the
command. Wildcarded AuditValue commands targeted at the whole
(i.e., addressed to ContextID=Null, TerminationID=ALL) return
list of all Terminations, including the User Interface
and all supported Audio Transducer Terminations. Since the
TerminationIDs use well known identifier names, the MGC can
the specific audio input/output elements available on the
device, and their intended purpose. Further AuditValues commands
individual named Terminations provide further details of each,
example for the MGC to query user interface support
available on the User Interface Termination ("ui").
naming conventions in combination with wildcards can be used
AuditValues commands to query specific Package support for
collection of all Audio Transducer Terminations ("at/*").
Since the structure of the Megaco IP Phone MG is well known
advance, by virtue of the IPPhone Protocol Profile, audits can
efficiently directed at discovering only what additional
is required by the MGC. Thus the MGC is able to efficiently
unambiguously discover both the specific user interface
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
supported Packages within a random collection of Terminations, and
great deal of behavior common to all Megaco IP Phone MGs can
be assumed. This pre-determined organization and behavior
greatly reduces design complexity of both MG and MGC, and
improves interoperability
5. Termination
The Termination types defined for use in the Megaco IP Phone MG are
* User Interface (implements user interface);
Blatherwick, et al. Informational [Page 7]
RFC 3054 Megaco IP Phone Media GW Application Profile January 2001
* Audio Transducer (implements audio input/output to the user,
potentially appears as several individual
corresponding to individual audio input/outputs on the
device);
* RTP (transport of audio streams over IP).
These Termination types represent minimal capabilities to
fully featured business telephones. Additional Termination types
be defined to extend these capabilities
The following subsections describe requirements and constraints
each type in further detail
5.1. User Interface Termination
The User Interface Termination represents the Megaco IP Phone MG
interface elements. Megaco IP Phone MGs MUST support exactly
User Interface Termination
TerminationID of the User Interface Termination MUST be "ui",
for both command addressing and command response return. ABNF
encoding for this MUST be as described in Megaco/H.248
Appendix B.1 [3].
Note: If ASN.1 binary encoding is used (OPTIONAL in
specification), TerminationID for the User Interface Termination
be encoded as described in Megaco/H.248 Protocol Appendix A.1 [3],
with alphabetic characters of the identifier given above mapping
the equivalent octet string in the ASN.1 encoding
The User Interface Termination cannot be part of any context,
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
Elements and Actions Packages" [4].
Blatherwick, et al. Informational [Page 8]
RFC 3054 Megaco IP Phone Media GW Application Profile January 2001
__________________________________________________________
| 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
are defined to extend to additional user interface elements
Note: The reasoning to make all Packages optional in the
Interface Termination is to allow maximum flexibility to create
very broad range of Internet telephones and similar devices.
example, anything from a simple hotel lobby phone (handset
hookswitch only), to conferencing units (handsfree unit and one
two buttons) to fully featured business telephones (display, rich
of keys and indicators, both handset and handsfree, etc) could
designed
5.2. Audio Transducer Termination
The Audio Transducer Terminations are used to control
input/output to/from the end user of the device. Megaco IP Phone
MUST support at least one Audio Transducer Termination, which MAY
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
form "at/", where is the 2 character identifier
above, used for both command addressing and command response return
If more than one Audio Transducer Termination of a particular type
implemented, the TerminationIDs of each MUST be of the
"at//", where is a 2 digit index number
hexadecimal format beginning at 01. Examples of valid
include: "at/hs" (handset), "at/mi/02" (microphone 2), "at/*" (
audio input/outputs). ABNF text encoding for this MUST be
described in Megaco/H.248 Protocol Appendix B.1 [3].
Blatherwick, et al. Informational [Page 9]
RFC 3054 Megaco IP Phone Media GW Application Profile January 2001
Note: If ASN.1 binary encoding is used (OPTIONAL in
specification), TerminationIDs and wildcards MUST be encoded
described in Megaco/H.248 Protocol Appendix A.1 [3], with
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
the implementer, however well know identifier names for these
outside the scope of this specification
All Audio Transducer type Terminations MUST support the
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
applicable to audio input/output functions
5.3. RTP Termination
Megaco IP Phone MGs MUST support at least one RTP Termination
order to support audio streams to/from the device, as defined
Megaco/H.248 Protocol Annex E.12 [3].
No special TerminationID naming convention is defined for
Terminations as part of this specification
6. IPPhone Protocol
The following subsections provide details of the IPPhone
Profile, used between Megaco IP Phone MGs and their controlling MGCs
This includes implicit application-level agreements between
Megaco IP Phone MG and its controlling MGC on organization
behavior of the MG, types of Terminations used and the
minimum Package support for each, and specific minimum selections
the transport and encoding methods used
Use of a this Profile greatly simplifies assumptions necessary by
MGC regarding MG organization, thereby reducing complexity and
of both MG and MGC, and improves interoperability for the
Megaco IP Phone application. Since the Profile is specific to
Blatherwick, et al. Informational [Page 10]
RFC 3054 Megaco IP Phone Media GW Application Profile January 2001
Megaco IP Phone MG, no other applications of Megaco/H.248
are affected
It is important to note that the IPPhone Profile specifies
functionality only, for interoperability purposes.
Termination types, Package support, transport or encoding methods,
other capabilities MAY be added at the discretion of the
within the general structure described
6.1. Profile Descriptor and
Profile name: "IPPhone
Version: 1
The Megaco/H.248 Protocol [3] describes startup and service
procedures in detail, including use of Profiles
In brief, the above Profile name and version are supplied by
Megaco IP Phone MG on startup or at service change, in
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
Service Change, 2) pass control to a different MGC by replying with
new MGC to try, or 3) refuse control entirely by rejecting
Service Change. If MGC control is refused, the Megaco IP Phone
may attempt registration with other MGCs in its list of MGCs to try
Once a controlling MGC accepts the IPPhone Profile, both it and
Megaco IP Phone MG become bound by the Profile rules and
described in subsequent subsections as well as Megaco IP
Termination/Package organization and behavior rules described
previous sections of this document. Thereafter, any protocol
outside these rules is considered an error
6.2 Termination Organization and Package
Termination organization, required Termination types, and
specific Packages supported by each MUST be as described in
4 - 5 of this document
Note that additional Termination types and Package support MAY
be provided within the general structure described
6.3.
Megaco IP Phone MGs MUST support Application Layer Framing (ALF)
UDP transport, as specified in the Megaco/H.248 Protocol Appendix D.1
[3].
Blatherwick, et al. Informational [Page 11]
RFC 3054 Megaco IP Phone Media GW Application Profile January 2001
Note that this does not imply that the Megaco IP Phone MG
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
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
support ASN.1 binary encoding as well. ASN.1 binary encoding
OPTIONAL, but if used MUST conform to Megaco/H.248 Protocol
A [3].
7. Security
The Megaco IP Phone Media Gateway Application Profile adds no
security issues beyond those endemic to all applications
Megaco/H.248 Protocol [3].
8.
[1] TIA/EIA, IS-811, Performance and Interoperability
for Voice-over-IP (VoIP) Feature Telephones
http://www.tiaonline.org/standards/ip/voip/tia-eia-is-811-
final.
[2] Greene, N., Ramalho, M. and B. Rosen, "Media Gateway
Protocol Architecture and Requirements", RFC 2805, April 2000.
[3] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B. and J
Segers, "Megaco Protocol Version 1.0", RFC 3015, November 2000.
[4] ITU-T SG16, H.248 Annex G: User Interface Elements and
Packages, Brown, M. & P. Blatherwick, November 2000.
http://www.itu.int/itudoc/itu-t/rec/h/h248anxg.
[5] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997.
Blatherwick, et al. Informational [Page 12]
RFC 3054 Megaco IP Phone Media GW Application Profile January 2001
9. Authors'
Peter Blatherwick (Editor
Nortel
P.O. Box 3511, Stn
Ottawa, Ontario
Canada K1Y 4H
Phone: (613) 763-7539
(613) 724-4726
EMail: blather@nortelnetworks.
peter.blatherwick@home.
Bob
Cisco Systems Inc
576 S. Brentwood Ln
Bountiful, UT 84010
Phone: (801) 294-3034
EMail: rtbell@cisco.
Phil
Circa Communications Ltd
1000 West 14th
North Vancouver, British Columbia
Canada V7P 3P
Phone: (604) 924-1742
EMail: phil.holland@circa.
Blatherwick, et al. Informational [Page 13]
RFC 3054 Megaco IP Phone Media GW Application Profile January 2001
10. Full Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Blatherwick, et al. Informational [Page 14]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
