Internet Engineering Task Force P. Sijben Internet Draft Lucent Technologies Expires 9 August 1999 9 February 1999 Internal connection model for generic media gateways This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Status of this Memo Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract This draft proposes a way to model media devices (for example media gateways) to allow control for those devices without standardizing the internals of the device. The model is symmetric, considered to be applicable to a wide range of applications, flexible, extendible, and efficient. 2. Introduction Gateways provide interface and interworking for devices on the packet network and devices on other networks. In Figure 1 an example is shown how calls may be set up through two such gateways. Sijben 1 Internal connection model for generic MGs February 1999 + - - - - - - - - - - - - - - + | +-----+ +-----+ | | MGC |---------| MGC | | +-----+ +-----+ | | | \ | | | \ | | | \ | / | +---+-+ / | | SG |-----\ | / MEGACO MEGACO | +---+-+ \ / \ \ | / \ | \ / \ \ +-----+ ++----+ voice +----++ +------------+ | PBX |------| AG |-------------------| MG |------| PSTN switch| +-----+ ++----+ (RTP) +----++ +------------+ / | ------- | | | / DATA NETWORK | / + - - - - - - - - - - - - - - + | +-----+ +-----+ |phone| |phone| +-----+ +-----+ Figure 1: Gateway example. MGC = media gateway controller; SG = signaling gateway; AG = access gateway; MG = media gateway. The media stream in Figure 1 traverses 5 legs of interest for this discussion. 1. from the phone to the access gateway 2. through the access gateway 3. between the two gateways 4. through the media gateway 5. from the media gateway to the switch (the stream beyond the switch is not of interest here) We see the need to model this call in accordance with the distributed nature of the architecture. For instance, part of the streams will be governed by the left controller part by the right one. Legs 1 and 2 are clearly governed by the left controller and legs 4 and5 clearly by the right. Leg 3 is subject to control by both of the controllers. Each of these streams will have certain properties associated with them (like codec used, QoS level, encoding etc.) which are relevant for one or some of the legs. The parameters for legs 1 and 5 are determined by the physical lines they are connected to; the only influence the controllers may have over these lines is possibly which to choose. The properties of leg 3 will be established by negotiation. Sijben 2 Internal connection model for generic MGs February 1999 This defines legs 2 and 4 by implication. At this level the gateways simply need to provide the right kinds of media streams at their edges. + - - - - - - - - - - - - - - - - - - - - - - - - - - + +----------+ | | MGC | | +----------+ | / | \ | / | \ signaling | ------------ | ------------- | / | \ | / MEGACO | MEGACO \ | / | \ +-------+ +-+------+ RTP +----------+ RTP +--------+ | | GSM | |GSM-data| stream | media | stream |terminal| | phone |----| MG |----------|transcoder|-----------| | +-------+ +-+------+ (GSM) +----------+ (G.723.1) +--------+ | | | DATA NETWORK + - - - - - - - - - - - - - - - - - - - - - - - - - - + Figure 2. Packet-to-packet transcoding "gateway" + - - - - - - - - - - - - - - - - - - + | +-----+ +-----+ | | MGC |-----------------| MGC | | +-----+ +-----+ | / | \ MEGACO | \ +--+--+ | ------ | +---+-+ ---| SG | | \ | | SG |---- / +--+--+ | +-----+ | +---+-+ \ / / | IVR | | \ / | / MEGACO +-----+ \ | \ / / / \ \ / | / --------- MEGACO \ | \ / / / voice (RTP) \ \ +-------+ ++----+/ +----++ +------+ |PSTN |----| TG |---------------------------| TG |--------|PSTN | |switch | ++----+ voice (RTP) +----++ |switch| +-------+ +------+ | | | | | DATA NETWORK | | + - - - - - - - - - - - - - - - - - - + | +-----+ +-----+ |phone| |phone| +-----+ +-----+ Figure 3: Stand alone IVR system. MGC = media gateway controller; SG = signaling gateway; TG = trunking gateway. Sijben 3 Internal connection model for generic MGs February 1999 Figures 2 and 3 give examples of other applications that are so similar to media gateway gateways that they can be considered to be of the same class of problems and can be treated as the same problem. Zooming in one level lower we come to the inside of the media gateways or more generic media devices. 3. Functional Model of Media Devices Media devices consist of a number of resources that must be connected and controlled to establish media connections. We recognize that there are two kinds of resources in the internal architecture model: 1 Edge Points: Internal representations of connections from the Media Gateway to the outside world. Examples of edge point types are RTP Stream, UDP Port, SCN Bearer Channel (e.g. DS0), ATM SVC, and Signalling Backhaul. Edge points have associated with them properties that can be controlled by the MGC via the control protocol. Different edge point types have different sets of properties. Properties include, for instance, the allocation of an echo canceller or DTMF detector to the edge point, or the codec being used for the media stream that flows through the edge point. 2 Media Resources: These operate on media streams but do not send or receive media directly to or from the outside of the media device. An example of a media resource is a conference bridge. Media resources also have properties. A property of a conference bridge, for instance, would be the number of ports on the bridge. Not all resource types are required to be supported in all media devices. This allows media devices to be tailored to specific applications. Also we believe that vendor specific extensions to existing resource types should be allowed as well as the addition of new resource types. Figure 4 gives an example of the functional model for a basic call. We use three interfaces to the media device. N.A, N.B, N.C in accordance with the ETSI/Tiphon and the appropriate SG16 ToR. Note that in this example the two interfaces N.A and N.B terminate at the same edge point in the media device. The reason is that they both pertain to the same call. For backhaul of facility associated signalling there is a separate edge point. 4. Control Model Taking the functional model described above, we propose the following control model. The media device is made up of a number of resources that must be connected and controlled to make up media connections. A connection is an association of edge points and media resources that operates unidirectionally on one media type. A call is defined as a collection of one or more edge points and/or media resources, and zero or more connections. A conference is defined as a collection of one or more calls. Sijben 4 Internal connection model for generic MGs February 1999 +-------------------------------------------------+ | | | media gateway controller | +-------------------------------------------------+ | | | N.A | | N.B | N.C +----------+ +----------+ |edge point| |edge point| +-------+----------+----+----------+--------------+ | | control | | control | | +-------+--+ |signaling | |signaling | +--+-------+ |edge point| +----------+ +----------+ |edge point| +----------+ | | +----------+ ---| H.245 | --------------| FAS | |signaling | | | backhaul | +-------+--+ +--+-------+ | +- - -+ | | | |codec| | | +- - -+ | | +----------+ | +----------+ |edge point|-- +- - - - - - - - - - - - - - -|edge point| +----------+-------------------------------------->+----------+<-> -->| RTP |- - - - -+ ---------|SCN bearer| | stream | / ----| channel | +----------+ | / | +----------+ | / | | +----------+ | / +- - - - - -+ | |edge point|<------------------------- |DTMF det | | +----------+ | |prog tones | | <--| RTP |- - - - -+ |annc player| | | stream |---| |echo cancel| | +----------+ +- - - - -+ +- - - - - -+ | | |music scr| | | |codec | | | +- - - - -+ MEDIA GATEWAY | +-------------------------------------------------+ Figure 4 Functional Model Example For example: - A point-to-point voice call is be made up of two unidirectional voice connections. - A multicast call is made up of a number of unidirectional connections that connect to multicast stream edge points (e.g. having as properties multicast IP addresses or multicast ATM VCs). - A multipoint conference is made up of a number of calls, all of which connect to a conference bridge. - A point-to-point multimedia call is made up a series of voice, video and data connections. The conference and connection states are maintained in the Media Gateway Controller. A call may encompass media streams of different types (audio, video and data). Sijben 5 Internal connection model for generic MGs February 1999 The model exists of four entities: conferences, calls, connections and resources. 1. Conferences. A conference comprises one or more related calls. The simplest case is that of a single call. A multiparty conference would consist of a number of calls and a conference bridge resource. The MGC that controls a conference keeps track of all calls for the conference that connect to a given conference bridge, allowing it to control them independently or collectively (e.g. release individual calls from the conference versus releasing the entire conference). 2. Calls. A Call identifies the resources and connections between them that pertain to one point-to-point connection. A call may encompass media streams of different types (audio, video, data). A call can involve one or more connections. 3. Connections. Connections describe how resources are connected. If there is a media stream between two resources, there is a connection between these resources. The media stream is a generic stream of an appropriate type (audio, video, data), the MG is assumed to be capable to transcode media as required. Connections are unidirectional. 4. Resources. In the model proposed, resources are abstract representations of functionality in the media gateway. Resources have properties that specify their operation. A property of an RTP resource, for instance, is the codec used. Properties may have attributes. The echo canceller property of a SCN circuit resource, for instance, may have its status attribute set to 'enabled' and its type attribute to 'G.165.' 4.1 Resource Categories We propose three categories of resources. 1. Media Edge Points. These are representations of physical connections from a media device to the outside world. Media edge points are resources with a number of properties describing the nature of the connection to the outside world (DS0, RTP, ATM) and the capabilities that are supported for the outside connection. These capabilities include, for instance, tone generation, DTMF detection, etc. In Figure 5 the properties of the edge points are clearly shown. 2. Media Resources. Media resources are resources that operate on media streams but do not connect to the outside of the media device. An example of a media resource is a conference bridge. A conference bridge is a resource that receives media streams from a number of media edge points, manipulates the incoming streams and sends manipulated streams to other media edge points. See Figure 5. 3. Signalling Edge Points. These also represent connections from a media device to the outside world. These connections are used only for transport of signalling information to and from MGCs. A signalling edge point is allocated on the media device end of Sijben 6 Internal connection model for generic MGs February 1999 interface N for every conference in the media device and for backhaul of facility associated signalling. A signalling edge point may have a script associated with it. This allows some of the connection control to be moved from the MGC to the media device, reducing the signalling traffic and the load on the MGC. 5. Advantages of the model The model has five advantages: 1. The model proposed in this document abstracts from a particular implementation. 2. The model allows the combination of an arbitrary set of edge points to make a connection. The MGW is thought to have the intelligence to connect the edge points and come up with transcoding if required. 3. The model is extendible, so by defining a new edge point type one immediately allows the bridging to any existing edge point type. 4. Using this model network independent services can be created without the need to rewrite the service logic for a new kind of bearer, the properties like announcement players etc. are applicable to all kinds of edge points. Figure 5 gives an example of how this model easily allows a conference bridge that connects to three kinds of networks, IP, ATM and SCN. 5. The model is also efficient for simple matters, like simple trunk gateways. Figure 5 is not available in the text version. Figure 5 Bridge example 6. Acknowledgements The author wishes to acknowledge the assistance of John Segers, Rex Coldren, Mike Buckley and John Wachter in the creation of this document. 7. Author's Addresses Paul Sijben Lucent Technologies PO box 18 1270 AA Huizen the Netherlands Phone: +31 35 687 4774 Email: sijben@lucent.com Sijben 7