Internet Engineering Task Force Nancy Greene INTERNET DRAFT Nortel Networks <draft-ietf-megaco-reqs-00.txt> Michael Ramalho Category: Informational Bellcore Expires: July 27, 1999 Media Gateway Control Protocol Architecture and Requirements Nancy Greene, Michael Ramalho January 27, 1999 Status of this document This document is an Internet-Draft. Internet-Drafts are working docu- ments 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 document lists requirements for the media gateway control protocol. Table of Contents Page Greene, Ramalho [Page 1]
Internet draft MEGACO Requirements 27 January 1999 Input to this document is from: Draft-taylor-megaco-reqs-01.txt Draft-cuervo-navdec-mg-arch-01.txt Draft-sijben-megaco-mdcp-00.txt Draft-greene-ss7-arch-frame-01.txt Draft-draft-vandenameele-tiphon-arch-gway-decomp-01.txt mailing list discussions over the past few months 3. Definitions 4. Architecture 4.1 SG-MGC-MG functional breakdown 4.2 Types of Networks 4.2.1. Circuit Networks 4.2.2. IP Networks 4.2.3. ATM networks 4.3. Gateway Resources 4.4. Types Of Gateways 4.4.1. Network Access Server 4.4.2. Telephony Gateway (Voice Over IP Gateway) 4.4.3 Combined Servers 4.4.4 Interactive Voice Response Unit 4.5. Network Configurations for Voice 4.5.1. Trunking Gateway, In A North American SS7 4.5.2. Trunking Gateway, Channel Associated Signalling 4.5.3. Access Gateway, ISDN Signalling. 4.5.4. Residential Gateway. 4.5.5 ATM Trunking Gateway 4.6. Network Configurations For Data 4.6.1. NAS In A North American SS7 Environment 4.6.2. Network Access Server, Channel Associated 4.6.3. Network Access Server, ISDN signalling. 4.6.4. ATM NAS 4.7 Specific functions that are assumed to be within an MG 5. General Protocol Requirements 5.1 Connection Topology - Endpoint concept and allowing connections to be created between any two endpoints in a MG - an endpoint is a point of entry and/or exit for media flows relative to the MG 5.2 Event detection requirements 5.3 Scalability 5.4 Distribution of Intelligence, flexibility, signalling terminations 5.5 Extensibility 5.6 Reliability requirements 5.7 Performance requirements 6. General Management requirements 6.1 Configuration Requirements Greene, Ramalho [Page 2]
Internet draft MEGACO Requirements 27 January 1999 6.2 Endpoint configuration requirements 6.3MG-MGC association requirements 6.4 Resource management requirements 6.5 Accounting requirements 7. Security Requirements 8.Profile-specific Requirements 8.1 Media-specific Profiles (e.g. endpoint attributes for ATM, FrameRelay, IP, ) 8.2 Application-specific Profiles (e.g. VoIP Trunking GW) Greene, Ramalho [Page 3]
Internet draft MEGACO Requirements 27 January 1999 1. Introduction 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and indi- cate requirement levels for the Media Gateway control protocol. 3. Definitions * Connections Editor's Note: this definition still needs work Under the control of a Media Gateway Controller, the Media Gateway realizes "connections". Connections are associations of resources hosted by the MG. They typically they involve ANY two endpoints, and possibly additional media resources. We can distinguish between media connections between an endpoint on this MG and endpoints or network resources also on this MG (internal media connections), versus media connections between an endpoint on this MG and an endpoint on another network entity (MG, client, switch, ...) (external media connections).. * Endpoint Editor's NOTE: this definition needs work - comments welcome An endpoint is a point of entry and /or exit of media flows relative to MG. When an MG is asked to connect two endpoints, it understands how the flows entering and leaving each endpoint are related to each other. All the endpoints are "internal" to the MG in one way - it knows how to connect to them. Whether the entire endpoint is completely within the MG (like a tone generator), or whether it is some kind of external interface that the MG implements (like a line card), it is still a point the MG can make a connection to. Endpoints are, for instance, DS0's, ATM VCs and RTP ports. It MAY make sense to differentiate between an <<endpoint>> that has one physical end in an MG and something across the network reached by a Greene, Ramalho [Page 4]
Internet draft MEGACO Requirements 27 January 1999 "bearer" data channel would be constructed by the MG. The "name" of the other end is an address, like an IP address, a DNS name or an ATM NSAP or something else. I'd advocate that the protocol make the least set of assumptions possible about the differences between <<endpoints>> that are directly connected to the MG and things that are connected to via IP (or ATM). We COULD make them distinguishable only by a naming conven- tion. (comment by Brian Rosen) On the IP side, the incoming flow is characterized by a different address from the outgoing flow: The incoming flow is the address on this MG, and the outgoing flow is the address on the remote end. An endpoint in this case is a logical relationship covering all flows to and from a remote entity, i.e., it is an RTP stream plus a remote address. If the mapping is from H.320 on the circuit side, and H.323 on the packet side, it is assumed that the MG knows how to map respective sub- channels from H.320 side to streams on packet side. If extra information is required when connecting two endpoints, then it must be supplied so that the connections are not ambiguous. * Line or Loop An analogue or digital access connection from a user terminal which car- ries user media content and telephony access signalling (DP, DTMF, BRI, proprietary business set). * Media Gateway unit - physical entity: An MG-unit contains an MG function and may also contain other functions, e.g. an SG function. * Media Gateway (MG) An MG terminates switched circuit network (SCN) facilities (trunks, loops), packetizes the media stream, if it is not already packetized, and delivers packetized traffic to the packet network. It performs these functions in the reverse order for media streams flowing from the packet network to the SCN. Using terminology introduced in this docu- ment, a Media Gateway hosts resources that can be broadly categorised as "endpoints" and "media resources". * Media Gateway Controller (MGC) An MGC handles the registration and management of resources at the MG. The MGC may have the ability to authorize resource usage based on local policy. Greene, Ramalho [Page 5]
Internet draft MEGACO Requirements 27 January 1999 * Media resources (or network resources?) Examples of media resources are IVR units, bridges, etc. * Profile A Profile is defined as the General Protocol requirements (or a subset of them), plus any new specific requirements needed for that protocol. A Profile provides the detailed requirements for its particular application/bearer type. * Signaling Gateway (SG) An SG is a signalling agent [1,4] that receives/sends SCN native signal- ling at the edge of the IP network. In particular the SG function may relay, translate or terminate SS7 signaling in an SS7-Internet Gateway. As shown in examples below, the SG function may also be co-resident with the MG function to process SCN signalling associated with line or trunk terminations controlled by the MG. * Trunk An analogue or digital connection from a circuit switch which carries user media content and may carry telephony signalling (MF, R2, etc.). Digital trunks may be transported and may appear at the Media Gateway as channels within a framed bit stream, or as an ATM cell stream [Editor's Note: Digital trunks do support ATM cell streams, but whether we want to say this here is for discussion]. Trunks are typically provisioned in groups, each member of which provides equivalent routing and service. 4. Architecture 4.1. MG-MGC-SG functional breakdown based on draft-greene-ss7-arch-frame-01.txt will reflect the megaco WG charter 4.2. Types of Networks The Media Gateway function includes the function of transforming media between the transport networks which it joins. This section provides a Greene, Ramalho [Page 6]
Internet draft MEGACO Requirements 27 January 1999 brief review of the character of media streams within these networks. 4.2.1. Circuit Networks In circuit switched networks the following aspects of stream handling and transport media conversion are important: * different level of abstraction of device naming, for example, phy- sical versus logical (service-related) naming hierarchies [Editor's Note: example, you may want trunk selection done in the gateway and dynamically bound to a higher layer identifier.] * changes in the attributes of flows through an endpoint from one call to another, e.g., voice (e.g. 64 kbs, 56 kbs, 48 kbs), fax, data (e.g. modem calls, H.320, H.321, H.324I) * differing encoding algorithms in use (e.g. G.711 A-law, mu-law) * device control for signal quality, e.g. echo cancellation, loss plan, etc. * channel associated signalling, e.g. DTMF, MF, R2 handling The rest of this section explains this in more detail. A reader familiar with these concepts may skip to the next section. Circuit networks carry traffic within channelized bearers of uniform size. Typically these bearers contain either digital streams operating at 64,000 bits per second (64 kbs) or analogue signals contained within a 4 kHz band. Either analogue or digital bearers may be multiplexed into larger transmission streams, leading to a physical grouping of bearers which, in the case of trunks, does not necessarily coincide with the logical grouping of the trunks into trunk groups. On a per-call basis, the bearer channels may be grouped to carry content which requires more than the 64 kbs capacity of a single channel. On the other hand, it is possible to use the capacity of a single channel to carry more than one media stream, with each possibly associated with a different call. The encoding of information within the bearer stream will typically vary on a per-call basis. The encoding is the combined result of the nature of the original content and of the circuit network through which the encoded content passes. In the public land network, the most common cases of original content are voice or modem signals carried within the full bandwidth of a single Greene, Ramalho [Page 7]
Internet draft MEGACO Requirements 27 January 1999 channel. Both may be encoded digitally according to the G.711 standard (8,000 samples per second encoded into 8 bits each). The encoding algo- rithm itself varies between North America (mu-law) and the rest of the world (A-law). Modem signals are in principle incompressible, but voice (typically in trans-oceanic operation or private long-haul networks) may alternatively be compressed into sub- channel bandwidths using various algorithms. Voice compression is normal in digital wireless networks such as GSM, but the content is transcoded into G.711 when it enters the land network. It is also possible to have original content which is of its nature a digital data stream, organized in frames rather than packets. One exam- ple of this is the digital content exchanged between H.320, H.321, and H.324I conferencing systems. Media Gateways dealing with such streams are clearly of a specialized nature. The circuit network through which the content passes also influences the nature of the signal received at the Media Gateway. Some multiplexing systems steal the low-order bit of the digital channels passing through them to provide an 8 kbs low-level signalling path (e.g. for on- and off-hook supervision). This means that any circuit network path passing through such systems offers only 56 kbs rather than 64 kbs channel capa- city. Some multiplexing systems reduce this even further, to 48 kbs. The effective capacity of a trunk terminating on the Media Gateway may thus vary on a per-call basis, depending on where in the SCN the call has originated. Call signalling offers some control over the choice of path to provide 64 kbs clear-channel or lesser-capability operation. Tones such as dial tone, busy tone, or receiver off-hook warning tone are most frequently applied in access gateways (see below). Typically, although explicit control from the Media Gateway Controller is possible, they should be terminated upon detection of an event which is detectable by the Media Gateway: the commencement of user dialing, user hang-up, or a timeout. Tones and announcements together may be applied in a pre- defined sequence, with a timeout for one leading to the application of the next. For instance, one could pass through successive timeouts from dial tone through "fast busy" through receiver off-hook warning tone and finally to deletion of the connection entirely (i.e. silence). Echoes can propagate over a circuit network between the points where analogue- to-digital conversion takes place. These echoes are notice- able and affect perceived quality of voice signals when end-to-end pro- pagation delay gets large. To counteract this effect, echo cancellation is applied to the connection on a per-call basis. Modem calls require that echo cancellation be disabled. Voice transmission quality is also improved by adding variable amounts of loss padding to the signal according to a carefully developed Greene, Ramalho [Page 8]
Internet draft MEGACO Requirements 27 January 1999 network-wide loss and level plan. This loss padding may vary by direc- tion of the media stream. 4.2.2. IP Networks >From the point of view of Media Gateway control, the key characteristics of IP networks are their connectionless nature. With respect to IP net- works, the Media Gateway performs as a combination of host and router, capable of directing packets to multiple internal and external inter- faces. In an IP network, packetized media flows are encapsulated within RTP (Real-time Transport Protocol, [2]). The RTP payload type (static pro- files are defined in [3]) indicates the encoding of the contents includ- ing * compression algorithm * packetization interval * the use of silence suppression * comfort noise insertion during silences. For each RTP stream, it is possible to set up an RTCP (Real Time Control Protocol [2]) stream in the reverse direction. This stream provides feedback on transport QoS performance and may also provide other infor- mation which the Media Gateway Controller requires. The following paragraphs illustrate the handling of packetized media streams. RTP uses port-level multiplexing of multiple RTP streams. Such multi- plexing may be used for multimedia operation. As a particular example, media content may be separated into voice and DTMF streams under a pro- posed mode of operation for H.323 Gateways when G.723.1 voice codecs are in use. (G.723.1, in contrast to G.729 at equivalent compression rates, cannot provide reliable carriage of DTMF signals.) An alternative mode of H.323 operation with G.723.1 codecs has a similar requirement that DTMF tones be detected and replaced with silence in the outgoing audio stream. However, instead of being sent as another RTP stream, they must be reported to the Media Gateway Controller (for onward transmission in signalling instead of user content). The QoS feedback on the RTCP stream may be used to determine whether performance is up to agreed service levels and, if not, whether to Greene, Ramalho [Page 9]
Internet draft MEGACO Requirements 27 January 1999 discontinue the call. It may also be analyzed by a network management function to determine bottlenecks in the network. To provide integrity and confidentiality over a shared medium, the Media Gateway may be required to encrypt outgoing packet streams and decrypt incoming ones. 4.2.3. ATM networks >From the point of view of Media Gateway control, the key characteristics of ATM networks are their connection orientation, their ability to pro- vide both circuit and packet connections, and in general the range of QoS they offer per connection. The ATM-capable Media Gateway performs as a switch with QoS functionality. ATM endpoints are more "real" than packet endpoints in that they have an identity of their own (provided by the VC identifier and possibly AAL2 slot) and, if pre-provisioned, per- sist beyond the life of any particular Media Gateway connection which uses them. If the ATM network is used to carry IP traffic then it may simply be viewed as an IP network. If it is carrying packet traffic directly over ATM the requirements for specification of RTP payload type and session number, uni- versus multi-cast, DTMF handling, RTCP usage, and the use of proprietary packet formats apply. When ATM is used to emulate cir- cuit connections, the requirements described for circuit switched net- works for content coding, the use of echo cancellation and loss padding apply. In addition, in the circuit case, the considerations described in the following paragraphs must be taken into account. ATM connections may either be switched or pre-provisioned. They may be provided either at the level of the virtual channel (VC) itself or at the level of a slot within an AAL2 connection. It is possible for ATM connection management to be handled either at the Media Gateway Con- troller or at the Media Gateway itself. For switched connections, management at Media Gateway level may go beyond allocation of local resources to perform the ATM-level signalling required to establish the connection to the remote element. Thus, depending on the local mode of operation, the designation of an ATM connection could be in terms of a VC identifier, a VC identifier plus AAL2 slot number, a wild-carded variant of either of these, a remote endpoint address, or just a remote endpoint identifier. ATM connections are inherently bi-directional, but not necessarily sym- metric. The bi-directionality means that their use to emulate circuit connections is simplified. For packet connections, the bandwidth and other properties may have to be specified at different times for the two directions of propagation. Whether this results in modification of the original connection or allocation of a new one is an implementation Greene, Ramalho [Page 10]
Internet draft MEGACO Requirements 27 January 1999 detail, but the latter possibility means that the device control proto- col must support the indication of a changed connection identifier value back to the Media Gateway Controller when a packet connection is modi- fied. ATM QoS specifications can be complex. The device control protocol is required to carry some level of QoS information, but details need further discussion. 4.3. Gateway Resources Some of the internal Media Gateway resources, such as DSPs assigned to echo cancellation, transcoding, and packetization, may be implicitly assigned by specifying the media transformations as already described. However, other internal Media Gateway resources must be explicitly assigned and connected to specific media flows within a connection [4]. Examples of these are tones, announcements, music-on-hold, wiretaps, and modems. Each resource type is associated with its own set of parameters describing how it is to be used. Tones such as dial tone, busy tone, or receiver off-hook warning tone are most frequently applied in access gateways (see below). Typically, although explicit control from the Media Gateway Controller is possible, they should be terminated upon detection of an event which is detectable by the Media Gateway: the commencement of user dialing, user hang-up, or a timeout. Tones and announcements together may be applied in a pre- defined sequence, with a timeout for one leading to the application of the next. For instance, one could pass through successive timeouts from dial tone through "fast busy" through receiver off-hook warning tone and finally to deletion of the connection entirely (i.e. silence). At one level announcements are similar to tones. However, they may be associated with additional parameters such as termination after a cer- tain number of cycles rather than a specific timeout, the language to be used, and possible variable elements (effectively, text and numbers) to be included in the announcement. The more sophisticated elements of announcement control are typically associated with Integrated Voice- Response (IVR) units, and thus are an extension to basic gateway control requirements. While announcements transmit recorded or synthesized content of finite duration, music-on-hold differs by its nature as a connection to a con- tinuous real-time stream of content. It is also initiated and ter- minated as the result of explicit call signalling rather than automatic actions at the Media Gateway. Wiretaps capture both the incoming and the outgoing media flows at a given endpoint, invisibly to other routing of those flows. In an access Greene, Ramalho [Page 11]
Internet draft MEGACO Requirements 27 January 1999 gateway, it is possible for wiretaps to be applied automatically by the Media Gateway as a result of configuration of the endpoint concerned. In general, however, it is also possible that the Media Gateway will have to connect wiretaps on a per-call basis as directed by the Media Gateway Controller. The media encoding for output at a wiretap will be constant over the life of the wiretap, so may be specified by configura- tion rather than parameters in the device control protocol. Unlike the preceding entities, modem resources may be invoked in two ways. The Media Gateway may be programmed to listen for modem tone (FAX or data) and connect automatically to the appropriate modem. Alterna- tively, the Media Gateway Controller may instruct the Media Gateway to connect an endpoint to a modem based on information received through signalling. When a modem is in use echo cancellation must be disabled. A modem assumes G.711 encoding for digital streams, but the modem start-up protocol is able to detect the other details of the encoding of media coming in from a circuit network. 4.4. Types Of Gateways The descriptions below set the stage for the network scenarios of the next section. The size ranges given, particularly the upper values, represent planning figures rather than current reality in the market- place; they are presented for use in sizing identifiers within the pro- tocol and assessing protocol scalability and performance. 4.4.1. Network Access Server A Network Access Server is a device that can attach a modem to a tele- phone circuit and provide data access to the Internet. Besides the transcoding and packet layer protocol functions involved, the Network Access Server has a role to play in the operations of user authentica- tion, authorization, and usage accounting (AAA functions). The protocol(s) used for the AAA functions themselves are out of scope. However, in some cases, the Media Gateway Controller must pass AAA- related information to the Media Gateway for onward transmission to the AAA server or proxy. Network Access Servers may terminate a number of circuits ranging from a few tens to tens of thousands. 4.4.2. Telephony Gateway (Voice Over IP Gateway) A telephony gateway is a network element that converts between the audio signals carried on the SCN and streams of data packets, or even streams Greene, Ramalho [Page 12]
Internet draft MEGACO Requirements 27 January 1999 of cells, carried over the Internet or over other packet networks. Examples of telephony gateways are: * trunking gateways, serving from a few tens to a few thousands of trunks. * residential gateways, providing a traditional analog (RJ11) inter- face for one to ten lines. Examples of residential gateways include cable modem/cable set-top boxes, xDSL devices, broadband wireless devices. * public access gateways, providing a traditional analog (RJ11) or digital PBX interface for a few tens to a few thousands of lines and trunks. * business gateways, providing a traditional digital PBX interface or an integrated "soft PBX" interface to anywhere from a single line to a few thousands of lines. The following examples are extensions to the basic telephony gateway concept. * voice over ATM gateways. * circuit switches or packet switches offering a control interface to an external call control element. 4.4.3. Combined Servers Some gateways will combine Voice over IP services and Network Access services. By taking advantage of differing patterns of usage levels for these services over the day, such gateways provide a reduction in total number of ports required to serve a given population. Size ranges for combined units will be similar to those for trunking gateways or public access gateways. 4.4.4. Interactive Voice Response Unit An Interactive Voice Response Unit (IVR) is a specialized device to which other devices will make network connections during certain phases of some calls. IVRs could be connected through the switched circuit net- work or through the packet/cell network. If the IVR is a packet-based device, then the IVR appears to be a Media Gateway on which all connec- tions are between packet endpoints and internal resources. However, since it does not lie on the boundary between the switched circuit net- work and a packet network, it represents an extension of the basic Media Greene, Ramalho [Page 13]
Internet draft MEGACO Requirements 27 January 1999 Gateway definition. The IVR requires additional control capabilities beyond those for simple announcements, because of the additional complexity of the IVR function. IVR sizes will range from a few tens to in the order of a thousand simultaneous connections. 4.5. Network Configurations for Voice 4.5.1. Trunking Gateway, In A North American SS7 Environment. +----+ |ISUP| /---------| SG |____ / SS7 ISUP +----+ \ (Sigtran) / \ | | | +-----+ (Sigtran, H.323, SIP) | |MGC |_______________ | +-----+ | | | / (Navdec) +------+ (trunks)+----+____/ |switch|=========| MG |______________ RTP +------+ +----+ Figure 1: Trunking gateway, in a North American SS7 environment. In this example, the trunking gateway unit contains only the Media Gate- way function. The Navdec-defined interface is between that function and the Media Gateway Controller. One requirement on that interface is to propagate ISUP-initiated continuity testing of the trunk connection. 4.5.2. Trunking Gateway, Channel Associated Signalling (MF, R2, J2, ...) Common associated signalling uses a set of tones and signals to convey call state transitions and call parameters such as called and calling numbers. There are two possible ways to support common associated sig- nalling. The first way is to convert the signalling locally into a stream of signalling packets, as shown in figure 2a; the second way is to use the event detection capability of the Media Gateway control pro- tocol, as shown in figure 2b. Greene, Ramalho [Page 14]
Internet draft MEGACO Requirements 27 January 1999 (Sigtran) ______+-----+ (Sigtran, H.323, SIP) | |MGC |_______________ +----+ +-----+ |CAS | | | SG | | +--|-+ / (Navdec) +------+ (CAS/MF) +--|-+____/ |switch|===========| MG |____________ RTP +------+ +----+ Figure 2a: Trunking gateway, Channel associated signalling, packets. +-----+ (Sigtran, H.323, SIP) |MGC |_______________ +-----+ | | / (Navdec) +------+ (CAS/MF) +----+____/ |switch|===========| MG |____________ RTP +------+ +----+ Figure 2b: Trunking gateway, Channel associated signalling, events. In the example of Figure 2a, the trunking gateway contains an instance of the Media Gateway function and, depending upon the implementation, an instance of a Channel Associated Signalling (CAS) Signalling Gateway function. It is assumed that the Media Gateway function has ultimate control of the circuit endpoint and does the original detection of sig- nalling events on that endpoint. In this configuration, the Media Gate- way passes notification of the signalling events to the Signalling Gate- way function, which encodes and transmits them over a Sigtran-defined interface. In the example of figure 2b, the Media Gateway function either passes notification of the signalling events directly to the MGC over a Navdec-defined interface. Whichever interface handles event reporting should also provide the means to control digit collection, to the extent that such control must be exercised on a per-call basis. At a minimum it is necessary to indi- cate that more digits are expected. Whether the device control protocol should provide detailed rules for deciding when enough digits have been collected is a matter for further discussion. Greene, Ramalho [Page 15]
Internet draft MEGACO Requirements 27 January 1999 Note that Q.931, a candidate protocol for the Sigtran interface from a trunking gateway, does provide the Progress Information Element to warn of interworking with a non-ISDN trunk, and provides procedures for pro- gressive collection of digits. However, it does NOT provide any guidance on digit analysis, assuming that such information is configured at the point of collection. Regardless of how the signalling events are reported to the MGC, the Media Gateway function is able to use them itself to determine, for instance, when to terminate an announcement or tone. 4.5.3. Access Gateway, ISDN Signalling. +------+ (Sigtran, H.323, SIP) ____|MGC |_______________ (Sigtran) / +------+ +----+ | |ISDN| | ___| SG | | (Navdec) Q.931 / +----+ / +---+ / +----+____/ |PBX|======-----| MG |______________ RTP +---+ ISDN Trks +----+ -- Figure 3: Access gateway, ISDN signalling. In Figure 3, the access gateway combines the Media Gateway function with a Q.931 Signalling Gateway function instance. Because the Q.931 signal- ling comes in on a channel which is segregated from the trunks to which it relates, it is simplest to view it as being routed directly to the Signalling Gateway function without the intervention of the Media Gate- way function. 4.5.4. Residential Gateway. _+-----+ (Sigtran, H.323, SIP) |MGC |_______________ +-----+ | | / (Navdec) +------+(RJ11/analog)+----+____/ |phone |=============| MG |_____________ RTP +------+ +----+ -- Figure 4a: Residential gateway, events Greene, Ramalho [Page 16]
Internet draft MEGACO Requirements 27 January 1999 (Sigtran) ______+-----+ (Sigtran, H.323, SIP) | |MGC |_______________ +-------+ +-----+ |DP/DTMF| | | SG | | +----|--+ / (Navdec) +------+(RJ11/analog)+--|-+_____/ |phone |=============| MG |_____________ RTP +------+ +----+ -- Figure 4b: Residential gateway, packets The residential gateway presents a situation very similar to the trunk- ing gateway with channel associated signalling. Signalling events to and from the line can be passed either over the Navdec-defined interface (figure 4a) or via the Sigtran- defined interface and DP/DTMF Signalling Gateway function instance (figure 4b). As with the trunking gateway, per-call control of digit collection must be provided over the reporting interface. In any event, line signalling events can be processed by the Media Gateway function to determine, for example, when to stop dial tone or busy tone. 4.5.5. ATM Trunking Gateway +----+ |ISUP| /---------| SG |____ SS7(ISUP+) +----+ \ (Sigtran) / \ | | | +-----+ (Sigtran, H.323, SIP) | |MGC |_______________ | +-----+ | | | ATM / (Navdec) +------+ (trunks)+----+____/ |switch|=========| MG |______________ RTP +------+ +----+ Figure 5: ATM Trunking gateway. In this example, the trunking gateway unit contains only the Media Gate- way Function, as in figure 1. Here, though, the incoming trunks are ATM Greene, Ramalho [Page 17]
Internet draft MEGACO Requirements 27 January 1999 trunks, and the signalling to the SG is ISUP plus additional elements carrying ATM addressing information. 4.6. Network Configurations For Data 4.6.1. NAS In A North American SS7 Environment +----+ |ISUP| __(SS7)---| SG |____ / +----+ \ (Sigtran) / \ | | | +-----+ | |MGC | | +-----+ | | | / (Navdec) +------+ (trunks)+----+____/ |switch|=========| MG |____________ AAA | | | |____________ User packets +------+ +----+ -- Figure 6: NAS in a North American SS7 environment. This looks similar to the SS7/ISUP trunking gateway case with two excep- tions. First, instead of an RTP-encapsulated media stream, the gateway sends and receives user and associated control packets. For instance, data and control packets may be encapsulated on permanently provisioned layer 2 tunnels, requiring the MG to switch packets on trunk endpoints to layer 2 endpoints. Secondly, figure 6 distinguishes a AAA interface which may either connect to the MGC function or to a AAA server or proxy located elsewhere. In the latter case, the MGC has to pass information such as the number dialed in an incoming call down to the MG for for- warding via the AAA interface. 4.6.2. Network Access Server, Channel Associated Signalling Greene, Ramalho [Page 18]
Internet draft MEGACO Requirements 27 January 1999 (Sigtran) ______+-----+ | |MGC | +----+ +-----+ |CAS | | | SG | | +--|-+ / (Navdec) +------+ (CAS/MF) +--|-+____/ |switch|===========| MG |_________ AAA | | | |_________ User packets +------+ +----+ -- Figure 7: NAS with Channel associated signalling (MF, R2, J2, This again is similar to the corresponding trunking gateway case, with the data related differences pointed out in the previous case. As in the telephony case, there are two option for signalling: * Conversion from CAS to a packet based protocol, and transmission through an SG, * Transmission of CAS signalling events through the Media gateway control protocol. 4.6.3. Network Access Server, ISDN signalling. ____+-----+ (Sigtran) / |MGC | +----+ +-----+ |ISDN| | ___| SG | | Q.931 / +----+ / (Navdec) +---+ / +----+____/ |PBX|======-----| MG |____________ AAA | |ISDN Trunks| |____________ User packets +---+ +----+ -- Figure 8: NAS with ISDN signalling. This is like the access gateway case previously illustrated, with the data- related differences. 4.6.4. ATM NAS Greene, Ramalho [Page 19]
Internet draft MEGACO Requirements 27 January 1999 +----+ |ISDN| (SS7-ISUP+)-| SG |____ / +----+ \ (Sigtran) / \ | | | +-----+ | |MGC | | +-----+ | | | ATM / (Navdec) +------+ (trunks)+----+____/ |switch|=========| MG |____________ AAA | | | |____________ User packets +------+ +----+ -- Figure 9: NAS with ATM signalling. This is like the access gateway case previously illustrated. Here, though, the incoming trunks are ATM trunks, and the signalling to the SG is ISUP plus information elements carrying ATM addressing information. 4.7. Specific functions assumed within the MG NOTE: this list will drive the general protocol requirements MGs can be architected in many different ways depending where the media conversions and transcoding (if required) are performed, the level of programmability of endpoints, how conferences are supported, and how associated signalling is treated. The functions assumed to be within the MG must not be biased towards a particular architecture. For instance, announcements in an MG could be provided by media resources or by the endpoint itself. Further, this difference shall not be visible to MGC, the MGC must be able to issue the same request to two different implementations and achieve the same result. Endpoints and connections are clearly the cornerstone of the MG. The operation of other media resources must be captured only as they relate to either connections or endpoints in an implementation independent manner. Depending on the application of the MG (e.g., trunking, residential), some functions will be more prominent than others, and in some cases functions may even disappear. Although media adaptation is the essence of the MG, it is not necessary Greene, Ramalho [Page 20]
Internet draft MEGACO Requirements 27 January 1999 for every connection to involve media adaptation. A connection may join two endpoints of the same type (i.e., the MG behaves as a switch). The required media conversion depends on the media type supported by the connected endpoints. In addition to media adaptation function, endpoint resources have a number of unique properties , for instance: * certain types of endpoints have associated signalling capabilities (e.g., PRI signalling, DTMF), * some endpoints perform maintenance functions (e.g., continuity tests), * the MGC needs to know the state changes of endpoints (e.g., a trunk group going out of service), * the MG retains some control over the allocation and control of some resources (e.g., endpoint name space: RTP port numbers). Therefore, an MG realizes connections (point-to-point and confer- ences), and supports several endpoint functions. These functions include media conversion, resource allocation and management, and event notifi- cations. Handling endpoint associated signalling is either done using event notifications, or is handled by the signalling backhaul part of a MG-unit (i.e. NOT directly handled by the MG). MGs must also support some level system related functions, such as, establishing and maintaining some kind of MG-MGC association. This is essential for MGC redundancy, fail- over and resource sharing. Therefore, an MG contains these functions: * Reservation and release, of endpoints * Ability to provide state of endpoints * Maintenance of endpoints - It must be possible to make maintenance operations independent of other endpoint functions, for instance, some maintenance states should not affect the resources associated with the endpoint. Examples of maintenance functions are loopbacks and continuity tests. * Connection management, including connection state. All resources (i.e., endpoints and media resources) may participate in a connec- tion. * Media processing, using media resources: these provide services Greene, Ramalho [Page 21]
Internet draft MEGACO Requirements 27 January 1999 such as transcoding, conferencing, IVR units. Media resources may or may not be directly part of endpoints. * Location resolution for resources (wiretap bridges, conference bridges, announcements,) - they are either internal, and called media resources, or associated with particular endpoints, or they are resources external to the MG * automatic setup of media connections to external resources without specific direction from the MGC - (if it is without direction from the MGC, whether this is provided or not should probably be optional) * Incoming digit analysis for endpoints, interpretation of scripts for endpoints * Event detection, event insertion for per-channel signalling * Ability to configure signalling backhauls * Management of the association between MGC and the MG, or between the MGC and MG endpoints 5. General Protocol Requirements Requirements are classified into General Protocol requirements and Profile-Specific requirements. The General Protocol requirements provide a framework (a base?) for the protocol. The detailed requirements are reserved for the profile-specific requirements sections. 5.1. Connection Topology 5.1.1. Endpoints and connections An endpoint is a point of entry and/or exit for media flows relative to the MG. Connections must be allowed to be created between any number of end- points, and between any type of endpoint in a MG. These connections can be unidirectional, bi-directional, or inactive. If the endpoints in a connection produce/consume the same types of media units or streams then the MG operates as a switch (i.e., connection input endpoints to output endpoints in point-to-point or point-to- Greene, Ramalho [Page 22]
Internet draft MEGACO Requirements 27 January 1999 multipoint). If the endpoints have dissimilar media units or streams then the endpoints and, possibly, other resources in the MG, perform the adaptation function. In this case it is possible that the connection model needs to support an arbitrary connection tree. For example, a connection may require resources for 3-way connection, transcoding or announcements. These resources are named "media resources". They may be specified in the connection set up, but depend- ing upon the capabilities of the MG, some of these media resources may be brought in without the participation of the MGC. In any case, the MGC must be able to ask for connections between an endpoint and a media resource, if media resources are visible to the MGC. An MG must able to provide internal duplication or multiplication of flows for more than one endpoint if this is a requirement of a particu- lar type of MG. Connections are, in general, independent of the functions and state of the endpoints that they connect. Specific behaviours may be added to the connections, for instance, to delete a connection if an endpoint is put in maintenance state or goes out of service. It is expected that connections will require multiple MGC-MG exchanges with intervening call signalling; however, it should be possible to define a connection with a single message. This message must therefore be able to carry configuration or programming information for both end- points and other media resources that may be required to establish the connection. Connections are established as a result of a request from the MGC. There are two ways they could be taken down: * Connections may be taken down unilaterally by the MG. In this case the MGC must simply acknowledge that the connection has disappeared and proceed according to its service logic (e.g., clear a call, try to reestablish the service). * The MG may request the MGC to release a connection. As a result the MGC may agree to take the connection down, leave it as is or modify it. Modifications of an existing connection such as use of higher compression to compensate for insufficient bandwidth or changing transport network connections may, for instance, be used to maintain QoS of an established service without making the end- user aware of resource changes. 5.1.2. Media resources Media resources are in many ways similar to endpoints. They may be Greene, Ramalho [Page 23]
Internet draft MEGACO Requirements 27 January 1999 programmable and participate in connections. For that reason, media resources must use the same hierarchical naming of endpoints. It is not necessary for an MG to be modeled as having media resources, for instance, conference and announcement capabilities could be directly associated with and endpoint. However, the more general approach of hav- ing a separate functional block should be preferred since it does not preclude implementations in which it is necessary to address other resources in the MG besides endpoints. For instance, conferences can be handled in at least three ways: * 1-The MGC does not know about the media resource, it just keep adding parties to the call * 2-The MGC selects and configures the conferencing resource in the MG and explicitly adds each new party to the conference resource. * 3-The MGC knows that the conference will have, say, 10 partici- pants and will specify this in the set-up connection request, allowing the MG to autonomously select and configure the appropriate conferencing resource. This example illustrates the following: method 1- is generic but most certainly lead to bad performance, method 2- is quite acceptable with the exception that it suggests an implementation, method 3- seems to be the most appropriate since the MG will be capable to determine the needed resources to achieve good performance without assuming an imple- mentation. Deciding what is a media resource that is visible to the MGC, or what is the best mechanism to allow an MG to effectively manage its resources without exposing their every detail is the biggest challenge. It is clear that more work is still required in this area. 5.2. Event detection requirements Since it is not possible to characterize all resources hosted by an MG with the same programming or configuration mechanisms, the protocol should be able to support multiple mechanisms, such as passing confi- guration parameters to a resource or downloading executable behaviours. The protocol should also accommodate the definition of many distinct Greene, Ramalho [Page 24]
Internet draft MEGACO Requirements 27 January 1999 resources that offer different control interfaces, without modification of the operation of the base protocol. Endpoints can be programmed for several reasons, programming an endpoint might be related to handling of signalling for an endpoint, or for media conversion, local bandwidth management or maintenance functions. It can help provide more scalable and efficient solutions. Programmability of endpoints is used in a broad sense, it does not imply only the capability to download code into a device, but includes other means such as passing a URL, supplying parameters to an already loaded function, obtaining parameters from a profile or providing a digit-map, or even initiating a Daemon Interface. Programming fulfills both functional requirements and architecture sca- lability. For instance, being able to program TDM interfaces to recog- nize fax modulation, data or voice is a functional requirement. 5.3. Scalability Of Media Gateways And Controllers Size ranges for Media Gateways of various types were given above. The protocol should support Media Gateway Controllers whose domain includes from a few tens to a few million endpoints, and from one or two to several million Media Gateways. The protocol should permit the process- ing at reasonable cost of maximum call rates of the order of several hundred per second at the Media Gateway Controller. Media Gateway Controllers may be implemented as distributed systems, using multiple network interfaces and multiple IP addresses. The proto- col shall not include assumptions that control messages to a gateway shall always come from the same IP address. The protocol should allow endpoints to accumulate signalling events or collect strings of digits. This is a scalability consideration. 5.4. Distribution Of Intelligence/ Flexibility /Signalling Terminations 5.4.1. Distribution Of Intelligence The device control protocol should support Media Gateways of both greater and lesser intelligence. As an example, in some cases the Media Gateway is able to manage its own resources, as for instance if it is able to select an available outgoing trunk given the trunk group name. This sort of intelligence is essential to meet the upper range of sizes suggested in the previous paragraph for Media Gateway Controllers. Greene, Ramalho [Page 25]
Internet draft MEGACO Requirements 27 January 1999 In other cases the Media Gateway Controller will do the detailed manage- ment of Media Gateway resources; in the trunking example, the MGC will specify the exact circuit endpoint to use in an outgoing call. The MG may have the power to infer behaviours required of the devices it hosts (e.g., tone collection, IVR interworking). It is also possible that distributed call processing over two MGs may be required to address issues such as post-dial delay and open dialing plans. This needs to be developed further. [Editor's Note: this is an area in which not much debate has occurred, therefore the protocol requirements might not yet be completely identi- fied.] 5.4.2. Flexibility * When MGC-MG is carried on an IP network, the IP network shall be assumed to be a generic shared IP: proximity assumptions are not allowed. Need to allow upgrading of different network entities indepen- dently. MG should be able to indicate a temporary resource unavailability. Need to allow for signalled flow characteristics on circuit as well as on packet bearer connections. Need to allow multiple MGCs to have active access to the same MG [Editor's Note: needs further discussion]. 5.4.3. Signalling Terminations In the MGC/MG architecture it is possible to terminate signalling either at the MGC or MG-unit. The MGC may terminate signalling coming from a separate SG or signalling that is "backhauled" from a Signalling Gateway function instance in the MG-unit. These two cases are identical from the MGC perspective. However, "backhauling" signalling into the MGC is out- side the scope of the MGC-to-MG protocol. The MG should support delegation of client types, that is, it could be instructed to place calls using diverse signalling mechanisms out of an endpoint device (e.g., H.323, SIP, etc.). The MGC-to-MG protocol may provide the characterization of the signalling to be used by the end- point. Greene, Ramalho [Page 26]
Internet draft MEGACO Requirements 27 January 1999 Endpoints shall not be assumed to be RTP/UDP/IP. They could also use ATM virtual circuits. The protocol must be able to install various types of connections, such as simplex, duplex, N-points (multiple legs) and multipoint (using net- work level multicast services). 5.5. Extensibility It is essential that the protocol be both modular and extensible. Not all implementations may wish to support all of the possible profiles for the protocol. This will permit lightweight implementations for special- ized tasks where processing resources are constrained. .LP The protocol shall provide the means whereby a controller can determine the capabilities supported by a particular Media Gateway. In particular, independent upgradability of network components should be supported (when one node speaks a newer version of the protocol and its peer still has an older version). In that case unrecognized verbs that are marked as "optional" can be ignored in a message, while messages with unrecognized "mandatory" parameters must be rejected). The protocol shall support backwards compatibility as new versions are released. The protocol shall allow the possibility of vendor-specific extensions/profiles. 5.6. Reliability The protocol must provide for reliability mechanisms to be put in place. In certain cases, the MG may have some level of autonomy to complete some types of connections. For instance, an MG may be autonomous within a call, to the extent that it handles some of the bearer signalling functions (e.g., choosing and dynamically creating ATM trunks, negotiat- ing with far end for AAL2 CID values) and determining the signal pro- cessing required (e.g., detecting fax and switching to fax demodula- tion). For example, a NAS may have all the means to provide a basic call in the absence of an MGC. Another requirement may be that a single MG needs to be able to be used by more than one MGC without the MGCs requiring knowledge of each other. This may be necessary for competing service providers using the same MG Greene, Ramalho [Page 27]
Internet draft MEGACO Requirements 27 January 1999 to get to a trunk member or a loop, or because of specialization of MGCs for certain types of signalling. [Editor's Note: this is an area in which not much debate has occurred, therefore protocol requirements might not yet be completely identified.] Need audits to return actual states in MG rather than requested states. Need audits to return available resources at MG, for example, which end- points are out of service, which are in service. Also should be able to detect mismatches of perceived resource state between MG and MGC MGC and MG should be able to provide each other with booting and reboot indications, as well as what resources are available, what MG's confi- guration is. MGC and MG able to detect loss of connectivity. Use names rather than physical addresses to locate network entities. Allow for different control relationship profiles, then define a very few that cover the majority of industry needs. Reporting of unexpected endpoint state, of endpoints generating "showers" of supervision events. Explicit activation of endpoints, and of endpoint programs by MGC on boot/reboot Appropriate handling of end- point program activity status on failover. Need to correlate commands and responses, detect duplicate transmis- sions, deliver events in order. 5.7. Performance Requirements E.500 series recommendation that specifies performance requirements for telephony GW operations (numbers given in that Recommendation should be used as design targets (particularly to guard against specifying overly-stringent response times for the protocol). When used in a "carrier" configuration, the device control protocol has QoS requirements which are similar to those for other telephony signal- ling protocols. Since signalling is shared by a large number of voice paths its availability and performance is wide reaching. For QoS, ensure requirements of control protocol are separate from requirements of con- trol connection. Need to consider critical resource consumption in design of the Greene, Ramalho [Page 28]
Internet draft MEGACO Requirements 27 January 1999 protocol. Need to consider protocol PDU sizes vs transport MTU sizes in designing the protocol. Need to support peak calling rates in the order of 140 calls/second at the MGC. Need to consider cost of encryption when designing the wireling proto- col. Need to reduce the number of unnecessary iterations between MGC and MG, for example, minimize messages required upon boot/reboot. Need to respect time constraints on processing of individual control messages. Need to allow for default/provisioned settings so that commands need only contain non-default parameters Endpoint programmability is a performance consideration. For continuity tests, need to minimize the number of messages required. Constraints are a maximum of 200ms cross-MGC IAM propagation delay, and a maximum of 200ms from end of dialling to IAM emission. 5.8. Resource Reservation (Editor - where does this section belong?) Call directionality, and resources the call needs immediately, and during the life of the call must be defined and preserved independently from whether the resource is reserved, activated/mute or in maintenance. For example, if an MGC even- tually wants a bidirectional path, but currently wishes to mute the for- ward path, then the forward path must still be reserved. Thus, it must be possible to specify that the MG either holds the for- ward path while it sets up the bidirectional path or specify that the forward path does not have to be held . 6. General Management Requirements 6.1. MG Configuration Configuration refers to the number, type, state and local associations of devices hosted by the MG. Greene, Ramalho [Page 29]
Internet draft MEGACO Requirements 27 January 1999 The MG may be required to offer its configuration to MGC or to satisfy MGC requests asking for its configuration This may occur in relation to the following actions: * upon initialization: the MGC may need to learn the capabilities of an MG that is just agreeing to control, for instance endpoint dev- ices that are being reset, etc. (Fail-over must be considered in here) * upon recovery of MGC/MG association or even as a means of recover- ing an association * for resource management purposes: This means real-time notification of the availability status of resources needed for call processing. Depending on the size and function of the MG it is possible that the configuration exchange between the MGC and MG be impractical or unneces- sary. Therefore, while this may be a useful overall goal, the base pro- tocol MUST be able to operate with an understanding of mutually pro- visioned configurations (i.e. by another means such as explicit provi- sioning) rather than via MGC/MG protocol. 6.2. Endpoint configuration 6.3. MG-MGC association requirements The following is the list of requirements for the MG-MGC association: * An MG-MGC association exists between an MGC and MG endpoints * The protocol should also support the model of an MGC to MG associa- tion. Establishment and management of MG-MGC association is for further study (Vendor extension or another protocol) * An MGC can be specified by a number of mechanisms, e.g. logical name, address * MG-MGC standby associations are for further study * Either end can rapidly detect loss of contact on either an active or an inactive association * Procedures defined for MG startup, recovery actions on detection of control failure, when MG is required to maintain state and when it Greene, Ramalho [Page 30]
Internet draft MEGACO Requirements 27 January 1999 isn't, graceful control switchover in the absence of failure * More than one MGC in active control of the same MG - for further study * MGC can request MG to reset its endpoints and connections (this is NOT a reboot request) * The MGC may indicate to the MG the rate at which it can handle requests (or may be done using windowing techniques, exponential backoff) * MG should be able to declare resources to the MGC upon creation of association - for further study * An MGC must be able to tell an MG that it cannot handle any more requests - for further study Requirements to be consolidated with the above list: ,LP 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 associa- tion with an alternate Media Gateway Controller if its currently associ- ated controller becomes unavailable. It shall be possible for either the Media Gateway or the Media Gateway Controller to detect loss of the control association. 6.4. Resource management requirements * MG can indicate resource exhaustion, for example, the MG can indi- cate to the controller that it lacks sufficient resources to carry out a given command. * MGC can audit status of individual endpoints and connections - using MIB, details for further study * Circuit endpoint registration with MGC - using MIB * Setting of default behaviours, including dialing plans - using MIB * Notification of failure and recovery of major components - part of the protocol, and using MIB Greene, Ramalho [Page 31]
Internet draft MEGACO Requirements 27 January 1999 * Administrative blocking and release of circuit endpoints (needed for SS7) (see VB5.2) * Test capabilities (e.g. loopbacks through the MG to test DSP opera- tion) * A common identifier to mark connections/resources related to one call is required for controlling, billing and monitoring the MGC's network-wide functions. * MGC can request bulk audits - for further study Requirements to be consolidated with the above list: 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 Controller to audit the com- mitment 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 con- nection state of connections in Media Gateways with which it is associ- ated. It shall be possible for the Media Gateway to report changes in opera- tional 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. 6.5. Accounting requirements A common identifier to mark connections/resources related to one call is required for controlling, billing and monitoring the MGC's network-wide functions. For each call, the MGC needs to be able to account for the following: Greene, Ramalho [Page 32]
Internet draft MEGACO Requirements 27 January 1999 * Number of IP packets sent/received * Number of bytes sent/received * Bandwidth used - in case of ATM ABR, VBR, peak usage, average usage. Thus this information needs to be available to the MGC using the megaco protocol. This information would then be passed by the MGC to the appropriate accounting server. How this is done is outside the scope of the megaco protocol. 7. General Security Requirements The protocol shall allow for mutual authentication at the start of an MGC-MG association , and for preservation of the integrity and confiden- tiality of control messages once the association has been established. Security requirements are integrity, defense against denial of service, authentication of source, authority. When the device control protocol is carried on an IP network, authenti- cation and encryption should be separate from the device control proto- col itself. For IP use IPSEC's authentication headers RFC 1826. If con- trol privacy is required (unlikely for trunk Gateways) then use RFC 1827. Both MG and MGC must be able to authenticate the source of messages received, and be able to ensure that the commands come from sources authorized to use the resources affected Privacy of control messages must be maintained. Protocols must operate across untrusted domains in a secure fashion. Non-repudiation on the context of customer-located MG talking to a net- work operator's MGC 8. Profile-specific Requirements Table 1: Endpoints vs Applications Greene, Ramalho [Page 33]
Internet draft MEGACO Requirements 27 January 1999 Types of Endpoints Applications =================================================================== Trunk+ISUP NAS, trunking/access VoIP, VoATM, VoFR Trunk+MF NAS, trunking/access VoIP, VoATM, VoFR ISDN NAS, trunking/access VoIP, VoATM, VoFR Analogue IP, VoATM, VoFR Endpoint in a restricted IP, VoATM, VoFR Capability Gateway Application endpoint (or Network IVR, Announcement Server, Voice Resource?) Recognition Server, Wiretap,. . . Network/Media resources: - naming of announcements to be played: for example, announcementx@domain - need to resolve the address, and then who decides whether to set up an IP connection to a specialized server, or whether it can be handled by a media resource, or by an endpoint in the MG? - it may be an endpoint in a MG, or the MGC could set up the connection to an AS, or the MG could set up the connection to an AS. In any case, we need a location independent specification of network resources The endpoints listed in Table 1 can be packaged into different types of Media Gateways. Examples are listed in the following sections. How they are packaged is outside the scope of the general protocol, but would be defined by different protocol profiles. The General megaco protocol must support all types of endpoints listed above. The WG needs to decide which applications or types of Media Gateways need to be covered by Profile- specific requirements in the first RFC, and which will go in separate RFCs. 8.1. Media-specific Profiles This section describes requirements for handling endpoints attached to specific types of networks. 8.1.1. Endpoint requirements for PSTN (ISUP) (Circuit) - applicable to Trunking GW, Access GW, Greene, Ramalho [Page 34]
Internet draft MEGACO Requirements 27 January 1999 MGC can specify ingress and egress coding (which presumably are identi- cal) In general, if something is set by a global signalling protocol (e.g. ISUP allows mu-Law or A-Law to be signalled using ISUP) then it must be settable by this device control protocol. ===> need to go through each endpoint and see what signalling can change and list it here as an endpoint attribute Endpoint attributes: * Echo cancellation, encoding, encrypting * The following requirements come from the discussion of circuit networks. The device control protocol MUST allow: * identification of a specific circuit endpoint * for calls outgoing to the circuit network, identification of a cir- cuit group with the indication that the Media Gateway must select and return the identification of an available member of that group * specification of the default encoding of content passing to and from a given circuit, possibly on a logical or physical circuit group basis * specification at any point during the life of a connection of vari- able aspects of the content encoding, particularly including chan- nel information capacity * specification at any point during the life of a connection of loss padding to be applied to incoming and outgoing media streams at the circuit endpoint * specification at any point during the life of a connection of the applicability of echo cancellation to the outgoing media stream. The device control protocol MAY also allow: * specification of sub-channel media streams * specification of multi-channel media streams. Greene, Ramalho [Page 35]
Internet draft MEGACO Requirements 27 January 1999 8.1.2. Requirements for Packet capabilities: * MGC can specify transport QOS parameters . * MGC can specify ingress and egress coding (i.e. the way packets coming in and out are encoded) (including encryption). * MG can report flow QOS has dropped below threshold on a given net- work connection * MG can report that it has renegotiated codec for cause -for further study * MGC can request and receive packet QOS statistics when connection is cleared * MGC can request and receive packet QOS statistics at any time dur- ing connection * MGC can specify near and far-end ports and other session parameters for RTP, RTCP * MGC can ask MG to specify near-end ports and possibly other ses- sion parameters for RTP, RTCP * On Trunking and Access Gateways, resources capable of more than one active connection at a time must also be capable of mixing and packet duplication The following requirements come from the discussion of packet networks. The device control protocol MUST allow: * specification of parameters for outgoing and incoming packet flows at separate points in the life of the connection (because far-end port addresses are typically obtained through a separate signalling exchange before or after the near-end port addresses are assigned) * the possibility for each Media Gateway to allocate the ports on which it will receive packet flows (including RTCP as well as media streams) and report its allocations to the Media Gateway Controller for signalling to the far end * the specification at any point during the life of a connection of RTP payload type and RTP session number for each RTP-encapsulated media flow * indication that the Media Gateway must detect DTMF on the circuit Greene, Ramalho [Page 36]
Internet draft MEGACO Requirements 27 January 1999 side of a connection, replace it by silence, and either report the detected DTMF to the Media Gateway Controller or transmit it as a separate RTP flow * specification of parameters to be used by the Media Gateway to negotiate QoS with the packet/cell network * The need for the ability to specify whether outgoing flows are to be uni-cast or multi-cast is a matter for discussion, since on the IP network this information is implicit in the destination address. * enabling/disabling of the reporting of QoS statistics * reporting of QoS statistics on a per-packet-stream basis at the end of a connection and be able to supply them to the controller upon request any time during the connection * invoking of encryption/decryption on media flows and specification of the associated algorithm and key. The device control protocol SHOULD also allow: * the MGC to configure non-RTP (proprietary or other) encapsulated packet flows. 8.1.3. Endpoint requirements for ATM applicable to Trunking GW, Access GW, Endpoint attributes: * VC identifier, * VC identifier plus AAL2 slot, and wildcarded variant of these, * remote endpoint network address, remote MG name - these are needed if the MG is to manage inter-MG connectivity (if this were left to the MGC only, then it would be like an MGC receiving routing update packets from everywhere, and then setting source routing options on a call by call basis - not something we would want). * QoS for the network connection for the connection as a whole, and by direction, means to change QoS as a whole and by direction Greene, Ramalho [Page 37]
Internet draft MEGACO Requirements 27 January 1999 The following requirements come from the discussion of ATM net- works. The device control protocol MUST allow: * specification of an ATM endpoint which is to be assigned to a Media Gateway connection as a VC identifier, a VC identifier plus AAL2 slot, a wild-carded variant of either of these. A remote endpoint network address, or a remote Media Gateway name could be used also when the MG can select the Virtual Circuit and change the VC during the life of the connection by using ATM signalling. * indication by the Media Gateway of the VC identifier and possibly AAL2 slot of the endpoint actually assigned to a connection * means to refer subsequently to that endpoint * means to indicate the QoS required for the network connection, both for the connection as a whole (e.g. circuit versus packet usage) and by direction (e.g. specific requirements for bandwidth) * means to change some aspects of QoS by flow direction at different times throughout the life of the connection * specification of parameters associated with the media format and handling as appropriate for circuit or packet operation. 8.1.4. Endpoint requirements for Frame Relay - applicable to Trunking GW, Access GW, 8.1.5. Requirements for endpoints in an Analogue Gateway 8.1.6. Requirements for endpoints in an ISDN Gateway 8.2. Application-Specific Requirements 8.2.1. Trunking Gateway A Trunking Gateway is an interface between SCN networks and Voice over IP or Voice over ATM networks. Such gateways typically interface to SS7 or other NNI signalling on the SCN and manage a large number of digital circuits. Greene, Ramalho [Page 38]
Internet draft MEGACO Requirements 27 January 1999 Trunk circuit bearers: TDM Core ATM VC Core ATM AAL2 slot Core Types of connections: Circuit-IP Packet Core Circuit-circuit (Needed in case of DSP/ packet side resource shortage or to reroute to a NAS) Core Circuit loopback (Needed for SS7 COT) Core Packet-side loopback, loopbacks in either direction back into MG (for testing) Extension IP-side multicast Core Circuit-side n x 64kbs, subrate, multirate Extensions Media resources: Wiretap Core Locally-provided announcements Core Locally provided tones (e.g. reorder) Core For tones and announcement, specification of events which terminate their application if disconnection is done under MG control Extension Reporting/generation of signalling: Per-trunk CAS signalling (DP, DTMF, MF, R2, J2) Core, Sigtran as vendor specific choice SS7 ISUP or regional variants Out of scope (Sigtran) ISDN Out of scope (Sigtran) DTMF capabilities: MGC can request reporting of detected DTMF Core MGC can request packaging of detected DTMF in separate RTP stream Core Test tones: MGC can request circuit-side test tone generation and detection (SS7 continuity, 105 test line) Core Resource selection: Can ask MG to select outgoing TDM circuit from logical group (e.g. by name wildcarding) Core Greene, Ramalho [Page 39]
Internet draft MEGACO Requirements 27 January 1999 8.2.2. Access Gateway An Access Gateway connects UNI interfaces like ISDN (PRI and BRI) or traditional analogue voice terminal interfaces, to a Voice over IP or Voice over ATM network. Greene, Ramalho [Page 40]
Internet draft MEGACO Requirements 27 January 1999 Media Gateway scope: Single line MG Core Multi-line MG Core Circuits: Analogue lines Core Digital lines (ISDN) Core IP packet Core TDM trunks Core ATM VC trunks Extension ATM AAL2 trunks Extension Types of connection: Any type of endpoint can connect to any type of endpoint (e.g., line-packet, line-line for local connections, line-trunk) Core Telephone signalling: Residential DP Core Residential DTMF Core ISDN Out of scope (Sigtran) Business set Extension Coin phone Extension Media resources: Locally-provided announcements Core Locally provided tones (e.g. busy, ringback) Core For tones and announcement, specification of events which Terminate their application if disconnection is done under MG control Extension Per-line programmability: Configure sigtran vs. megaco reporting of signalling events Out of scope or MIB (provisioning) Enable/disable/Update digit collection instructions Core Procedures and messages to support explicit MGC control of teardown of connections Core Procedures and messages to support scripts, profiles (e.g., automatic teardown by MG when on-hook detected) Core Other programming methods Extension DTMF capabilities (following call setup): MGC can request reporting of detected DTMF Core MGC can request packaging of detected DTMF Greene, Ramalho [Page 41]
Internet draft MEGACO Requirements 27 January 1999 in separate RTP stream Core Proxying of the device control protocol Extension 8.2.3. Trunking/Access Gateway with fax ports 8.2.4. Trunking/Access Gateway with conference ports (Multipoint Pro- cessing Unit) 8.2.5. Network Access Server requirements A NAS is an access gateway which converts modem signals from an SCN net- work and provide data access to the packet network. Assumed to occupy position in network similar to trunking gateway. Hence must handle same set of trunk circuit bearers, same trunk signal- ling. Connection types: Circuit-modem (onward routing implicit) Circuit-specified L2TP tunnel via modem Circuit-circuit (reroute to VoIP MG) Media resources: Data modem (implicit) Test tones: MGC can request circuit-side test tone generation and detection (SS7 continuity, 105 test line) Resource selection: Can ask MG to select outgoing TDM circuit from logical group (e.g. by name wildcarding) Authentication would be handled by the NAS or MGC dialoguing with an AAA server. The appropriate AAA protocol would be used for this (Radius, Diameter, ) It is not within the scope of the megaco protocol. The megaco protocol would need to be able to gather authentication informa- tion required by the AAA Server, for example, username, calling number, called number, PIN number based on an IVR prompt Greene, Ramalho [Page 42]
Internet draft MEGACO Requirements 27 January 1999 The MGC should be able to let MG know how it wants it to communicate the authentication parameters to a AAA server. Service authorization is also out of scope for the megaco protocol. The MGC could make service authorization decisions and refuse to set up a call, but how the decision is made is not within the scope of the proto- col. However, NAT mapping, port filters or tunnel parameters for a par- ticular user may need to be communicated to the MG. QoS - the megaco protocol needs to be able to signal QoS parameters to the NAS. It should be able to specify QoS parameters based on the authentication parameters. It should be able to describe a type of connection in terms of: Bandwidth usage (peak, average), packet loss, latency, .. Resource management - The MG should be able to report the following for an endpoint either over a restart or after an upgrade: * Provide configuration information on the endpoints, for example, if it will be a PPP port then provide info on IP address, ability for connection type (V.34/V90/..), AAA mechanism (RADIUS/DIAMETER/..), access type (PPP/SLIP/..) * mapping between an endpoint and resources associated with it, e.g., shelf#, port#, chassis#(?), trunk (T1/PRI) * Notify when endpoint is out of service * Be able to test the endpoint or a resource associated with the End- point * in general we need bidirectional service messages (need to expand on this) * need real-time status messages * need triggered registration messages (triggered after reboot) Operations Continuity checks which instruct the NAS to loopback or receive loop- backs (needed also for voice) Greene, Ramalho [Page 43]
Internet draft MEGACO Requirements 27 January 1999 8.2.6. Residential Gateway A Residential Gateway is an access gateway for a small number of voice terminals that can be co-located with a cable modem or set top box. List here specific requirements for a residential gateway. 8.2.7. Restricted Capability Gateway A Restricted Capability Gateway is an access gateway that is a voice terminal with one to five or so lines. List here specific requirements for a restricted capability gateway. 8.2.8. Analogue Gateway 8.2.9. ISDN Gateway 8.2.10. IVR Unit An IVR unit provides automatic voice response and switching services in response to DTMF signals from the SCN. A scripting requirement for IVR would involve IVR-controlling extensions to basic scripting packages 8.2.11. Other Application-specific Gateways (Announcement Server, Voice Recognition Server) 9. References ***references are not complete*** [1] Cuervo, Greene, Holdrege, Ong, Huitema, "SS7-Internet Interworking - Architectural Framework", work in progress. [2] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996. [3] Schulzrinne, H., "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 1890, January 1996 [4] Cuervo, Gibbs, "Media Gateway Architecture: A Functional Model of Greene, Ramalho [Page 44]
Internet draft MEGACO Requirements 27 January 1999 the Media Gateway", work in progress. [5] Arango, Dugan, Elliott, Huitema, Pickett, "Media Gateway Control Protocol (MGCP)", work in progress. [6] Arango, Huitema, "Simple Gateway Control Protocol (SGCP), work in progress [7] IP Device Control series of Internet-Drafts, work in progress, August, 1998 [8] Jozef Vandenameele, "Requirements for the Reference Point ("N") between Media Gateway Controller and Media Gateway", ETSI Tiphon WG2 working document and Internet-Draft, <draft-tiphon-arch-gway- decomp-01.txt>, January, 1999 10. Acknowledgements The authors would like to acknowledge the many contributors who debated the media gateway control architecture and requirements on the IETF megaco and sigtran mailing lists. Greene, Ramalho [Page 45]
Internet draft MEGACO Requirements 27 January 1999 11. Authors' addresses Nancy Greene Nortel Networks Ottawa, ON, Canada Email: ngreene@nortelnetworks.com Michael Ramalho Bellcore Email: mramalho@bellcore.com Greene, Ramalho [Page 46]
