summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3054.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3054.txt')
-rw-r--r--doc/rfc/rfc3054.txt787
1 files changed, 787 insertions, 0 deletions
diff --git a/doc/rfc/rfc3054.txt b/doc/rfc/rfc3054.txt
new file mode 100644
index 0000000..1f565e8
--- /dev/null
+++ b/doc/rfc/rfc3054.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+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.
+
+Abstract
+
+ 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 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. Introduction
+
+ This document represents the current view from the TIA working group
+ 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 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
+
+
+
+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 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;
+
+ 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, 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 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
+
+
+
+
+
+Blatherwick, et al. Informational [Page 3]
+
+RFC 3054 Megaco IP Phone Media GW Application Profile January 2001
+
+
+ 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
+
+
+
+
+
+Blatherwick, et al. Informational [Page 4]
+
+RFC 3054 Megaco IP Phone Media GW Application Profile January 2001
+
+
+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
+
+
+
+Blatherwick, et al. Informational [Page 5]
+
+RFC 3054 Megaco IP Phone Media GW Application Profile January 2001
+
+
+ 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.
+
+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.
+
+
+
+
+Blatherwick, et al. Informational [Page 6]
+
+RFC 3054 Megaco IP Phone Media GW Application Profile January 2001
+
+
+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 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);
+
+
+
+
+
+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, 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.
+
+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].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 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.
+
+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].
+
+
+
+
+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 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.
+
+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
+
+
+
+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 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.
+
+ 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].
+
+
+
+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 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].
+
+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] Greene, N., Ramalho, M. and B. Rosen, "Media Gateway Control
+ 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 Actions
+ Packages, Brown, M. & P. Blatherwick, November 2000.
+ http://www.itu.int/itudoc/itu-t/rec/h/h248anxg.html
+
+ [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ 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' Addresses
+
+ Peter Blatherwick (Editor)
+ Nortel Networks
+ P.O. Box 3511, Stn C
+ Ottawa, Ontario,
+ Canada K1Y 4H7
+
+ Phone: (613) 763-7539
+ (613) 724-4726
+ EMail: blather@nortelnetworks.com
+ peter.blatherwick@home.com
+
+
+ Bob Bell
+ Cisco Systems Inc.
+ 576 S. Brentwood Ln.
+ Bountiful, UT 84010
+ USA
+
+ Phone: (801) 294-3034
+ EMail: rtbell@cisco.com
+
+
+ Phil Holland
+ Circa Communications Ltd.
+ 1000 West 14th Street
+ North Vancouver, British Columbia,
+ Canada V7P 3P3
+
+ Phone: (604) 924-1742
+ EMail: phil.holland@circa.ca
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blatherwick, et al. Informational [Page 13]
+
+RFC 3054 Megaco IP Phone Media GW Application Profile January 2001
+
+
+10. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blatherwick, et al. Informational [Page 14]
+