Network Working Group P. Blatherwick (Editor) Request for Comments: 3054 Nortel Networks Category: Informational R. Bell Cisco Systems P. Holland Circa Communications (Chair TIA TR-41.3.4) January 2001 Megaco IP Phone Media Gateway Application Profile Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved.
AbstractThis 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 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, and is thus a straight-forward application of the Megaco/H.248 Protocol. 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 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). RFC 2119 . 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;
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  and be a straight-forward application of the Megaco/H.248 Protocol . 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 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
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. 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.
* 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. The following subsections describe requirements and constraints on each type in further detail. Appendix B.1 . 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 , 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" .
__________________________________________________________ | 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. Appendix B.1 .
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 , 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 . ____________________________________________________________ | 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. 3]. No special TerminationID naming convention is defined for RTP Terminations as part of this specification.
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. 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 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. sections 4 - 5 of this document. Note that additional Termination types and Package support MAY also be provided within the general structure described. Appendix D.1 .
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 . Appendix B . 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].  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  Greene, N., Ramalho, M. and B. Rosen, "Media Gateway Control Protocol Architecture and Requirements", RFC 2805, April 2000.  Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B. and J. Segers, "Megaco Protocol Version 1.0", RFC 3015, November 2000.  ITU-T SG16, H.248 Annex G: User Interface Elements and Actions Packages, Brown, M. & P. Blatherwick, November 2000. http://www.itu.int/itudoc/itu-t/rec/h/h248anxg.html  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.