Internet Engineering Task Force Jozef Vandenameele INTERNET DRAFT Chair ETSI-TIPHON WG 2 draft-vandenameele-tiphon-arch-gway-decomp-00.txt November 1998 Expires in six months Requirements for the Reference Point ('N') between Media Gateway Controller and Media Gateway 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 those excerpts of ETSI-TIPHON's work that focus on the reference point between Media Gateway Controller and Media Gateway (reference point "N" in TIPHON parlance). ETSI-TIPHON is working on standards to connect VoIP (Voice over IP) networks and phone networks. PLEASE NOTE THAT THIS INPUT FROM TIPHON IS WORK IN PROGRESS. IT HAS BEEN APPROVED NEITHER ON THE TIPHON WORKING GROUP 2 LEVEL, NOR ON THE TIPHON PROJECT LEVEL. However, as input is always welcome, we are herewith submitting the current status of the discussion within TIPHON to the IETF. TABLE OF CONTENTS 1. Introduction 2. Definitions 3. Reference Configuration 3.1 Reference Configuration Overview 3.2 Reference Configuration Details 4. Functional Blocks 4.1 Media Gateway 4.2 Media Gateway Controller 5. Requirements for Reference Point (N) between Media Gateway Controller and Media Gateway 5.1 Introduction 5.2 Scope of Media Gateway Control 5.2.1 Connection Control 5.2.2 Media Stream Transformations 5.2.3 Content Insertion 5.2.4 Event Catching 5.3 Other Requirements 5.3.1 Modularity and Extensibility 5.3.2 Resource Management 5.3.3 Control Session Management 5.3.4 Control Session Security 6. References 7. Acknowledgments 8. Contact Address 1 INTRODUCTION ETSI-TIPHON [1a] is working on standards to connect VoIP (Voice over IP) networks and phone networks. Of its six working groups, working group 2 (WG2), is on architecture and reference configurations. One of WG2's documents is, in ETSI parlance, Technical Specification DTS/TIPHON-02002 [1b]. It defines the network architecture, system architecture, and the 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 in 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 contains those excerpts of DTS/TIPHON-02002 Version V0.3.1 (status 30 October 1998) that focus on the reference point between Media Gateway Controller and Media Gateway (reference point "N" in TIPHON parlance). PLEASE NOTE THAT THIS INPUT FROM TIPHON IS WORK IN PROGRESS. IT HAS BEEN APPROVED NEITHER ON THE TIPHON WORKING GROUP 2 LEVEL, NOR ON THE TIPHON PROJECT LEVEL. However, as input is always welcome, we are herewith submitting the current status of the discussion within TIPHON to the IETF. ETSI-TIPHON and ITU Study Group 16 are actively cooperating on the the gateway decomposition [1c], and ETSI-TIPHON whishes for active collaboration with the relevant IETF working group(s) as well. 2 DEFINITIONS - 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 - gatekeeper : An H.323 entity on the IP network which provides address translation and controls access to the network for terminals, gateways, and MCUs. The gatekeeper may also provide other services to terminals, gateways and MCUs, such as bandwidth management and gateway location. - 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. - terminal: An H.323 terminal (see [2]), other than a gateway or a multipoint control unit. 3 REFERENCE CONFIGURATION This clause gives reference configurations that shall apply for the interworking function (IWF) to ensure service interoperability for TIPHON phase 2 systems. 3.1 Reference configuration overview The reference configuration shall consist of following entities: - terminal connected to the IP network; - IP access (e.g. Public Switched Telephone Network (PSTN), Integrated Services Digital Network (ISDN), x Digital Subscriber Line (xDSL)); - IP network; - gateway - Media Gateway Controller - Media Gateway - Signalling Gateway; - gatekeeper; - an SCN; - a terminal connected to an SCN network; - back-end services; +--------+ D +--------+ G +--------+ | GK |------| GK |------|Back End| +--------+ +--------+ +--------+ | | / A | C | ___F___/ | . . . . . . ./. . . . . . . . +--------+ . +--------+ J +--------+ . E.b |H323 Ter|------| MGC |------| SG |------ +--------+ . +--------+ +--------+ . \____B_. | . .\ N | . . \ | . . +--------+ . E.a . | MG |-----------------.---- . +--------+ . . . . . . . . . . . . . . . . Figure 1: Basic call reference configuration (MGC = Media Gateway Controller, MG = Media Gateway, SG = Signalling Gateway) NOTE 1: This diagram does not represent a network topology. For example, a gatekeeper that communicates with both a terminal and a gateway is using reference points A and C. Whilst figure 1 contains two gatekeepers (in order to show the reference point between two gatekeepers), a particular TIPHON system may contain one or more gatekeepers. However, it appears to each terminal that it communicates with as a single gatekeeper, and similarly for the gateway. Different gatekeepers may be responsible for different administrative domains, or for different parts of a single administrative domain (i.e. one administrative domain may contain multiple gatekeepers). The architectural model of the gateway is split in three functional components: the Signalling Gateway (SG), the Media Gateway (MG) and the Media Gateway Controller (MGC). 3.2 Reference configuration details The interoperability between SCN and IP networks for voice services shall have minimal impact on those networks. The lines in the reference configuration diagram represent network connections between the elements. Dedicated or non-dedicated, long- lived or on-demand connections may be used. 3.2.3 Gatekeeper The gatekeeper is the element in the network that shall be responsible for the Registration, Admission, and Status (RAS) of terminals and gateways. The gatekeeper shall participate in zone management, call processing and call signalling. 3.2.4 Gateway A gateway shall be physically connected to one or more IP networks and to one or more SCN networks. A gateway is composed of - Signalling Gateway - Media Gateway - Media Gateway Controller These different functions can be co-located with either a gatekeeper, a gateway or both. 3.2.4.1. Signalling Gateway The Signalling Gateway provides the signalling mediation function between the IP domain and the SCN domain. It may support functional or signalling mediation between the IP domain (e.g. H.323) and call signalling in the SCN domain (e.g. channel associated signalling, non - channel associated signalling, ...). 3.2.4.2. Media Gateway The Media Gateway provides the media mapping and / or transcoding functions. It maps (e.g. tandemfree operation) or transcodes the media in the IP domain (e.g. media transported over RTP/UDP/IP) and media in the SCN domain (e.g. PCM encoded voice, GSM, etc.). 3.2.4.3. Media Gateway Controller The Media Gateway Controller sits between the Media Gateway, the Signalling Gateway and the Gatekeeper. It provides the call processing (call handling) function for the Gateway. It controls the Media Gateways; it receives SCN signalling information from the Signalling Gateway and IP signalling from the Gatekeeper. 3.2.5 Back-end services Back End Services may be used by gateways and gatekeepers to provide functions (e.g. authentication function, billing and rating/ tariffing, or address resolution function, etc.). These back-end services may be provided by equipment within the SCN, within the IP Network, or elsewhere. 4 FUNCTIONAL BLOCKS Three main functional blocks are identified within the IP domain: terminals, gateways, and gatekeepers. This section identifies functions within the media gateway and the media gateway controller only. The gateway Functional Block ensures the interworking between the IP domain and the SCN domain. It is composed of three separate Functional Blocks: - the Signalling Gateway (not discussed in this Internet-Draft) - the Media Gateway - the Media Gateway Controller 4.1. Media Gateway - Media channel address resolution function - provides IP transport addresses for media reception and transmission; - Stream conditioning function - transfers the media streams between the IP domain and the SCN domain, including (e.g.) transcoding and echo cancellation; - Codec translation function - routes the media streams between the IP domain and the PSTN/ISDN/GSM domain - Media channel privacy - ensures media privacy to and from the GW; - Circuit Network Media Termination - This includes all lower-layer circuit network hardware and protocols, including the method by which speech is placed on the wire, e.g. PCM A-law, PCM Mu-law, etc. - Packet Media Termination - This includes all protocols involved in putting media over the packet network, including the codecs used. For H.323 this includes RTP/RTCP as described in H.225.0, and also the coders such as G.711, G.723.1. etc. - SCN Circuit Interface: terminates the bearer channel (e.g. DS0) from the SCN and makes it available to the Media Processing functions. - Packet / Circuit Media Processing Function - converts between audio, fax or data bearer channels on the SCN side and data packets (e.g. RTP/UDP/IP, or ATM) on the packet network side. This also performs associated signal processing functions such as voice compression, network echo-cancellation, silence suppression, comfort noise generation, encryption, fax conversion, and analog modem conversion (for passing analog modem signals "transparently" through the packet network). In addition, this function performs the conversion between DTMF tones on the SCN side and the appropriate signals on the packet network side when the speech codec is not transparent to DTMF. The SCN/Packet Media Processing function may also collect the packet traffic and quality data experienced by each call for use in call detail reporting and call control. - NAS Media Processing and Control Function: provides the functionality of an IP Remote Access Server and terminates PPP, RADIUS, etc. stacks used for transport and management of the dial-up data channel. This function, if present, always resides in the Media Gateway. - Service Circuit Function: provides services such as playing announcements and tones towards either the SCN or packet network. This function may also provide capabilities to collect and generate DTMF digits, perform voice recognition, etc. The Service Circuit function resources again are managed from within the Media Gateway and may be requested by more than one Call Control function or other external system (e.g., SCP). Some or all of these functions may be provided by an external entity in which case this function may be optional. - Usage recording function - determines and/or records signalling and/or media reception and transmission. - Usage reporting function - reports to an external entity the determined and/or recorded usage. - OAM&P: Operations, administration, maintenance, and provisioning information that is not directly needed for call control can be passed through a logically separate interface to an element management system. This operations interface is beyond the scope of this paper. - Management function - interfaces to the network management system - Packet Network Interface: terminates packet network. 4.2. Media Gateway Controller - GW H.225 function - receives and emits H.225 messages (see [4]); - GW H.245 function - receives and emits H.245 messages (see [3]); - Authentication function - establishes the identity of the user, device, or network entity (see [5]); - GW media stream admission control function - allows or disallows media streaming; - Non-repudiation evidence gathering - collects information to be used to prove that a certain signalling or media was transmitted or received; - Packet Signaling - This includes all "call like" signaling that might exist on the packet network and is carried out by an endpoint on such a network. For H.323, this includes H.225.0 Q.931-like call signaling, H.225.0 RAS, and H.245. For an H.323 receive-only endpoint, this includesH.225.0 RAS, but not H.245. - Packet Network Signaling Interface: terminates the packet network signaling protocol (e.g., H.323, UNI, PNNI, etc.) It maintains only enough call state information to manage the protocol interface. Strictly speaking, the Packet Network Signaling Interface that exists in the Gateway Controller has no direct interface to the Media Gateway as all information passes from it to the Media Gateway via the Call Control Function. In general this function will reside in the Gateway controller. - Gateway Control - This includes all connection control logic, resource management, and protocol translation (e.g. SS7 to H.225.0) that might take place. - Remote Resource Monitoring: maintains the Gateway Controller's view of network-level resources available for calls or NAS termination. These include such things as Media Gateway trunk utilization and availability, IP network bandwidth and utilisation, etc. useful for making call routing decisions. - Call Control Function: maintains the Gateway call state. The Call Control function contains all connection control logic of the Gateway. The Call Control function may interface with backend services, which may include IN services (SCP or SSP). Note: This function may perform call routing, authorisation, authentication, quality of service selection, billing data and per- call information recording and resource identification functions. It communicates bearer trunk circuit termination (DS0 channel) and data network addressing, security and configuration information (voice coder, echo cancellation parameters, encryption tokens, etc.) to the Media Gateway. - Media Gateway Resource Management - allocates internal resources within the media gateway. - Signalling mediation function maps between signalling in the IP domain (e.g. H.323) and signalling in the SCN domain, in co-operation with the SG. - Usage recording function - determines and/or records signalling and/or media reception and transmission - Usage reporting function - reports to an external entity the determined and/or recorded usage. - OAM&P: Operations, administration, maintenance, and provisioning information that is not directly needed for call control can be passed through a logically separate interface to an element management system. This operations interface is beyond the scope of this paper. - Management function - interfaces to the network management system - Packet Network Interface: terminates packet network. 5 REQUIREMENTS FOR REFERENCE POINT ("N") BETWEEN MEDIA GATEWAY CONTROLLER AND MEDIA GATEWAY 5.1. Introduction Reference Point N designates the information flows required for control of a Media Gateway in a decomposed H.323 Gateway. NOTE: There is a strong causal relationship between H.245 signalling and information flow over reference point N. The detailed content required in Media Gateway control messages in a decomposed H.323 Gateway derives in large part from the potential content of the associated H.245 signalling. 5.2. Scope of Media Gateway Control Media Gateway control consists of four 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, both initially as connections are created and subsequently during the life of the connection. 3. Requests to the Media Gateway to insert content (tones and announcements) into media streams, either on direct orders from the controller or beginning and ending with the detection of specified events within the Media Gateway itself. 4. Requests to the Media Gateway to report and possibly to take specified actions upon detection of specified events within the media streams. 5.2.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) - circuit to circuit (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, both IPv4 and IPv6 are supported. H.245 contains parameters which must be passed on to the transport network to select transport QoS. H.245 sets up both an RTP and an optional RTCP connection in each direction. 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. 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 connection end- points involved in a connection. On the packet side, end-point descriptions shall reflect the content provided by networkAddress portion of the H.245 NetworkAccessParameters type. On the circuit side, it shall be possible to designate circuits using a hierarchical naming construct. 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 an idle endpoint instance and return its full identity to the controller. Wildcarding shall also be provided to allow a simultaneous reference to multiple endpoints. 2) Ability to request the selection of ports for both RTP and RTCP reception on the packet side. 3) Ability to specify unicast or multicast propagation of the media stream on the network side. 4) Ability to specify the QOS parameters applicable on the packet side of a media stream connection. 5) Ability to monitor QOS statistics for an established connection, or at least the accumulated statistics for each connection as it is taken down. 6) Ability for the Media Gateway to autonomously report if the QOS on a given connection has fallen below a specified value. 7) Ability to support circuit-to-circuit connections (the case of circuit-side fallback when the packet side is congested). 8) Ability to support at least the circuit-side loopbacks needed for SS7 continuity testing. 5.2.2 Media stream transformations This section has to do with the "steady-state" characteristics of the media streams. Again beginning with the packet side, H.245 specifies the RTP payload type to be used for a given media stream. The Media Gateway control protocol shall permit the payload type to be transmitted onward to the Media Gateway. The Media Gateway control protocol shall also allow the controller to pass explicit designation of the codec, packetization interval, and jitter buffer size for each media stream. In some cases, it will be necessary to specify the coding information on both sides of the connection. This will be true for a packet-to- packet connection, and could happen if the coding on the circuit side varies on a per-call basis (e.g. because bearer capacity varies between 56kbs and 64kbs depending on which facilities the call has passed through along the way). In addition to RTP payload type, H.245 can specify whether silence suppression is to be used. Moreover, the Media Gateway may be the point at which encryption is applied because the subscriber has requested confidentiality service across the packet network. For GSM codecs, H.245 signals whether comfort noise is to be generated during silent periods. On the packet side, echo cancellation may be applied on a per-call basis. The Media Gateway control protocol shall be able to pass all of this information on to the Media Gateway. Typically much of this information must be specified at the same time that the connection is created. The Media Gateway control protocol shall allow for this possibility. However, it shall also be possible to change media handling instructions for an already-existing connection, in response, for instance, to an H.245 FlowControlCommand. A final requirement relating to media processing is that the Media Gateway control protocol shall support requests to initiate or terminate lawful interception of the content of a specified media stream. 5.2.3 Content Insertion The requirement to play out one or more tones in a specified direction (usually toward the circuit side) occurs for almost all media stream connections. Occasionally it may be necessary to play out a Media-Gateway-resident announcement. These actions are triggered by call processing rather than H.245 signalling. The Media Gateway control protocol shall support the ability to request the playing of a specific tone or announcement at any point during the life of a connection. To reduce the messaging and other processing burden on the controller and improve response times, it is highly desirable that the Media Gateway control protocol go beyond requests to start and stop the playing of specified announcements or tones, to support at a minimum the specification of the conditions under which playout should stop. For example, a prompting tone or announcement should stop when incoming DTMF is detected, without the need to report that event to the controller and receive another instruction stopping the playout. This capability is a subset of the general requirement for the controller to be able to program the Media Gateway to detect and react to specific events associated with specific connections. The Media Gateway control protocol shall also support the ability to request muting of a media stream in a specified direction. Finally, the Media Gateway control protocol shall support 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. 5.2.4 Event Catching Even the narrowest definition of the scope of Media Gateway control within the context of H.323 Gateway decomposition requires the ability to instruct the Media Gateway to detect and act upon specified events. As a specific example, once the call has been established, the controller must tell the Media Gateway to begin listening for DTMF on the circuit side, report any digits detected, and remove the DTMF from the stream as it is passed to the packet side. This is an example where H.245 signalling (userInputIndication messages) will occur as a consequence of Media Gateway control messages rather than the reverse. The Media Gateway control protocol shall support this specific operation. The complete Media Gateway control repertoire of events to be detected and actions to be taken as a result is for further study. The main difficulty is to distinguish between Media Gateway control and circuit-side signalling (Reference Point J) requirements. 5.3 Other Requirements As a general requirement, the Media Gateway control 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 proprietary content. 5.3.1 Modularity and Extensibility It is essential that the protocol for Media Gateway control be both modular and extensible. Many uses are envisioned for this protocol, going beyond its implementation of an interface across Reference Point N. To begin with, the protocol may also be used to implement at least part of Reference Point J circuit-side signalling transport interface, particularly where MF or R2 is being used. Beyond that, it will probably be extended to handle Network Access Server (NAS) operation, where circuits must be connected to modems either unconditionally or upon detection of a modem tone. One further example is possible use to control a line-terminating Media Gateway. These are just three examples of potential extensions. However, not all implementations may wish to support all of the possible extensions. Thus the protocol shall be modular, permitting light-weight implementations for specialised 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. 5.3.2 Resource Management The Media Gateway control protocol shall provide the means for the controller to determine resource availability within the Media Gateway upon startup. 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 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 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. 5.3.3 Control Session Management The Media Gateway control protocol shall provide the means to start up and take down a control session between a specific controller and a specific Media Gateway. The ability for two controllers to make requests to the same Media Gateway at the same time is NOT a requirement. However, it shall be possible for a Media Gateway to establish a control session with an alternate controller if its primary controller becomes unavailable. It shall also be possible for a Media Gateway to establish an inactive control session with a standby controller. Control switchovers should occur without loss of connections already made within the Media Gateway. Means should be provided for the new controller to request a reset of all connections if it is unable to recover the existing connection states. DEFINITION: A Control session is an application level relationship between a Media Gateway Controller and a Media Gateway. The use of the term session does not carry any implications for the protocol stack below the application level. It shall be possible for either the Media Gateway or the controller to detect loss of contact with the other party to the control session within a configurable time of the order of ten seconds or less. The appropriate actions to take upon detection of loss of contact are for further study. 5.3.4 Control Session Security The Media Gateway control protocol shall provide the means for mutual authentication at the start of a control session, and for preservation of the integrity and confidentiality of control messages once the session has started. 6. REFERENCES [1a] 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. [1b] DTS/TIPHON-02002 V0.3.1: "TIPHON; Network architecture and reference configurations; Phase II: Scenario 1 + Scenario 2"; http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07- drafts/wg2/DTS02002/V0.3.1/ [1c] http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/05-9810- Tel_Aviv/10td137r1.doc [2] ITU-T Recommendation H.323 (1998) (version 2): "Packet based multimedia communication" [3] ITU-T Recommandation H.245 (1998) (version 3): "Control protocol for multimedia communication". [4] ITU-T Recommandation H.225.0 (1998) (version 2): "Call signalling protocols and media stream packetization for packet based multimedia communications systems". [5] TR 101 306: "Telecommunications and Internet Protocol Harmonization Over Network (TIPHON); Requirements for service interoperability; Scenario 1". 7. Acknowledgments This draft is the work of Working Group 2 of ETSI-TIPHON. Many thanks to all contributors. 8. 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)