Internet Engineering Task Force Fernando Cuervo INTERNET DRAFT Nortel Networks September 21, 1999 Bryan Hill Expires March 21, 2000 Gotham Networks Nancy Greene Nortel Networks Christian Huitema Telcordia Technologies Abdallah Rayhan Nortel Networks Brian Rosen FORE Systems John Segers Lucent Technologies Megaco Protocol Status of this document This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 nappropriate 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. This document will expire in March 2000. Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 1] Internet draft MEGACO Protocol September 21, 1999 Table of Contents 1. SCOPE ..................................................... 6 2. REFERENCES ................................................ 6 2.1. Normative References ................................. 6 2.2. Informative References ............................... 7 3. DEFINITIONS ............................................... 7 4. ABBREVIATIONS ............................................. 9 5. CONVENTIONS ............................................... 9 6. CONNECTION MODEL .......................................... 9 6.1. Contexts ............................................. 12 6.1.1. Context Properties and Descriptors .............. 13 6.1.2. Creating, Deleting and Modifying Contexts ....... 13 6.2. Terminations ......................................... 13 6.2.1. Termination Dynamics ............................ 14 6.2.2. TerminationIDs .................................. 14 6.2.3. Packages ........................................ 14 6.2.4. Termination Properties and Descriptors .......... 15 6.2.5. Root Termination ................................ 16 7. COMMANDS .................................................. 17 7.1. Descriptors .......................................... 18 7.1.1. Wildcarding Parameter Values in Commands ........ 18 7.1.2. Specifying Parameters ........................... 19 7.1.3. Modem Descriptor ................................ 19 7.1.4. Multiplex Descriptor ............................ 19 7.1.5. Media Descriptor ................................ 20 7.1.6. Termination State Descriptor .................... 20 7.1.7. Stream Descriptor ............................... 20 7.1.8. LocalControl Descriptor ......................... 21 7.1.9. Local and Remote Descriptors .................... 21 7.1.10. Events Descriptor .............................. 22 7.1.11. Signals Descriptor ............................. 23 7.1.12. RequestedInfo Descriptor ....................... 23 7.1.13. ServiceChange Descriptor ....................... 24 7.1.14. DigitMap Descriptor ............................ 24 7.1.15. Statistics Descriptor .......................... 25 7.1.16. Topology Descriptor ............................ 26 7.2. Command Application Programming Interface ............ 28 7.2.1. Add ............................................. 29 7.2.2. Modify .......................................... 30 7.2.3. Subtract ........................................ 30 7.2.4. Move ............................................ 31 7.2.5. AuditValue ...................................... 32 7.2.6. AuditCapabilities ............................... 33 7.2.7. Notify .......................................... 34 7.2.8. ServiceChange ................................... 34 7.2.9. Generic Command Syntax .......................... 36 7.3. Command Error Codes .................................. 37 Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 2] Internet draft MEGACO Protocol September 21, 1999 8. TRANSACTIONS .............................................. 38 8.1. Common Parameters .................................... 39 8.1.1. Transaction Identifiers ......................... 39 8.1.2. Context Identifiers ............................. 39 8.2. Transaction Application Programming Interface ........ 39 8.2.1. TransactionRequest .............................. 40 8.2.2. TransactionReply ................................ 40 8.2.3. TransactionPending .............................. 41 8.3. Messages ............................................. 41 9. TRANSPORT ................................................. 42 10. SECURITY CONSIDERATIONS .................................. 42 10.1. Protection of Protocol Connections .................. 42 10.2. Interim AH-within-MEGACO/H.248 scheme ............... 43 10.3. Protection of Media Connections ..................... 44 11. MG-MGC CONTROL INTERFACE ................................. 44 11.1. Multiple Virtual MGs ................................ 45 11.2. Cold Start .......................................... 45 11.3. Failure of an MG .................................... 46 11.4. Failure of an MGC ................................... 46 12. PACKAGE DEFINITION ....................................... 47 12.1. Guidelines for defining packages .................... 47 12.2. Example Package ..................................... 48 12.3. Package Registration ................................ 52 13. IANA CONSIDERATIONS ...................................... 52 13.1. Packages ............................................ 52 13.2. Error Codes ......................................... 53 14. CONTACT INFORMATION ...................................... 53 ANNEX A - ASN.1 DESCRIPTION OF THE PROTOCOL (NORMATIVE) ....... 54 A.1. Specification language .............................. 54 A.2. Syntax specification ................................ 54 ANNEX B - TEXT ENCODING OF THE PROTOCOL (NORMATIVE) ........... 55 B.1. Translation Mechanism ............................... 55 B.2. ABNF specification .................................. 55 ANNEX C - BINARY ENCODING OF THE PROTOCOL ..................... 65 C.1. Translation mechanism ............................... 65 ANNEX D - TAGS FOR MEDIA STREAM PROPERTIES .................... 66 D.1. General Media Attributes ............................ 66 D.2. Multiplex properties ................................ 66 D.3. Properties for BearerDescriptor ..................... 67 D.4. For DS0 ............................................. 67 D.5. For ATM VC .......................................... 67 D.6. Frame Relay ......................................... 67 D.7. RTP Stream .......................................... 67 Annex E - TRANSPORT USING UDP AND APPLICATION LAYER FRAMING ... 68 E.1. Providing At-Most-Once functionality ................ 68 E.2. Transaction identifiers and three-way handshake ..... 69 E.3. Computing retransmission timers ..................... 69 E.4. Provisional responses Executing some transactions ... 70 Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 3] Internet draft MEGACO Protocol September 21, 1999 E.5. Ordering of commands ................................ 73 E.6. Fighting the restart avalanche ...................... 74 ANNEX F - TRANSPORT USING TCP ................................. 75 F.1. Providing the At-Most-Once functionality ............ 75 F.2. Transaction identifiers and three way handshake ..... 76 F.3. Computing retransmission timers ..................... 76 F.4. Provisional responses ............................... 76 F.5. Ordering of commands ................................ 76 F.6. Fighting the restart avalanche ...................... 77 ANNEX G EXAMPLE CALL FLOWS .................................... 77 G.1. Residential Gateway to Residential Gateway Call ..... 77 G.1.1. Programming Residential GW Analog Line ......... 77 G.2. Multimedia Gateway Examples ......................... 88 G.2.1. H.320 Gateway .................................. 88 G.2.2. Multipoint Context Example ..................... 96 G.2.3. Single Media Call The single media the call .... 97 G.2.4. H.323 and FAS Signaling in MG ..................101 G.2.5. Simple text telephone call .....................103 G.2.5.1. Basic operation ...........................106 G.2.5.2. Voice channels in the simple text only ....106 G.2.5.3. Operation with the alternating text and ...106 Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 4] Internet draft MEGACO Protocol September 21, 1999 TABLE OF FIGURES Figure 1 Example of MEGACO Connection Model ..................... 10 Figure 2 Example Call Waiting Scenario / Alerting Applied to T1 . 11 Figure 3 Example Call Waiting Scenario / Answer by T1 ........... 12 Figure 4 Example topologies ..................................... 27 Figure 5 Transactions, Actions and Commands ..................... 38 Figure 6 H.320 Gateway Context .................................. 89 Figure 7 Multimedia Context Example ............................. 97 Figure 8 Single Media Call Example .............................. 98 Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 5] Internet draft MEGACO Protocol September 21, 1999 1. SCOPE MEGACO defines the protocols used between elements of a physically decomposed multimedia Gateway consisting of a Media Gateway and a Media Gateway Controller. There are no functional differences from a system view between a decomposed gateway, with distributed sub- components potentially on more than one physical device, and a monolithic gateway. This document does not define how gateways, multipoint control units or integrated voice response units (IVRs) work. Instead it creates a gen- eral framework that is suitable for these applications. Packet network interfaces may include IP, ATM or possibly others. The interfaces will support a variety of SCN signaling systems, including tone signaling, ISDN, ISUP, QSIG, and GSM. National variants of these signaling systems will be supported where applicable. The protocol definition in this document is common text with ITU Recom- mendation H.248. 2. REFERENCES 2.1. Normative References ITU-T Recommendation H.225.0 (1998): "Call Signaling Protocols and Media Stream Packetization for Packet Based Multimedia Communications Sys- tems". ITU-T Recommendation H.245 (1998): "Control Protocol for Multimedia Com- munication" ITU-T Recommendation H.323 (1998): "Packet Based Multimedia Communica- tion Systems" ITU-T Draft Recommendation H.246 (1998), "Interworking of H-series mul- timedia terminals with H-series multimedia terminals and voice/voiceband terminals on GSTN and ISDN" RFC 1006, "ISO Transport Service on top of the TCP, Version 3", Marshall T. Rose, Dwight E. Cass, May 1987. RFC 2119, "Key words for use in RFCs to Indicate Requirement Levels", Scott Bradner, March 1997. RFC 2145, "Use and Interpretation of HTTP Version Numbers", J. C. Mogul, R. Fielding, J. Gettys, H. Frystyk, May 1997. RFC 2327, "SDP: Session Description Protocol", M. Handley, V. Jacobson, April 1998. Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 6] Internet draft MEGACO Protocol September 21, 1999 RFC 2402, "IP Authentication Header", S. Kent, R. Atkinson, November 1998. RFC 2406, "IP Encapsulating Security Payload (ESP)", S. Kent, R. Atkin- son, November 1998. 2.2. Informative References ITU-T Recommendation Q.931 (1993): "Digital Subscriber Signalling System No. 1 (DSS 1) - ISDN User-Network Interface Layer 3 Specification for Basic Call Control" RFC 1889, "RTP: A Transport Protocol for Real-Time Applications", H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, January 1996. RFC 1890, "RTP Profile for Audio and Video Conferences with Minimal Con- trol", H. Schulzrinne, January 1996. RFC 2234, " Augmented BNF for Syntax Specifications: ABNF", D. Crocker, P. Overell, November 1997. RFC 2401, "Security Architecture for the Internet Protocol", S. Kent, R. Atkinson, November 1998. RFC 2543, " SIP: Session Initiation Protocol", M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, March 1999. 3. DEFINITIONS Access Gateway: A type of gateway that provides a User to Network Inter- face (UNI) such as ISDN. Back-haul: The transport of signaling information from a media termina- tion gateway containing a signaling gateway function to a call process- ing entity. For example, a layer 3 protocol such as Q.931 might be tran- sported between MG and MGC such that the MGC terminates layer 3, although the MG terminates layers 1 and 2. The signalling gateway func- tion terminates layers 1 and 2 and replaces them with an appropriate equivalent on the packet network. Descriptor: A syntactic element of the protocol that groups related pro- perties. For instance, the properties of a media flow on the MG can be set by the MGC by including the appropriate descriptor in a command. Gatekeeper (GK): A functional entity serving a gateway, providing ser- vices such as authentication, authorization, alias resolution and call routing. Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 7] Internet draft MEGACO Protocol September 21, 1999 H.323 Signaling: This function in the decomposed gateway supports normal H.323 signaling, such as H.225.0, H.245, or H.450.x as described in H.323. Media Gateway (MG): The media gateway converts media provided in one type of network to the format required in another type of network. For example, a MG could terminate bearer channels from a switched circuit network (i.e., DS0s) and media streams from a packet network (e.g., RTP streams in an IP network). This gateway may be capable of processing audio, video and T.120 alone or in any combination, and will be capable of full duplex media translations. The MG may also play audio/video messages and perform other IVR functions, or may perform media con- ferencing. Media Gateway Controller (MGC): Controls the parts of the call state that pertain to connection control for media channels in a MG. Multipoint Control Unit (MCU): An entity that controls the setup and coordination of a multi- user conference that typically includes pro- cessing of audio, video and data. Network Access Server: A gateway function in a MG that converts modem signals from an SCN network and provides data access to the Internet. Residential Gateway: A gateway that interworks an analog line to a packet network. A residential gateway typically contains one or two ana- log lines and is located at the customer premises. SCN FAS Signaling Gateway: This function contains the SCN Signaling Interface that terminates SS7, ISDN and other signaling links where the call control channel and bearer channels are collocated in the same phy- sical span. SCN NFAS Signaling Gateway: This function contains the SCN Signaling Interface that terminates SS7 and other signaling links where the call control channels are separated from bearer channels. Stream: Bidirectional media or control flow received/sent by a media gateway as part of a call or conference. Trunk: A communication channel between two switching systems such as a DS0 on a T1 or E1 line. Trunking Gateway: A gateway between SCN network and packet network that typically terminates a large number of digital circuits. Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 8] Internet draft MEGACO Protocol September 21, 1999 4. ABBREVIATIONS This recommendation defines the following terms. ATM Asynchronous Transfer Mode BRI Basic Rate Interface CAS Channel Associated Signaling DTMF Dual Tone Multi Frequency FAS Facility Associated Signaling GK GateKeeper GW GateWay IP Internet Protocol ISUP ISDN User Part MG Media Gateway MGC Media Gateway Controller NAS Network Access Server NFAS Non Facility Associated Signaling PRI Primary Rate Interface PSTN Public Switched Telephone Network QoS Quality of Service RTCP Real-time Transport Control Protocol RTP Real-time Transport Protocol SCN Switched Circuit Network SG Signaling Gateway SS7 Signalling System No7 5. CONVENTIONS The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. 6. CONNECTION MODEL The connection model for the protocol describes the logical entities, or objects, within the Media Gateway that can be controlled by the Media Gateway Controller. The main abstractions used in the connection model are Terminations and Contexts. A Termination sources and/or sinks one or more media streams. In a mul- timedia conference, a Termination can be multimedia and sources or sinks multiple media streams. The media stream parameters, as well as modem, and bearer parameters are encapsulated within the Termination. A Context is an association between a collection of Terminations. There is a special type of Context, the null Context, which contains all Ter- minations that are not associated to any other Termination. For instance, in a decomposed access gateway, all idle lines are represented by Terminations in the null Context. Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 9] Internet draft MEGACO Protocol September 21, 1999 Following is a graphical depiction of these concepts. The diagram of Figure 1 gives several examples and is not meant to be an all-inclusive illustration. The asterisk box in each of the Contexts represents the logical association of Terminations implied by the Context. +------------------------------------------------------+ |Media Gateway | | +-------------------------------------------------+ | | |Context +-------------+ | | | | | Termination | | | | | |-------------| | | | | +-------------+ +->| SCN Bearer |<---+-> | | | Termination | +-----+ | | Channel | | | | | |-------------| | |---+ +-------------+ | | <-+--->| RTP Stream |---| * | | | | | | | | |---+ +-------------+ | | | | +-------------+ +-----+ | | Termination | | | | | | |-------------| | | | | +->| SCN Bearer |<---+-> | | | Channel | | | | | +-------------+ | | | +-------------------------------------------------+ | | | | | | +------------------------------+ | | |Context | | | +-------------+ | +-------------+ | | | | Termination | | +-----+ | Termination | | | | |-------------| | | | |-------------| | | <-+->| SCN Bearer | | | * |------| SCN Bearer |<---+-> | | Channel | | | | | Channel | | | | +-------------+ | +-----+ +-------------+ | | | +------------------------------+ | | | | | | +-------------------------------------------------+ | | |Context | | | | +-------------+ +-------------+ | | | | | Termination | +-----+ | Termination | | | | | |-------------| | | |-------------| | | <-+--->| SCN Bearer |---| * |------| SCN Bearer |<---+-> | | | Channel | | | | Channel | | | | | +-------------+ +-----+ +-------------+ | | | +-------------------------------------------------+ | | ___________________________________________________ | +------------------------------------------------------+ Figure 1: Example of MEGACO Connection Model Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 10] Internet draft MEGACO Protocol September 21, 1999 The example below shows an example of one way to accomplish a call- waiting scenario in a decomposed access gateway, illustrating the relo- cation of a Termination between Contexts. Terminations T1 and T2 belong to Context C1 in a two-way audio call. A second audio call is waiting for T1 from Termination T3. T3 is alone in Context C2. T1 accepts the call from T3, placing T2 on hold. This action results in T1 moving into Context C2, as shown below. +------------------------------------------------------+ |Media Gateway | | +-------------------------------------------------+ | | |Context C1 | | | | +-------------+ +-------------+ | | | | | Term. T2 | +-----+ | Term. T1 | | | | | |-------------| | | |-------------| | | <-+--->| RTP Stream |---| * |------| SCN Bearer |<---+-> | | | | | | | Channel | | | | | +-------------+ +-----+ +-------------+ | | | +-------------------------------------------------+ | | | | +-------------------------------------------------+ | | |Context C2 | | | | +-------------+ | | | | +-----+ | Term. T3 | | | | | | | |-------------| | | | | | * |------| SCN Bearer |<---+-> | | | | | Channel | | | | | +-----+ +-------------+ | | | +-------------------------------------------------+ | +------------------------------------------------------+ Figure 2 Example Call Waiting Scenario / Alerting Applied to T1 Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 11] Internet draft MEGACO Protocol September 21, 1999 +------------------------------------------------------+ |Media Gateway | | +-------------------------------------------------+ | | |Context C1 | | | | +-------------+ | | | | | Term. T2 | +-----+ | | | | |-------------| | | | | <-+--->| RTP Stream |---| * | | | | | | | | | | | | | +-------------+ +-----+ | | | +-------------------------------------------------+ | | | | +-------------------------------------------------+ | | |Context C2 | | | | +-------------+ +-------------+ | | | | | Term. T1 | +-----+ | Term. T3 | | | | | |-------------| | | |-------------| | | <-+--->| SCN Bearer |---| * |------| SCN Bearer |<---+-> | | | Channel | | | | Channel | | | | | +-------------+ +-----+ +-------------+ | | | +-------------------------------------------------+ | +------------------------------------------------------+ Figure 3. Example Call Waiting Scenario / Answer by T1 6.1. Contexts A Context is an association between a number of Terminations. The Con- text describes the topology (who hears/sees whom) and the media mixing and/or switching parameters if more than two Terminations are involved in the association. There is a special Context called the null Context. It contains Termina- tions that are not associated to any other Termination. Terminations in the null Context can have their parameters examined or modified, and may have events detected on them. In general, an Add command is used to add Terminations to Contexts. If the MGC does not specify an existing Context to which the Termination is to be added, the MG creates a new Context. A Termination may be removed from a Context with a Subtract command, and a Termination may be moved from one Context to another with a Move command. A Termination exists in only one Context at a time. The maximum number of Terminations in a Context is a MG property. Media gateways that offer only point-to-point connectivity might allow at most two Terminations per Context. Media gateways that support multipoint Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 12] Internet draft MEGACO Protocol September 21, 1999 conferences might allow three or more terminations per Context. 6.1.1. Context Properties and Descriptors The properties of Contexts include * ContextID, a 32 bit integer chosen by the MG. It may be specified as ALL "*" or NULL "-" in some circumstances. * the topology (who hears/sees whom). The topology of a Context describes the flow of media between the Terminations within a Context. In contrast, the mode of a Termina- tion (send/receive/...) describes the flow of the media at the ingress/egress of the media gateway. 6.1.2. Creating, Deleting and Modifying Contexts The protocol can be used to (implicitly) create Contexts and modify the parameter values of existing Contexts. The protocol has commands to add Terminations to Contexts subtract them from Contexts, and to move Termi- nations between Contexts. Contexts are deleted implicitly when the last remaining Termination is subtracted from it. 6.2. Terminations A Termination is a logical entity on a MG that sources and/or sinks media and/or control streams. A Termination is described by a number of characterizing Properties, which are grouped in a set of Descriptors that are included in commands. Terminations have unique identities (Ter- minationIDs), assigned by the MG at the time of their creation. Terminations representing physical entities have a semi-permanent existence. For example, a Termination representing a TDM channel might exist for as long as it is provisioned in the gateway. Terminations representing ephemeral information flows, such as RTP flows, would usu- ally exist only for the duration of their use. Ephemeral Terminations are created by means of an Add command. They are destroyed by means of a Subtract command. In contrast, when a physical Termination is Add'ed to or Subtract'ed from a Context, it is taken from or to the null Context, respectively. Terminations may have signals applied to them. Signals are MG generated media streams such as tones and announcements as well as line signals such as hookswitch. Terminations may be programmed to detect Events, the occurrence of which can trigger notification messages to the MGC, or action by the MG. Statistics may be accumulated on a Termination. Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 13] Internet draft MEGACO Protocol September 21, 1999 Statistics are reported to the MGC upon request (by means of the Audit- Value command, see Section 7.2.5) and when the Termination is taken out of the call it is in. Multimedia gateways may process multiplexed media streams. For example, Recommendation H.221 describes a frame structure for multiple media streams multiplexed on a number of digital 64 kbit/s channels. Such a case is handled in the connection model in the following way. For every bearer channel that carries part of the multiplexed streams, there is a Termination. The Terminations that source/sink the digital channels are connected to separate Termination called the multiplexing Termination. This Termination describes the multiplex used (e.g. how the H.221 frames are carried over the digital channels used). The MuxDescriptor is used to this end. If multiple media are carried, this Termination contains multiple MediaDescriptors. The media streams can be associated with streams sourced/sunk by other Terminations in the Context. 6.2.1. Termination Dynamics The protocol can be used to create new Terminations and to modify pro- perty values of existing Terminations. These modifications include the possibility of adding or removing events and/or signals. The Termina- tion properties, and events and signals are described in the ensuing sections. 6.2.2. TerminationIDs Terminations are referenced by a TerminationID, which is an arbitrary schema chosen by the MG. TerminationIDs of physical Terminations are provisioned in the Media Gateway. In a text encoding of the protocol, while TerminationIDs are arbitrary, by judicious choice of names, the wildcard character, "*" may be made more useful. When the wildcard character is encountered, it will "match" all TerminationIDs having the same previous and following char- acters (if appropriate). For example, if there were TerminationIDs of R13/3/1, R13/3/2 and R13/3/3, the TerminationID R13/3/* would match all of them. There are some circumstances where ALL Terminations must be referred to. The TerminationID "*" suffices, and is referred to as "ALL". When a TerminationID is required, but the Termination does not yet exist, the "CHOOSE" TerminationID "$" may be used. 6.2.3. Packages Different types of gateways may implement Terminations that have widely differing characteristics. Variations in Terminations are accommodated Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 14] Internet draft MEGACO Protocol September 21, 1999 in the protocol by allowing Terminations to have optional Properties, Events, Signals and Statistics implemented by MGs. In order to achieve MG/MGC interoperability, such options are grouped into Packages, and a Termination realizes a set of such Packages. More information on definition of packages can be found in Section 12. An MGC can audit a Termination to determine which Packages it realizes. 6.2.4. Termination Properties and Descriptors Terminations have properties. The properties have unique PropertyIDs. Most properties have default values. When a Termination is created, properties get their default values, unless the controller specifically sets a different value. The default value of a property of a physical Termination can be changed by setting it to a different value when the Termination is in the null Context. Every time such a Termination returns to the null Context, the values of its properties are reset to this default value. There are a number of common properties for Terminations and properties specific to media streams. The common properties are also called the termination state properties. For each media stream, there are local properties and properties of the received and transmitted flows. Properties not included in the base protocol are defined in Packages. These properties are referred to by a name consisting of the PackageName and a PropertyID. Most properties have default values described in the Package description. Actual or allowed values of properties can be set and inspected by MGCs. Related properties are grouped into descriptors for convenience. When a Termination is Added to a Context, its property values can be set by including the appropriate descriptors as parameters to the Add com- mand. Properties not mentioned in the command retain their prior values. Similarly, a property of a Termination in a Context may have its value changed by the Modify command. Properties not mentioned in the Modify command retain their prior values. When a Termination is Subtracted from a Context, properties are reset to the values they had just prior to the most recent Add command. The following table lists all of the possible Descriptors and their use. Not all descriptors are legal as input or output parameters to every command. Descriptors Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 15] Internet draft MEGACO Protocol September 21, 1999 ______________________________________________________________________________ |Descriptor Name| Description | |_______________|____________________________________________________________| |Modem | Identifies modem type and properties when applicable | |_______________|____________________________________________________________| |Mux | Describes multiplex type for multimedia terminations | | | (e.g. H.221, H.223, H.225.0) and Terminations forming | | | input mux | |_______________|____________________________________________________________| |Media | A list of media stream specifications (see below) | |_______________|____________________________________________________________| |Events | Describes events to be listened for by the MG and what to | | | do when an event is detected | |_______________|____________________________________________________________| |Signals | Describes signals and/or actions to be applied (e.g. | | | ringback) | |_______________|____________________________________________________________| |Requested Info | In Audit, identifies which information is desired | |_______________|____________________________________________________________| |Packages | In Audit, returns a list of Packages realized by | | | Termination | |_______________|____________________________________________________________| |DigitMap | Instructions for handling DTMF tones at the MG | |_______________|____________________________________________________________| |ServiceChange | In ServiceChange, what, why, etc. | |_______________|____________________________________________________________| |ObservedEvents | In Notify, report of events observed | |_______________|____________________________________________________________| |Statistics | In Subtract and Audit, Report of Statistics kept on a | | | Termination | |_______________|____________________________________________________________| |Extension | Allows inclusion of vendor-specific extensions | |_______________|____________________________________________________________| Within the Media descriptor, there is the Termination State descriptor and one or more Stream Descriptors. A stream is identified by a streamID. The streamID is used to link the streams in a Context that belong together. Within the Stream Descriptor, there are up to three subsidiary descriptors, LocalControl, Local and Remote. The relationship between these descriptors is thus: Media Descriptor TerminalStateDescriptor Stream Descriptor LocalControl Descriptor Local Descriptor Remote Descriptor As a convenience for the audio-only case, a LocalControl, Local or Remote descriptor may be included in the Media Descriptor without an enclosing Stream descriptor. In this case, the StreamID is assumed to be 1, designating an audio stream. 6.2.5. Root Termination Occasionally, a command must refer to the entire gateway, rather than a termination within it. A special TerminationID, "ROOT" is reserved for this purpose. A package (MG) defines the properties of Root. Root thus Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 16] Internet draft MEGACO Protocol September 21, 1999 may have properties and events (signals and statistics are not appropri- ate for root). Accordingly, the root terminationID may appear in: * a Modify command - to change a property or set an event * a Notify command - to report an event * an AuditValue return - to examine the values of properties * an AuditCapability - to determine what properties of root are implemented * a ServiceChange - to declare the gateway in or out of service Any other use of the root terminationID is an error. 7. COMMANDS The protocol provides Commands for manipulating the logical entities of the protocol connection model, Contexts and Terminations. Commands pro- vide control at the finest level of granularity supported by the proto- col. For example, Commands exist to add Terminations to a Context, modify Terminations, subtract Terminations from a Context, and audit properties of Contexts or Terminations. Commands provide for complete control of the properties of Contexts and Terminations. This includes things such as specifying which events a Termination is to report, which signals/actions are to be applied to a Termination and specifying the topology of a Context (who hears/sees whom). Most Commands are for the specific use of the Media Gateway Controller as command initiator in controlling Media Gateways as command responders. However, there are several Commands for the Media Gateway to use as command initiator in reporting events that have occurred to the controller as command responder. The protocol has commands. The commands are sent to the MG by the MGC, except Notify. Notify is sent to the MGC by the MG. ServiceChange may be sent by either entity to the other. 1. Add. The Add command adds a termination to a context. The Add com- mand on the first Termination in a Context is used to create a Con- text. 2. Modify. The Modify command modifies the properties, events and sig- nals of a termination. 3. Subtract. The Subtract command disconnects a Termination from its Context and returns statistics on the Termination's participation Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 17] Internet draft MEGACO Protocol September 21, 1999 in the Context. The Subtract command on the last Termination in a Context deletes the Context. 4. Move. The Move command atomically moves a Termination to another context. 5. AuditValue. The Audit command returns the current state of proper- ties, events and signals of Terminations. 6. AuditCapabilities. The AuditCapabilities command returns all the possible values for Termination properties, events and signals allowed by the Media Gateway 7. Notify. The Notify command allows the Media Gateway to inform the Media Gateway Controller of the occurrence of events in the Media Gateway. 8. ServiceChange. The ServiceChange Command allows the Media Gateway to notify the Media Gateway Controller that a Termination or group of Terminations is about to be taken out of service or has just been returned to service. ServiceChange is also used by the MG to announce its availability to an MGC (registration), and to notify the MGC of impending or completed restart of the MG. The MGC may announce a handover to the MG by sending it a ServiceChange com- mand. These commands are detailed in Sections 7.2.1 through 7.2.8 7.1. Descriptors The parameters to a command are termed Descriptors. A Descriptor con- sists of a name and a list of items. Some items may have values. Many Commands share common Descriptors. This subsection enumerates these Descriptors. Parameters and parameter usage specific to a given Command type are described in the subsection that describes the Command. 7.1.1. Wildcarding Parameter Values in Commands Some parameter values may be wildcarded in commands. Two wildcard con- structs are provided: "all" and "choose". The "all" construct allows a Command to specify all possible values of a name component. For exam- ple, all Terminations can be subtracted from a Context by means of this construct. The "choose" construct allows a command initiator to specify that it would like the command responder to select and return a possible value for a parameter. This mechanism, for example, allows the MGC to have the MG select a DS0 within a DS1. Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 18] Internet draft MEGACO Protocol September 21, 1999 7.1.2. Specifying Parameters Command parameters are structured into a number of descriptors. In gen- eral, descriptors are of the form DescriptorName={parm=value, parm=value....} Properties may be fully specified, overspecified or under-specified: 1. Fully specified parameters have a single, unambiguous value that the command initiator is instructing the command responder to use for the specified parameter. 2. Under-specified parameters, using the "choose" value, allow the command responder to choose any value it can support. 3. Over-specified parameters have a list of potential values. The list order specifies the command initiator's order of preference of selection. The command responder chooses one value from the offered list and returns that value to the command initiator. Unspecified, mandatory parameters (i.e.-mandatory parameters not speci- fied in any descriptor) result in the command responder retaining the previous value for that property. 7.1.3. Modem Descriptor The Modem descriptor specifies the modem type and parameters, if any. By default, no modem descriptor is present in a Termination. 7.1.4. Multiplex Descriptor In multimedia calls, a number of media streams are carried on a (possi- bly different) number of bearers. The multiplex descriptor associates the media and the bearers. The descriptor includes the multiplex type: * H.221 * H.223, * H.226, * H.225.0, * V.75. * Possible Extensions (e.g. X-SpecialMux) Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 19] Internet draft MEGACO Protocol September 21, 1999 and a set of TerminationIDs representing the multiplexed inputs, in order. For example: Mux {H.225, MyT3/1/2, MyT3/2/13, MyT3/3/6, MyT3/21/22} 7.1.5. Media Descriptor The Media Descriptor specifies the parameters for all the media streams. These parameters are structured into two descriptors, a Termination State Descriptor, which specifies the properties of a termination that are not stream dependent, and one or more Stream Descriptors each of which describes a single media stream. 7.1.6. Termination State Descriptor The Termination State Descriptor contains the TerminationBuffered param- eter, the serviceStates parameter and properties of a termination (defined in Packages) that are not stream specific. The TerminationBuffered parameter describes actions taken by the MG when events are not immediately notified to the controller. 1. BufferedEventProcessingMode - specifies whether buffered events should be processed or discarded. 2. BufferedEventNotificationMode - specifies whether the Media Gateway is expected to detect the requested event and notify the controller once (step by step) or repeatedly. The serviceStates parameter describes the overall state of the termina- tion (not stream-specific). A Termination can be in one of the following states: "test", "out of service", or "in service". "in service" is the default state. 7.1.7. Stream Descriptor A Stream descriptor specifies the parameters of a single bi-directional media stream. These parameters are structured into three descriptors, one that contains termination properties specific to a stream, and one each for local and remote flows. Stream Descriptor Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 20] Internet draft MEGACO Protocol September 21, 1999 ______________________________________________________________________________ | Parameter | Description | |_______________________|______________________________________________________| | StreamID | Identifies the context stream to be associated | | | with this termination media flow (e.g., 1, 2, | | | 3, ... ) | |_______________________|______________________________________________________| |LocalControl Descriptor| Contains properties that are of interest between the | | | MG and the MGC | |_______________________|______________________________________________________| | Local Descriptor | Contains properties that specify the Local side of a | | | media flow, and are of interest between two MGs | |_______________________|______________________________________________________| | Remote Descriptor | Contains properties that specify the Remote side of | | | a media flow, and are of interest between two MGs | |_______________________|______________________________________________________| 7.1.8. LocalControl Descriptor The LocalControl Descriptor contains the Mode parameter and properties of a termination (defined in Packages) that are stream specific, and are of interest between the MG and the MGC. The allowed values for the mode parameter are "send only" (sendonly), "receive only" (recvonly), "send/receive" (sendrecv), "inactive" (inac- tive), "loop back" (looback) and "delete" (delete). "Send" and "Receive" are with respect to the stream within a termination, so that, for example, a stream set to mode=sendonly can talk but it cannot listen. Mode set to delete is used to remove a stream from a termination. 7.1.9. Local and Remote Descriptors The Local and Remote Descriptors contain the parameters describing the flows sent to and received from the MG, and are of interest between two MGs. They are encoded as SDP strings as specified in RFC2327, or tag- value pairs as specified in Annex D. Local is the capability of the local MG and is typically sent from MG to MGC, and subsequently used as part of a capability negotiation between two MGCs. Remote is the param- eters describing the flows the remote MG will send/receive, is typically sent from MCG to MG, and is the result of the capability negotiation. Between two MGs A and B, MG A receives a negotiated version of MG B's Local Descriptor as its Remote Descriptor, and MG B receives a nego- tiated version of MG A's Local Descriptor as its Remote Descriptor. Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 21] Internet draft MEGACO Protocol September 21, 1999 7.1.10. Events Descriptor The EventsDescriptor parameter contains a RequestIdentifier and a list of events that the Media Gateway is requested to detect and report. The RequestIdentifier is used to correlate the request with the notifica- tions that it may trigger. Requested events include, for example, fax tones, continuity tones, and on-hook and off-hook transitions. Each event in the descriptor contains the Event name, an optional Action, and optional parameters. The Event name consists of a Package Name (where the event is defined) and an EventID. Events can have parameters. This allows a single event description to have some varia- tion in meaning without creating large numbers of individual events. Parameters are defined in the package and are named. The Action parame- ter specifies one of several possible actions to take upon the occurrence of the event: Event Actions ______________________________________________________________________________ |NotifyAction | A Notify message is sent by the MG when the Event is | | | detected | |____________________|_________________________________________________________| |AccumulateByValue | The Event is added to the Event Buffer | |____________________|_________________________________________________________| |AccumulateByDigitMap| The Event is processed by the specified Digit Map | |____________________|_________________________________________________________| When Accumulate by Digit Map is specified in an Action, a Digit Map or the name of a pre- stored DigitMap is specified with the Action parame- ter. For example: Event=1139 { Line/DTMF {ACTION=AccumulateByDigitMap{GenMap} } } An Action can also include an Embedded Signals descriptor or an Embedded Events Descriptor which, if present, is used as a replacement for the current Signals/Events descriptor. It is possible, for example, to specify that the dial-tone Signal be generated when an off-hook Event is detected, or that the dial-tone Signal be stopped when a digit is detected. If no embedded Signals descriptor is specified, the produc- tion of Signals continues as specified in the command. Only one level of embedding is permitted. An embedded Signals Descrip- tor SHALL NOT contain another embedded Signals Descriptor. Similarly, An embedded Events Descriptor SHALL NOT contain another embedded Events Descriptor. Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 22] Internet draft MEGACO Protocol September 21, 1999 7.1.11. Signals Descriptor A SignalsDescriptor is a parameter that contains the set of signals that the Media Gateway is asked to apply to a Termination. Signals are named with a Package name (where the signal is defined) and a SignalID. There are three types of signals: * on/off - the signal lasts until it is turned off, * timeout - the signal lasts until it is turned off or a specific period of time elapses, * brief - the signal duration is so short that it will stop on its own unless a new signal is applied that causes it to stop; no timeout value is needed. Signals can have parameters. This allows a single signal description to have some variation in meaning without creating large numbers of indivi- dual signals. A common use for this capability is to produce signals such as dialtone that have national variants. Signal{ Line/Dialtone{US} } A new SignalDescriptor replaces any existing SignalDescriptor. Any sig- nals applied to the Termination not in the replacement descriptor are stopped, and new signals are applied. 7.1.12. RequestedInfo Descriptor Audit commands (AuditValue and AuditCapabilities) may specify what information is to be audited. The RequestedInfo Descriptor contains the list of descriptors to be returned from the Audit command. Possible items in the RequestedInfo Descriptor are: ____________________ | TerminationState | |___________________| | Modem | |___________________| | Mux | |___________________| | Stream | |___________________| | Events | |___________________| | Signals | |___________________| Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 23] Internet draft MEGACO Protocol September 21, 1999 | ObservedEvents | |___________________________| | DigitMap | |___________________________| | Statistics | |___________________________| | Extension (e.g. X-Special)| |___________________________| 7.1.13. ServiceChange Descriptor The ServiceChangeDescriptor contains the following parameters: * ServiceChangeMethod * ServiceChangeReason * Port * Delay * Version * MGCIdToTry 7.1.14. DigitMap Descriptor A DigitMap is a dialing plan resident in the Media Gateway used for detecting and reporting digit events received on a Termination. The DigitMap Descriptor contains a DigitMap name and the DigitMap to be assigned. A digit map may be preloaded into the MG by management action and referenced by name in an EventDescriptor, may be defined dynamically and subsequently referenced by name, or the actual digitmap itself may be specified in the EventDescriptor. DigitMaps defined in a DigitMapDescriptor can occur in any of the stan- dard Termination manipulation Commands of the protocol. A DigitMap, once defined, can be used on all Terminations specified by the (possibly wildcarded) TerminationID in such a command. When a DigitMap is defined dynamically in a DigitMap Descriptor: * A new DigitMap is created by specifying a name that is not yet defined. The value shall be present. * A DigitMap value is updated by supplying a new value for a name that is already defined. Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 24] Internet draft MEGACO Protocol September 21, 1999 * A DigitMap is deleted by supplying an empty value for a name that is already defined. The collection of digits according to a DigitMap may be protected by three timers, viz. a start timer, short timer, and long timer. 1. The start timer is used prior to any digits having been dialed. 2. If the Media Gateway can determine that at least one more digit is needed for a digit string to match any of the allowed patterns in the digit map, then the interdigit timer value should be set to a long duration (e.g.-16 seconds). 3. If the DigitMap specifies that a variable number of additional digits may be needed then the short timer is used. The timers are configurable parameters to a DigitMap. The formal syntax of the digit map is described by the DigitMap rule in the formal syntax description of the protocol (See Annex A and Annex B). A DigitMap, according to this syntax, is defined either by a string or by a list of strings. Each string in the list is an alternative number- ing scheme, specified either as a set of digits or timers, or as regular expression. A MG that detects digits, letters or timers while a DigitMap is active SHALL: 1. Add the event parameter to the end of an internal state variable called the "current dial string" 2. Apply the current dial string to the DigitMap, attempting a match to each regular expression in the DigitMap in lexical order 3. If the result is under-qualified (partially matches at least one entry in the DigitMap), do nothing further. 4. If the result matches, or is over-qualified (i.e. no further digits could possibly produce a match), send the current dial string to the MGC. Note that unexpected timers, for example, can cause over-qualified matches. 7.1.15. Statistics Descriptor The Statistics parameter provides information describing the status and usage of a Termination during its existence within a specific Context. There is a set of standard statistics kept for each termination where appropriate (number of octets sent and received for example). The Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 25] Internet draft MEGACO Protocol September 21, 1999 particular statistical properties that are reported for a given Termina- tion are determined by the Packages realized by the Termination. Statistics are reported when the Termination is Subtracted from the Con- text. Statistics may also be returned from the AuditValue command. 7.1.16. Topology Descriptor A topology descriptor is used specify flow directions between termina- tions in a conference. Contrary to the descriptors in previous sections, the topology descriptor applies to a Context instead of a Termination. The default topology of a Context is that is that each termination's transmission is received by all other terminations. The Topology Descriptor optional to implement. A topology descriptor consists of a sequence of triples of the form (T1, T2, association). T1 and T2 specify Terminations within the Con- text, possibly using the ALL wildcard. The association specifies how media flows between these to Terminations as follows. * (T1, T2, isolate) means that the Terminations matching T2 do not receive media from the Terminations matching T1, nor vice versa. * (T1, T2, oneway) means that the Terminations that match T2 receive media from the Terminations matching T1, but not vice versa. In this case it is not allowed to use wildcards such that there are Terminations that match both T1 and T2. * (T1, T2, bothway) means that the Terminations matching T2 receive media from the Terminations matching T1, and vice versa. In this case it is allowed to use wildcards such that there are Termina- tions that match both T1 and T2. However, if there is a Termina- tion that matches both, no loopback is introduced; loopbacks are created by setting the TerminationMode. The Figure below and the Table following it show some examples of the effect of including topology descriptors in commands. Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 26] Internet draft MEGACO Protocol September 21, 1999 Context 1 Context 2 Context 3 +------------------+ +------------------+ +------------------+ | +----+ | | +----+ | | +----+ | | | T2 | | | | T2 | | | | T2 | | | +----+ | | +----+ | | +----+ | | ^ ^ | | ^ | | ^ | | | | | | | | | | | | +--+ +--+ | | +---+ | | +--+ | | | | | | | | | | | | v v | | v | | | | | +----+ +----+ | | +----+ +----+ | | +----+ +----+ | | | T1 |<-->| T3 | | | | T1 |<-->| T3 | | | | T1 |<-->| T3 | | | +----+ +----+ | | +----+ +----+ | | +----+ +----+ | +------------------+ +------------------+ +------------------+ 1. No Topology Desc. 2. T1, T2 Isolate 3. T3, T2 oneway Context 1 Context 2 Context 3 +------------------+ +------------------+ +------------------+ | +----+ | | +----+ | | +----+ | | | T2 | | | | T2 | | | | T2 | | | +----+ | | +----+ | | +----+ | | | | | ^ | | ^ ^ | | | | | | | | | | | | +--+ | | +---+ | | +--+ +--+ | | | | | | | | | | | | v | | v | | v v | | +----+ +----+ | | +----+ +----+ | | +----+ +----+ | | | T1 |<-->| T3 | | | | T1 |<-->| T3 | | | | T1 |<-->| T3 | | | +----+ +----+ | | +----+ +----+ | | +----+ +----+ | +------------------+ +------------------+ +------------------+ 1. T2, T3 oneway 2. T2, T3 bothway 3. T1, T2 bothway Figure 4: Example topologies Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 27] Internet draft MEGACO Protocol September 21, 1999 __________________________________________________________________________ |Topology| Description | |________|_________________________________________________________________| |1 | No topology descriptors. | | | | | | When no topology descriptors included, all terminations have a | | | both way connection to all other terminations. | |________|_________________________________________________________________| |2 | T1, T2, Isolated. | | | | | | Removes the connection between T1 and T2. | | | T3 has a both way connection with both T1 and T2. T1 and T2 | | | have bothway connection to T3. | |________|_________________________________________________________________| |3 | T3, T2, oneway. | | | | | | A oneway connection from T3 to T2 (i.e. T2 receives media flow | | | from T3). A bothway connection between T1 and T3. | |________|_________________________________________________________________| |4 | T2, T3, oneway. | | | | | | A oneway connection between T2 to T3. T1 and T3 remain | | | bothway connected | |________|_________________________________________________________________| |5 | T2, T3 bothway. | | | | | | T2 is bothway connected to T3. This results in the same as 2. | |________|_________________________________________________________________| |6 | T1, T2 bothway. | | | | | | All terminations are considered connected to each other. | | | This is the same as 1. | |________|_________________________________________________________________| A topology change is performed by including a topology descriptor in an Add or Modify command. Allowing a topology descriptor in an Add command facilitates addition of a Termination to a Context and setting the topology in one atomic action. When the topology is included in the "Add" command, then either "Ter- minationA" or "TerminationB" shall be of value "*" to indicate the ter- mination being added to the context. 7.2. Command Application Programming Interface Following is an Application Programming Interface (API) describing the Commands of the protocol. This API is shown to illustrate the Commands and their parameters and is not intended to specify implementation (e.g.-via use of blocking function calls). It will describe the input parameters in parentheses after the command name and the return values in front of the Command. This is only for descriptive purposes; the Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 28] Internet draft MEGACO Protocol September 21, 1999 actual Command syntax and encoding are specified in later subsections. All parameters enclosed by square brackets ([. . . ]) are considered optional. 7.2.1. Add The Add Command adds a Termination to a Context. [TerminationID] [,MediaDescriptor] [,ModemDescriptor] [,MuxDescriptor] [,EventsDescriptor] [,SignalsDescriptor] [,DigitMapDescriptor] [,ObservedEventsDescriptor] [,StatisticsDescriptor] [,PackagesDescriptor] Add( TerminationID [, MediaDescriptor] [, ModemDescriptor] [, MuxDescriptor] [, EventsDescriptor] [, SignalsDescriptor] [, DigitMapDescriptor] [, AuditDescriptor] ) The TerminationID specifies the termination to be added to the Context. For an existing Termination, the TerminationID would be specific. For a Termination which does not yet exist, the TerminationID is specified as Choose ("$") in the command. The new TerminationID will be returned. Wildcards may be used in an Add, but such usage would be unusual. If the wildcard matches more than one TerminationID, all possible matches are attempted, with results reported for each one. The order of attempts when multiple TerminationIDs match is not specified. The optional MediaDescriptor describes all media streams. The optional ModemDescriptor and MuxDescriptor specify a modem and mul- tiplexer if applicable. For convenience, if a Multiplex Descriptor is present in an Add command and lists any Terminations that are not currently in the Context, such Terminations are added to the context as if individual Add commands listing the Terminations were invoked. The EventsDescriptor parameter is optional. If present, it provides the list of events that should be detected on the Termination. Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 29] Internet draft MEGACO Protocol September 21, 1999 The SignalsDescriptor parameter is optional. If present, it provides the list of signals that should be applied to the Termination. The DigitMapDescriptor parameter is optional. If present, defines a DigitMap definition that may be used in an EventsDescriptor. The AuditDescriptor is optional. If present, the command will return descriptors as specified in the AuditDescriptor. 7.2.2. Modify The Modify Command modifies the properties of a Termination. [TerminationID] [,MediaDescriptor] [,ModemDescriptor] [,MuxDescriptor] [,EventsDescriptor] [,SignalsDescriptor] [,DigitMapDescriptor] [,ObservedEventsDescriptor] [,StatisticsDescriptor] [,PackagesDescriptor] Modify( TerminationID [, MediaDescriptor] [, ModemDescriptor] [, MuxDescriptor] [, EventsDescriptor] [, SignalsDescriptor] [, DigitMapDescriptor] [, AuditDescriptor] ) The TerminationID may be specific if a single Termination in the Context is to be modified. Use of wildcards in the TerminationID may be appropriate for some operations. If the wildcard matches more than one TerminationID, all possible matches are attempted, with results reported for each one. The order of attempts when multiple TerminationIDs match is not specified. The "choose" option is an error, as modify may only be used on existing Terminations. The remaining parameters to Modify are the same as those to Add. The Media Descriptor is optional for Modify. 7.2.3. Subtract The Subtract Command disconnects a Termination from its Context and Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 30] Internet draft MEGACO Protocol September 21, 1999 returns statistics on the Termination's participation in the Context. [TerminationID] [,MediaDescriptor] [,ModemDescriptor] [,MuxDescriptor] [,EventsDescriptor] [,SignalsDescriptor] [,DigitMapDescriptor] [,ObservedEventsDescriptor] [,StatisticsDescriptor] [,PackagesDescriptor] Subtract(TerminationID [, AuditDescriptor] ) TerminationID in the input parameters represents the Termination that is being subtracted. The TerminationID may be specific or may be a wild- card value indicating that all (or a set of related) Terminations in the Context of the Subtract Command are to be subtracted. If the wildcard matches more than one TerminationID, all possible matches are attempted, with results reported for each one. The order of attempts when multiple TerminationIDs match is not specified. The "choose" option is an error, as subtract may only be used on existing Terminations. The Statistics parameter is returned to report information collected on the Termination or Terminations specified in the Command. The informa- tion reported applies to the Termination's or Terminations' existence in the Context from which it or they are being subtracted. The AuditDescriptor is optional. If present, the command will return descriptors as specified in the AuditDescriptor. 7.2.4. Move The Move Command moves a Termination to another Context from its current Context in one atomic operation. [TerminationID] [,MediaDescriptor] [,ModemDescriptor] [,MuxDescriptor] [,EventsDescriptor] [,SignalsDescriptor] [,DigitMapDescriptor] [,ObservedEventsDescriptor] [,StatisticsDescriptor] Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 31] Internet draft MEGACO Protocol September 21, 1999 [,PackagesDescriptor] Move( TerminationID [, MediaDescriptor] [, ModemDescriptor] [, MuxDescriptor] [, EventsDescriptor] [, SignalsDescriptor] [, DigitMapDescriptor] [, AuditDescriptor] ) The TerminationID specifies the Termination to be moved. It may be wildcarded. If the wildcard matches more than one TerminationID, all possible matches are attempted, with results reported for each one. The order of attempts when multiple TerminationIDs match is not specified. By convention, the Termination is subtracted from its previous Context. The remaining descriptors are processed as in the Modify Command. The AuditDescriptor with the Statistics option, for example, would return statistics on the Termination just prior to the Move. 7.2.5. AuditValue The AuditValue Command returns the current values of properties, events, signals and statistics associated with Terminations. [TerminationID] [,MediaDescriptor] [,ModemDescriptor] [,MuxDescriptor] [,EventsDescriptor] [,SignalsDescriptor] [,DigitMapDescriptor] [,ObservedEventsDescriptor] [,StatisticsDescriptor] [,PackagesDescriptor] AuditValue(TerminationID, AuditDescriptor ) TerminationID may be specific or wildcarded. If the wildcard matches more than one TerminationID, all possible matches are attempted, with results reported for each one. The order of attempts when multiple Ter- minationIDs match is not specified. Use of "choose" is an error. The appropriate descriptors, with the current values for the Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 32] Internet draft MEGACO Protocol September 21, 1999 Termination, are returned from AuditValue. ObservedEvents returns a list of events in the EventBuffer (BufferedEventDescriptor returns Buf- ferMode and ProcessingMode). PackagesDescriptor returns a list of pack- ages realized by the Termination. AuditValue results depend on the Context, viz. Specific, null, or unspecified. The TerminationID may be specific, or wildcarded. The following illustrates other information that can be obtained with the Audit Command: ______________________________________________________________________________ |ContextID | TerminationID| Information Obtained | |Specific | all | List of Terminations in a Context | |Specific | wildcard | List of matching Terminations in a Context | |Specific | specific | Audit of a single Termination in a Context | |Null | Root | Audit of Media Gateway state and events | |Null | all | List of all Terminations in the Media Gateway | |Null | wildcard | List of all matching Terminations | |Null | specific | Audit of a single Termination in outside of any | | | Context | |Unspecified| Root | Audit of Media Gateway state and events | |Unspecified| all | List of all Terminations in the Media Gateway | | | | and the Context(s) to which they are associated | |Unspecified| wildcard | List of all matching Terminations and the | | | | Context to which they are associated | |___________|_______________|__________________________________________________| 7.2.6. AuditCapabilities The AuditCapabilities Command returns the possible values of properties, events, signals and statistics associated with Terminations. [TerminationID] [,MediaDescriptor] [,ModemDescriptor] [,MuxDescriptor] [,EventsDescriptor] [,SignalsDescriptor] [,DigitMapDescriptor] [,ObservedEventsDescriptor] [,StatisticsDescriptor] [,PackagesDescriptor] AuditCapabilities(TerminationID, AuditDescriptor ) The appropriate descriptors, with the possible values for the Termina- tion are returned from AuditCapabilities. Descriptors may be repeated Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 33] Internet draft MEGACO Protocol September 21, 1999 where there are multiple possible values. Interpretation of what capabilities are requested for various values of ContextID and TerminationID is the same as in AuditValue. 7.2.7. Notify The Notify Command allows the Media Gateway to notify the Media Gateway Controller of events occurring within the Media Gateway. Notify(TerminationID, ObservedEventsDescriptor) The TerminationID parameter specifies the Termination issuing the Notify Command. The TerminationID shall be a fully qualified name. The ObservedEventsDescriptor contains the RequestID and a list of events that the Media Gateway detected in the order that they were detected. The RequestID returns the RequestID parameter of the EventsDescriptor that triggered the Notify Command. It is used to correlate the notifi- cation with the request that triggered it. The events in the list must have been requested via the RequestedEvents parameter of the triggering EventsDescriptor. The list must contain the events that were either accumulated (but not notified) or treated according to digit map (but no match found yet) and well as the final event that triggered the detec- tion or provided a final match in the digit map. Each event in the list is accompanied by properties associated with the event and an indication of the time that the event was detected. Unsolicited Notify Commands are not possible. 7.2.8. ServiceChange The ServiceChange Command allows the Media Gateway to notify the Media Gateway Controller that a Termination or group of Terminations is about to be taken out of service or has just been returned to service. It also allows a MGC to hand over control of a MG to another MGC. [ServiceChangeDescriptor] ServiceChange(TerminationID, ServiceDescriptor ) The TerminationID parameter specifies the Termination(s) that are taken out of or returned to service. Wildcarding of Termination names is quite useful here, with the exception that the "choose" mechanism shall not be used. Use of the "Root" TerminationID indicates a ServiceChange Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 34] Internet draft MEGACO Protocol September 21, 1999 affecting the entire Media Gateway. The ServiceDescriptor contains the following parameters: * ServiceChangeMethod * ServiceChangeReason * ServiceChangeDelay * Port * Profile * MGCIdToTry The ServiceChangeMethod parameter specifies the type of ServiceChange that will or has occurred: 1. Graceful - indicates that the specified Terminations will be taken out of service after the specified ServiceChangeDelay; established connections are not yet affected, but the Media Gateway Controller should refrain from establishing new connections and should attempt to gracefully tear down existing connections IP P 2. Forced - indicates that the specified Terminations were taken abruptly out of service and any established connections associated with them were lost 3. Restart - indicates that service will be restored on the specified Terminations after expiration of the ServiceChangeDelay; the Termi- nations are assumed to now not be associated with any Context 4. Disconnected - always applied with the Root TerminationID, indi- cates that the MG lost communication with the MGC, but it was sub- sequently restored. Since MG state may have changed, the MGC may wish to use the Audit command to resynchronize its state with the MG's. 5. Handoff - sent from the MGC to the MG, this reason indicates that the MGC is going out of service and a new MGC association must be established. The ServiceChangeReason parameter specifies the reason why the Servi- ceChange has or will occur. It consists of an alphanumeric token (IANA registered) and an explanatory string. The optional Port parameter specifies the port number to be used for Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 35] Internet draft MEGACO Protocol September 21, 1999 subsequent communications. It can be specified in the input parameter descriptor or the returned result descriptor. The optional ServiceChangeDelay parameter is expressed in seconds. If the delay is absent or set to zero the delay value should be considered to be null. In the case of a "graceful" ServiceChangeMethod, a null delay indicates that the Media Gateway Controller should wait for the natural removal of existing connections and should not establish new connections. The ServiceChangeDelay is always considered null in the case of the "forced" method. The Profile parameter specifies the Profile (if any) of the protocol supported. The Profile includes the version of the profile supported. A ServiceChange Command specifying the "Root" for the TerminationID is a registration command by which a Media Gateway announces its existence to the Media Gateway Controller. The Media Gateway is expected to be pro- visioned with the name of one primary and some number of alternate Media Gateway Controllers. The ServiceChangeMethod shall be "forced" for this usage. Acknowledgement of the ServiceChange Command completes the registration process. Normally, the MG will specify the transport port number to be used by the MGC for sending messages in the Port parameter in the input ServiceChangeDescriptor. The MGC specifies the port number for the MG to use in the returned result ServiceDescriptor. The Media Gateway Controller may return a MGCIdToTry parameter that describes the Media Gateway Controller that should preferably be con- tacted for further service by the Media Gateway. In this case the Media Gateway shall reissue the ServiceChange command to the new Media Gateway Controller. The Gateway specified in a MGCIdToTry, if provided, shall be contacted before any further alternate MGCs. On a HandOff message from MGC to MG, the MGCIdToTry is the new MGC that will take over from the current MGC. 7.2.9. Generic Command Syntax The protocol can be encoded in a binary format or in a text format. MGCs should support both encoding formats. MGs may support both for- mats. The protocol syntax is defined in Annex A. A complete ABNF of the text encoding of the protocol per RFC2234 is given in Annex B. The mechanism for binary encoding is specified in Annex C. Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 36] Internet draft MEGACO Protocol September 21, 1999 7.3. Command Error Codes Errors consist of an IANA registered alphanumeric token and an explana- tory string. The identified error codes are: Note: we need to renumber the error codes. 400 - Bad Request 401 - Protocol Error 402 - Unauthorized 403 - Syntax Error in Transaction 410 - Incorrect identifier 411 - The transaction refers to an unknown ContextId 412 - No ContextIDs available 420 - No such Event or signal in this package 421 - Unknown action or illegal combination of actions 422 - Syntax Error in Action 430 - Unknown TerminationID 431 - No TerminationID matched a wildcard 432 - Out of TerminationIDs or No TerminationID available 433 - TerminationID is already in a Context 440 - Unsupported or unknown Package 441 - Missing RemoteDescriptor 442 - Syntax Error in Command 443 - Unsupported or Unknown Command 444 - Unsupported or Unknown Descriptor 445 - Descriptor not legal in this command 446 - Descriptor appears twice in a command 450 - No such property in this package 451 - Parameter illegal in this Descriptor 453 - Parameter or Property appears twice in this Descriptor 500 - Internal Gateway Error 501 - Not Implemented 502 - Not ready. 503 - Service Unavailable 510 - Insufficient resources 512 - Gateway unequipped to detect requested Event 513 - Gateway unequipped to generate requested Signals 514 - Gateway cannot send the specified announcement 515 - Unsupported Media Type 517 - Unsupported or invalid mode 518 - Out of space to store digit map 519 - Gateway does not have a digit map 520 - Termination is "ServiceChangeing" 526 - Insufficient bandwidth Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 37] Internet draft MEGACO Protocol September 21, 1999 529 - Internal hardware failure" 581 - Does Not Exist 8. TRANSACTIONS Commands between the Media Gateway Controller and the Media Gateway are grouped into Transactions, each of which is identified by a Transac- tionID. Transactions consist of one or more Actions. An Action con- sists of a series of Commands that are limited to operating within a single Context. Consequently each Action typically specifies a Contex- tID. However, there are two circumstances where a specific ContextID is not provided with an Action. One is the case of modification of a Ter- mination outside of a Context. The other is where the controller requests the gateway to create a new Context. Following is a graphic representation of the Transaction, Action and Command relationships. +----------------------------------------------------------+ | Transaction x | | +----------------------------------------------------+ | | | Action 1 | | | | +---------+ +---------+ +---------+ +---------+ | | | | | Command | | Command | | Command | | Command | | | | | | 1 | | 2 | | 3 | | 4 | | | | | +---------+ +---------+ +---------+ +---------+ | | | +----------------------------------------------------+ | | | | +----------------------------------------------------+ | | | Action 2 | | | | +---------+ | | | | | Command | | | | | | 1 | | | | | +---------+ | | | +----------------------------------------------------+ | | | | +----------------------------------------------------+ | | | Action 3 | | | | +---------+ +---------+ +---------+ | | | | | Command | | Command | | Command | | | | | | 1 | | 2 | | 3 | | | | | +---------+ +---------+ +---------+ | | | +----------------------------------------------------+ | +----------------------------------------------------------+ Figure 5 Transactions, Actions and Commands Transactions are presented as TransactionRequests. Corresponding responses to a TransactionRequest are received in a single reply. There Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 38] Internet draft MEGACO Protocol September 21, 1999 are two types of replies, a TransactionReply, and a TransactionPending. Transactions guarantee ordered Command processing. That is, Commands within a Transaction are executed sequentially. At the first failing Command in a Transaction, processing of the remaining Commands in that Transaction stops. If a command contains a wildcarded terminationID, each of the actual TerminatioIDs matching the wildcard is attempted. A response within the TransactionReply is included for each matching Ter- minationID, even if one or more instances generated an error. If any TerminationID matching a wildcard results in an error when executed, any commands following the wildcarded command are not attempted. A TransactionReply includes the return values for all of the Commands in the corresponding TransactionRequest. The TransactionReply includes the return values for the Commands that were executed successfully, and the Command and error descriptor for any Command that failed. Transaction- Pending is used to periodically notify the receiver that a Transaction has not completed yet, but is actively being processed. 8.1. Common Parameters 8.1.1. Transaction Identifiers Transactions are identified by a TransactionID, which is assigned by sender and is unique within the scope of the sender. 8.1.2. Context Identifiers Contexts are identified by a ContextID, which is assigned by the Media Gateway and is unique within the scope of the Media Gateway. The Media Gateway Controller shall use the ContextID supplied by the Media Gateway in all subsequent Transactions relating to that Context. The protocol makes reference to two distinguished values that may be used by the Media Gateway Controller when it has no ContextID to use in a Transac- tion: 1. The "null" Context, which is used to refer to a Termination that is currently not associated with a Context. 2. The "unspecified" Context, which is used to request that the Media Gateway create a new Context. 8.2. Transaction Application Programming Interface Following is an Application Programming Interface (API) describing the Transactions of the protocol. This API is shown to illustrate the Tran- sactions and their parameters and is not intended to specify implementa- tion (e.g.-via use of blocking function calls). It will describe the Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 39] Internet draft MEGACO Protocol September 21, 1999 input parameters and return values expected to be used by the various Transactions of the protocol from a very high level. Transaction syntax and encodings are specified in later subsections. 8.2.1. TransactionRequest The TransactionRequest is invoked by the sender. There is one Transac- tion per request invocation. A request contains one or more Actions, each of which specifies its target Context and one or more Commands per Context. TransactionRequest(TransactionId { ContextID {Command ... Command}, . . . ContextID {Command ... Command } }) The TransactionID parameter must specify a value for later correlation with the TransactionReply or TransactionPending response from the receiver. The ContextID parameter must specify a value to pertain to all Commands that follow up to either the next specification of a ContextID parameter or the end of the TransactionRequest, whichever comes first. The Con- textID may be specific, unspecified, or null. The Command parameter represents one of the Commands mentioned in the "Command Details" subsection titled "Application Programming Interface". 8.2.2. TransactionReply The TransactionReply is invoked by the receiver. There is one reply invocation per transaction. A reply contains one or more Actions, each of which must specify its target Context and one or more Responses per Context. TransactionReply(TransactionID { ContextID { Response ... Response }, . . . ContextID { Response ... Response } }) The TransactionID parameter must specify a keyword value for correlation with the corresponding TransactionRequest from the sender. The ContextID parameter must specify a value to pertain to all Responses for the action. The ContextID may be specific or null. Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 40] Internet draft MEGACO Protocol September 21, 1999 Each of the Response parameters represents a return value as mentioned in Section 7.2, or an error descriptor if the command execution encoun- tered an error. Commands after the point of failure are not processed and, therefore, Responses are not issued for them. If the receiver encounters an error in processing a ContextID, the requested Action response will consist of the context ID and a single error descriptor. If the receiver encounters an error such that it cannot determine a legal Action, it will return a TransactionReply consisting of the Tran- sactionID and a single error descriptor. If the receiver encounters an error such that is cannot determine a legal Transaction, it will return a TransactionReply with a null Tran- sactionID and a single error descriptor. 8.2.3. TransactionPending The receiver invokes the TransactionPending. A TransactionPending indi- cates that the Transaction is actively being processed, but has not been completed. It is used to prevent the sender from assuming the Transac- tionRequest was lost where the Transaction will take some time to com- plete. TransactionPending(TransactionID { } ) The TransactionID parameter must specify a keyword value for correlation with the corresponding TransactionRequest from the sender. A property of root (normalMGExecutionTime) is settable by the MGC to indicate the interval within which the MGC expects a response to any transaction from the MG. Another property (normalMGCExecutionTime) is settable by the MGC to indicate the interval within which the MG should expects a response to any transaction from the MGC. Senders may receive more than one TransactionPending for a command. 8.3. Messages Multiple Transactions can be concatenated into a Message. Messages have a header, which includes the identity of the sender. The Message Iden- tifier (MID) of a message is set to a provisioned name (e.g. domain address/domain name/device name) of the entity transmitting the message. Domain name is a suggested default. Every Message contains a Version Number identifying the version of the protocol the message conforms to. Versions are defined as in RFC2145, and consist of a major/minor version with one or two digits each. Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 41] Internet draft MEGACO Protocol September 21, 1999 9. TRANSPORT The transport mechanism for the protocol should allow the reliable tran- sport of transactions between an MGC and MG. The transport shall remain independent of what particular commands are being sent and shall be applicable to all application states. There are several transports defined for the protocol, which are defined in normative Annexes to this document. Additional Transports may be defined as additional annexes in subsequent editions of this document, or in separate documents. The MG is provisioned with a DNS name or IP address of a primary and zero or more secondary MGCs (see section 7.2.8) which is the address the MG uses to send messages to the MGC. The MGC receives the Servi- ceChange message from the MG and can determine the MGs IP address. Responses to commands are sent back to the source address of the com- mands. The initial ServiceChange message should be sent to port ???? if using TCP and port ???? if using UDP. The ServiceChange command contains a ServiceChangePort parameter. The MG specifies the TCP/UDP port number it wishes the MGC to use for communication. The MGC replies with the Port set to the TCP/UDP port number it wishes the MG to use for further communications. 10. SECURITY CONSIDERATIONS 10.1. Protection of Protocol Connections A security mechanism is clearly needed to prevent unauthorized entities from using the MEGACO/H.248 protocol for setting up unauthorized calls or interfering with authorized calls. The security mechanism for the MEGACO/H.248 protocol is IPsec [RFC2401 to RFC2411]. The AH header [RFC2402] affords data origin authentication, connection- less integrity and optional anti-replay protection of messages passed between the MG and the MGC. The ESP header[RFC2406] provides all the above security services plus confidentiality of messages, if desired. For instance, the ESP encryption service should be requested if the ses- sion descriptions are used to carry session keys, as defined in SDP. MEGACO/H.248 implementations employing the ESP header SHALL comply with section 5 of [RFC2406], which defines a minimum set of algorithms for integrity checking and encryption. Similarly, MEGACO/H.248 implementa- tions employing the AH header SHALL comply with section 5 of [RFC2402], which defines a minimum set of algorithms for integrity checking using manual keys. MEGACO/H.248 implementations SHOULD use IKE [RFC2409] to permit more robust keying options. MEGACO/H.248 implementations employing IKE SHOULD support authentication with RSA signatures and RSA public key Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 42] Internet draft MEGACO Protocol September 21, 1999 encryption. 10.2. Interim AH-within-MEGACO/H.248 scheme Implementation of IPsec requires that the AH or ESP header be inserted immediately after the IP header. This cannot be easily done at the application level. Therefore, this presents a deployment problem for the MEGACO/H.248 protocol where the underlying network implementation does not support IPsec. As an interim solution, the MEGACO/H.248 protocol defines an optional AH header within the MEGACO/H.248 protocol header. The header fields are exactly those of the SPI, SEQUENCE NUMBER and DATA fields as defined in [RFC2402]. The semantics of the header fields are the same as the "tran- sport mode" of [RFC2402], except for the calculation of the Integrity Check value (ICV). In IPsec, the ICV is calculated over the entire IP packet including the IP header. This prevents spoofing of the IP addresses. To retain the same functionality, the ICV calculation should be performed across the entire transaction prepended by a synthesized IP header consisting of a 32 bit source IP address, a 32 bit destination address and an 16 bit UDP encoded as 10 hex digits. When the AH-within- MEGACO/H.248 mechanism is employed when TCP is the transport Layer, the UDP Port above becomes the TCP port, and all other operations are the same. Implementations of the MEGACO/H.248 protocol SHALL implement IPsec where the underlying operating system supports IPsec. Implementations of the MEGACO/H.248 protocol using IPv4 SHALL implement the interim AH-within- MEGACO/H.248 scheme. However, this interim scheme SHALL NOT be used when the underlying network layer supports IPsec. IPv6 Implementations are assumed to support IPsec and SHALL NOT use the AH-within- MEGACO/H.248 interim scheme. All implementations of the AH-within-MEGACO/H.248 interim mechanism SHALL comply with section 5 of [RFC2402] which defines a minimum set of algorithms for integrity checking using manual keys. The AH-within-MEGACO/H.248 interim scheme does not provide protection against eavesdropping; thus forbidding third parties from monitoring the connections set up by a given termination. Also, it does not provide protection against replay attacks. These procedures do not necessarily protect against denial of service attacks by misbehaving MGs or mis- behaving MGCs. However, they will provide an identification of these misbehaving entities, which should then be deprived of their authoriza- tion through maintenance procedures. Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 43] Internet draft MEGACO Protocol September 21, 1999 10.3. Protection of Media Connections The protocol allows the MGC to provide MGs with "session keys" that can be used to encrypt the audio messages, protecting against eavesdropping. A specific problem of packet networks is "uncontrolled barge-in." This attack can be performed by directing media packets to the IP address and UDP port used by a connection. If no protection is implemented, the packets must be decompressed and the signals must be played on the "line side". A basic protection against this attack is to only accept packets from known sources, checking for example that the IP source address and UDP source port match the values announced in the RemoteDescriptor. This has two inconveniences: it slows down connection establishment and it can be fooled by source spoofing: - To enable the address-based protection, the MGC must obtain the remote session description of the egress MG and pass it to the ingress MG. This requires at least one network roundtrip, and leaves us with a dilemma: either allow the call to proceed without waiting for the round trip to complete, and risk for example, "clipping" a remote announcement, or wait for the full roundtrip and settle for slower call-set-up procedures. - Source spoofing is only effective if the attacker can obtain valid pairs of source destination addresses and ports, for example by listening to a fraction of the traffic. To fight source spoofing, one could try to control all access points to the network. But this is in practice very hard to achieve. An alternative to checking the source address is to encrypt and authen- ticate the packets, using a secret key that is conveyed during the call set-up procedure. This will not slow down the call set- up, and provides strong protection against address spoofing. 11. MG-MGC CONTROL INTERFACE The control association between MG and MGC is initiated at MG cold start, and announced by a ServiceChange message, but can be changed by subsequent events, such as failures or manual service events. While the protocol does not have an explicit mechanism to support multiple MGCs controlling a physical MG, it has been designed to support the multiple logical MG (within a single physical MG) that can be associated with different MGCs. Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 44] Internet draft MEGACO Protocol September 21, 1999 11.1. Multiple Virtual MGs A virtual MG consists of a set of statically partitioned Terminations. The model does not require that other resources be statically allocated, just Terminations. The mechanism for allocating Terminations to virtual MGs is a management method outside the scope of the protocol. Each of the virtual MGs appears to the MGC as a complete MG client. In many cases, a physical MG may have only one network interface, which must be shared across virtual MGs. In such a case, the packet/cell side Termination is shared. It should be noted however, that in use, such interfaces require an ephemeral instance of the Termination to be created per flow, and thus sharing the Termination is straightforward. This mechanism does lead to a complication, namely that the MG must always know which of its controlling MGCs should be notified if an event occurs on the interface. In normal operation, the MG will be instructed by the MGC to create net- work flows (if it is the originating side), or to expect flow requests (if it is the terminating side), and no confusion will arise. However, if an unexpected event occurs, the MG must know what to do. If recovering from the event requires manipulation of the interface state, there can be only one MGC who can do so. These issues are resolved by allowing any of the MGCs to create EventDescriptors to be notified of such events, but only one MGC can have read/write access to the physical interface properties; all other MGCs have read-only access. The management mechanism is used to designate which MGC has read/write capability, and is designated the Master MGC. Each virtual MG has its own Root Termination. In most cases the values for the properties of the Root Termination are independently settable by each MGC. Where there can only be one value, the parameter is read-only to all but the Master MGC. 11.2. Cold Start A MG is pre-provisioned by a management mechanism outside the scope of this protocol with a Primary and (optionally) an ordered list of Secon- dary MGCs. Upon a cold start of the MG, it will issue a ServiceChange command with a "Restart" method, on the Root Termination to its primary MGC. If the MGC accepts the MG, it will send a Transaction Accept, with the MGCIdToTry set to itself. If the MG receives a MGCIdToTry not equal to the MGC it contacted, it sends a ServiceChange to the MGC specified in the MGCIdToTry. It continues this process until it gets a control- ling MGC to accept its registration, or it fails to get a reply. Upon failure to obtain a reply, either from the Primary MGC, or a designated successor, the MG tries it's pre-provisioned Secondary MGCs, in order. Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 45] Internet draft MEGACO Protocol September 21, 1999 11.3. Failure of an MG If a MG fails, but is capable of sending a message to the MGC, it sends a ServiceChange with an appropriate method (graceful or forced) and specifies the Root TerminationID. When it returns to service, it sends a ServiceChange with a "Restart" method. Allowing the MGC to send duplicate messages to both MGs accommodates pairs of MGs that are capable of redundant failover of one of the MGs. Only the Working MG shall accept or reject transactions. Upon failover, the Primary MG sends a ServiceChange command with a "Failover" method and a "Failed MG" reason. The MGC then uses the primary MG as the active MG. When the error condition is repaired, the Working MG can send a "ServiceChange" with a "Restart" method. 11.4. Failure of an MGC If the MG detects a failure of it's controlling MGC, it attempts to con- tact the next MGC on its pre-provisioned list. It starts it's attempts at the beginning (Primary MGC), unless that was the MGC that failed, in which case it starts at it's first Secondary MGC. It sends a Servi- ceChange message with a "Failover" method and a "Failed MGC" reason. In partial failure, or manual maintenance reasons, an MGC may wish to direct its controlled MGs to use a different MGC. To do so, it sends a ServiceChange method to the MG with a "HandOff" method, and it's desig- nated replacement in MGCIdToTry. The MG should send a ServiceChange mes- sage with a "Forced" method and a "MGC directed change" reason to the designated MGC. If it fails to get a reply, or fails to see an Audit command subsequently, it should behave as if it's MGC failed, and start contacting secondary MGCs. When the MGC initiates a HandOff, the handover should be transparent to Operations on the Media Gateway. Commands in progress continue, tran- saction replies are sent to the new MGC, and the MG should expect out- standing transaction replies from the new MGC. All connections should stay up. It is possible that the MGC could be implemented in such a way that a failed MGC is replaced by a working MGC where the identity of the new MGC is the same as the failed one. In such a case, MGCIdToTry would be specified with the previous value. In such a case, the MG shall behave as if the value was changed, and send a ServiceChange message, as above. failover by the above mechanism. Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 46] Internet draft MEGACO Protocol September 21, 1999 12. PACKAGE DEFINITION The primary mechanism for extension is by means of Packages. Packages define additional Properties, Events, Signals and Statistics that may occur on Terminations. Packages defined by IETF will appear in separate RFCs. Packages relevant to H.323 systems are listed in an Annex to Recommenda- tion H.323. Packages defined by ITU-T will be described in Annexes to H.248. 12.1. Guidelines for defining packages Packages define properties, events, signals and statistics. Names of all such defined constructs shall consist of the ID of the package, the character "/" and the ID of the item, for example, "tone/ring". A Pack- age shall contain the following sections: 1. Full Package name, PackageID, and description. PackageIDs shall be a string of up to 64 characters, containing no spaces, and consist- ing of alphas and digits, and possibly including the special char- acter underscore ("_"). The PackageID is used in a TerminationSta- teDescriptor, or the LocalControl Descriptor, for example, "tone/dialtone" specifies a signal "dialtone" in the package "tone". The Package name is descriptive only. 2. Properties defined by the package, specifying a Property name, Pro- pertyID, possible values, and description. PropertyID shall be a string of up to 64 characters, containing no spaces, and consisting of alphas and digits, and possibly including the special character underscore ("_"). The PropertyID is used in a TerminationSta- teDescriptor, or the LocalControl Descriptor. For example "foo/color" specifies the "color" property defined in the package "foo". The Property name is descriptive only. 3. Events defined by the package, specifying an Event name, EventID, possible Parameter names, ParameterIDs and possible values for each parameter. EventIDs and ParameterIDs shall be a string of up to 64 characters, containing no spaces, and consisting of alphas and digits, and possibly including the special character underscore ("_"). EventIDs and PropertyIDs are used in an Event Descriptor. For example "line/offhook" specifies the "offhook" event defined in the "line" package. The Event name is descriptive only. 4. Signals defined by the package, specifying a Signal name, SignalID, possible Parameter names, ParameterIDs and possible values for each Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 47] Internet draft MEGACO Protocol September 21, 1999 parameter. SignalID and ParameterIDs shall be a string of up to 64 characters, containing no spaces, and consisting of alphas and digits, and possibly including the special character underscore ("_"). SignalID and PropertyIDs are used in a Signal Descriptor. The Signal name is descriptive only. 5. Statistics defined by the package, specifying a Statistic name, StatisticID, units, and description. StatisticID shall be a string of up to 64 characters, containing no spaces, and consisting of alphas and digits, and possibly including the special character underscore ("_"). The StatisticID is used in a Statistics Descrip- tor. The Statistic name is descriptive only. 12.2. Example Package Section 1. DTMF Package PackageID: dtmf Description: This package is used to detect and generate tones on the analog trunk or line connection on a media gateway. Section 2. Properties 2.1 Media Gateway Country Code PropertyID: mgcountry Possible values: 3 character string Description: Country code from ITU?????? Section 3. Events 3.1 ToneDetected EventID: tonedt Parameters: 3.1.2 Stream ID ParameterID: streamid Direction: IN Possible Values: Integer in the range of 0-256 Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 48] Internet draft MEGACO Protocol September 21, 1999 Description: id of audio stream to detect tones on. 3.1.3 Detected Tone List ParameterID: listoftones Direction: IN/OUT Possible Values: a string (max 64 characters) consisting of the characters '0', '1', '2', '3', '4', '5', '6', '7', '8', '9', '*', '#', 'A', 'B', 'C', 'D', 'X', '/' Description: one or more dtmf tones (to be) detected, separated by '/' Example: "0/1/2/3/4/5/6/7/8/9/*/#". 3.1.4 Event Type ParameterID: eventtype Direction: OUT Possible Values: "MULTI": multiple digits have been accumu- lated and sent. "START": one tone start detected "LONG": one tone has been detected for more than 2 seconds "END': one tone end detected. Description: What kind of detection has occurred 3.2.2 Duration ParameterID: duration Direction: OUT Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 49] Internet draft MEGACO Protocol September 21, 1999 Possible Values: Integer (32 bit) Description: When eventtype is END, the length of the tone detected Description: Detects a DTMF tone. Reports stream and which tone was detected. 3.2 SilenceDetected EventID: silencedt Parameters: 3.2.1 Stream ID ParameterID: streamid Direction: IN Possible Values: Integer in the range of 0-256 Description: id of audio stream to detect tones on. 3.2.2 Duration ParameterID: duration Direction: IN/OUT Possible Values: Integer (32 bit) Description: How many ms to wait before trigger Description: This event is triggered after a period of silence has occurred. Section 4. Signals 4.1 Play Tones SignalID: playtone Parameters: 4.1.1 Stream ID Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 50] Internet draft MEGACO Protocol September 21, 1999 ParameterID: streamid Direction: IN Possible Values: Integer in the range of 0-256 Description: id of audio stream to play tones on. 4.1.2 Tone List ParameterID: listoftones Direction: IN/OUT Possible Values: a string (max 64 characters) consisting of the Characters '0', '1', '2', '3', '4', '5', '6', '7', '8', '9', '*', '#', 'A', 'B', 'C', 'D', 'X', '/' Description: one or more dtmf tones to be played, separated by '/' Example: "0/1/2/3/4/5/6/7/8/9/*/#". 4.1.3 Signal Type ParameterID: signaltype Possible values: "BR" brief duration (provisioned) "ON" Play until instructed to stop "TO" Play until timed out 4.1.4 Duration ParameterID: duration Direction: IN/OUT Possible Values: Integer (32 bit) Description: If signalType is TO, How many ms Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 51] Internet draft MEGACO Protocol September 21, 1999 to play each tone 12.3. Package Registration A package can be registered with IANA for interoperability reasons. See section 13 for IANA considerations. 13. IANA CONSIDERATIONS 13.1. Packages The following considerations SHALL be met to register a package with IANA: 1. A unique string name and serial number is registered for each pack- age. 2. A public document or a standard forum document, which can be refer- enced as the document that describes the package following the guideline above, must be specified. The document SHALL specify the version of the Package that it describes. 3. A contact name, email and postal addresses for that contact shall be specified. The contact information shall be updated by the defining organization as necessary. 4. The document should be available on a public web server and should have a stable url. The site should provide a mechanism to provide comments and appropriate responses should be returned. The following package names are reserved * dtmf * generic * keypad * Packages registered by other than recognized standards bodies shall have a minimum package name length of 8 characters All other package names are first come-first served if all other condi- tions are met Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 52] Internet draft MEGACO Protocol September 21, 1999 13.2. Error Codes The following considerations SHALL be met to register an error code with IANA: 1. A error number and a one line (80 character maximum) string is registered for each error. 2. A complete description of the conditions under which the error is detected shall be included in a publicly available document. The description shall be sufficiently clear to differentiate the error from all other existing error codes. 3. The document should be available on a public web server and should have a stable url. 4. Error numbers registered by recognized standards bodies shall have 3 or 4 character error numbers 5. Error numbers registered by all other organizations or individuals shall have 4 character error numbers 6. An error number shall not be redefined, nor modified except by the organization or individual that originally defined it, or their successors or assigns. 14. CONTACT INFORMATION IETF Editor Brian Rosen FORE Systems 1000 FORE Drive Warrendale, PA 15086 U.S.A. Phone: +1 724-742-6826 Email: brosen@fore.com ITU Editor John Segers Lucent Technologies Room HE 306 Dept. Forward Looking Work P.O. Box 18, 1270 AA Huizen Netherlands Phone: +31 35 687 4724 Email: jsegers@lucent.com Additional IETF Authors Fernando Cuervo Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 53] Internet draft MEGACO Protocol September 21, 1999 Nortel Networks P.O. Box 3511 Stn C Ottawa, ON, K1Y 4H7 Canada Email: cuervo@nortelnetworks.com Bryan Hill Gotham Networks 15 Discovery Way Acton, MA 01720 USA Phone: +1 978-263-6890 Email: bhill@gothamnetworks.com Christian Huitema Telcordia Technologies MCC 1J236B 445 South Street Morristown, NJ 07960 U.S.A. Phone: +1 973-829-4266 EMail: huitema@research.telcordia.com Nancy Greene Nortel Networks P.O. Box 3511 Stn C Ottawa, ON, K1Y 4H7 Canada Phone: +1 514-271-7221 Email: ngreene@nortelnetworks.com Abdallah Rayhan Nortel Networks P.O. Box 3511 Stn C Ottawa, ON, K1Y 4H7 Canada Email: arayhan@nortelnetworks.com 15. ANNEX A - ASN.1 DESCRIPTION OF THE PROTOCOL (NORMATIVE) 15.1. Specification language The baseline text for this section will be taken from APC-1608. 15.2. Syntax specification This section will contain the protocol syntax specification using the language described in the previous section. Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 54] Internet draft MEGACO Protocol September 21, 1999 16. ANNEX B - TEXT ENCODING OF THE PROTOCOL (NORMATIVE) 16.1. Translation Mechanism A future edition of this document will describe how the syntax of Annex A is translated into ABNF. This version contains hand-coded ABNF 16.2. ABNF specification The protocol syntax is presented in ABNF according to RFC2234. megacoMessage = LWSP [authenticationHeader SEP ] message authenticationHeader = AuthToken EQUAL SecurityParmIndex COLON SequenceNum COLON AuthData SecurityParmIndex = 8(HEXDIG) SequenceNum = 8(HEXDIG) AuthData = 16(HEXDIG) message = MegacopToken SLASH Version SEP mId SEP ( errorDescriptor | 1*(transactionRequest | transactionReply | transactionPending)) transactionPending = PendingToken EQUAL TransactionID LBRKT [TimeNotation] RBRKT transactionRequest = TransToken EQUAL TransactionID LBRKT actionRequest *(COMMA actionRequest) RBRKT actionRequest = CtxToken EQUAL ContextID LBRKT ((contextProperties COMMA commandList) | contextProperties | commandList ) RBRKT contextProperties = contextProperty *(COMMA contextProperty) ; at-most-once contextProperty = topologyDescriptor ; | bridgeDescriptor ; bridgeDescriptor is still to be defined. commandList = commandRequest *(COMMA commandRequest) commandRequest = (ammRequest | subtractRequest | auditRequest | notifyRequest | serviceChangeRequest) transactionReply = ReplyToken EQUAL TransactionID LBRKT ( errorDescriptor | ( actionReply *(COMMA actionReply ))) RBRKT Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 55] Internet draft MEGACO Protocol September 21, 1999 actionReply = CtxToken EQUAL ContextID LBRKT ( errorDescriptor | ( commandReply *(COMMA commandReply)) ) RBRKT commandReply = (serviceChangeReply | auditReply | ammsReply | notifyReply ) ;Add Move and Modify have the same request parameters ammRequest = (AddToken | MoveToken | ModifyToken ) EQUAL TerminationID [LBRKT ammParameter *(COMMA ammParameter) RBRKT] ;at-most-once ammParameter= (mediaDescriptor | modemDescriptor | muxDescriptor | eventsDescriptor | signalsDescriptor | digitMapDescriptor | auditDescriptor) ammsReply = ( AddToken | MoveToken | ModifyToken | SubtractToken ) ( commandError | ( [EQUAL TerminationID] [terminationAudit] )) commandError = EQUAL TerminationID LBRKT errorDescriptor RBRKT subtractRequest = subtractToken EQUAL TerminationID [ LBRKT auditDescriptor RBRKT] auditRequest = (AuditValueToken | AuditCapToken ) EQUAL TerminationID [ LBRKT auditDescriptor RBRKT ] auditReply = ( AuditValueToken | AuditCapToken) ( contextAudit | commandError | [EQUAL TerminationID] terminationAudit ) terminationAudit = LBRKT auditReturnParameter *(COMMA auditReturnParameter) RBRKT contextAudit = EQUAL CtxToken terminationIDList ;at-most-once auditReturnParameter = (mediaDescriptor | modemDescriptor | muxDescriptor | eventsDescriptor | signalsDescriptor | digitMapDescriptor | observedEventsDescriptor | statisticsDescriptor | packagesDescriptor ) auditDescriptor = AuditToken LBRKT auditItem *(COMMA auditItem) RBRKT notifyRequest = NotifyToken EQUAL TerminationID LBRKT observedEventsDescriptor RBRKT notifyReply = NotifyToken ( commandError | [EQUAL TerminationID] ) Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 56] Internet draft MEGACO Protocol September 21, 1999 serviceChangeRequest = serviceChangeToken EQUAL TerminationID LBRKT serviceChangeDescriptor RBRKT serviceChangeReply = serviceChangeToken (commandError | ([EQUAL TerminationID] [LBRKT serviceChangeDescriptor RBRKT] )) errorDescriptor = ErrorToken EQUAL ErrorCode LBRKT quotedString RBRKT ErrorCode = 1*3(DIGIT) ; could be extended TransactionID = UINT32 mId = ( domainAddress | domainName ) [":" portNumber] | deviceName domainName = "<" (ALPHA | DIGIT) *63(ALPHA | DIGIT | "-" | ".") ">" deviceName = pathNAME ContextID = (UINT32 | "-" | "$") domainAddress = "[" (IPv4address | IPv6address) "]" ;RFC2373 contains the definition of IP6Addresses. IPv6address = hexpart [ ":" IPv4address ] IPv4address = V4hex DOT V4hex DOT V4hex DOT V4hex V4hex = 1*3(DIGIT) ; "0".."225" IPv6prefix = hexpart SLASH 1*2DIGIT hexpart = hexseq "::" [ hexseq ] | "::" [ hexseq ] | hexseq hexseq = hex4 *( ":" hex4) hex4 = 1*4HEXDIG portNumber = UINT16 terminationIDList = LBRKT TerminationID *(COMMA TerminationID) RBRKT ; Total length of pathNAME must not exceed 64 chars. ; "*" should not appear more than twice in pathNAME. pathNAME = NAME *(["/"] ["*"] (ALPHA | DIGIT)) ["*"] TerminationID = "$" | "*" | "ROOT" | pathNAME mediaDescriptor = mediaToken LBRKT mediaParm *(COMMA mediaParm) RBRKT ; at-most-once per item ; and either streamParm or streamDescriptor but not both mediaParm = (streamParm | streamDescriptor | terminationStateDescriptor) ; at-most-once Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 57] Internet draft MEGACO Protocol September 21, 1999 streamParm = ( localDescriptor | remoteDescriptor | localControlDescriptor ) streamDescriptor = StreamToken EQUAL StreamID LBRKT streamParm *(COMMA streamParm) RBRKT localControlDescriptor = LocalControlToken LBRKT localParm *(COMMA localParm) RBRKT ; at-most-once per item localParm = ( streamMode | propertyParm ) streamMode = ModeToken EQUAL streamModes streamModes = (SendonlyToken | RecvonlyToken | SendrecvToken | InactiveToken | LoopbackToken | DeleteToken ) propertyParm = pkgdName propertyValue propertyValue = (EQUAL alternativeValue| INEQUAL VALUE) alternativeValue = ( VALUE | LSBRKT VALUE *(COMMA VALUE) RSBRKT | LSBRKT VALUE DOT DOT VALUE RSBRKT ) INEQUAL = LWSP (">" | "<" | "#" ) LWSP LSBRKT = LWSP "[" LWSP RSBRKT = LWSP "]" LWSP localDescriptor = LocalToken EQUAL (tvList | octetStringParm) OctetStringParm = (SdpToken | extensionParameter)LBRKT OctetString RBRKT tvList = TagValueToken EQUAL LBRKT NAME propertyValue *(NAME propertyValue) RBRKT remoteDescriptor = RemoteToken EQUAL (tvList | octetStringParm) terminationStateDescriptor = TerminationStateToken LBRKT terminationStateParm *(COMMA terminationStateParm) RBRKT ; at-most-once per item terminationStateParm =(terminationBuffered | propertyParm | serviceStates) serviceStates = ServiceStatesToken EQUAL ( TestToken | OutOfSvcToken | InSvcToken ) terminationBuffered = BufferedEventHandlingToken LBRKT bufferedEventHandling [COMMA Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 58] Internet draft MEGACO Protocol September 21, 1999 bufferedEventHandling] RBRKT bufferedEventHandling = ( loopControl | processControl) loopControl = (StepToken | LoopToken ) processControl = ( ProcessToken | DiscardToken ) muxDescriptor = MuxToken EQUAL MuxType terminationIDList MuxType = ( H221Token | H223Token | H226Token | H225-0Token | extensionParameter) StreamID = UINT16 pkgdName = [ (PackageName | "*") SLASH ] (ItemID | "*" ) PackageName = NAME ItemId = NAME eventsDescriptor = EventsDescriptorToken EQUAL RequestID LBRKT requestedEvent *(COMMA requestedEvent) RBRKT requestedEvent = pkgdName [ LBRKT eventParameter *(COMMA eventParameter) RBRKT ] ; at-most-one eventAction eventParameter = ( eventAction | eventOther ) eventAction = ActionToken LBRKT requestedActions RBRKT eventOther = eventParameterName EQUAL VALUE eventParameterName = NAME requestedActions = requestedAction LWSP [COLON LWSP embeddedSignalEvents ] [COLON LWSP InterceptToken ] requestedAction = ( accumulateDescriptor | NotifyActionToken | AccumulateToken | extensionParameter ) accumulateDescriptor = DigitMapToken ((EQUAL digitMapName ) | (LBRKT digitMapValue RBRKT )) embeddedSignalEvents = firstembedding [COMMA firstEmbedding] ; at-most-once firstEmbedding = ( secondEvent | signalsDescriptor ) secondEvent = EventsDescriptorToken EQUAL RequestID LBRKT secondRequestedEvent *(COMMA secondRequestedEvent) RBRKT Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 59] Internet draft MEGACO Protocol September 21, 1999 secondRequestedEvent = pkgdName [ LBRKT secondEventParameter *(COMMA secondEventParameter) RBRKT ] ; at-most-one secondEventAction secondEventParameter = ( secondEventAction | eventOther ) secondEventAction = ActionToken LBRKT secondAction RBRKT secondAction = requestedAction LWSP [COLON LWSP signalsDescriptor ] [COLON LWSP InterceptToken ] signalsDescriptor = SignalsDescriptorToken LBRKT signalRequest *(COMMA signalRequest) RBRKT signalRequest = signalName [ LBRKT sigParameter *(COMMA sigParameter) RBRKT ] signalName = pkgdName sigParameter = sigParameterName EQUAL VALUE sigParameterName = NAME observedEventsDescriptor = ObservedEventsToken EQUAL RequestID LBRKT observedEvent *(COMMA observedEvent) RBRKT ;time per event, because it might be buffered observedEvent = [ TimeNotation LWSP COLON] LWSP signalRequest RequestID = UINT32 modemDescriptor = ModemToken (( EQUAL modemType) | (LSBRKT modemType *(COMMA modemType) RSBRKT)) [ LBRKT NAME propertyValue *(COMMA NAME propertyValue) RBRKT ] ; at-most-once modemType = (V18Token | V34Token | V90Token | V91Token | SynchISDNToken |extensionParameter) digitMapDescriptor = DigitMapToken EQUAL digitMapName LBRKT digitMapValue RBRKT digitMapName = NAME digitMapValue=["L" COLON Timer COMMA] ["M" COLON Timer COMMA] digitMap Timer = 1*2DIGIT digitMap = (digitString | LWSP "(" LWSP digitStringList LWSP ")" LWSP) digitStringList = digitString *( LWSP "|" LWSP digitString ) digitString = 1*(digitStringElement) digitStringElement = digitPosition [DOT] digitPosition = digitMapLetter | digitMapRange Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 60] Internet draft MEGACO Protocol September 21, 1999 digitMapRange = ("x" | LWSP "[" LWSP digitLetter LWSP "]" LWSP) digitLetter = *((DIGIT "-" DIGIT ) | digitMapLetter) digitMapLetter=DIGIT | "#" | "*" | "A" | "B" | "C" | "D" | MFSig | "T" MFSig = "K0" | "K1" | "K2" | "S0" | "S1" | "S2" | "S3" ;at-most-once auditItem = ( MuxToken | ModemToken | MediaToken | EventsDescriptorToken | SignalsDescriptorToken | DigitMapToken | StatsToken | ObservedEventsToken | PackagesToken ) serviceChangeDescriptor = ServicesToken LBRKT serviceChangeParm *(COMMA serviceChangeParm) RBRKT ;at-most-once. Version is REQUIRED on first ServiceChange ;request&response serviceChangeParm = (serviceChangeMethod | serviceChangeReason | serviceChangeDelay | serviceChangePort | serviceChangeProfile | extension | serviceChangeMgcId ) serviceChangeMethod = MethodToken EQUAL (FailoverToken | ForcedToken | GracefulToken | RestartToken | DisconnectedToken | HandOffToken | extensionParameter) ;need some reasons!!!, or should it be a string? serviceChangeReason = ReasonToken EQUAL VALUE serviceChangeDelay = DelayToken EQUAL UINT32 serviceChangePort = PortToken EQUAL portNumber serviceChangeMgcId = MgcIdToken EQUAL mId serviceChangeProfile = ProfileToken EQUAL NAME SLASH Version extension = extensionParameter EQUAL VALUE packagesDescriptor = PackagesToken LBRKT packagesItem *(COMMA packagesItem) RBRKT Version = 1*2(DIGIT) DOT 1*2(DIGIT) packagesItem = NAME TimeNotation = Date "T" Time; per ISO 8601:1988 ; Date = yyyymmdd Date = 8(DIGIT) ; Time = hhmmssss Time = 8(DIGIT) statisticsDescriptor = StatsToken LBRKT statisticsParameter *(COMMA statisticsParameter ) RBRKT ;at-most-once per item Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 61] Internet draft MEGACO Protocol September 21, 1999 statisticsParameter = ( pkgdName EQUAL VALUE ) | ( extension) ; I don't know yet about this. topologyDescriptor = TopologyToken LBRKT terminationA COMMA terminationB COMMA topologyDirection RBRKT terminationA = TerminationID terminationB = TerminationID topologyDirection = BothwayToken | IsolateToken | OnewayToken extensionParameter = "X" ("-" | "+") 1*6(ALPHA | DIGIT) ; OctetString is used to describe SDP defined in RFC2327. ; Caution should be taken if CRLF in RFC2327 is used. ; To be safe, use EOL in this ABNF. ; Whenever "}" appears in SDP, it is escaped by " OctetString = *(nonEscapeChar) nonEscapeChar = ( "" | %x01-7C | %x7E-FF ) quotedString = DQUOTE 1*64(SafeChar) DQUOTE UINT16 = 1*5(DIGIT) ; %x0-FFFF UINT32 = 1*10(DIGIT) ; %x0-FFFFFFFF UINT64 = 1*20(DIGIT) ; %x0-FFFFFFFFFFFFFFFF NAME = ALPHA *63(ALPHA | DIGIT | "_" ) VALUE = quotedString | 1*64(SafeChar) SafeChar = DIGIT | ALPHA | "+" | "-" | "&" | "!" | "_" | "/" | "'" | "?" | "@" | "^" | "`" | "~" | "*" | "$" | " "(" | ")" | "%" | "|" | "." EQUAL = LWSP %x3D LWSP ; "=" COLON = %x3A ; ":" LBRKT = LWSP %x7B LWSP ; "{" RBRKT = LWSP %x7D LWSP ; "}" COMMA = LWSP %x2C LWSP ; "," DOT = %x2E ; "." SLASH = %x2F ; "/" ALPHA = %x41-5A | %x61-7A ; A-Z | a-z DIGIT = %x30-39 ; 0-9 DQUOTE = %x22 ; " (Double Quote) HEXDIG = ( DIGIT | "A" | "B" | "C" | "D" | "E" | "F" ) SP = %x20 ; space HTAB = %x09 ; horizontal tab CR = %x0D ; Carriage return LF = %x0A ; linefeed LWSP = *( WSP | COMMENT | EOL ) EOL = (CR [LF] | LF ) Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 62] Internet draft MEGACO Protocol September 21, 1999 WSP = SP | HTAB ; white space SEP = ( WSP | EOL | COMMENT) LWSP COMMENT = ";" *(SafeChar| RestChar | WSP) EOL Restchar = ";" | "[" | "]" | "{" | "}" | ":" | "," | "#" | "<" | ">" | "=" | %x22 ActionToken = ("Action" | "AN") AccumulateToken = ("Accumulate" | "AM") AddToken = ("Add" | "A") AuditToken = ("Audit" | "AT") AuditCapToken = ("AuditCapability" | "AC") AuditValueToken = ("AuditValue" | "AV") AuthToken = ("Authentication" | "AU") AvgLatencyToken = ("AverageLatency" | "AL") BothwayToken = ("Bothway" | "BW") BufferedEventHandlingToken = ("BufferedEventHandling" | "BE") CtxToken = ("Context" | "C") DigitMapToken = ("DigitMap" | "DM") DiscardToken = ("Discard" | "DS") DisconnectedToken = ("Disconnected" | "DC") DelayToken = ("Delay" | "DL") DeleteToken = ("Delete" | "DE") ErrorToken = ("Error" | "ER") EventsDescriptorToken = ("Events" | "E") FailoverToken = ("Failover" | "FL") ForcedToken = ("Forced" | "FO") GracefulToken = ("Graceful" | "GR") H221Token = ("H221" ) H223Token = ("H223" ) H226Token = ("H226" ) H225-0Token = ("H225-0") HandoffToken = ("HandOff" | "HO") InactiveToken = ("Inactive" | "IN") InterceptToken = ("Intercept" | "IC") IsolateToken = ("Isolate" | "IS") InSvcToken = ("InService" | "IV") JitterToken = ("Jitter" | "JI") LocalToken = ("Local" | "L") LocalControlToken = ("LocalControl" | "O") LoopbackToken = ("Loopback" | "LB") LoopToken = ("Loop" | "LP") MediaToken = ("Media" | "M") MegacopToken = ("MEGACO" | "!") MethodToken = ("Method" | "MT") MgcIdToken = ("MgcIdToTry" | "MG") ModeToken = ("Mode" | "MO") ModifyToken = ("Modify" | "MF") Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 63] Internet draft MEGACO Protocol September 21, 1999 ModemToken = ("Modem" | "MD") MoveToken = ("Move" | "MV") MuxToken = ("Mux" | "MX") NotifyActionToken = ("NotifyAction" | "NA") NotifyToken = ("Notify" | "N") ObservedEventsToken = ("ObservedEvents" | "OE") OctetsRecvdToken = ("OctetsReceived" | "OR") OnewayToken = ("Oneway" | "OW") OctetsSentToken = ("OctetsSent" | "OT") OutOfSvcToken = ("OutOfService" | "OS") PackagesToken = ("Packages" | "PG") PendingToken = ("Pending" | "PN") PktsLostToken = ("PacketsLost" | "PL") PktsRecvdToken = ("PacketsRecived" | "PR") PktsSentToken = ("PacketsSent" | "PS") PortToken = ("Port" | "PT") ProcessToken = ("Process" | "PC") ProfileToken = ("Profile" | "PF") ReasonToken = ("Reason" | "RE") RecvonlyToken = ("ReceiveOnly" | "RC") ReplyToken = ("Reply" | "P") RestartToken = ("Restart" | "RS") RemoteToken = ("Remote" | "R") SdpToken = ("SDP" | "D") SignalsDescriptorToken = ("Signals" | "SG") SendonlyToken = ("SendOnly" | "SO") SendrecvToken = ("SendReceive" | "SR") ServicesToken = ("Services" | "SV") ServiceStatesToken = ("ServiceStates" | "SI") ServiceChangeToken = ("ServiceChange" | "SC") StatsToken = ("Statistics" | "SA") StepToken = ("Step" | "SP") StreamToken = ("Stream" | "ST") SubtractToken = ("Subtract" | "S") SynchISDNToken = ("SynchISDN" | "SN") TagValueToken = ("TagValue" | "TV") TerminationStateToken = ("TerminationState" | "TS") TestToken = ("Test" | "TE") TopologyToken = ("Topology" | "TP") TransToken = ("Transaction" | "T") V18Token = ("V18") V34Token = ("V34") V90Token = ("V90") V91Token = ("V91") VersionToken = ("Version" | "V") Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 64] Internet draft MEGACO Protocol September 21, 1999 17. ANNEX C - BINARY ENCODING OF THE PROTOCOL 17.1. Translation mechanism This section will specify the mechanism for obtaining a binary encoding from the syntax specification given in Annex A. It will also contain a compiler to generate binary encoded protocol messages according to this mechanism. Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 65] Internet draft MEGACO Protocol September 21, 1999 18. ANNEX D - TAGS FOR MEDIA STREAM PROPERTIES As an alternative to SDP, Remote and Local Descriptors may be specified as a list of tag=value pairs. The >, <, alternative options as speci- fied in section ???? may be used. The possible tag values are: 18.1. General Media Attributes Note that these attributes are not necessarily applicable to all codecs or required for fully describe a particular codec's mode of operation. ______________________________________________________________________ |Full Tag |Short Tag| Type | Values | |_________________|_________|__________________|_______________________| |MediaType | MED | Enumeration | Audio, Video, Data, | |_________________|_________|__________________|_______________________| |TransmissionMode | TRM | Set | (Send, Receive) | |_________________|_________|__________________|_______________________| |NumberOfChannels | NCH | Unsigned Integer| 0-255 |_________________|_________|__________________|_______________________| |Sampling rate | SMR | Unsigned Integer| 0-2^32 |_________________|_________|__________________|_______________________| |Bit rate mode | BRM | Enumeration | e.g. for GSM:{"full", | | | | | "enhanced_full", | | | | | "half"} DEFAULT "full"| |_________________|_________|__________________|_______________________| |Codec | COD | Eumeration | "PCM","G711u","G711A",| | | | | "G722,"GSM","G7231, | | | | | "G729","G729A,"G729B",| | | | | "G729AB","G723C", ... | | | | | Note: The values | | | | | should match the IANA-| | | | | assigned values to | | | | | describe mapping in | | | | | SDP specifications | | | | | (rtpmap). | |_________________|_________|__________________|_______________________| |Samples per | SPP | Unsigned Integer | 0-65535 | | packet | | | | |_________________|_________|__________________|_______________________| |Silence | SIL | BOOLEAN | True/False | | suppression | | | | |_________________|_________|__________________|_______________________| |Encryption type | ENT | Enumeration | Off, .... | |_________________|_________|__________________|_______________________| |Encryption key | ENC | Unsigned Integer | 0-2^1024 | |_________________|_________|__________________|_______________________| |Echo canceller | ECN | Enumeration | Off, G.165, G168, ... | |_________________|_________|__________________|_______________________| |Gain | GAI | Unsigned Integer | 0-65535 | |_________________|_________|__________________|_______________________| |Jitterbuffer | JTB | Unsigned Integer | 0-65535 | |_________________|_________|__________________|_______________________| 18.2. Multiplex properties The multiplexer would describe how media and transport would be linked. _____________________________________ | Full Tag| Short Tag| Type| Values| |_________|___________|______|________| | H.221 | | | | |_________|___________|______|________| | H.223 | | | | |_________|___________|______|________| | V.76 | | | | |_________|___________|______|________| | H.2250 | | | | |_________|___________|______|________| | Null | | | | |_________|___________|______|________| Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 66] Internet draft MEGACO Protocol September 21, 1999 18.3. Properties for BearerDescriptor Generic properties: ________________________________________________________________________ |Full Tag | Short Tag| Type | Values | |____________________|___________|_____________|_________________________| |Media transport type| MTT | Enumeration| DS0, ATMaal5, ATMaal2, | | | | | FR, RTP ... | |____________________|___________|_____________|_________________________| 18.4. For DS0 ____________________________________________ | Full Tag| Short Tag| Type | Values | |_________|___________|__________|__________| | OPC | OPC | Integer | 0-2^14-1| |_________|___________|__________|__________| | DPC | DPC | Integer | 0-2^14-1| |_________|___________|__________|__________| | CIC | CIC | Integer | 0-2^12-1| |_________|___________|__________|__________| 18.5. For ATM VC ______________________________________________________________ | Full Tag| Short Tag | Type | Values | |_________|____________|___________|__________________________| | Address | ATMaddress| String | NSAP/AESA | |_________|____________|___________|__________________________| | VCC | VCC | 2xInteger| VCI/VPI | |_________|____________|___________|__________________________| | QoS mode| | | As defined in H.245 (or | | | | | RSVP) | |_________|____________|___________|__________________________| 18.6. Frame Relay ______________________________________________________________ | Full Tag | Short Tag| Type | Values | |________________________|___________|_________|______________| | Data link connection id| DLCI | Integer| (0-65536)???| |________________________|___________|_________|______________| | sub-Channel ID | CID | Integer| (0-255)? | |________________________|___________|_________|______________| 18.7. RTP Stream An RTP stream requires two addressing parts for this the local and remote side. Both will have the form of: Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 67] Internet draft MEGACO Protocol September 21, 1999 ____________________________________________________________________________ |Full Tag | Short Tag| Type | Values | |____________________|___________|___________|_____________________________| |IP address | IPAD | | Ipv4Address or Ipv6 address| |____________________|___________|___________|_____________________________| |RTP port | RPTP | Integer | 0-65535 | |____________________|___________|___________|_____________________________| |DiffServe Codepoint | DSCP | Integer | 0-255 Packet marking value | |____________________|___________|___________|_____________________________| 19. TRANSPORT USING UDP AND APPLICATION LAYER FRAMING MECACO/Recommendation H.248 messages may be transmitted over UDP. When no port is specified for by the other side (see section 7.2.8), the com- mands should be sent to the default MEGACO port, ????. 19.1. Providing At-Most-Once functionality Messages, being carried over UDP, may be subject to losses. In the absence of a timely response, commands are repeated. Most commands are not idempotent. The state of the MG would become unpredictable if, for example, Add commands were executed several times. The transmission procedures shall thus provide an "At-Most-Once" functionality. MECACO/Recommendation H.248 entities are expected to keep in memory a list of the responses that they sent to recent transactions and a list of the transactions that are currently outstanding. The transaction identifiers of incoming messages are compared to the transaction iden- tifiers of the recent responses. If a match is found, the entity does not execute the transaction, but simply repeats the response. The remaining messages will be compared to the list of current transactions. If a match is found, indicating a duplicate transaction, the entity does not execute the transaction, which is simply ignored. The procedure uses a long timer value, noted LONG-TIMER in the follow- ing. The timer should be set larger than the maximum duration of a transaction, which should take into account the maximum number of repetitions, the maximum value of the repetition timer and the maximum propagation delay of a packet in the network. A suggested value is 30 seconds. The copy of the responses may be destroyed either LONG-TIMER seconds after the response is issued, or when the MG (or the MGC) receives a confirmation that the response has been received, through the "Response Acknowledgement parameter". For transactions that are acknowledged through this parameter, the MG shall keep a copy of the transaction-id for LONG-TIMER seconds after the response is issued, in order to detect and ignore duplicate copies of the transaction response that could be produced by the network. Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 68] Internet draft MEGACO Protocol September 21, 1999 19.2. Transaction identifiers and three-way handshake Transaction identifiers are 32 bit integer numbers. An Media Gateway Controller may decide to use a specific number space for each of the MGs that they manage, or to use the same number space for all MGs that belong to some arbitrary group. MGCs may decide to share the load of managing a large MG between several independent processes. These processes will share the same transaction number space. There are mul- tiple possible implementations of this sharing, such as having a cen- tralized allocation of transaction identifiers, or pre-allocating non- overlapping ranges of identifiers to different processes. The implemen- tations shall guarantee that unique transaction identifiers are allo- cated to all transactions that originate from a logical MGCs. MGs can simply detect duplicate transactions by looking at the transaction iden- tifier only. The Response Acknowledgement parameter can be found in any message. It carries a set of "confirmed transaction-id ranges." Entities may choose to delete the copies of the responses to transactions whose id is included in "confirmed transaction-id ranges" received in the transac- tion response messages. They should silently discard further commands when the transaction-id falls within these ranges. The "confirmed transaction-id ranges" values shall not be used if more than LONG-TIMER seconds have elapsed since the MG issued its last response to that MGC, or when a MG resumes operation. In this situa- tion, transactions should be accepted and processed, without any test on the transaction-id. Messages that carry the "Response Acknowledgement" parameter may be transmitted in any order. The entity shall retain the union of the "confirmed transaction-id ranges" received in recent messages. 19.3. Computing retransmission timers It is the responsibility of the requesting entity to provide suitable time outs for all outstanding transactions, and to retry transactions when time outs have been exceeded. Furthermore, when repeated transac- tions fail to be acknowledged, it is the responsibility of the request- ing entity to seek redundant services and/or clear existing or pending connections. The specification purposely avoids specifying any value for the retransmission timers. These values are typically network dependent. The retransmission timers should normally estimate the timer value by measuring the time spent between the sending of a command and the return of a response. One possibility is to use the algorithm implemented in TCP-IP, which uses two variables: Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 69] Internet draft MEGACO Protocol September 21, 1999 the average acknowledgement delay, AAD, estimated through an exponen- tially smoothed average of the observed delays, * the average deviation, ADEV, estimated through an exponentially smoothed average of the absolute value of the difference between the observed delay and the current average. The retransmission timer, in TCP, is set to the sum of the average delay plus N times the average deviation. In MEGACO/Recommendation H.248, the maximum value of the timer should however be bounded, in order to guarantee that no repeated packet would be received by the gateways after LONG-TIMER seconds. A suggested maximum value is 4 seconds. After any retransmission, the entity should do the following: * It should double the estimated value of the average delay, AAD * It should compute a random value, uniformly distributed between 0.5 AAD and AAD * It should set the retransmission timer to the sum of that random value and N times the average deviation. This procedure has two effects. Because it includes an exponentially increasing component, it will automatically slow down the stream of mes- sages in case of congestion. Because it includes a random component, it will break the potential synchronization between notifications triggered by the same external event. 19.4. Provisional responses Executing some transactions may require a long time. Long execution times may interact with the timer based retransmission procedure. This may result either in an inordinate number of retransmissions, or in timer values that become too long to be effi- cient. Entities that can predict that a transaction will require a long execution time may send a provisional response, "Transaction Pending". They should send this response if they receive a repetition of a tran- saction that is still being executed. Entities that receive a Transaction Pending shall switch to a longer repetition timer for that transaction. The root termination has a pro- perty (ProvisionalResponseTimerValue) which can be set to the requested maximum number of milliseconds between receipt of a command and transmission of the TransactionPending response. The protocol is organized as a set of transactions, each of which is composed request and a response, commonly referred to as an acknowledge- ment. The protocol messages, being carried over UDP, may be subject to losses. In the absence of a timely response, transactions are repeated. Entities are expected to keep in memory a list of the responses that Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 70] Internet draft MEGACO Protocol September 21, 1999 they sent to recent transactions, i.e. a list of all the responses they sent over the last LONG-TIMER seconds, and a list of the transactions that are currently being executed. The transaction identifiers of incoming transactions are compared to the transaction identifiers of the recent responses. If a match is found, the entity does not execute the transaction, but simply repeats the response. The remaining transactionIds will be compared to the list of current transactions. If a match is found, the entity does not execute the transaction, which is simply ignored - a response will be provided when the execution of the transaction is complete. The repetition mechanism is used to guard against three types of possi- ble errors: * transmission errors, when for example a packet is lost due to noise on a line or congestion in a queue, * component failure, when for example an interface to a entity becomes unavailable, * Entity failure, when for example an entire entity become unavail- able, The entities should be able to derive from the past history an estimate of the packet loss rate due to transmission errors. In a properly con- figured system, this loss rate should be kept very low, typically less than 1%. If a Media Gateway Controller or a Media Gateway has to repeat a message more than a few times, it is very legitimate to assume that something else than a transmission error is occurring. For example, given a loss rate of 1%, the probability that 5 consecutive transmission attempts fail is 1 in 100 billion, an event that should occur less than once every 10 days for a Media Gateway Controller that processes 1,000 transactions per second. (Indeed, the number of repetition that is con- sidered excessive should be a function of the prevailing packet loss rate.) We should note that the "suspicion threshold", which we will call "Max1", is normally lower than the "disconnection threshold", which should be set to a larger value. {Editor's note, the following is all intertwined with MGCP failover mechanism, it must be edited to deal with whatever we decide to use in MEGACO/H.248} Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 71] Internet draft MEGACO Protocol September 21, 1999 Transaction issued: N=0 | transmission: N++ | +------------ retransmission: N++ -----------+ | | | | | transmission | | | +---to new address -+<--------------------|--+ | | | N=0 | | | V V V | | | +-----------+ | | | | awaiting |--- new entity --> + +------------+ | | | response |--- timer elapsed --->| N > Max1 ? |-(no)+ | +-----------+ <----------+ +------------+ ^ | | | | | | | | +- wrong key? -+ (yes) | | | | | | response received (if N=Max1, | | | or N=Max2 | | | check DNS) | | v | | | (end) +---------------+ | | |more addresses?|(yes)|--+ +---------------+ | | | (no) | | | +------------+ | | N > Max2 ? |(no)-+ +------------+ | (yes) | v (disconnected) A classic retransmission algorithm would simply count the number of suc- cessive repetitions, and conclude that the association is broken after re-transmitting the packet an excessive number of times (typically between 7 and 11 times.) In order to account for the possibility of an undetected or in-progress "failover", we modify the classic algorithm so that if the Media Gateway receives a valid ServiceChange message announcing a failover, it will start transmitting outstanding commands to that new MGC. Responses to commands are still transmitted to the source address of the command. In order to automatically adapt to network load, MEGACO/Recommendation Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 72] Internet draft MEGACO Protocol September 21, 1999 H.248 specifies exponentially increasing timers. If the initial timer is set to 200 milliseconds, the loss of a fifth retransmission will be detected after about 6 seconds. This is probably an acceptable waiting delay to detect a failover. The repetitions should continue after that delay not only in order to perhaps overcome a transient connectivity problem, but also in order to allow some more time for the execution of a failover - waiting a total delay of 30 seconds is probably acceptable. It is however important that the maximum delay of retransmissions be bounded. Prior to any retransmission, it is checked that the time elapsed since the sending of the initial datagram is no greater than T- MAX. If more than T-MAX time has elapsed, the MG concludes that the MGC has failed, and it begins its recovery process. The value T-MAX is related to the LONG-TIMER value: the LONG-TIMER value is obtained by adding to T-MAX the maximum propagation delay in the network. 19.5. Ordering of commands The MEGACO/Recommendation H.248 does not mandate that the underlying transport protocol guarantees the sequencing of transactions sent to an entity. This property tends to maximize the timeliness of actions, but it has a few drawbacks. For example: * Notify commands may be delayed and arrive at the MGC after the transmission of a new command changing the EventsDescriptor * If a new command is transmitted before a previous one is ack- nowledged, there is no guarantee that prior command will be exe- cuted before the new one. Media Gateway Controllers that want to guarantee consistent operation of the Media Gateway may use the following rules: 1. When a Media Gateway handles several Terminations, commands per- taining to the different Terminations may be sent in parallel, for example following a model where each Termination (or group of Ter- minations) is controlled by its own process or its own thread. 2. In a given Context, there should normally be only one outstanding command (Add or Modify or Move). However, a Subtract command may be issued at any time. In consequence, a Media Gateway may some- times receive a Modify command that applies to a previously sub- tracted Termination. Such commands should be ignored, and an error code should be returned. 3. On a given Termination, there should normally be only one outstand- ing Notify command at any time. The RequestId parameter should be used to correlate Notify commands with the triggering notification Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 73] Internet draft MEGACO Protocol September 21, 1999 request. 4. In some cases, an implicitly or explicitly wildcarded Subtract com- mand that applies to a group of Terminations may step in front of a pending Add command. The Media Gateway Controller should individu- ally delete all connections whose completion was pending at the time of the global Subtract command. Also, new Add commands for Terminations named by the wild- carding may not be sent until the wild-carded Subtract command is acknowledged. 5. AuditValue and AuditCapability is not subject to any sequencing. 6. ServiceChange shall always be the first command sent by a MG as defined by the restart procedure. Any other command or response must be delivered after this ServiceChange command. These rules do not affect the Media Gateway, which should always respond to commands. 19.6. Fighting the restart avalanche Let's suppose that a large number of Media Gateways are powered on simultaneously. If they were to all initiate a ServiceChange transac- tion, the Media Gateway Controller would very likely be swamped, leading to message losses and network congestion during the critical period of service restoration. In order to prevent such avalanches, the following behavior is suggested: 1. When a Media Gateway is powered on, it should initiate a restart timer to a random value, uniformly distributed between 0 and a max- imum waiting delay (MWD). Care should be taken to avoid synchroni- city of the random number generation between multiple Media Gate- ways that would use the same algorithm. 2. The Media Gateway should then wait for either the end of this timer or the detection of a local user activity, such as for example an off-hook transition on a residential Media Gateway. 3. When the timer elapses, or when an activity is detected, the Media Gateway should initiate the restart procedure. The restart procedure simply requires the MG to guarantee that the first message that the Media Gateway Controller sees from this MG is a Servi- ceChange message informing the Media Gateway Controller about the res- tart The value of MWD is a configuration parameter that depends on the type of the Media Gateway. The following reasoning may be used to determine Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 74] Internet draft MEGACO Protocol September 21, 1999 the value of this delay on residential gateways. Media Gateway Controllers are typically dimensioned to handle the peak hour traffic load, during which, in average, 10% of the lines will be busy, placing calls whose average duration is typically 3 minutes. The processing of a call typically involves 5 to 6 Media Gateway Controller transactions between each Media Gateway and the Media Gateway Con- troller. This simple calculation shows that the Media Gateway Con- troller is expected to handle 5 to 6 transactions for each Termination, every 30 minutes on average, or, to put it otherwise, about one transac- tion per Termination every 5 to 6 minutes on average. This suggests that a reasonable value of MWD for a residential gateway would be 10 to 12 minutes. In the absence of explicit configuration, residential gate- ways should adopt a value of 600 seconds for MWD. The same reasoning suggests that the value of MWD should be much shorter for trunking gateways or for business gateways, because they handle a large number of Terminations, and also because the usage rate of these Terminations is much higher than 10% during the peak busy hour, a typi- cal value being 60%. These Terminations, during the peak hour, are this expected to contribute about one transaction per minute to the Media Gateway Controller load. A reasonable algorithm is to make the value of MWD per "trunk" Termination six times shorter than the MWD per residen- tial gateway, and also inversely proportional to the number of Termina- tions that are being restarted. for example MWD should be set to 2.5 seconds for a gateway that handles a T1 line, or to 60 milliseconds for a gateway that handles a T3 line. 20. TRANSPORT USING TCP MECACO/Recommendation H.248 messages may be transmitted over TCP. When no port is specified by the other side (see section 7.2.8), the commands should be sent to the default MEGACO port, ????. MECACO/Recommendation H.248 messages are the unit of transfer, while TCP is a stream oriented protocol. TPKT, according to RFC1006 SHALL be used with MECACO/Recommendation H.248. In a transaction-oriented protocol like MEGACO/H.248, there are still ways for transaction requests or responses to be lost. As such, it is recommended that entities using TCP transport implement application level timers for each request and each response, similar to those speci- fied for application level framing over UDP. 20.1. Providing the At-Most-Once functionality Messages, being carried over TCP, are not subject to transport losses, but loss of a transaction request or its reply may none-the-less be Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 75] Internet draft MEGACO Protocol September 21, 1999 noted in real implementations. In the absence of a timely response, com- mands are repeated. Most commands are not idempotent. The state of the MG would become unpredictable if, for example, Add commands were exe- cuted several times. To guard against such losses, it is recommended that entities follow the procedures in Section E.1 20.2. Transaction identifiers and three way handshake For the same reasons, it is possible that transaction replies may be lost even with a reliable delivery protocol such as TCP. It is recom- mended that entities follow the procedures in Section E.2 20.3. Computing retransmission timers With reliable delivery, the incidence of loss of a transaction request or reply is expected to be very low. Therefore, only simple timer mechanisms are required. Exponential back-off algorithms should not be necessary, although they could be employed where, as in an MGC, the code to do so is already required, since MGCs must implement ALF/UDP as well as TCP. 20.4. Provisional responses As with UDP, executing some transactions may require a long time. Enti- ties that can predict that a transaction will require a long execution time may send a provisional response, "Transaction Pending". They should send this response if they receive a repetition of a transaction that is still being executed. Entities that receive a Transaction Pending shall switch to a longer repetition timer for that transaction. Entities shall retain Transactions and replies until they are confirmed. The basic procedure of section E.4 should be followed, but simple timer values should be sufficient. 20.5. Ordering of commands TCP provided ordered delivery of transactions. No special procedures are required. It should be noted that ALF/UDP allows sending entity to modify its behavior under congestion, and in particular, could reorder transactions when congestion is encountered. TCP could not achieve the same results. Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 76] Internet draft MEGACO Protocol September 21, 1999 20.6. Fighting the restart avalanche The procedures of section E.6 shall be followed when using TCP as the transport mechanism. 21. ANNEX G EXAMPLE CALL FLOWS {Editor's Notes: - Review these use cases for consistency with the changes to the main text * SDP in the Local and Remote descriptors needs to be verified * Package names, and property, event and signal names within packages are of course just examples - when a Megaco packages I-D comes out with proposed packages, these would be used } The examples in this section use SDP for encoding of the Local and Remote stream descriptors. SDP is defined in RFC 2327. Audio profiles used are those defined in RFC 1890, and others registered with IANA. For example, G.711 A-law is called PCMA in the SDP, and is assigned profile 0. G.723 is profile 4, and H263 is profile 34. See also http://www.isi.edu/in-notes/iana/assignments/rtp-parameters 21.1. Residential Gateway to Residential Gateway Call This example scenario illustrates the use of the elements of the proto- col to set up a Residential Gateway to Residential Gateway call over an IP-based network. For simplicity, this example will assume that both Residential Gateways involved in the call are controlled by the same Media Gateway Controller. 21.1.1. Programming Residential GW Analog Line Terminations for Idle Behavior The following illustrates the API invocations from the Media Gateway Controller and Media Gateways to get the Terminations in this scenario programmed for idle behavior. Both the originating and terminating Media Gateways have idle Analog Line Terminations programmed to look for call initiation events (i.e.-offhook) by using the Modify Command with the appropriate parameters. The null Context is used to indicate that the Terminations are not yet involved in a Context. 1. An MG registers with an MGC using the ServiceChange command: MEGACO/1.0 [124.124.124.222]:55555 Transaction = 9998 { Context = - { ServiceChange = ROOT {Services { Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 77] Internet draft MEGACO Protocol September 21, 1999 Method=Restart, Version=1.0, Port=55555, Profile=ResGW} } } } 2. The MGC sends a reply: MEGACO/1.0 [124.124.124.121]:55566 Reply = 9998 { Context = - {ServiceChange = ROOT } } 3. The MGC programs a Termination in the NULL context. The termina- tionId is A4444, the streamId is 1111, the requestId in the Events descriptor is 2222. The Megaco mId is the identifier of the sender of this message, in this case, it is the IP address and port [124.124.124.121]:55566. Process is the default, so it is not necessary to have it in BufferedEventHandling. MEGACO/1.0 [124.124.124.121]:55566 Transaction = 9999 { Context = - { Modify = A4444 { Media { TerminationState { BufferedEventHandling{Step,Process} }, Stream = 1111 { LocalControl { Mode = SendReceive, Package1/GainControl=2, ; in dB, Package1/Encryption=xxx, Package1/EchoCancellation=G165, Package1/VoiceActDet=yes }, Local = SDP {c=LOCAL m=audio 0 LOCAL 0 a=sendrecv a=ptime:10 } ; SDP profile 0 is G.711mu-law sampled at 8kHz } }, Events = 2222 {Package1/offhook} } } Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 78] Internet draft MEGACO Protocol September 21, 1999 } The dialplan script could have been loaded into the MG previously. Its function would be to wait for the OffHook, turn on dialtone and start collecting DTMF digits. However in this example, we use the digit map, which is put into place after the offhook is detected (step 5 below). Note that the embedded EventsDescriptor could have been used to combine steps 1 & 2 with steps 6 & 7, eliminating steps 4 & 5. 4. The MG1 accepts the Modify with this reply: MEGACO/1.0 [124.124.124.222]:55555 Reply = 9999 { Context = - {Modify} } 5. A similar exchange happens between MG2 and the MGC, resulting in an idle Termination called A5555. 21.1.2. Collecting Originator Digits and Initiating Termination The following builds upon the previously shown conditions. It illus- trates the API invocations from the Media Gateway Controller and ori- ginating Media Gateway (MG1) to get the originating Termination (TID1) through the stages of digit collection required to initiate a connection to the terminating Media Gateway (MG2). The following builds upon the previously shown conditions. It illus- trates the API invocations from the Media Gateway Controller and ori- ginating Media Gateway (MG1) to get the originating Termination (TID1) through the stages of digit collection required to initiate a connection to the terminating Media Gateway (MG2). 6. MG1 detects an offhook event from User 1 and reports it to the Media Gateway Controller via the Notify Command. MEGACO/1.0 [124.124.124.222]:55555 Transaction = 10000 { Context = - { Notify = A4444 {ObservedEvents =2222 { 19990729T22000000:Package1/offhook}} } } IP 7. And the Notify is acknowledged Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 79] Internet draft MEGACO Protocol September 21, 1999 MEGACO/1.0 [124.124.124.121]:55566 Reply = 10000 { Context = - {Notify} } 8. The MGC Modifies the termination to look for digits now. MEGACO/1.0 [124.124.124.121]:55566 Transaction = 10001 { Context = - { Modify = A4444 { Events = 2223 { Package1/onhook { Action { DigitMap=Dialplan0 } } }, DigitMap= Dialplan0{ (0T|00T|[17]xxx|8xxxxxxx|#xxxxxxx|*xx|91xxxxxxxxxx|9011x.T)} } } } 9. And the Modify is acknowledged MEGACO/1.0 [124.124.124.222]:55555 Reply = 10001 { Context = - {Modify} } 10. Next, digits are accumulated by MG1 as they are dialed by User 1. When an appropriate match is made of collected digits against the currently programmed Dialplan for A4444, another Notify is sent to the Media Gateway Controller. MEGACO/1.0 [124.124.124.222]:55555 Transaction = 10002 { Context = - { Notify = A4444 {ObservedEvents =2223 { 19990729T22010001:Package1/digits{digits=16135551212}}} } } 11. And the Notify is acknowledged Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 80] Internet draft MEGACO Protocol September 21, 1999 MEGACO/1.0 [124.124.124.121]:55566 Reply = 10002 { Context = - {Notify} } 12. The controller then analyzes the digits and determines that a con- nection needs to be made from MG1 to MG2. Both the TDM termination A4444, and an RTP termination are added to a new context in MG1. Mode is ReceiveOnly since Remote descriptor values are not yet specified. Preferred codecs are in the MGC's preferred order of choice. MEGACO/1.0 [124.124.124.121]:55566 Transaction = 10003 { Context = $ { Add = A4444, Add = $ { Media { Stream = 1111 { LocalControl { Mode = ReceiveOnly, Package1/MaxJitterBuffer=40, ; in ms Package1/PreferredPacketization=20, ; in ms Package1/PreferredCodecs=[G723, PCMU], Package1/Gain=0 ; in dB }, Local = SDP {c=IN IP4 ANY m=audio ANY RTP/AVP ANY a=sendrecv }, Remote = SDP {c=IN IP4 ANY m=audio ANY RTP/AVP ANY a=sendrecv } } }, Events = 2224 {Package1/onhook} } } } NOTE: The MGC states its preferred parameter values in the LocalControl. Local and Remote could be left empty in the Request from MGC to MG. In any case, the MG fills in the Local in the Reply. 13. MG1 acknowledges the new Termination and fills in the Local IP Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 81] Internet draft MEGACO Protocol September 21, 1999 address and UDP port. It also makes a choice for the codec based on the MGC preferences in LocalControl. MEGACO/1.0 [124.124.124.222]:55555 Reply = 10003 { Context = 2000 { Add, Add= A4445{ Media { Stream = 1111 { Local = SDP {v=0 c=IN IP4 45.123.1.1 m=audio 5555 RTP/AVP 0 4 a=ptime:20 } ; RTP profile for G.723 is 4 } } } } } 14. The MGC will now associate A5555 with a new Context on MG2, and establish an RTP Stream (i.e, A5556 will be assigned) receiveOnly connection through to the originating user, User 1. The signal Package1/Ring put on A5555 sends ring back to MG1. The signal Package1/RingTone on the new termination (A5556) makes MG2's phone ring. MEGACO/1.0 [124.124.124.121]:55566 Transaction = 50003 { Context = $ { Add = A5555 { Signals { Package1/Ring {variant=NorthAmerica}} }, Add = $ { Media { Stream = 1212 { LocalControl { Mode = SendReceive, Package1/MaxJitterBuffer=40, ; in ms Package1/PreferredPacketization=20, ; in ms Package1/PreferredCodecs=G723, Package1/Gain=0 ; in dB }, Local=SDP{c=IN IP4 ANY m=audio ANY RTP/AVP ANY a=sendrecv Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 82] Internet draft MEGACO Protocol September 21, 1999 }, Remote=SDP{c=IN IP4 45.123.1.1 m=audio 5555 RTP/AVP 0 4 a=sendrecv } ; RTP profile for G.723 is 4 } }, Signals { Package1/RingTone {variant=NorthAmerica}} } } } 15. This is acknowledged. MEGACO/1.0 [124.124.124.222]:55555 Reply = 50003 { Context = 5000 { Add, Add = A5556{ Media { Stream = 1212 { Local = SDP {c=IN IP4 111.1.1.1 m=audio 1111 RTP/AVP 0 4} } ; RTP profile for G723 is 4 } } } } 16. The above IPAddr and UDPport need to be given to MG1 now. From MGC to MG1: MEGACO/1.0 [124.124.124.121]:55566 Transaction = 10004 { Context = 2000 { Modify = A4445 { Media { Stream = 1111 { Remote = SDP {c=IN IP4 111.1.1.1 m=audio 1111 RTP/AVP 0 4} } } } } } From MG1 to MGC: Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 83] Internet draft MEGACO Protocol September 21, 1999 MEGACO/1.0 [124.124.124.222]:55555 Reply = 10004 { Context = 2000 {Modify} } 17. The two gateways are now connected and User 1 hears the RingBack. The MG2 now waits until User2 picks up the receiver and then the two-way call is established. From MG2 to MGC: MEGACO/1.0 [124.124.124.222]:55555 Transaction = 50004 { Context = 5000 { Notify = A5555 {ObservedEvents =1234 { 19990729T22020002:Package1/offhook}} } } From MGC to MG2: MEGACO/1.0 [124.124.124.121]:55566 Reply = 50004 { Context = - {Notify} } From MGC to MG2: MEGACO/1.0 [124.124.124.121]:55566 Transaction = 50005 { Context = 5000 { Modify = A5555 { Events = 1235 {Package1/onhook}, Signals {Package1/Clear} }, Modify = A5556 { Signals {Package1/Clear} } } } From MG2 to MGC: MEGACO/1.0 [124.124.124.222]:55555 Reply = 50005 { Context = 5000 {Modify, Modify} } Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 84] Internet draft MEGACO Protocol September 21, 1999 18. Change mode on MG1 to SendReceive MEGACO/1.0 [124.124.124.121]:55566 Transaction = 10005 { Context = 2000 { Modify = A4445 { Media { Stream = 1111 { LocalControl { Mode=SendReceive } } } } } } MEGACO/1.0 [124.124.124.222]:55555 Reply = 10005 { Context = 2000 {Modify= A4445 } } 19 The MGC decides to Audit the RTP termination on MG2. MEGACO/1.0 [124.124.124.121]:55566 Transaction = 50006 { Context = - {AuditValue = A5556{ Audit{Media, DigitMap, Events, Signals }} } } 20. The MGC replies. MEGACO/1.0 [124.124.124.222]:55555 Reply = 50006 { Context = - { AuditValue { Media { TerminationState { BufferedEventHandling{Process} }, Stream = 1212 { LocalControl { Mode = SendReceive, Package1/MaxJitterBuffer=40, ; in ms Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 85] Internet draft MEGACO Protocol September 21, 1999 Package1/PreferredPacketization=20, ; in ms Package1/PreferredCodecs=G723, Package1/Gain=0 ; in dB }, Local = SDP {c=IN IP4 111.1.1.1 m=audio 1111 RTP/AVP 0 4 }, Remote=SDP{c=IN IP4 45.123.1.1 m=audio 5555 RTP/AVP 0 4 a=sendrecv } ; RTP profile for G.723 is 4 } }, Signals {Package1/Clear}, Packages {Package1, RTPPkg}, Statistics { RTPPkg/PacketsSent=1200, RTPPkg/OctetsSent=62300, RTPPkg/PacketsReceived=700, RTPPkg/OctetsReceived=45100, RTPPkg/PacketsLost=6, RTPPkg/Jitter=20, RTPPkg/AverageLatency=40 } } } } 21. When the MGC receives an onhook signal from one of the MGs, it brings down the call. In this example, the user at MG2 hangs up first. From MG2 to MGC: MEGACO/1.0 [124.124.124.222]:55555 Transaction = 50007 { Context = 5000 { Notify = A5555 {ObservedEvents =1235 { 19990729T24020002:Package1/onhook} } } } From MGC to MG2: MEGACO/1.0 [124.124.124.121]:55566 Reply = 50007 { Context = - {Notify} Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 86] Internet draft MEGACO Protocol September 21, 1999 } 22. The MGC now sends both MGs a Subtract to take down the call. Only the subtracts to MG2 are shown here. From MGC to MG2: MEGACO/1.0 [124.124.124.121]:55566 Transaction = 50008 { Context = 5000 { Subtract = A5555 , Subtract = A5556 } } From MG2 to MGC: MEGACO/1.0 [124.124.124.222]:55555 Reply = 50008 { Context = 5000 { Subtract { Statistics { ; what are the stats for a TDM connection? TDMPkg/OctetsSent=45123 } }, Subtract { Statistics { RTPPkg/PacketsSent=1245, RTPPkg/OctetsSent=62345, RTPPkg/PacketsReceived=780, RTPPkg/OctetsReceived=45123, RTPPkg/PacketsLost=10, RTPPkg/Jitter=27, RTPPkg/AverageLatency=48 } } } } 23. The MGC now sets up both MG1 and MG2 to be ready to detect the next off-hook event. See step 1. Note that this could be the default state of a termination in the null context, and if this were the case, no message need be sent from the MGC to the MG. Once a termi- nation returns to the null context, it goes back to the default termination values for that termination. Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 87] Internet draft MEGACO Protocol September 21, 1999 21.2. Multimedia Gateway Examples Multimedia sessions using this protocol will use multimedia Terminations and Contexts for example for H.320 ISDN connections and for IP based multimedia connections. The MGC determines the need for multimedia Con- texts from the SCN or IP Side call signaling. Once multimedia is detected the MGC will create the Context and appropriate Terminations. In general, a Termination will associate all media of an individual user and handles network jitter Streams sourced/sinked by a Termination are identified by a StreamId to instruct the MG how to connect them. Media from terminations with identical streamIDs are connected. The MGC can instruct the MG to synchronize streams by setting Context properties. One of the properties of a Context is the mixing properties. In the fig- ure below these are represented by the black dots in the context. The concept of connecting streams makes for a straight forward implemen- tation of functionality such as speech-to-text transmediation. If an MG supports this type of operation, a MGC can assign identical StreamIDs to a speech stream and a text stream to indicate that incoming speech should be transformed into text. 21.2.1. H.320 Gateway The Context for a point-to-point multimedia call in an H.320-H.323 gate- way contains two muxing Terminations. It contains a muxing Termination that sources and sinks the H.221 frames on DS0s. This Termination references a number of DS0s, six in the example for a call with a total bandwidth of 384 kbit/s. Each of these DS0s are also terminations in their own right. The mux/demux descriptor of the muxing Termination describes how the audio, video and data streams are transported over the six 64 kbit/s bearer channels. The second muxing Termination sources and sinks the media flows on the packet network Side. Assuming that there are audio, video and data streams, the Termination contains a muxDescriptor with a list of three bearer descriptors. No multiplexing is involved in this muxing Termina- tion: every media flow maps to one stream on the network. Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 88] Internet draft MEGACO Protocol September 21, 1999 +----------------------------------------------+ | Context C1 | | +-------+ +-------+ | | | H.323 | | H.320 | | | +-----+ | | +-----+ | ---| RTP | |------O-------| | DS0 |--- | |Audio| | | | | | | +-----+ | | +-----+ | | | | | | | | +-----+ | | +-----+ | ---| RTP | |------O-------| | DS0 |--- | |Video| | | | | | | +-----+ | | +-----+ | | | | | | | | +-----+ | | +-----+ | ---| RTP | |------O-------| | DS0 |--- | |Data | | | | | | | +-----+ | | +-----+ | | | | | | | | +-------+ +-------+ | | | +----------------------------------------------+ Figure 6 H.320 Gateway Context The following is a call flow for a point-to-point H.320 to H.323 call initiated from the WAN Side. The call flow shows that either the H.323 or H.320 Side can initiate opening (or closing) an audio or video chan- nel through the gateway. In H.320, there is the requirement that such mode changes take at most 20 milliseconds. In the call flow we see that messages are exchanged between MG and MGC to inform the MGC of a request for a mode change from the H.320 Side. The MGC will then send an OLC to the H.323 terminal. 1. MGC gets an incoming call with (Q.931) call type of data and sends an Add command to MG, to create a Context with one muxing termina- tion and one DS0 termination, indicating in the parameters for the muxing termination that Bonding will be used and that the multiplex type is H.221. MEGACO/1.0 [124.124.124.121]:55566 Transaction = 9999 { Context = $ { Add = $ { Mux = H221 {DS0_A}, Media { Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 89] Internet draft MEGACO Protocol September 21, 1999 Stream = 1111 { LocalControl { Mode = SendReceive, PackageMux/Mux = yes } } }, Events = 2222 { Bonding/CallID {Action {NotifyAction}}, Bonding/TransferRate {Action {NotifyAction}} } } } } The MuxDescr contains the mux type, and an ordered list of termina- tionIds used in the call (here there is only one). If the termina- tionIds are not yet added to the context, the MG takes care of adding them. In the LocalControl, a muxing package parameter marks the stream as being part of a muxing termination (necessary?). At this stage in the session there is only an audio channel, using 56 kbit/s G.711 coder (corresponding to H.221 mode 0F). A script is used to monitor the line for Bonding and H.221 in-band H.221 framing. [Editor's Note: the ABNF does not have a script descriptor - this would need to be added if a script is needed for this case] 2. The MG acknowledges the Context creation, informing the MGC of the ContextID 2000 and TerminationID A4444 (for the muxing termination) it assigned. MEGACO/1.0 [124.124.124.222]:55555 Reply = 9999 { Context = 2000 {Add= A4444} } 3. When the termination finds Bonding, it assigns a Bonding call ID x and accepts the proposed call transfer rate requested by the cal- ling H.320 endpoint. The MG then sends a Notify message to the MGC informing it of the Bonding call identifier 'x' and the transfer rate: MEGACO/1.0 [124.124.124.222]:55555 Transaction = 10000 { Context = 2000 { Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 90] Internet draft MEGACO Protocol September 21, 1999 Notify = A4444 {ObservedEvents =2222 { 19990729T22040400:Bonding/CallID{CallID=x}, Bonding/TransferRate {TransferRate=384} } } } } The Notify is acknowledged: MEGACO/1.0 [124.124.124.121:]55566 Reply = 10000 { Context = 2000 {Notify} } 4. The MGC allocates additional phone numbers for the call and requests the MG to send these back to the calling side by changing the signals descriptor: MEGACO/1.0 [124.124.124.121:]55566 Transaction = 10001 { Context = 2000 { Modify = A4444 { Signals { Bonding/AddPhoneNrs{Phone=N1,Phone=N2,Phone=N3, Phone=N4,Phone=N5} } } } } 5. The MG replies to the MGC's message and sends the additional phone numbers back to the calling Side via Bonding. 6. When the SGW notifies the MGC of incoming calls for the phone numbers associated with Bonding call x, the MGC sends Modify com- mands to the MG to add the appropriate DS0 bearer channels to the Termination created previously; the MG acknowledges these commands. For instance, for the first two additional DS0s added: MEGACO/1.0 [124.124.124.121:]55566 Transaction = 10002 { Context = 2000 { Modify = A4444 { Mux = H221 {DS0_1,DS0_2,DS0_3,DS0_4,DS0_5} } Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 91] Internet draft MEGACO Protocol September 21, 1999 } } A reply to this Modify is sent by the MG. 7. With the final Modify in which bearer channels (DS0s) are added to the muxing termination, the MGC request the MG to notify it when H.221 frames are detected. MEGACO/1.0 [124.124.124.121:]55566 Transaction = 10003 { Context = 2000 { Modify = A4444 { Events = 2223 {Bonding/H221Frames} } } } A reply to this Modify is sent by the MG. 8. Once H.221 framing is found, a Notify is sent to the MGC. MEGACO/1.0 [124.124.124.222]:55555 Transaction = 10004 { Context = 2000 { Notify = A4444 {ObservedEvents =2223 { 19990729T22050005:Bonding/H221Frames{H221Frame=x}}} } } The Notify is acknowledged: MEGACO/1.0 [124.124.124.121:]55566 Reply = 10004 { Context = 2000 {Notify} } 9. The MGC instructs the Termination to listen for DTMF tones in the audio stream, and possibly to play an announcement to the calling user. 10. The audio announcement will be played and then the Termination will listen for DTMF tones in the audio portion of the mux and it com- mences a TCS4/IIS signaling exchange in the BAS channel. The Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 92] Internet draft MEGACO Protocol September 21, 1999 information received is considered the destination alias z for this call. 11. The MG Notifies the MGC of at least three pieces of information: 1) frame alignment found, 2) H.320 capabilities, and 3) destination alias z. The MGC sends ARQ to resolve IP address for alias z 12. Once the address is resolved, the MGC does H.225 call setup. . . gets caps from H.323 etc. Note that we assume that the MGC sets up the H.245 connection with the called party. 13. The MGC sends a Modify to the H.320 termination causing a new capa- bility set to be sent from the MG to the H.320 terminal, based on the received capabilities the MGC got from the H.323 endpoint. 14. MGC may get an OLC from H.323 Side for audio, the MGC will then Add a packet Termination to the Context. In this example, the MGC sets the transmitting IP address and UDP port. MEGACO/1.0 [124.124.124.121:]55566 Transaction = 10013 { Context = 2000 { Add = $ { Mux = H225-0 {A4444}, ;not sure what terminationId belongs in the mux Media { Stream = 1212 { LocalControl { MaxJitterBuffer=40, Mode = SendReceive}, Local = SDP {c=IN IP4 ANY m=audio ANY RTP/AVP 0 99 a=rtpmap:99 G729 }, Remote = SDP {c=IN IP4 45.123.1.1 m=audio 5555 RTP/AVP 0 4} } ; RTP profile for G.723 is 4 } } } } The Modify is accepted with the following reply: MEGACO/1.0 [124.124.124.222]:55555 Reply = 10013 { Context = 2000 { Add= A4445 { Media { Stream = 1212 { Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 93] Internet draft MEGACO Protocol September 21, 1999 Local = SDP {c=IN IP4 111.1.1.1 m=audio 6666 RTP/AVP 0 99 a=rtpmap:98 G729} } } } } } The MGC assigns a StreamID to the media stream to allow the MG to identify the streams that have to be connected within the Context. The MG acknowledges the command and reports the assigned Termina- tionId to the MGC, as well as the IP address and UDP port it selected for the Local Descriptor. 15. The MGC sends a Modify to the H.320 termination sending a Stream- Descriptor to the MG: MEGACO/1.0 [124.124.124.121:]55566 Transaction = 10013 { Context = 2000 { Modify= A4445 { Media { Stream = 1212 { LocalControl {Mode = SendReceive}, Remote = SDP {m=audio a=sendrecv} } } } } } The MG acknowledges the Modify command. At this point the MG knows that the audio streams from the packet and circuit sides have to be connected because they have the same StreamID. 16. The H.320 side may do a mode switch to H.263 video for example. The H.320 termination will then send an event to the MGC requesting H.263 video: MEGACO/1.0 [124.124.124.222]:55555 Transaction = 10004 { Context = 2000 { Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 94] Internet draft MEGACO Protocol September 21, 1999 Notify = A4444 { ObservedEvents =2224 { 19990729T22050100:H242Pkg/ModeChange{Mode=AddH263} } } } } The MGC sends a reply to this Notify. 17. The MGC must send an OLC to the H.323 side. 18. The MGC modifies the packet termination, by adding another RTP flow and changing the stream descriptor to include the video. In the same Transaction, the H.320 termination is modified to include the video: MEGACO/1.0 [124.124.124.121:]55566 Transaction = 10013 { Context = 2000 { Modify= A4445 { Media { Stream = 1213 { LocalControl {Mode = SendReceive}, Local = SDP {c=IN IP4 ANY m=video ANY RTP/AVP 34}, ;RTP profile for H.263 is 34 Remote = SDP {c=IN IP4 45.123.1.2 m=video 5556 RTP/AVP 34} } } }, Modify= A4444 { Media { Stream = 1213 { LocalControl {Mode = SendReceive}, Local = SDP {m=video a=sendrecv} } } } } } The MG already knows the parameters of the video stream on the H.320 side. The only thing that the controller has to do is to set the StreamID of the video stream. Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 95] Internet draft MEGACO Protocol September 21, 1999 The of the Modify to terminationId A4445 would return to the MGC the IP address and port of the Local descriptor. 21.2.2. Multipoint Context Example This example shows how a multimedia context can be used to bridge an H.320 user and three H.323 users into a single multipoint conference. In the picture the types of media flowing over the links between the terminations are shown for clarity. The bridging functionality is a con- text property, there is no separate bridge entity in the connection model. Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 96] Internet draft MEGACO Protocol September 21, 1999 +--------------------------------------------------------+ | Context x | | | | +---------+ +-------+ | | | | | | | | +-------| | | | | | | RTP | | | |--------+ | | | Audio | |- /-| | DS-0-1 | | | +-------| H.225.0 | / | H.221 |--------+ | | | MUX | / | MUX | | | +-------| | / | | | | | RTP | | / | |--------+ | | | Video | | ___/ /| | DS-0-2 | | | +-------| | | | / | |--------+ | | | | /___ / | | | | +-------| | / / | | | | | T.120 | | / /| | | | | Data | | / | | / | | | | +-------| | | | / | | | | +---------+ / | | | | +-------+ | | | | / | | | | +---------+ | | ___/ | | +---------+ | | | | | | | | | | | | | | +-------| | | | /___ | | | |-------+| | | RTP | |/ | / | | RTP || | | Audio | | |/ | | Audio || | +-------| H.225.0 | | | | H.225.0 |-------+| | | MUX | / / | MUX | | | +-------| | / / | |-------+| | | RTP | |/ / | RTP || | | Video | | ___/ | | Video || | +-------| | | | | |-------+| | | | /___ | | | | +-------| | / | |-------+| | | T.120 | |----/ ----| | T.120 || | | Data | | | | Data || | +-------| | | |-------+| | +---------+ +---------+ | +--------------------------------------------------------+ Figure 7 Multimedia Context Example 21.2.3. Single Media Call The single media the call flow example describes a call that originates in the SCN and is terminated in the packet network. The packet network signaling in this example is H.323 but other signaling protocols such as SIP can be used, the purpose of the example is to describe MG/MGC interactions. Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 97] Internet draft MEGACO Protocol September 21, 1999 +---------------------------------------------------+ | Context x | | | | +-------------+ +-+ +-------------+ | | | RTP Audio |--------|*|--------| DS0 Audio | | | | Termination | +-+ | Termination | | | +-------------+ +-------------+ | | | +---------------------------------------------------+ Figure 8 Single Media Call Example The assumption is made that the signalling between the signalling gate- way (SGW) and MGC is based on Q.931. This does not indicate that no other signalling can be used on this interface. 1. The SGW sends a Setup message to the MGC after receiving an IAM from a SCN switch. 2. From the IAM message, the MGC may infer which circuit on which MG is involved and where to terminate the call. How the MGC does this, is outside the scope of this document. 3. The MGC creates a Context for the call. The Context contains two terminations: one for the SCN side and one for the packet side. In this example, the MGC has selected a particular physical termina- tion; DS0/13/2. MEGACO/1.0 [124.124.124.121:]55566 Transaction = 9999 { Context = $ { Add = DS0/13/2 { Media { TerminationState { BufferedEventHandling{Step,Process}}, Stream = 1111 { LocalControl { Mode = SendReceive, Package1/GainControl=0, Package1/EchoCancellation=G165, Package1/VoiceActDet=yes }, Local = SDP {c=LOCAL m=audio 0 LOCAL 0 a=recv a=ptime:10 Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 98] Internet draft MEGACO Protocol September 21, 1999 }; SDP profile 0 is G.711mu-law sampled at 8kHz } } }, Add = $ { Mux = H225-0 {DS0/13/2}, ; is terminationId correct here for the mux? Media { Stream = 1111 { LocalControl { Mode = ReceiveOnly, Package1/MaxJitterBuffer=40, ; in ms Package1/PreferredPacketization=20, ; in ms Package1/PreferredCodecs=[G723, PCMU], Package1/Gain=0 ; in dB }, Local = SDP {c=IN IP4 ANY m=audio ANY RTP/AVP ANY a=sendrecv }, Remote = SDP {c=IN IP4 ANY m=audio ANY RTP/AVP ANY a=sendrecv } } } } } } The different media flows are identified by a StreamID. In the case that there is only one medium, this StreamID can be omitted. We see in the command syntax how the MGC uses a "$" to leave the assignment of names for both the Context itself and the Termina- tions in it, to the MG. 3. The MG accepts the Context creation with this reply: MEGACO/1.0 [124.124.124.222]:55555 Reply = 9999 { Context = 2000 { Add, Add= A4445 { Media { Stream = 1111 { Local = SDP {v=0 Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 99] Internet draft MEGACO Protocol September 21, 1999 c=IN IP4 45.123.1.1 m=audio 5555 RTP/AVP 0 4 a=ptime:20 } ; RTP profile for G.723 is 4 } } } } } This step shows how the MG reports to the MGC what parameters it filled in for the IP address and UDP port to which media should be addressed. 4. The MGC sends a Setup message to the destination endpoint, here assumed to be a H.323 endpoint (terminal, GW, ...). It indicates in the fastStart element that either G.711 or G.723 may be used for the voice stream. 5. The H.323 endpoint sends an Alerting message back to the MGC, informing it of the codec to be used (assume G.723 for both direc- tions) and the transport address. 6. The MGC sends a Modify command to the MG to set the Mode and Bearer information for the packet side Remote Descriptor: MEGACO/1.0 [124.124.124.121:]55566 Transaction = 10000 { Context = 2000 { Modify = A4445 { Media { Stream = 1111 { Remote = SDP {c=IN IP4 111.1.1.1 m=audio 1111 RTP/AVP 0 4} } } } } } 5. The MG accepts the Modify command with this reply: MEGACO/1.0 [124.124.124.222]:55555 Reply = 10000 { Context = 2000 {Modify} Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 100] Internet draft MEGACO Protocol September 21, 1999 } 6. The MGC sends an Alerting message to the SGW. 7. The called endpoint at some instance sends a Connect message to the MGC. 8. In response to the Connect, the MGC sends a Modify command to the MG to change the Activity of the Local stream descriptor on the SCN Side: MEGACO/1.0 [124.124.124.121:]55566 Transaction = 10001 { Context = 2000 { Modify = A4445 { Media { Stream = 1111 { Local = SDP {a=sendrecv} } } } } } 9. The MGC sends a Connect message to the SGW 10. The MG accepts the Modify command with this reply: MEGACO/1.0 [124.124.124.222]:55555 Reply = 10001 { Context = 2000 {Modify} } 21.2.4. H.323 and FAS Signaling in MG {Editor's note: This section needs reviewing to make sure it reflects the changes of the Santiago meeting. } The following flow describes an H.320 to H.323 gateway call where the signaling and media terminations for the SCN and packet network both reside on the MG. In this case the MG terminates an ISDN PRI interface and the packet interface is H.323 IP and also resides on the MG. The signaling capabilities are represented as physical H.323 and FAS termi- nations that exchange events with the MGC to indicate changes in call state. This gateway session uses Bonding channel aggregation making the Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 101] Internet draft MEGACO Protocol September 21, 1999 example a super-set of gateway call that uses H.221 channel aggregation. 1. The MG creates a FAS termination and an H.323 termination on power-on and reports these events to the MGC in a Notify. 2. MGs FAS termination gets an incoming call with (Q.931) call type of data, the MG sends a Notify to the MGC. 3. The MGC creates a context and Adds a FAS termination to it, con- taining H.320 and Bonding packages, to connect the B channel. 4. When the termination finds Bonding, it assigns a Bonding call ID x and then allocates additional phone numbers for the call and sends these back to the calling side via Bonding. 5. The MG sends a Notify to the MGC. 6. The MGC sends an Add to the MG to create a multimedia context and sends a Modify to move/add the DS0 termination to the new mul- timedia context . 7. The FAS termination detects signaling for 5 additional B channels, sends a Notify to MGC, and the MGC adds these B channels to the mux termination in the MG 8. The MG detect Bonding and sends a Notify to the MGC 9. The MGC sends a modify to move the termination into the multimedia context 10. The remaining B channels connect in the same manner 11. After all five additional DS0s have been added the H.320 termina- tion can complete Bonding and start looking for H.221 framing. 12. Once H.221 framing is found a Notify is sent to the MGC. 13. The H.221 Termination will play the audio announcement and listen for DTMF tones in the audio portion of the mux and it commences a TCS4/IIS signaling exchange in the BAS channel. The information received is considered the destination z alias for this call. 14. The MG Notifies the MGC of the destination alias z. 15. The MGC sends ARQ to resolve IP address for alias z 16. Once the address is resolved, the MGC Adds an H.323 signaling to the multimedia context Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 102] Internet draft MEGACO Protocol September 21, 1999 17. The H.323 termination in the context starts H.225/h.245 call setup and media negotiation sequence. 18. The MG sends a Notify to the MGC announcing the completion of call signaling. 19. In the MG capabilities received from the H.323 terminations are forward to the H.320 termination and vice versa. The GW sends a Notify to the MGC whenever an H.242 or H.245 media capability exchange occurs. 20. MG may get an OLC from H.323 Side for audio, the MG will send a Notify to the MGC 21. The MGC will Add an Audio/RTP termination to the context. 22. The MGC will send a Modify to the H.221 termination causing the H.221 mux to change and the selected audio channel (G.711, G.723 etc.) to be opened. The H.320 side may do a mode switch to H.263 video for example. The H.221 termination will then send a Notify to the MGC requesting H.263 video. The MGC will send an Add Video/RTP termination to the context and a Modify H.320/video to the context. 21.2.5. Simple text telephone call The Simple Text Telephone Call flow example describes a call that ori- ginates in a Text Telephone in the SCN and is terminated in an H.323 Annex G Text Conversation capable terminal in the packet network. The purpose of the example is to describe MG/MGC interactions. The SGW sends a Setup message to the MGC after receiving an IAM from an SCN switch. 2. From the IAM message, the MGC may infer which circuit on which MG is involved and where to terminate the call. 3. The MGC creates a Context for the call. The Context contains two terminations: one for the SCN side and one for the packet side: MEGACO/1.0 [124.124.124.121:]55566 Transaction = 50003 { Context = $ { Add = DS0/12/2 { Media { Stream = 1212 { LocalControl { Mode = ReceiveOnly, Package1/VoiceActivityDet=No, Package1/PreferredCodecs=T140}, Local= SDP {c=LOCAL m=text 0 LOCAL 0 Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 103] Internet draft MEGACO Protocol September 21, 1999 } } }, Modem=V18, Signals {Package_texttel/signal1 {name1=value1}} }, Add = $ { Media { Stream = 1212 { LocalControl { Mode = ReceiveOnly, Package1/PreferredCodecs=T140 }, Local= SDP {c=IN IP4 ANY m=text ANY RTP/AVP 0 95 a=rtpmap:95 T140 }, Remote= SDP {c=IN IP4 ANY m=text ANY RTP/AVP 0 95 a=rtpmap:95 T140 } } } } } } This is acknowledged: the MG creates the context and returns info. MEGACO/1.0 [124.124.124.222]:55555 Reply = 50003 { Context = 5000 {Add, Add = A5556 { Media { Stream = 1212 { Local = SDP {c=IN IP4 111.1.1.1 m=text 1111 RTP/AVP 0 95 a=rtpmap:95 T140} } } } } } 2. The MGC sends a Setup message to the destination endpoint, here assumed to be a H.323 endpoint (terminal, GW, ...). It indicates in the fastStart element that a reliable data channel shall be used and T.140 shall be used as the applicationCapability of the Data Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 104] Internet draft MEGACO Protocol September 21, 1999 stream. 3. The H.323 endpoint sends an Alerting message back to the MGC, informing it of the data stream to be used and the transport address. 4. The MGC sends a Modify command to the MG to set the mode and remote termination description on the packet side: MEGACO/1.0 [124.124.124.121:]55566 Transaction = 50004 { Context = 2000 { Modify = A5556 { Media { Stream = 1212 { LocalControl { Mode = SendReceive }, Remote = SDP {c=IN IP4 222.2.2.2 m=text 2222 RTP/AVP 0 95 a=rtpmap:95 T140 } } } } } } The MG accepts the Modify commands with this reply: MEGACO/1.0 [124.124.124.222]:55555 Reply = 50004 { Context = 2000 {Modify} } 5. The MGC sends an Alerting message to the SGW. 6. The called endpoint at some instance sends a Connect message to the MGC. 7. In response to the Connect, the MGC sends a Modify command to the MG to change the mode of the SCN side termination to SendRecv: MEGACO/1.0 [124.124.124.121:]55566 Transaction = 50005 { Context = 2000 { Modify = DS0/12/2 { Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 105] Internet draft MEGACO Protocol September 21, 1999 Media { Stream = 1212 { LocalControl { Mode = SendReceive } } } } } } 8. The MGC sends a Connect message to the SGW 9. The MG accepts the Modify command with this reply: MEGACO/1.0 [124.124.124.222]:55555 Reply = 50005 { Context = 2000 {Modify} } 21.2.5.1. Basic operation 21.2.5.2. Voice channels in the simple text only case 21.2.5.3. Operation with the alternating text and voice case Cuervo, Hill, Greene, Huitema, Ryahan, Rosen, Segers [Page 106]