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]
