HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 12:00:56 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Mon, 25 Jan 1999 21:13:40 GMT ETag: "2e6df5-45f6-36acde84" Accept-Ranges: bytes Content-Length: 17910 Connection: close Content-Type: text/plain Internet Engineering Task Force Jozef Vandenameele INTERNET DRAFT Chair ETSI-TIPHON WG 2 draft-vandenameele-tiphon-arch-gway-decomp-01.txt January 1999 Expires in six months Requirements for a Protocol between Media Gateway Controller and Media Gateway (Reference Point 'N') Status of this document This document is an Internet-Draft. 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." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract This Internet-Draft contains an update of ETSI-TIPHON's work on requirements for a protocol at the reference point N (in TIPHON parlance) of the TIPHON reference configuration. Reference point N designates the information flows required for control of a Media Gateway in a decomposed Gateway [0]. This Internet-Draft supercedes the one submitted in November 1998 and represents consensus of working group 2 in TIPHON. ETSI-TIPHON is working on standards to connect VoIP (Voice over IP) networks and phone networks. TABLE OF CONTENTS 1 Introduction 2 References 3 Definitions and abbreviations 3.1 Definitions 3.2 Abbreviations 4 Reference Configuration 5 Scope of Media Gateway Control 6 Media Gateway Examples 7 Protocol Requirements 7.1 Connection Control 7.2 Endpoint Attributes 7.3 Content Insertion 7.4 Event Detection and Notification 7.5 Other Requirements 7.5.1 Modularity and Extensibility 7.5.2 Resource Management 7.5.3 MGC-MG Association Management 7.5.4 Scripting 7.6 Security 8 Subjects for further study 9 Acknowledgements 10 Contact Address 1 INTRODUCTION ETSI-TIPHON [12] is working on standards to connect VoIP (Voice over IP) networks and phone networks. Of its now 7 working groups, working group 2 (WG2) is on architecture and reference configurations which are necessary for the delivery of telephone calls which originate in - an IP network and are delivered to Switched Circuit Networks (SCN), such as Public Switched Telephone Network (PSTN), Integrated Services Digital Networks (ISDN) and Global System for Mobile communication (GSM) networks (so-called TIPHON Scenario 1), - an SCN and are delivered to an IP network (TIPHON Scenario 2), - an SCN and are delivered to an SCN via an IP transit network (TIPHON Scenario 3). This Internet-Draft is the asciified version of, in ETSI parlance, Technical Specification DTS/TIPHON-02005 Version V0.1.1, with status 15 January 1999 [0]. 2 References [0] DTS/TIPHON-02005 V0.1.1 (1999-01): "Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON); Requirements for a Protocol at Reference Point N; Media Gateway Controller to Media Gateway"; http://docbox.etsi.org/tech-org/tiphon/Document/ tiphon/07-drafts/wg2/DTS02005/V0.1.1/DTS02005%20V011.doc [1] ITU-T Recommendation E.164 (1997): "The international public telecommunications numbering plan". [2] ITU-T Recommendation H.323 (1998): "Packet-based multimedia communication". [3] ITU-T Recommendation H.245 (1998): "Control protocol for multimedia communication". [4] ITU-T Recommendation H.225.0 (1998): "Call signalling protocols and media stream packetization for packet based multimedia communication systems". [5] ITU-T Recommendation H.235 (1998): "Security and encryption for H. series [H.323 and other H.245-based] multimedia terminals". [6] TR 101 306: "Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON); Requirements for service interoperability; Scenario 1". [7] TS 101 324: " Naming and addressing; Scenario 1". [8] ITU-T Recommendation G.711: "Pulse code modulation (PCM) of voice frequencies". [9] ITU-T Recommendation G.723.1: "Dual rate speech coder for multimedia communications transmitting at 5.3 and 6.3 kbit/s". [10] ITU-T Recommendation Q.931: "ISDN user-network interface layer 3 specification for basic call control". [11] TS 101 313: "Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON); Network architecture and reference configurations; Phase II: Scenario 1 + Scenario 2", Version 0.4.1, January 1999. [12] http://www.etsi.org/tiphon. All ETSI-TIPHON documents are publicly available for free through this website. TIPHON mailing lists are also open to everyone. 3 Definitions and abbreviations 3.1 Definitions - Gateway: A gateway is an endpoint on a network which provides for real-time, two-way communication between terminals on an IP based network and other terminals on switched circuit network. - Media gateway: Provides the media mapping and/or transcoding functions. - Media gateway controller: Controls the Media Gateways. - Signalling gateway: Provides the signalling mediation function between the IP domain and the SCN domain. 3.2 Abbreviations ATM Asynchronous Transfer Mode BRI Basic Rate Interface DTMF Dual Tone Multi Frequency GK GateKeeper GW Gateway IP Internet Protocol MG Media Gateway MGC Media Gateway Controller NNI Network to Network Interface PRI Primary Rate Interface PSTN Public Switched Telephone Network QoS Quality of Service RTCP Real-time Transport Control Protocol RTP Real-time Transport Protocol SCN Switched Circuit Networks SG Signalling Gateway SS7 Signalling System N 7 UNI User to Network Interface 4. Introduction Figure 1 shows the reference configuration as defined in [11]. Reference Point N designates the information flows required for control of a Media Gateway in a decomposed Gateway. +--------+ D +--------+ G +--------+ | GK |------| GK |------|Back End| +--------+ +--------+ +--------+ | | / A | C | ___F___/ | . . . . . . ./. . . . . . . . +--------+ . +--------+ J +--------+ . |H323 Ter| . | MGC |------| SG |------ +--------+ . +--------+ +--------+ . \____B_. | . .\ N | . . \ | . . +--------+ . . | MG |-----------------.---- . +--------+ . . . . . . . . . . . . . . . . Figure 1: Basic call reference configuration (MGC = Media Gateway Controller, MG = Media Gateway, SG = Signalling Gateway, H323 Ter = H.323 Terminal) 5. Scope of Media Gateway Control This subclause is a copy of subclause 6.7 of [11] Information flows at reference point N shall include support for the following functions: 1) creation, modification, and deletion of media stream connections across the Media Gateway; 2) specification of the transformations to be applied to media streams as they pass through the Media Gateway, when connections are created and subsequently during the life of the connection; 3) requesting the insertion of tones and announcements into media streams, either by explicit request of the Media Gateway Controller or by indicating that insertion should begin and end with the detection of specified events within the Media Gateway itself; 4) requesting the reporting of, and possibly specifying the actions to take upon detection of specified events within the media streams. 6. Media Gateway Examples Media Gateway examples include but are not limited to the following applications: - Trunk gateways that interface between SCN networks and Voice over IP network. Such gateways typically interface to SS7 or other NNI signalling on the SCN and manage a large number of digital circuits. - Voice over ATM gateways which operate much the same way as voice over IP trunk gateways, except that they interface to an ATM network. - Access gateways that interface UNI interfaces like ISDN (PRI and BRI) and traditional analogue voice terminal interfaces to a Voice over IP network. - Residential gateways are access gateways for a small number of voice terminals that can be co-located with a cable modem or set top box. - Network Access Servers, which convert modem signals from an SCN network and provide data access to the packet network. - Multipoint Processing Units that provide multipoint connectivity between terminals on SCN and packet networks. - Interactive Voice Response systems that provide automatic voice response and switching services in response to DTMF signals from the SCN. - IP Gateways that are used to interface either between administrative domains which apply different policies (e.g. proxies), or to transform media streams formats (e.g. transcoding). - Fax Gateways 7. Protocol Requirements 7.1 Connection Control In keeping with the capabilities of H.245, connection control shall be able to provide at least the following types of connection: - circuit to packet (IP); - circuit to packet (ATM - H.323 Annex C operation); - packet to packet - circuit to circuit (e.g. circuit side fallback). The connection mode may be unicast or multicast, or a connection may be inactive. Typically connections are specified unidirectionally, but may be specified in both directions at once. On internet connections, IPv4 is mandatory and IPv6 may be supported. On the circuit side, SS7 requires the ability to perform a loopback for continuity testing. This requirement applies especially to loopback through a circuit at the edge of the Media Gateway (path 1 in Figure 2), but as Figure 2 shows, four different types of loopback are possible (e.g. fault isolation) SCN Packet +========================+ | | ---------------------------------------\ | | path 2 <--------------------------------------/ | | . . | . . . . . . . . . . . . . . . . . . . | | . . | . . . . . . . . . . . .|. . . . . > path 4 | | path 1 -------------\ . . . . . . . . . . | . | <------------/ . . . . . . . . . > path 3 | | +========================+ Figure 2 - Possible Types Of Loopback Abstracting from this, the Media Gateway control interface shall support the following capabilities for connection control: 1) Ability to identify the IP, ATM, and/or circuit local end-points, and local connections within the Media Gateway between two or more of its endpoints. Endpoints shall be designated using a hierarchical naming construct. 2) It must be possible to wildcard the low-order portion of the endpoint identifier (i.e. the port number for an IP transport address or the low-order term of a circuit identifier), with the intent that Media Gateway shall select a suitable endpoint instance and return its full identity to the Media Gateway Controller. 3) Wildcarding shall be provided to allow a simultaneous reference to multiple endpoints. 4) Ability to request the selection of ports for both RTP and RTCP reception on the packet side. The numerical values of RTP and RTCP ports may be non-subsequent numbers. [2] 5) Ability to convey the requested QoS parameters applicable on the packet side of a media stream connection. 6) Ability to convey the requested bearer capabilities applicable on the SCN side of a media stream connection. 7) Ability to convey QoS statistics for an established connection at any time during the call and at teardown. 8) Ability for the Media Gateway to autonomously report if the QoS on a given connection has fallen below a specified value. 7.2 Endpoint Attributes The protocol shall be able to convey the following endpoint attributes: 1) Media protocol used (RTP, fax-protocol, ...) 2) Payload type (e.g. codec), 3) Codec-related attributes like packetisation interval, jitter buffer size and silence suppression where appropriate 4) Generation of comfort noise during silent periods. 5) Application of encryption/decryption and identification of the encryption schemes. 6) Echo cancellation 7) Lawful interception of the content of a specified media stream. 8) It should be possible to support additional endpoint attributes as they are defined without modifying the existing semantics. The protocol shall allow - the specification of the endpoint attributes when the connection is created; - modification of endpoint attribute values for an already-existing connection (e.g. in response to a H.245 FlowControlCommand or ReplacementFor OLC (OpenLogicalChannel) ). 7.3 Content Insertion The protocol shall support - the ability to request the sending of a specified tone or announcement, at any time, in a specified direction - the specification of the conditions under which the sending should stop - the ability to request muting of a media stream. - the ability for the controller to request the Media Gateway to insert and detect tones as required for SS7 continuity testing and other forms of testing. 7.4 Event Detection and Notification The protocol shall support the ability to instruct the Media Gateway to detect, notify and possibly act upon specified events. Examples of events are: - DTMF tones, - off-hook, on-hook 7.5 Other Requirements As a general requirement, the protocol shall allow the Media Gateway to indicate to the controller whenever some or all of a request cannot be executed. It shall be possible for the Media Gateway to indicate the general nature of the problem and to provide further details, possibly including vendor-specific content. 7.5.1 Modularity and Extensibility It is essential that the protocol be both modular and extensible. Not all implementations may wish to support all of the possible extensions. This will permit light-weight implementations for specialized tasks where processing resources are constrained. The protocol shall provide the means whereby a controller can determine the capabilities supported by a particular Media Gateway. The protocol shall support backwards compatibility as new versions are released. The protocol shall allow the possibility of vendor-specific extensions. 7.5.2 Resource Management The protocol shall provide the means for the Media Gateway Controller to determine resource availability within the associated Media Gateway. The protocol shall allow for unsolicited messages between the Media Gateway and Media Gateway Controller. Optionally, this capability may allow for queries during regular operation. The means by which remaining capacity is quantified is for further study. It shall be possible for the Media Gateway to indicate to the controller that it lacks sufficient resources to carry out a given command. It shall be possible for the Media Gateway Controller to audit the commitment of resources to connections, to ensure that all commitments are valid. It shall further be possible for the controller to order that specific resource assignments be cleared if it finds that they are invalid. It shall be possible for the Media Gateway Controller to audit the connection state of connections in Media Gateways with which it is associated. It shall be possible for the Media Gateway to report changes in operational status of significant resources from in-service to out- of-service and vice versa. This is especially required for transmission facilities terminating on the Media Gateway. 7.5.3 MGC-MG Association Management - The protocol shall provide the means to establish and remove an MGC-MG association between a specific controller and a specific Media Gateway. - It shall be possible for a Media Gateway to establish an MGC-MG association with an alternate Media Gateway Controller if its currently associated controller becomes unavailable. - It shall be possible for either the Media Gateway or the Media Gateway Controller to detect loss of the control association. 7.5.4 Scripting The protocol shall provide the means to download scripts to be executed autonomously by the Media Gateway. 7.6 Security The protocol shall allow for mutual authentication at the start of an MGC-MG association , and for preservation of the integrity and confidentiality of control messages once the association has been established. 8. Subjects for further study - Support for H.323 fast start 9. Acknowledgments This draft is the work of Working Group 2 of ETSI-TIPHON. Many thanks to all contributors. 10. Contact Address Jozef Vandenameele Alcatel Bell NV Francis Wellesplein 1 B-2018 Antwerpen, Belgium Tel: + 32-3-240 4361 Fax: + 32-3-240 9999 or 9961 email : Jozef.Vandenameele@btmaa.bel.alcatel.be or send mail to the mailing list of ETSI-TIPHON WG 2: TIPHON_WG2@list.etsi.fr (to subscribe, send "subscribe TIPHON_WG2" to listserv@list.etsi.fr)