Internet Engineering Task Force Fernando Cuervo INTERNET DRAFT Nortel Networks April 16, 1999 Christian Huitema Expires October 16, 1999 Telcordia Technologies Keith Kelly NetSpeak Brian Rosen FORE Systems Paul Sijben Lucent Technologies Eric Zimmerer Level 3 Communications 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 inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). IMPORTANT NOTE This version of the draft has been rushed so that members of the WG not part of the small design team that created this document could have early input to the design process. The last few sections of the document have not been reviewed by the team, and are largely lifted from other documents, especially the MGCP document. The design team did not reach Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 1] Internet draft MEGACO Protocol April 16, 1999 consensus on several major issues, including how the protocol messages will be encoded. This has complicated text in several areas. The latter sections (the un-reviewed ones) make assumptions on encoding which have not been agreed to. The team feels that presenting the information con- tained in these sections will assist readers to understand the proposal in greater depth, and thus chose to leave the text as is. Abstract This document is an early draft of a proposed protocol that can be used to control a Media Gateway (MG) from an external controller called a Media Gateway Controller (MGC). The document is organized into the following major sections: * The Introduction section presents a high-level overview of the pro- tocol. It discusses the connection model used and provides an example call flow to help illustrate the protocol's functionality. * The Commands section presents a description of each of the opera- tions supported along with their parameters. * The Security section presents the security requirements of the pro- tocol and describes its usage of IP security services (IPSEC). * The Syntax section presents the syntactical elements of the proto- col independent of its encoding. * The Transport section presents how the protocol is carried on a packet network and describes the reliability and fail-over mechan- isms that it supports. * The Event Packages and Termination Classes section describes the elements of commonly implemented devices and services. Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 2] Internet draft MEGACO Protocol April 16, 1999 Table of Contents Page 1. Introduction .............................................. 5 1.1. High Level Description of the Protocol ............... 5 1.1.1. Connection Model ................................ 5 1.1.2. Terminations .................................... 8 1.1.3. Termination Capabilities ........................ 8 1.1.4. Instantiation of a Termination An MG realizes ... 9 1.1.5. Termination Dynamics ............................ 9 1.1.6. Issuing Commands in Transactions ................ 11 1.1.7. Sample Command Flow ............................. 12 2. Commands .................................................. 15 2.1. Names and Common Parameters .......................... 16 2.1.1. Context Identifiers ............................. 16 2.1.2. Termination Names ............................... 16 2.1.3. Specifying Properties ........................... 17 2.1.4. Termination State Properties .................... 18 2.1.5. Termination Descriptors ......................... 19 2.1.6. Events, Signals and Packages .................... 19 2.1.7. SignalDescriptors ............................... 20 2.1.8. EventDescriptors ................................ 21 2.1.9. Digit Maps ...................................... 21 2.1.10. Statistics ..................................... 23 2.2. Termination Management Commands ...................... 24 2.2.1. Add ............................................. 24 2.2.2. Modify .......................................... 25 2.2.3. Subtract ........................................ 27 2.2.4. Move ............................................ 28 2.2.5. Audit ........................................... 28 2.3. MG-Issued Commands ................................... 30 2.3.1. Notify .......................................... 30 2.3.2. ServiceChange ................................... 31 2.4. The following table lists the defined commands, and .. 33 3. MG-MGC Control Associations ............................... 33 3.1. Multiple MGCs per MG ................................. 33 3.2. Cold Start ........................................... 34 3.3. Upon failure to obtain a reply, either from the ...... 35 3.4. Failover ............................................. 35 3.4.1. Failure of an MG ................................ 35 3.4.2. Failure of an MGC ............................... 35 3.5. Error Codes .......................................... 36 4. Security Considerations ................................... 36 4.1. Protection of Media Connections ...................... 38 5. Syntax .................................................... 40 5.1. Termination Names .................................... 44 5.2. Events, Signals and Packages ......................... 45 5.3. Digit Maps ........................................... 47 5.4. Statistics ........................................... 48 Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 3] Internet draft MEGACO Protocol April 16, 1999 5.5. Examples ............................................. 51 5.5.1. Example Add transaction: ........................ 52 5.5.2. Example response to Add transaction: ............ 52 5.5.3. Example Modify transaction: ..................... 52 5.5.4. Example Subtract transaction: ................... 52 5.6. Transaction Response Codes ........................... 53 5.6.1. Transaction Response Success Codes .............. 53 5.6.2. Transaction Response Reject Codes ............... 53 6. Transport ................................................. 54 6.1. Transport capabilities, and relationship to Transport 54 7. Event Packages and Termination Classes .................... 55 7.1. Basic Event Packages ................................. 56 7.1.1. Generic Media Event Package ..................... 56 7.1.2. DTMF Event Package .............................. 57 7.1.3. MF Event Package ................................ 60 7.1.4. Trunk Event Package ............................. 61 7.1.5. Line Event Package .............................. 62 7.1.6. Handset emulation Event Package ................. 66 7.1.7. RTP Event Package ............................... 67 7.1.8. Network Access Server Event Package ............. 68 7.1.9. Announcement Server Event Package ............... 69 7.1.10. Script Event Package ........................... 70 7.2. Basic Termination Classes ............................ 71 7.2.1. DS0 Terminations ................................ 71 7.2.2. Analog Terminations ............................. 72 7.2.3. RTP Audio Terminations .......................... 74 7.2.4. ATM audio Terminations .......................... 78 7.2.5. Network access service Termination .............. 80 8. Acknowledgements .......................................... 84 9. References ................................................ 84 10. Authors' Addresses ....................................... 85 Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 4] Internet draft MEGACO Protocol April 16, 1999 1. Introduction This document describes the MEGACO protocol for controlling Media Gate- ways from external call control elements called Media Gateway Controll- ers. 1.1. High Level Description of the Protocol This section describes the model and main concepts upon which the MEGACO Protocol is built. It is intended to familiarize the reader with the model, terminology and working concepts of the protocol. This section's contents are illustrative and do not intend to supersede information contained in later sections of this document. Where discrepancies may exist, the later sections shall be assumed to contain the correct infor- mation. 1.1.1. Connection Model The connection model for the MEGACO protocol is described using just two abstractions, Terminations and Contexts. Terminations (T) are entities representing physical endpoints, such as analog loops or timeslots on a TDM channel, as well as more ephemeral representations of flow termina- tions, such as RTP streams. Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 5] Internet draft MEGACO Protocol April 16, 1999 *======================================================* | Media Gateway | | +-----------------------------------+ | | | Context +---+ | | | | | T | | | | +---+ | +-+-+ | | | | T | | | | | | +---+ | +---+ +-+ +---+ | | | | | T +---------+M+---------| T | | | | | +---+ +-+ +---+ | | | | | | | | | +-+-+ | | | | | T | | | | | +---+ | | | +-----------------------------------+ | | | | +----------------------+ +---------------+ | | | Context | | Context | | | | +---+ +-+ | | +---+ +-+ | | | | | T +---------+M+ | | | T +----+M+ | | | | +---+ +-+ | | +---+ +-+ | | | | | | +---------------+ | | | +-+-+ | | | | | T | | | | | +---+ | | | +----------------------+ | *======================================================* Examples of Contexts and Terminations Within an MG Contexts represent a star configuration (i.e.-a variable number of interconnected nodes) of Terminations of a single media type. Audio connections are modeled by viewing the Context as a mixing bridge (M). For connections involving other media types and for mixed media gate- ways, the Context's behavior will be described as an extension to the protocol. There are commands to Add Terminations to a Context, Subtract Terminations from a Context, and Move Terminations between two Contexts. A Context must have at least one Termination and a Termination may belong to no more than one Context at a given time. A Context is created by the Add of its first Termination and is destroyed by a Sub- tract of its last remaining Termination. It is possible to move a Ter- mination from one Context to another with the use of the Move command. It is also possible for a Termination to exist outside of a Context. Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 6] Internet draft MEGACO Protocol April 16, 1999 A Media Gateway may limit the number of Terminations that it supports in a given Context. For example, a limit of two might exist for very sim- ple gateways. A limit of three might be common for gateways that sup- port a three-way calling but not multi-way calling of any larger propor- tions. To illustrate the use of a Context, consider a Media Gateway that pro- vides media adaptation between the PSTN and a VoIP network. In this case a typical Context might contain two Terminations, one representing a PSTN trunk (a DS0 Termination) and the other an RTP Stream Termina- tion. A PSTN hairpin connection would be represented by a Context with two DS0 Terminations in it. A three-way call and larger conferences would be represented by a Context with three or more Terminations in it. The use of Contexts to represent conferences is very powerful since it enables a description of the conference dynamics that is not restricted in any way by the order in which Terminations are added or subtracted. For instance, no special operations are required when a participant in a conference drops out. Its Termination may be subtracted without affect- ing the connectivity of the Terminations remaining in the conference. The call-waiting scenario shown below illustrates the use of the Move command to relocate a Termination between Contexts. In this example, Terminations T1 and T2 belong initially to Context C1. T1 might be the line side of a residential gateway, while T2 could represent an RTP Stream Termination. When T1 is connected to T2 in Context C1 a new call arrives for T1 from Termination T3. T3 is placed in Context C2. After alerting is applied to T1 in Context C1 and T1 provides signaling to accept the waiting call, T1 is moved from C1 to C2 through use of the Move command. The active call is represented now by C2 and the call on hold is represented by C1. Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 7] Internet draft MEGACO Protocol April 16, 1999 Call Waiting Scenario: Initial Call +-C1--------------------+ | +---+ +-+ +---+ | | |T1 +---+M+---| T2| | | +---+ +-+ +---+ | +-----------------------+ New Call Arrives +-C1--------------------+ +-C2--------------------+ | +---+ +-+ +---+ | | +-+ +---+ | | |T1 +---+M+---| T2| | | +M+---| T3| | | +---+ +-+ +---+ | | +-+ +---+ | +-----------------------+ +-----------------------+ Waiting Call Answered +-C1--------------------+ +-C2--------------------+ | +-+ +---+ | | +---+ +-+ +---+ | | +M+---| T2| | | |T1 +---+M+---| T3| | | +-+ +---+ | | +---+ +-+ +---+ | +-----------------------+ +-----------------------+ 1.1.2. Terminations A Termination representing a physical device may be permanently instan- tiated and can exist outside of a Context. Terminations representing packet flows are typically ephemeral and are created within a Context as a byproduct of an Add command. All Terminations, ephemeral or not, are named entities and are members of their specific TerminationClass. Names are hierarchical. Termina- tion names may be "underspecified" by the MGC and subsequently given a unique name (i.e.-the last component of the hierarchical name will be unique) by the Media Gateway. Wildcards may be used in the specifica- tion of a name. Section [2.1.2] describes in detail the structure and properties of entity names used in the MEGACO Protocol. 1.1.3. Termination Capabilities Membership in a TerminationClass determines the capabilities of a Termi- nation. The TerminationClass defines the default values and allowable Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 8] Internet draft MEGACO Protocol April 16, 1999 ranges for the Termination's capabilities. Capabilities include: * Properties, such as Termination address, media parameters, security parameters, etc. These are grouped into Profiles. * Events and Signals that a Termination supports. These are grouped in Packages. * Statistics that are kept for Terminations of this Class A TerminationClass is described by a list of Profiles, Packages and statistics that it implements. TerminationClasses, Profiles and Packages cannot be created or modified using the commands of the Megaco protocol, but this document defines several commonly implemented ones. The capabilities of a Termination can be obtained using the Audit com- mand. 1.1.4. Instantiation of a Termination An MG realizes instances of a TerminationClass. The Terminations are instantiated for each "port" on an MG, and are instantiated by the MG when it restarts (or potentially by some administrative provisioning means outside the scope of the Pro- tocol). For Physical Terminations, all instances of a Termination are instantiated by the MG when it restarts (or potentially by some adminis- trative provisioning means). Ephemeral Terminations are instantiated by the Add command, and destroyed by the Subtract command. The "highest order" (first component of a hierarchical name) termination has a full set of properties that can be altered by the MGC; they represent default values for fully instantiated Terminations. The Pro- file defines the initial default values assumed by the Termination upon MG restart. 1.1.5. Termination Dynamics As Terminations are Added or Moved it is necessary to specify state and media parameters for, Events to be detected on, and Signals to be applied to such Terminations within the Context in which they exist. It may also be necessary during the life of a Termination within a Context to Modify these properties. For Terminations representing physical entities it might also be desir- able to Modify their properties as they are Subtracted from a Context. This may be the case if a configuration different to the one provided by the defaults is needed. Such Terminations may have their properties Modified outside of their existence within a Context. The protocol assumes that it is the MG that is responsible for creating Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 9] Internet draft MEGACO Protocol April 16, 1999 the network connection to the other side of the call. The MGC directs that it do so by, for example, creating an RTP termination, which would have the side effect of causing the MG to create an RTP flow to the other party. On an ATM network using SVCs, it is the MG that would use, for example, UNI to create a bearer connection. The Add, Subtract, Move and Modify commands may affect the following sets of properties: * TerminationState: A list of properties that define the state of the Termination, but which are not directly linked to the description of a media flow, to an Event list or to a Signal list. * LocalTerminationDescriptor and RemoteTerminationDescriptor: Lists of properties describing the processing of the media flow in each direction. * EventsDescriptor: A list of Events that should be detected on the Termination. * SignalDescriptor: A list of Signals that should be applied on the Termination. For example, the Add Command has the following form: Add(TerminationId, [LocalTerminationState,] [LocalTerminationDescriptor,] [RemoteTerminationDescriptor,] [EventsDescriptor,] [SignalDescriptor]) All parameters listed are optional except for the TerminationId. This allows each command to specify exactly what needs to be modified. Addi- tionally, some parameters may not be required for certain TerminationC- lasses. For instance, DS0s do not use RemoteTerminationDescriptors. These descriptors are used only for packet TerminationClasses. A Termination is programmed to look for specific Events through the EventsDescriptor, which is a parameter to Add, Modify and Subtract. When a Termination detects an Event that matches the types of Events it is programmed to detect, the MG generates a Notify command. The MG can generate a ServiceChange message. ServiceChange has a number of uses: Registration of an MG with an MGC, notification of imminent downtime for one or more Terminations, notification that one or more Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 10] Internet draft MEGACO Protocol April 16, 1999 Terminations has already gone out of service, and notification that one or more Terminations have been brought back into service. Detailed definitions of Commands and their Responses are provided in Section 2. 1.1.6. Issuing Commands in Transactions The protocol has been designed to allow multiple Commands to be packed in single TransactionRequest. The corresponding Responses are received in a single Transaction reply. There are two types of replies, a Tran- sactionAccept and a TransactionReject. A Transaction allows Commands to share fate and guarantees ordered processing. Multiple Transactions may, in turn, be packed into a single message. Commands in a Transaction are executed sequentially according to an "all or nothing rule". That is, a TransactionAccept includes successful Responses for ALL the Commands in the corresponding TransactionRequest. A TransactionReject is sent when one of the Commands included in the Transaction fails. Responses for the Commands in a TransactionReject are issued as follows: * All Commands before the point of failure in the Command sequence should have a Response equal to "non-executed". * The failed Command should have a Response with a Reason Code. * Commands after the point of failure are not processed and, there- fore, Responses are not issued for them. The parsing mechanism described in the coding section (section 3) speci- fies how responses or reason codes are associated with individual Com- mands. When a MGC issues Commands to a MG, a Context must always be specified. This is quite natural for Add and Subtract. For Modify Commands on a Termination that is not in a Context, the null Context must be speci- fied, which changes the default values of properties for that Termina- tion. A Move Command clearly involves two Contexts, however only the target Context needs to be specified (i.e. the Move has the semantics of "Move-To"). Within a Transaction, all Commands that apply to a Context must appear after the ContextId parameter. The following lines illustrate (i.e., syntax is ad-hoc and actions some- what simplified) the use of Transactions in the call-waiting example of section 1.1.1. The Transaction that creates the second Context, applies Signals to Termination T1 (to indicate call-waiting) and detects Events from T1 (to swap the call) is formed as follows: Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 11] Internet draft MEGACO Protocol April 16, 1999 Transaction(TransactionId=12345 ContextId=* Add(T3) ContextId=C1 Modify(T1, EventDescriptor, SignalDescriptor) ) The Commands in this Transaction are processed sequentially. First, the MG creates a Context to Add T3. Second, T1 is programmed to Signal the waiting call and collect the Events that operate the call-waiting feature. The next Transaction shows the Commands issued by the MGC to swap the Terminations. Transaction(TransactionId=12346 ContextId=C2 Move(T1) Modify(T3, TerminationState) ContextId=C1 Modify(T2, TerminationState) ) Again, the Commands in this Transaction are processed sequentially. First, the MG moves T1 from C1 into C2. Then it modifies the Mode of T3 to Sendrecv. Finally, T2 in C1 is set to Receive Mode. 1.1.7. Sample Command Flow This section presents an illustration of the use of the protocol Com- mands to establish a communication between two Residential Gateways over an IP trunking network, both MGs are under the control of the same MGC. Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 12] Internet draft MEGACO Protocol April 16, 1999 |Step | User | ResMG | MGC | ResMGr | User | |_____|___________|_____________|________________|_____________|___________| | 0| | <------CTX=null,Modify(T1) | | | | | Resp-------------> | | | | | | (Ok,ready, looking for Off-hook) | | | 1| Off-hook | Notify----------------> | | | | | | | (off-hook recorded) | | | | | <--------------Resp(Ok)| | | | 2|Acc Digits | | | | | | | | | | | | | 3|DgtsColct'd| Notify -----------> | | | | 4| | <--------------Resp(Ok)| | | | | | | | | | | 5| | <------CTX=* ADD(T1) | | | | | | | ADD(RTP/* LocalDesc) | | | 6| | CTX=C1 ---------> | | | | | | Resp(Ok) | | | | | | | Resp(RTP/Id,LocalDesc,RemoteDesc | | | | | | | | | | 7| | |CTX=* ADD(T1r)---------> | | | | | | ADD(RTPr/*,LocalDesc,RemoteDesc) | | | | | | | | | 8| | | <---------------CTX=C1r | | | | | | | Resp(Ok) | | | | | Resp(RTP/Id,LocalDesc,RemoteDesc) | | | | | | | | | | 9| | |CTX=C1r --------------> | | | | | | Modify(T1r,SignalList=Ring) | | | | | | | | | | | | | | | | 10| | | <---------------CTX=C1r | Ring | | | | | | Resp(Ok) | | | | | | | | | | 11| | <-------CTX=C1 Modify(T1, SignalList=Ringback) | | | | | Modify(RTP/Id,LocalDesc,RemoteDesc) | 12| Ring-Back | CTX=C1 ---------> | | | | | | Resp(Ok) | | | | | | | Resp(RTP/Id,LocalDesc,RemoteDesc) | | | | | | | | | | 13| | | <------------- Notify | Off-hook | | 14| | | Resp(Ok)----------> | | | | | | | | | | | | | | | | | 15| | <------CTX=C1 Modify(T1,TerminalState=Sendrcv | | | | | | SignalList) | | | 16| | CTX=C1 ---------> | | | | | | Resp(Ok) | | | | Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 13] Internet draft MEGACO Protocol April 16, 1999 CTX = ContextID Step 0: The MGC issues a Modify Command to request that T1 detect an Off- hook and proceed with digit collection Step 1: The Off-hook is detected, the Notify Command is issued and the Off-hook recorded for billing purposes. Step 2: The Termination collects and accumulates digits according to an appropriate digit map. Step 3: The collected digits are sent to the MGC in a Notify Command. Step 4: The MGC acknowledges the digit string. Step 5: After determining that the digit string is valid to initiate a call, the MGC uses the Add Command to create a Context that includes T1 and a yet unnamed ephemeral packet Termination (RTP/*). The RTP Termination receives only a LocalTerminationDescriptor that specifies, for instance, a choice of codecs. Step 6: The reply to the Add Command includes a named Context (C1) and a named RTP Termination (RTP/Id) with its LocalTerminationDescriptor including supported Codecs and the receiving RTP port. Step 7: The MGC can now instruct the remote Residential MG to Add the Ter- mination that corresponds to the dialed string (e.g., T1r) and a corresponding RTP Termination in a Context. The information returned in T1's LocalTerminationDescriptor is passed to the remote Residential MG in the RemoteTerminationDescriptor. The LocalTer- minationDescriptor specifies the Codecs for T1r. Step 8: The reply to the Add Command includes a named Context (C1r) and a named RTP Termination (RTP/Idr) with its LocalTerminationDescriptor including supported Codecs and the receiving RTP port. Step 9: The MGC can now request that Ringing be applied on T1r. The Modify Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 14] Internet draft MEGACO Protocol April 16, 1999 Command is used for this. Looking for Off-hook is simultaneously programmed in T1r. Step 10: The Response indicating that Ringing is applied is sent to the MGC. Step 11: Two Modify commands are issued in this Transaction. The first requests that Ring-back be applied to T1. The second provides the RemoteTerminationDescriptor, which indicates the remote RTP receiv- ing port. Step 12: The TransactionReply acknowledges that Ringback is being applied and the RTP parameter settings have been updated. Step 13: The remote user goes off-hook. A Notify Command conveys that information to the MGC. It is assumed that the off-hook command has an associated action that cancels ringing. Step 14: The Notify is acknowledged by the MGC. Step 15: The MGC issues a Modify Command to T1 to set the two-way talk path and cancel ringback. Step 16: The MG acknowledges that the call set up is complete. 2. Commands Commands from the MGC to the MG are grouped into Transactions, each of which requires a Transaction ID. Transactions consist of one or more Actions. Each Action is limited to operate within a single Context and consequently must specify a ContextID. There are two circumstances where a specific ContextID is not provided. One is the case of modifi- cation of a Termination outside of a Context. The other is where the controller requests the gateway to create a new Context. Each of these two cases has a distinguished value for ContextID An Action consists of a series of Commands (Add, Subtract, Modify, Move, etc.). These Commands have very similar parameters, which may include: * TerminationState: A list of properties that define the state of the Termination, but which are not directly linked to the description of a media flow, to an Event list, or to a Signal list. This Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 15] Internet draft MEGACO Protocol April 16, 1999 includes a description of the media handling at the Termination (e.g., the Mode parameter that indicates loopback, COT, etc.) and a description of the handling of accumulated Events that are pending for processing (i.e., "buffered events"). * LocalTerminationDescriptor and RemoteTerminationDescriptor: Lists of properties describing the processing of the media flow in each direction. These are expressed in the form of SDPdescriptors[ref]. * EventsDescriptor: A list of Events that should be detected on the Termination. These Events must be supported by the Package(s) of the TerminationClass. The EventDescriptor can be augmented by a DigitMap. * SignalDescriptor: A list of Signals that should be applied on the Termination. These Signals must be supported by the Package(s) of the TerminationClass. * A DigitMapDescriptor, which creates, deletes, or redefines a Digit Map. A Digit Map is a concise description of how an MG is to han- dle a series of events from the detection of tones (such as from DTMF tone detection). Responses which return information do so in the form of a LocalTermina- tionDescriptor, RemoteTerminationDescriptor, or a Statistics summary. 2.1. Names and Common Parameters 2.1.1. 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 proto- col makes reference to two distinguished values: * The null Context, which is used to refer to a Termination outside of a Context. When used with a Modify Command, such a reference changes the default values for the Termination. * The "unspecified" Context, which is used to request that the MG create a new Context. The actual ContextID must be returned to the MGC for subsequent use. 2.1.2. Termination Names Names for Terminations (called a "TerminationID") are hierarchical. A separation character delimits the components of a name from one another. An example name in a Termination Class that implements a channelized T3 is "com1/3/17". This name refers to a T3 called "com1", the "3" Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 16] Internet draft MEGACO Protocol April 16, 1999 specifies a specific DS1 in the T3. The "17" specifies a specific DS0 in the DS1. There is a special Termination called "Root". Root refers to the MG itself. TerminationIDs in Commands may use wildcards. Two wildcard constructs are provided: "all" and "choose". The "all" construct allows a Command to specify all possible values of a component. One can, for example, use "all" to refer to all DS1s of a T3 (com1/*). When an Ephemeral Termination is to be created, the TerminationID may given with the last component specified as "choose". The MG would create a fully instantiated Termination and supply a unique name which must be returned to the MGC and be used for subsequent Transactions. The MGC may supply a unique TerminationID, in which case the MG is obliged to use that name. MGs MAY refuse a request to choose a name, in which case they must return an appropriate error code 2.1.3. Specifying Properties Commands may include descriptors. Each descriptor has a set of legal properties that may be included, which is part of the definition of the Termination Class (properties legal for TerminationState, LocalTermina- tionDescriptor and RemoteTerminationDescriptor), or Package (properties legal for EventDescriptor or SignalDescriptor). In a descriptor, each of the properties may be fully specified, under-specified, or unspeci- fied. * Fully specified properties have a single, unambiguous value that the MGC instruct the MG to use for the specified parameter * Under-specified properties have a list of potential values. The MG chooses one value from the offered list, and returns the value it chose to the MGC. A common example is choice of codec. The MGC may allow the MG to choose from G.729a, G.723 or G.711. The MG's choice may be limited based on availability of DSP resources at the time the request was made. The order in which the MGC presents choices to the MG represents the MGCs order of preference for the values offered, which the MG is encouraged, but not obligated to respect. * Unspecified properties (legal properties which do not occur in the descriptor) result in the MG retaining the previous value for that parameter. Each property has a default value, which is the value assumed by the property when it is not part of a context, or when the Termination is added to a Context but not assigned a specific value when added. Default values can be changed by the MGC. Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 17] Internet draft MEGACO Protocol April 16, 1999 2.1.4. Termination State Properties TerminationState groups a list of properties that define the state of the Termination, but are not directly linked to a media flow, to an Event list or to a Signal list. These properties are: * TerminationMode * EventBufferProcessing * EventBufferNotification The TerminationMode parameter indicates the relation between the Termi- nation and the "star" connection of the Context. The mode are "send only" (sendonly), "receive only" (recvonly), "send/receive" (sendrecv), "inactive" (inactive), "outofservice" and "test" (test). The handling of the media received on the Termination is determined by the TerminationMode parameter value: * Termination whose mode is "send", or "send/receive" receive the signals mixed in the Context, according to media specific rules - audio Terminations for example, will receive the sum of the audio flows coming from all other Terminations, excluding those coming from this specific Termination. * The "test" mode is used during maintenance and continuity test operations. There are several defined Packages that implement vari- ous forms of tests that can be applied to a Termination. The optional EventBufferProcessing and EventBufferNotification descrip- tors specifies the handling of "buffered" Events, i.e. Events that have been detected by the MG before the arrival of an EventsDescriptor, but have not yet been notified to the MGC. * EventBufferProcessing specifies whether the buffered Events should be processed or discarded (the default is to process them.) * EventBufferNotification specifies whether the MG is expected to generate at most one notification (step by step), or multiple notifications (loop), in response to this request (the default is at most one.) 2.1.5. Termination Descriptors The LocalTerminationDescriptor and RemoteTerminationDescriptor parame- ters describe the processing of the media flow in each of the direc- tions. The actual properties of each descriptor depend on the Profiles Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 18] Internet draft MEGACO Protocol April 16, 1999 specified for Termination Class. Examples of Termination Classes are RTP, Analog, DS0. For an RTP Termination, for example, some of the pro- perties might be: * IP address, * UDP ports (RTP and RTCP), * Encoding Method, * Packetization period, The LocalTerminationDescriptor and RemoteTerminationDescriptor are described in the form of an SDP descriptor which is part of the defini- tion of a Profile. These sets of properties can be enhanced by vendor specific optional or mandatory extensions. Properties in the LocalTer- minationDescriptor and the RemoteTerminationDescriptor may be fully specified, under-specified or (by omission) unspecified as described above. 2.1.6. Events, Signals and Packages The MGC may ask to be notified about certain Events occurring on a Ter- mination, e.g. off-hook Events, and a MGC may request certain Signals to be applied to a Termination, e.g. dial-tone. Events and Signals are grouped in Packages within which they share the same namespace which we refer to as Event names. Packages are groupings of the Events and that are related. For instance, one Package may sup- port a certain group of Events and Signals for Simple analog access lines, and another Package may support another group of Events and Sig- nals for video lines. One or more Packages may applicable for a given Termination Class, and part of the description of the Termination Class consists of a list of supported Packages. Event names are composed of two logical parts, a Package name and an Event name. Examples of Package names are DTMF, MF, Trunk or Line. Exam- ples of Event names are off hook, flash hook or "0" (the digit zero). This document defines a basic set of Package names and Event names. Additional Package names and Event names can be registered with the IANA. A Package definition shall define the name of the Package, and the definition of each Event belonging to the Package. The Event definition shall include the precise name of the Event (i.e., the code used in the MEGACO protocol), a plain text definition of the Event, and, went appropriate, the precise definition of the corresponding Signals, for example the exact frequencies of audio signal such as dial tones or DTMF tones. Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 19] Internet draft MEGACO Protocol April 16, 1999 Signals are divided into different types depending on their behavior: * On/off (OO) Once applied, these Signals last forever until they are turned off. This may happen either as the result of an Event or a new SignalRe- quests (see later). * Time-out (TO) Once applied, these Signals last until they are either turned off (by an Event or SignalRequests) or a Signal specific period of time has elapsed. Depending on Package specifications, a Signal that times out may generate an "operation complete" Event. * Brief (BR) The duration of these Signals is so short, that they stop on their own. If an Event occurs the Signal will not stop, however if a new SignalRequests is applied, the Signal will stop. TO Signals are normally used to alert the Terminations' users, to signal them that they are expected to perform a specific action, such as hang down the phone (ringing). Transmission of these Signals should typically be interrupted as soon as the first of the requested Events has been produced. 2.1.7. SignalDescriptors A SignalDescriptor is a parameter that contains the set of Signals that the MG is asked to apply to the Termination, such as, for example ring- ing, or continuity tones. Signals are identified by their name, which is an Event name, (and thus part of a Package)and may be qualified by pro- perties. If a Signal has already been attached to this Termination, the previous Signal is removed, and the specified one is attached. No Events which would have occurred on the previous Signal will be generated subsequent to a command that modifies the Signal descriptor, although the MGC may not have received an Event from the previous Signal prior to sending the command, and in fact the MG may have detected such an Event, but may not have notified the MGC of it when it receives the new command. The behavior of the MG in such a circumstance is not defined. It may send the notification, or it may flush it. 2.1.8. EventDescriptors The EventDescriptor parameter contains a RequestIdentifier and a list of Events that the MG is requested to detect and report. Such Events include, for example, fax tones, continuity tones, or on-hook transi- tion. The RequestIdentifier is used to correlate this request with the Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 20] Internet draft MEGACO Protocol April 16, 1999 notifications that it may trigger. To each Event is associated a notification action and an optional set of embedded Events and Signal descriptors. The notification actions are: * Notify the Event immediately, together with the accumulated list of observed Events, * Accumulate the Event in an Event buffer, but don't notify yet, * Accumulate according to a specified Digit Map, * Treat the Event according to a specific script, * Ignore the Event. (Events that are not specified in the descriptor are, by default, ignored.) The embedded Signal descriptor, if present, is used as a replacement for the current Signal 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 Signal descriptor is specified, the production of Signals continues as specified in the command. The embedded Events descriptor, if present, is used as a replacement for the current Event descriptor. It is possible, for example, to specify that DTMF digit collection starts as soon as an off-hook Event is detected. MEGACO Protocol implementations must be able to support at least one level of embedding. An embedded Events descriptor that respects this limitation shall not contain another Embedded Events descriptor. 2.1.9. Digit Maps The MGC can ask the MG to collect digits dialed by the user. This facil- ity is intended to be used with residential gateways to collect the numbers that a user dials; it may also be used with trunking gateways and access gateways alike, to collect the access codes, credit card numbers and other numbers requested by call control services. An alternative procedure is for the MG to notify the MGC of the dialed digits, as soon as they are dialed. However, such a procedure generates a large number of interactions. It is preferable to accumulate the dialed numbers in a buffer, and to transmit them in a single message. The problem with this accumulation approach, however, is that it is hard for the gateway to predict how many digits it needs to accumulate before Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 21] Internet draft MEGACO Protocol April 16, 1999 transmission. For example, using the phone on our desk, we can dial the following numbers: _______________________________________________________ | 0 | Local operator | | 00 | Long distance operator | | xxxx | Local extension number | | 8xxxxxxx | Local number | | #xxxxxxx | Shortcut to local number at| | | other corporate sites | | *xx | Star services | | 91xxxxxxxxxx | Long distance number | | 9011 + up to 15 digits| International number | |________________________|_____________________________| The solution to this problem is to load the MG with a digit map that correspond to the dial plan. A digit map is defined by a name and a value. The name is "visible" within a scope, which can be the gateway itself, a hierarchical group of Terminations, or a specific Termination. Digit maps are provisioned through standard Termination management operations such as Add, Modify, Subtract or Move. The scope of the digit map is determined by the name of the Termination to which the command is applied: * If the command is applied to the "all" wildcarded Termination, the digit map is visible within the scope of the MG, * If the command is applied to a hierarchical name such as "Com1/3", the digit map becomes visible within all Terminations whose name begins with the specified prefix. The DigitMapDescriptor contains a set of Digit Maps names and values to be assigned: * A new digit map is created by specifying a name that is not yet defined at this level of the naming hierarchy. The value must be present. * A digit map value is updated by supplying a new value for a name that is already defined at this level of the naming hierarchy. Terminations using the map in an EventDescriptor when it is modi- fied continue to use the old value. Subsequent EventDescriptors mentioning the DigitMap use the new value. * A digit map is deleted by supplying an empty value for a name that is already defined at this level of the naming hierarchy. A Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 22] Internet draft MEGACO Protocol April 16, 1999 wildcard naming convention can be used to delete all the digit maps associated with a specific Termination. The MGC can determine defined digit maps with the Audit command. The collection of digits according to a digit map may be protected by an "interdigit timer", which can take two values: - If the gateway can determine that at least one more digit is requested for the digit string to match any of the allowed patterns in the digit map, then the timer value should be set to a long duration, such as 16 seconds. - If the digit map specifies that a variable number of additional digits may be needed (the "." indication at the end of a string), then the timer value should be set to a medium duration, such as 8 seconds. The "long interdigit timer" and the "short interdigit timer" are parame- ters associated with a digit map. The digit map mechanism is only used to reduce the number of messages between the MG and the MGC. It does not interpret or translate dialed digits. The MGC is free to not employ digit maps, and to request an Event notification per digit. 2.1.10. Statistics The MG may maintain statistics that describe the status of the Termina- tion. The precise properties of the statistics depends on the Class of the Termination. In the RTP class, the properties might include: * Number of packets sent: * Number of octets sent: * Number of packets received: * Number of octets received: * Number of packets lost: * Interarrival jitter: Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 23] Internet draft MEGACO Protocol April 16, 1999 2.2. Termination Management Commands 2.2.1. Add The Add commands adds a Termination to a Context. [TerminationId,] [LocalTerminationDescriptor,] [RemoteTerminationDescriptor,] <--- Add(TerminationId, [TerminationState,] [LocalTerminationDescriptor,] [RemoteTerminationDescriptor,] [EventsDescriptor,] [SignalDescriptor,] [DigitMapDescriptor]) TerminationId is the name of the Termination that is being added to the Context. The TerminationId may be under-specified by using the "choose" wildcard convention. This convention must be used for packet Termina- tions. If the TerminationId is under-specified, the actual identifier must be assigned by the MG and its complete value returned in the response. The TerminationState properties can be fully specified or unspecified by the MGC. The MG uses the specified value when it is present. The pro- perty is unmodified if it is not mentioned The LocalTerminationDescriptor properties can be either fully specified, under-specified or unspecified by the MGC. The MGC may under-specify a parameter by providing a loose specification, such as a list of allowed encoding methods or a range of packetization periods. When the value are under-specified, the MG returns a fully qualified LocalTermination- Descriptor. When a value is unspecified, the MG does not change the value of a property. Since properties not in a Context have default values, unspecified properties in an Add will have default values. The RemoteTerminationDescriptor is the descriptor for the remote side of a Termination, for example on the other side of the IP network. It includes the same fields as in the LocalTerminationDescriptor, i.e. the fields that describe a session according to the SDP standard. This descriptor may be omitted when the information for the remote end is not known yet. This information may be provided later via a Modify command. Under-specified properties in RemoteTerminationDescriptor is possible where the remote side has offered a choice, but the MG may have resource restrictions which prevent the MGC from being able to make the choice. Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 24] Internet draft MEGACO Protocol April 16, 1999 When the value of any properties in the descriptor are under-specified, the MG returns a fully qualified RemoteTerminationDescriptor. When a value is unspecified, the MG does not change the value as described above. Physical Terminations typically would not have a RemoteTermination- Descriptor, but the Termination Class defines whether it does or does not in all cases After receiving an Add command that did not include a RemoteTermination- Descriptor, a MG is in an ambiguous situation. Because it has received a LocalTerminationDescriptor parameter, it can potentially receive pack- ets. Because it has not yet received the RemoteTerminationDescriptor of the other MG, it does not know whether the packets that it receives have been authorized by the MGC. It must thus navigate between two risks, i.e. clipping some important announcements or listening to potentially unintelligible, or unauthorized data. The behavior of the MG is deter- mined by the value of the Termination Mode element of the Termination- State parameter: * If the mode was set to ReceiveOnly, the MG should accept the voice signals and transmit them through the Termination. * If the mode was set to Inactive, Loopback, Continuity Test, the MG should ignore the voice signals. Note that the mode values SendReceive and SendOnly don't make sense in this situation. They should be treated as errors, and the command should be rejected. The EventsDescriptor parameter, if present, provides the list of Events that should be detected on the Termination. The SignalDescriptor parameter, if present, provides the list of Signals that should be produced on the Termination. The command may also include a DigitMapDescriptor. Each parameter describes the name and the value of a digit map in the Context of the Termination. 2.2.2. Modify The Modify command modifies the properties of a Termination. [LocalTerminationDescriptor,] [RemoteTerminationDescriptor,] <--- Modify(TerminationId, [TerminationState,] Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 25] Internet draft MEGACO Protocol April 16, 1999 [LocalTerminationDescriptor,] [RemoteTerminationDescriptor,] [EventsDescriptor,] [SignalDescriptor,] [DigitMapDescriptor]) TerminationId is the name of the Termination whose properties are being modified. The TerminationId may not be under-specified. The Modify command takes place within the Context to which the Termina- tion belongs, or within the "null" Context when modifications are to be made to the default values for the Termination. The TerminationState properties can be fully specified or unspecified by the MGC. The MG uses the specified value when it is present, the previ- ous value otherwise. The LocalTerminationDescriptor properties can be either fully specified, under-specified or unspecified by the MGC. The MGC may under-specify a parameter by providing a loose specification, such as a list of allowed encoding methods or a range of packetization periods. When the value are under-specified, the MG returns a fully qualified LocalTermination- Descriptor. When a value is unspecified, the MG retains the previous value. The RemoteTerminationDescriptor properties can be either fully speci- fied, under-specified, or left unspecified by the MGC. When a value is unspecified, the MG keeps the previous value. A value is under- specified, the MG performs a selection and returns a RemoteTermination- Descriptor that documents the choices made. The EventsDescriptor parameter, if present, provides the list of Events that should be detected on the Termination. The SignalDescriptor parameter, of present, provides the list of signals that should be produced on the Termination. The command may also include a DigitMapDescriptor. Each parameter describes the name and the value of a digit map. Modify of a Termination in the null Context changes the default values for TerminationState, LocalTerminationDescriptor, RemoteTermination- Descriptor, EventsDescriptor, and SignalDescriptor on that Termination. Modify of a wildcarded termination ID in the null Context changes all instances of the Termination covered by the wildcard specification. Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 26] Internet draft MEGACO Protocol April 16, 1999 Modify of a TerminationID where only a subset of the hierarchy is named (such as "com1/3" where com1 represents a channelized T3 as described above), changes properties assigned to the logical unit covered by the name specified. In the example, changing "com1/3"'s "linecode = B8ZS" would alter the line coding of one of the DS1s in the T3 to B8ZS. Simi- larly, changing the linecode of "com1/*" would change the line coding for all DS1s in the T3. Modify can also be used to program the MG to Notify the MGC at particu- lar intervals if no other communication is occurring between the MGC and the MG. This has the effect of providing a heartbeat message from the MG to the MGC. 2.2.3. Subtract The Subtract commands disconnects a Termination from a Context and returns statistics on it. Statistics | *[TerminationId, Statistics] <---- Subtract(TerminationId, [TerminationState,] [EventsDescriptor,] [SignalDescriptor,] [DigitMapDescriptor]) TerminationId is the name of the Termination whose properties are being modified. The TerminationId is either a fully specified value, or a wildcard value indicating that all the terminations of a given Context shall be removed. When all Terminations have been removed from a specified Context, that Context is deleted by the MG. Ephemeral Terminations are deleted when they are removed from their Con- text. The Subtract command, when applied to an Ephemeral Termination, shall not have any other parameter than the TerminationId. The LocalTerminationDescriptor and RemoteTerminationDescriptor of a per- manent termination are reset to their default value when the termination is removed from its Context. When applied to a Physical Termination, the Subtract command may include TerminationState, EventsDescriptor, SignalDescriptor and DigitMap- Descriptor parameters. These parameters are processed as defined in the Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 27] Internet draft MEGACO Protocol April 16, 1999 Modify command assuming a "null" Context, that is, they change the default values of the Termination. The command returns the statistics that were observed on the Termina- tion. When a wildcard is used, the command returns a Termination iden- tifier and statistics for each of the Terminations whose name matched the wildcard. 2.2.4. Move The Move command moves a Termination to another Context. The Termination is removed from its old Context and is added to the new Context as an atomic operation. While this action appears similar to the packaging of a subtract and an add command, it does not have the side effect of deleting an Ephemeral Termination that the subtract command would cause. [LocalTerminationDescriptor,] [RemoteTerminationDescriptor] <-- Move(TerminationId, [TerminationState,] [LocalTerminationDescriptor,] [RemoteTerminationDescriptor,] [EventsDescriptor,] [SignalDescriptor,] [DigitMapDescriptor]) The TerminationId is the fully specified name of a Termination that is being moved into the Context specified for the transaction. The termi- nation is subtracted from its previous Context. If it was the last Ter- mination in this previous Context, that Context is deleted. A Context with only one Termination is permitted. The TerminationState, LocalTerminationDescriptor, RemoteTermination- Descriptor, EventsDescriptor, SignalDescriptor, and DigitMapDescriptor parameters are processed as in the Modify command. Management Commands 2.2.5. Audit The Audit request returns properties associated with Terminations: Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 28] Internet draft MEGACO Protocol April 16, 1999 [TerminationId,] [TerminationState,] [LocalTerminationDescriptor,] [RemoteTerminationDescriptor,] [EventsDescriptor,] [SignalDescriptor,] [DigitMapDescriptor,] [Capabilities] [Statistics] <-- Audit (TerminationId, RequestedInfo) The TerminationId is the name of the termination that is being audited. The wildcard convention may be used. The command shall be applied either in the null Context, for Terminations that are not part of an active Context, or in the specific Context of the Termination(s). The (possibly empty) RequestedInfo parameter describes the information that is requested for the TerminationId specified. The following Termi- nation info can be audited with this command: TerminationState, LocalTerminationDescriptor, RemoteTermination- Descriptor, EventsDescriptor, SignalDescriptor, ObservedEvents DigitMapDescriptor, Statistics and Capabilities. The TerminationState, LocalTerminationDescriptor, RemoteTermination- Descriptor, EventsDescriptor, SignalDescriptor, ObservedEvents and DigitMapDescriptor values are the values currently used by the Termina- tion. ObservedEvents is as defined in Notify. The Capabilities parameter returns values such as compression algo- rithms, packetization period, connection networks that the MG is ready to support for that Termination. In addition, the option can also be used to return the Event Packages that the Termination supports, and the list of TerminationState parameter values that the MG is ready to sup- port for that Termination. The Statistics parameter returns the current state of the Termination statistics that would be generated on a Subtract. This option provides mid-call statistics. If the RequestedInfo parameter is empty, Audit returns the TerminationID only. Combining this with using null and unspecified for ContextID and wildcarding TerminationID, the Audit command can return a wide variety of information: Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 29] Internet draft MEGACO Protocol April 16, 1999 _________________________________________________________________________ |ContextID TerminationID Returns | |_______________________________________________________________________| |Specific all List of terminations in a Context | |Specific wildcard List of terminations in a Context, | | whose name matches the wildcard | |Null Root name Audit of MG (base state & Events) | |Null all List of all Terminations in the MG | |Null all/ List of all "highest order" Terminations | |Null wildcard List of all Terminations whose | | name matches the wildcard. | |unspecified Root name Audit of MG (null Context) | |unspecified all List of all Terminations in the MG | | and the Context[s] to which they are | | associated (maybe null) | |unspecified all/ List of all "highest order" Terminations,| | in the Context to which they are | | associated (maybe null) | |unspecified wildcard List of all Terminations whose | | name matches the wildcard, in the | | Context[s] to which they are | | associated (maybe null) | |_______________________________________________________________________| The MGC can effect a "Are you alive" poll by using the Audit command on the null Context with the Root name as the TerminationID and an empty RequestedInfo. This will result in a short response from the MG. 2.3. MG-Issued Commands 2.3.1. Notify Notify (TerminationId, ObservedEvents) TerminationId is the name for the Termination in the MG which is issuing the Notify command, as defined in section 2.1.2. The identifier must be a fully qualified termination identifier. The local part of the name must not use the wildcard convention. ObservedEvents is a parameter that contains a RequestIdentifier and a list of events that the MG detected in the order they have been detected. The RequestIdentifier repeats the RequestIdentifier parameter of the EventDescriptor that triggered this notification. It is used to correlate this notification with the request that triggered it. Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 30] Internet draft MEGACO Protocol April 16, 1999 The Events in the list must be reported in the order in which they were detected. The list may only contain the identification of Events that were requested in the RequestedEvents parameter of the triggering EventsDescriptor. It must contain the Events that were either accumu- lated (but not notified) or treated according to digit map (but no match yet), and the final Event that triggered the detection or provided a final match in the digit map. Each element in the list must contain the name of the Event, and may also contains properties associated with the Event and a notation of the time at which the Event was detected. The MG MUST NOT send an unsoli- cited notify. There is an Event defined for all MGs that can be programmed with an interval. This Event can be used for a "heart beat" notify message from MG to MGC. Use of this Event is optional by the MGC. Any message sent by the MG to the MGC restarts the timer for the Event. 2.3.2. ServiceChange The ServiceChange command is used by the MG to signal that a Termina- tion, or a group of Terminations, or the entire gateway, is about to be taken out of service, or has been brought back in to service. [MGCIdentity] <------- ServiceChange ( TerminationId, ServiceChangeMethod, ServiceChangeReason, [ServiceChangeDelay]) The TerminationId identifies the Terminations that are taken in or out of service. The "all" wildcard convention may be used to apply the com- mand to a group of Terminations, such as for example all Terminations that are attached to a specified interface, or even all Terminations that are attached to a given MG. The "choose" wildcard convention shall not be used. Hierarchical names can be used to specify that an element of a MG, such as for example a digital multiplex, is being brought out of service. The Root keyword indicates the gateway itself is restart- ing. The ServiceChangeMethod parameter specifies the type of ServiceChange. Three values have been defined: * A "graceful" ServiceChange method indicates that the specified Ter- minations will Be taken out of service after the specified delay. The established connections are not yet affected, but the MGC should refrain from establishing new connections, and should try to Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 31] Internet draft MEGACO Protocol April 16, 1999 gracefully tear down the existing connections. If is sent with the Root TerminationID, this message indicates the MG itself will be going out of service. * A "forced" ServiceChange method indicates that the specified Termi- nations were taken abruptly out of service. The established connec- tions, if any, are lost, although the Contexts are maintained. The MGC should Subtract the Terminations which could return available statistics. If is sent with the Root TerminationID, this message indicates the MG itself is out of service. * A "Restart" method indicates that service will be restored on the Terminations after the specified ServiceChangeDelay The Termina- tions are not currently attached to any Context. If sent with the Root TerminationID, the MG is announcing its availability to the MGC. * A "Disconnected" method, always applied with the Root Termina- tionID, indicates that the MG lost communication with the MGC, but it was subsequently restored. Since MG state may have changed, the MGC may wish to use the Audit command to resynchronize its state with the MG's. ServiceChangeReason supplies the reason why the Termination is being taken out of service or brought back into service. The optional ServiceChangeDelay parameter is expressed as a number of seconds. If the number is absent, the delay value should be considered null. In the case of the "graceful" method, a null delay indicates that the MGC should simply wait for the natural termination of the existing connections, without establishing new connections. The ServiceChangeDe- lay is always considered null in the case of the "forced" method. The MGC may return an MGCIdentity parameter that describes the MGC that should preferably be contacted by the MG. In this case the MG must reissue the ServiceChange command to the new MGCIdentity The ServiceChange command specifying the Root keyword for the Termina- tionId is the registration command by which an MG announces its existence to the MGC. The MG is expected to be provisioned with the name of one primary and some number of alternate MGCs. The Servi- ceChange method shall be "forced". Acknowledgement of the ServiceChange completes the registration process. If an MG knows that a Termination is about to go out of service, it can issue a ServiceChange with ServiceChangeMethod set to "graceful", and specify a ServiceChangeDelay. If an MG has just detected that a Termina- tion or a set of Terminations has just gone out of service, it issues a Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 32] Internet draft MEGACO Protocol April 16, 1999 ServiceChange with ServiceChangeMethod set to "forced". An MGC may inform an MG that it should send subsequent commands to another MGC by returning the identity of a new MGC when responding to ServiceChange. The MG may need to reissue ServiceChange to the new MGC. 2.4. The following table lists the defined commands, and the available input parameters. An "X" denotes the parameter is legal for the command __________________________________________________________________ __________________________________________________________________ | Add Sub Mdfy Move Audt Ntfy SvcChng| | TermID X X X X X X X | | TermState X X X X | | LocalTermDesc X X X X | | RemoteTermDesc X X X X | | EventsDesc X X X X | | SignalDesc X X X X | | DigitMapDescr X X X X | | RequestedInfo X | | ObservedEvents X | | SvcChngMethod X | | SvcChngReason X | | SvcChngDelay X | |_________________________________________________________________| 3. MG-MGC Control Associations An MG is under control of (one or more) MGCs. 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 an MG, it has been designed to support the following model, which has impacts on how protocol mechanisms are used in such a case. 3.1. Multiple MGCs per MG There are several circumstances where it is desired that an MG be con- trolled by more than one MGC. One is the case where different MGCs have varying abilities, for example, one MGC may be capable of SS7 interwork, another may only be capable of H.323 interwork. A physical MG may need some of it's trunks controlled by SS7, while others are con- trolled by H.323. The model supported by the protocol is statically allocated partitioning of Terminations. In this model, a physical MG can be thought of as Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 33] Internet draft MEGACO Protocol April 16, 1999 multiple virtual MGs, each with a non-intersecting set of 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 implementation of the MEGACOP 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 instantiated per flow, and thus sharing the Termination is straightfor- ward. 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 it's 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. 3.2. Cold Start An 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 it's primary MGC. If the MGC accepts the MG, it will send a Transaction Accept, with the MGCIdenty set to itself. If the MG recieves an an MGCIdentity not equal to the MGC it contacted, it sends a ServiceChange to the MGC specified in the MGCIdentity. It continues this process until it gets a controlling MGC to accept its registration, or it fails to get a reply. Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 34] Internet draft MEGACO Protocol April 16, 1999 3.3. 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. 3.4. Failover 3.4.1. Failure of an MG If an 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. Pairs of MGs that are capable of redundant failover of one of the MGs are accommodated by allowing the MGC to send duplicate messages to both MGs. Only the Working MG must accept or reject transactions. Upon failover, the Protect MG sends a ServiceChange command with a "Failover" method and a "Failed MG" reason. The MGC then uses the Protect MG as the active MG, and only it must accept/reject transactions. When the error condition is repaired, the Working MG can send a "ServiceChange" with a "Restart" method. 3.4.2. Failure of an MGC If the MG notices 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 sets the "ControllingMGC" property of the root Termination to its new MGC. As a side effect, the MG should send a ServiceChange message 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 failover, the handover should be transparent to Operations on the gateway. Commands in progress continue, transaction replies are sent to the new MGC, and the MG should expect outstanding 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, "ControllingMGC" would be replaced with the previous value. In such a case, the MG shall Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 35] Internet draft MEGACO Protocol April 16, 1999 behave as if the value was changed, and send a ServiceChange message, as above. Pairs of MGCs that are capable of redundant failover can notify the con- trolled MGs of the failover by the above mechanism. 3.5. Error Codes All MEGACO Protocol commands are acknowledged. The acknowledgment car- ries a return code, which indicates the status of the command. The return code is value for which three ranges have been defined: * successful completion, * transient error, * permanent error. 4. Security Considerations If unauthorized entities could use the MEGACO protocol, they would be able to set-up unauthorized calls, or to interfere with authorized calls. The primary security mechanism employed by the protocol is IPSEC [RFC2401]. Support of the AH header [RFC2402] affords authentication and integrity protection on messages passed between the MG and the MGC. Support of the ESP header [RFC2406] can provide confidentiality of mes- sages if desired. Implementation of IPSEC requires that the AH and ESP headers be inserted between the IP and UDP headers. This presents an implementation problem for MEGACO protocol implementations where the underlying network imple- mentation does not support IPSEC. As an interim solution, the MEGACO protocol defines an optional AH header within the protocol header. The header fields are exactly those of the AH header as defined in [RFC2402]. The semantics of the header fields are the same as the "transport 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 MEGACOP message prepended by a synthesized IP header consisting of a 32 bit source IP address, a 32 bit destination address and an 16 bit UDP port in the MSBs of a 32 bit word. The Authentication Data is assumed to be zero as in [RFC2402]. The "Next Header" and "RESERVED" fields MUST be set to "zero". The ICV calculation is thus performed over a structure that would look like: Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 36] Internet draft MEGACO Protocol April 16, 1999 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UDP Port | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Payload Len | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number Field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Authentication Data (variable) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + message contents (variable) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ When the AH-within-MEGACO mechanism is employed when TCP is the tran- sport Layer for MEGACOP, the UDP Port above becomes the TCP port, and all other operations are the same. Implementations of the MEGACO protocol using IPv4 MUST support the interim AH-within-MEGACO scheme. Implementations SHOULD implement IPSEC AH header if the underlying network system supports it. Implementations MAY support the ESP header. IPSEC and AH-within-MEGACO MUST NOT be used at the same time. IPv6 Implementations are assumed to have IPSEC imple- mentations and MUST NOT use the AH-within-MEGACO scheme. When employing the AH header, either in IPSEC or AH-within-MEGACO, all implementations of the protocol MUST implement section 5 of [RFC2402] which defines a minimum set of algorithms for integrity checking using manual keys. MECACOP implementations SHOULD implement IKE [RFC2409] to permit more robust keying options. MEGACOP implementations employing IKE SHOULD implement RSA signatures and authentication with RSA public key encryption. MECACOP implementations employing the ESP header [RFC2406] MUST implement section 6 of [RFC2406] which defines a minimum set of algorithms for integrity checking and encryption. NOTE: The AH-within-MEGACO scheme is defined as interim. The next Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 37] Internet draft MEGACO Protocol April 16, 1999 version of this protocol is likely to deprecate it (backwards compati- bility?). Adequate protection of the connections must be achieved if the MG and the MGC only accept messages for which authentication services of the AH header have been configured. Employing the ESP header for encryption service must provide additional protection against eavesdropping, thus forbidding third parties from monitoring the connections set up by a given Termination The encryption service should also be requested if the session descrip- tions are used to carry session keys, as defined in SDP. These procedures do not necessarily protect against denial of service attacks by misbehaving MGs or misbehaving MGCs. However, they will pro- vide an identification of these misbehaving entities, which should then be deprived of their authorization through maintenance procedures. Also note that the use of NAT (Network Address Translation) interferes with the operation IPSEC and IPSEC-like mechanisms, as they modify IP addresses and port numbers, and thus invalidate the ICV calculations. It is possible to use IPSEC between the point at which NAT is applied and the outside party. 4.1. 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 RemoteTerminationDescrip- tor But this has two inconveniences: it slows down connection establish- ment 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. Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 38] Internet draft MEGACO Protocol April 16, 1999 * 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. Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 39] Internet draft MEGACO Protocol April 16, 1999 5. Syntax Editor's Note: In this edition of the document, a decision has not been made on the encoding of the protocol. The following EBNF description is therefore somewhat awkward. Productions with the word "Token" are not defined. In an ASCII encoding, they would typically be some kind of keyword and a separator. In a binary encoding, they would be a code. The productions use the terms "digit", as in 9DIGIT, which would be understood as a 9 character numeric string in ASCII, or a 32 bit number in binary, although there may be small differences in coding when the decision is actually made. The syntax leaves out separators and whitespace which would be necessary in an ASCII encoding. It leaves out length fields, which may be necessary in a binary encoding. megacoMessage = authenticatedMessage / message authenticatedMessage = authToken authenticationHeader message authenticationHeader = ; as defined in RFC [] message = SystemID *(transactionRequest / transactionAccept / transactionReject) ; question of whether SystemID is there at all ; Version might be in registration in msg header if here transactionRequest = transToken transactionId 1*Action transactionAccept = acceptToken transactionId 1*ActionAccept transactionReject = rejectToken transactionId 1*ActionReject ActionAccept = ctxToken contextId *commandAccept commandAccept = commandName [terminationId] *(parameters) ActionReject = ctxToken contextID *commandReject CommandReject = commandName [terminationID] errorMessage errorMessage = errorCode errorText errorCode = OCTET STRING(3) ;could be extended errorText = OCTET STRING transactionId = INTEGER32 SystemId = domainName [":" portNumber] domainName = 1*256(ALPHA / DIGIT / "." / "-") ; as defined in RFC 821 portNumber = INTEGER16 ;should this be 5digit, 16 bit? version = megacopToken Version Profile Version = OCTET STRING Profile = OCTET STRING ;need explanation Action = ctxToken contextId 1*command Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 40] Internet draft MEGACO Protocol April 16, 1999 contextId = nullToken / unspecifiedToken / INTEGER32 command = commandName terminationId parameters commandName = (addToken / subtractToken / modifyToken / moveToken / auditToken / notifyToken / serviceChangeToken ) terminationId = "." / LocalNamePart / LocalNamePart *("/"LocalNamePart) LocalNamePart = AnyNameToken / AllNameToken / NameString AnyName = "$" AllNames = "*" NameString = 1*(SuitableCharacters) parameters = ([ TSToken TerminationState ] [LTToken LocalTerminationDescriptor ] [RTToken RemoteTerminationDescriptor ] [EDToken EventsDescriptor ] [SDToken SignalDescriptor ] [DMToken DigitMapDescriptor ] [RIToken RequestedInfo ] [RMToken ServiceChangeMethod ] [RDToken ServiceChangeDelay ] [OEToken ObservedEvents ] [STToken Statistics ] [CpToken Capabilities ] [MiToken MGCIdentity ] *[extensionParameterToken parameterValue] ]) ;fix TerminationState = stateParameter ;leftover production for bracketing stateParameter = ([modeToken TerminationMode] [bufferedEventHandlingToken BufferedEventHandling ]) ;fix, there are 2 of them TerminationMode = sendonlyToken / recvonlyToken / sendrecvToken / inactiveToken / loopbackToken / conttestToken / OutOfService BufferedEventHandling = loopControl / processControl / ;fix (loopControl processControl ) loopControl = stepToken / loopToken processControl = processToken / discardToken Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 41] Internet draft MEGACO Protocol April 16, 1999 LocalTerminationDescriptor = TerminationDescriptor RemoteTerminationDescriptor = TerminationDescriptor eventName = [ (packageName / "*") "/" ] (eventId / "all" / eventRange) packageName = 1*(SuitableCharacters) eventId = 1*(SuitableCharacters) ;could be an Integer32 EventsDescriptor = [requestedEvent 0*(requestedEvent)] requestedEvent = eventName [0*(eventParameters)] [requestedActions] eventParameters = *(parameterName parameterValue) requestId = INTEGER32 eventRange = "[" 1*(DIGIT / DTMFLetter / "*" / "#" / (DIGIT "-" DIGIT)/(DTMFLetter "-" DTMFLetter)) "]" ;may want to remove the above requestedActions = requestedAction [ embeddedSignalEvent ] [ mediaAction ] requestedAction = NotifyActionToken / AccumlateToken / AccumulateByDigitMapToken digitMapName / ScriptToken scriptName embeddedSignalEvent = [EventDescriptorToken EventsDescriptor ] [SignalDescriptorToken SignalDescriptor ] mediaAction = SToken SignalDescriptor = [ SignalRequest 0*(SignalRequest) ] SignalRequest = eventName [eventParameters ] eventParameters = eventParameter 0*( eventParameter ) eventParameter = eventParameterString / quotedString eventParameterString = 1*() DigitMapDescriptor = digitMapName DigitMapValue digitMapName = STRING DigitMapValue = ["L:" longTimer ","] ["M:" mediumTimer ","] DigitMap longTimer = 1*2DIGIT shortTimer = 1*2DIGIT DigitMap = DigitString / "(" DigitStringList ")" DigitStringList = DigitString *( "|" StringList ) DigitString = 1*(DigitStringElement) DigitStringElement = DigitPosition ["."] DigitPosition = DigitMapLetter / DigitMapRange DigitMapLetter = DIGIT / "#" / "*" / "A" / "B" / "C" / "D" / MFSig / "T" MFSig = "K0" / "K1" / "K2" / "S0" / "S1" / "S2" / "S3" / DigitMapRange = "x" / "[" DigitLetters "]" DigitLetter = *((DIGIT "-" DIGIT ) / DigitMapLetter) RequestedInfo = [infoCode 0*(infoCode)] infoCode = TerminationStateToken / LocalTermDescToken / RemoteTermDescToken / EventDeccToken / SignalDescToken / Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 42] Internet draft MEGACO Protocol April 16, 1999 DigMapToken / StatsToken / ObsrvdEvntsToken CapsToken / ServiceChangeMethod = GracefulToken / ForcedToken / RestartToken / FailoverToken ServiceChangeDelay = INTEGER32 ObservedEvents = (requestId [ observedEvent *(observedEvent) ]) observedEvent = [ TimeNotation ] SignalRequest TimeNotation= INTEGER64; 64 bits NTP time stamp ? Statistics = [StatisticsParameter 0*( StatisticsParameter ) ] StatisticsParameter = ( PktsSentToken packetsSent ) / ( OctetsSentToken octetsSent ) / ( PktsRecvdToken packetsReceived ) / ( OctetsRecvdToken octetsReceived ) / ( PktsLostToken packetsLost ) / ( JitterToken jitter ) / ( AvgLatencyToken averageLatency ) / ( StatisticsParameterExtensionName StatisticsParameterExtensionValue ) packetsSent = INTEGER64 octetsSent = INTEGER64 packetsReceived = INTEGER64 octetsReceived = INTEGER64 packetsLost = INTEGER32 jitter = INTEGER32 averageLatency = INTEGER32 StatisticsParameterExtensionName = "X" "-" 2*ALPHA ;fix StatisticsParameterExtensionValue = INTEGER32 extensionParameter = "X" ("-"/"+") 1*6(ALPHA / DIGIT) parameterString = 1*(%x20-7F) Capabilities = ;not defined yet MGCIdentity = SystemId SuitableCharacter= DIGIT / ALPHA / "+" / "-" / "_" / "&" / "!" / "'" / "|" / "=" / "#" / "?" / "/" / "." / "$" / "*" / ";" / "@" / "[" / "]" / "^" / "`" / "{" / "}" / "~" quotedString = DQUOTE visibleString 0*(quoteEscape visibleString) DQUOTE quoteEscape = DQUOTE DQUOTE visibleString = (%x00-21 / %x23-FF) TerminationDescriptor = ;Undecided, could be SDP as in RFC 2327 Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 43] Internet draft MEGACO Protocol April 16, 1999 5.1. Termination Names Each command contains a unique Termination name. The following rules for construction and interpretation of the Termination names MUST be sup- ported: 1) The individual terms of the naming path MUST be separated by a sin- gle slash ("/", ASCII 2F hex). 2) The individual terms are character strings composed of letters, digits or other printable characters, with the exception of charac- ters used as delimiters ("/", "@"), characters used for wildcarding ("*", "$") and white spaces. 3) Wild-carding is represented either by an asterisk ("*") or a dollar sign ("$") for the terms of the naming path which are to be wild- carded. Thus, if the full naming path looks like term1/term2/term3 then the Termination name looks like this depending on which terms are wild- carded: */term2/term3 if term1 is wild-carded term1/*/term3 if term2 is wild-carded term1/term2/* if term3 is wild-carded term1/*/* if term2 and term3 are wild-carded, etc. In each of these examples a dollar sign could have appeared instead of an asterisk. 4) A term represented by an asterisk is to be interpreted as: "use ALL values of this term known within the scope of the Media Gateway". A term represented by a dollar sign is to be interpreted as: "use ANY ONE value of this term known within the scope of the Media Gateway". The description of a specific command may add further criteria for selection within the general rules given here. Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 44] Internet draft MEGACO Protocol April 16, 1999 Examples of TerminationId: /MG7.network.com/com1/channel1 ; fully qualified Termination name ; one channel on device "com1" ; channels on device "com1" ; all devices on MG ; on all devices on MG When an Ephemeral Termination is to be created, the desired termination type is specified as the first component of the name with "/$" con- catenated on the name. For example, "RTP/$" would request a new Termi- nation from the RTP Termination Class. 5.2. Events, Signals and Packages Event names are case insensitive and are composed of two logical parts, a Package name and an Event name. Both names are strings of letters, hyphens and digits, with the restriction that hyphens shall never be the first or last characters in a name. Package or Event names are not case sensitive - values such as "hu", "Hu", "HU" or "hU" should be considered equal. In textual representations, the Package name, when present, is separated from the Event name by a slash ("/"). The Package name is in fact optional. Each termination-type has a default Package associated with it, and if the Package name is excluded from the Event name, the default Package name for that termination-type is assumed. For example, for an analog access line, the following two Event names are equal: l/dl dial-tone in the line Package for an analog access line. dl dial-tone in the line Package (default) for an analog access line. This document defines a basic set of Package names and Event names. Additional Package names and Event names can be registered with the IANA. A Package definition shall define the name of the Package, and the definition of each Event belonging to the Package. The Event definition shall include the precise name of the Event (i.e., the code used in the MEGACO protocol), a plain text definition of the Event, and, went appropriate, the precise definition of the corresponding signals, for example the exact frequencies of audio signal such as dial tones or DTMF Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 45] Internet draft MEGACO Protocol April 16, 1999 tones. In addition, implementers can gain experience by using experimental Packages. The names of experimental Packages must start with the two characters "x-"; the IANA shall not register Package names that start with these characters. Digits, or letters, are supported in many Packages, notably "DTMF", "MF" and "pulse". Digits and letters are defined by the rules "Digit" and "Letter" in the definition of digit maps. This definition refers to the digits (0 to 9), to the asterisk or star ("*") and orthotrope, number or pound sign ("#"), and to the letters "A", "B", "C" and "D", as well as the timer indication "T". These letters can be combined in "digit string" that represent the keys that a user punched on a dial. In addi- tion, the letter "X" can be used to represent all digits, and the sign "$" can be used in wildcard notations. The need to easily express the digit strings has a consequence on the form of Event names: An Event name that does not denote a digit should always contain at least one character that is neither a digit, nor one of the letters A, B, C, D, T or X. (Such names should not contain the special signs "*", "#", "/" or "$".) An MGC may often have to ask a MG to detect a group of Events. Two con- ventions can be used to denote such groups: * The wildcard convention can be used to detect any Event belonging to a Package, or a given Event in many Packages, or Event any Event in any Package supported by the MG. * The regular expression Range notation can be used to detect a range of digits. The star sign (*) can be used as a wildcard instead of a Package name, and the dollar sign ("$") or the keyword "all" can be used as a wildcard instead of an Event name: A name such as "foo/all" denotes all Events in Package "foo" A name such as "*/bar" denotes the Event "bar" in any Package sup- ported by the MG The names "*" or "*/all" denote all Events supported by the MG. The MGC can ask an MG to detect a set of digits or letters either by individually describing those letters, or by using the "range" notation defined in the syntax of digit strings. For example, the MGC can: Use the letter "x" to denote "any letter or digit." Use the notation "[0-9#]" to denote the digits 0 to 9 and the pound Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 46] Internet draft MEGACO Protocol April 16, 1999 sign. Events and Signals are described in Packages. The Package description must provide, for each Event, the following information: * The description of the Event and its purpose, which should mean the actual Signal that is generated by the client (i.e., xx ms FSK tone) as well as the resulting user observed result (i.e., MW light on/off). * The detailed characteristics of the Event, such as for example fre- quencies and amplitude of audio signals, modulations and repeti- tions, * The typical and maximum duration of the Event. Package descriptions should describe, for all Signals, their type (OO, TO, BR). They should also describe the maximum duration of the TO Sig- nals. 5.3. Digit Maps A digit map is expressed using a syntax derived from the Unix system command, egrep. For example, the dial plan described above in section 2 results in the following digit map: (0T| 00T|[1-7]xxx|8xxxxxxx|#xxxxxxx|*xx|91xxxxxxxxxx|9011x.T) The "DigitMapValue" rule of protocol syntax describes a format that con- tains three parameters: * An optional notation of a "Long Timer," in seconds, * An optional notation of a "Medium Timer," in seconds, * The actual expression of the map. The timer parameters are optional. When they are not specified, default values are assumed. Suggested default values are 16 seconds for the long timer, 8 seconds for the medium timer. 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. Each element in the string is composed of a set of string elements, each of which can optionally be followed by a repetition char- acter. The possible elements are: Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 47] Internet draft MEGACO Protocol April 16, 1999 * A digit, * The special characters "#" and "*" (number sign and star sign), * The letters A, B, C or D, * The symbols "K0", "K1", "K2", "S0", "S1", "S2" and "S3", which may be used in MF signalling, * A range notation such as "[0-9]" or "[0-9*#]", that would be matched by a single occurence of any letter in the range, * The character "x", that would be matched by any digit between 0 and 9. Each element may be followed by the repetition symbol "." (dot), to denote a variable number of occurences of the position. A MG that detects digits, letters or timers must: 1) Add the Event parameter code as a token to the end of an internal state variable called the "current dial string" 2) Apply the current dial string to the digit map table, attempting a match to each regular expression in the Digit Map in lexical order 3) If the result is under-qualified (partially matches at least one entry in the digit map), do nothing further. If the result matches, or is over-qualified (i.e. no further digits could possibly produce a match), notify the currently accumulated Events to the MGC, in the order in which they occurred. When an MG is unable to store a digit map, it shall return an error to the MGC. 5.4. Statistics The MG may maintain statistics that describe the status of the Termina- tion. The precise properties of the statistics depends on the Class of the Termination. In the RTP Class, the some the properties are: Number of packets sent: The total number of RTP data packets transmitted by the sender since starting transmission on this connection. The count is not reset if the sender changes its synchronization source identifier Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 48] Internet draft MEGACO Protocol April 16, 1999 (SSRC, as defined in RTP), for example as a result of a Modify com- mand. The value is zero if the connection was set in "receive only" mode. Number of octets sent: The total number of payload octets (i.e., not including header or padding) transmitted in RTP data packets by the sender since start- ing transmission on this connection. The count is not reset if the sender changes its SSRC identifier, for example as a result of a Modify command. The value is zero if the connection was set in "receive only" mode. Number of packets received: The total number of RTP data packets received by the sender since starting reception on this connection. The count includes packets received from different SSRC, if the sender used several values. The value is zero if the connection was set in "send only" mode. Number of octets received: The total number of payload octets (i.e., not including header or padding) transmitted in RTP data packets by the sender since start- ing transmission on this connection. The count includes packets received from different SSRC, if the sender used several values. The value is zero if the connection was set in "send only" mode. Number of packets lost: The total number of RTP data packets that have been lost since the creation of the RTP connection. This number is defined to be the number of packets expected less the number of packets actually received, where the number of packets received includes any which are late or duplicates. The count includes packets received from different SSRC, if the sender used several values. Thus packets that arrive late are not counted as lost, and the loss may be nega- tive if there are duplicates. The count includes packets received from different SSRC, if the sender used several values. The number of packets expected is defined to be the extended last sequence number received, as defined next, less the initial sequence number received. The count includes packets received from different SSRC, if the sender used several values. The value is zero if the connec- tion was set in "send only" mode. This property is omitted if the connection was set in "data" mode. Interarrival jitter: An estimate of the statistical variance of the RTP data packet interarrival time measured in milliseconds and expressed as an unsigned integer. The interarrival jitter J is defined to be the mean deviation (smoothed absolute value) of the difference D in packet spacing at the receiver compared to the sender for a pair of Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 49] Internet draft MEGACO Protocol April 16, 1999 packets. Detailed computation algorithms are found in RFC 1889. The count includes packets received from different SSRC, if the sender used several values. The value is zero if the connection was set in "send only" mode. This property is omitted if the connection was set in "data" mode. Average transmission delay: An estimate of the network latency, expressed in milliseconds. This is the average value of the difference between the NTP timestamp indicated by the senders of the RTCP messages and the NTP timestamp of the receivers, measured when this messages are received. The average is obtained by summing all the estimates, then dividing by the number of RTCP messages that have been received. This property is omitted if the connection was set in "data" mode. When the MG's clock is not synchronized by NTP, the latency value can be computed as one half of the round trip delay, as measured through RTCP. When the MG cannot compute the one way delay or the round trip delay, the property conveys a null value. For a detailed definition of these variables, refer to RFC 1889. When the connection was set up over an ATM network, the meaning of these properties may change: Number of packets sent: The total number of ATM cells transmitted since starting transmis- sion on this connection. Number of octets sent: The total number of payload octets transmitted in ATM cells. Number of packets received: The total number of ATM cells received since starting reception on this connection. Number of octets received: The total number of payload octets received in ATM cells. Number of packets lost: Should be determined as the number of cells lost, or set to zero if the adaptation layer does not enable the MG to assess losses. Interarrival jitter: Should be understood as the interarrival jitter between ATM cells. Average transmission delay: The MG may not be able to assess this property over an ATM network. Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 50] Internet draft MEGACO Protocol April 16, 1999 It could simply report a null value. When the Termination is of type TDM or analog, the meaning of these pro- perties is defined as follow: Number of packets sent: Not significant. Number of octets sent: The total number of payload octets transmitted over the local con- nection. Number of packets received: Not significant. Number of octets received: The total number of payload octets received over the connection. Number of packets lost: Not significant. A value of zero is assumed. Interarrival jitter: Not significant. A value of zero is assumed. Average transmission delay: Not significant. A value of zero is assumed. 5.5. Examples The following examples use, for practical reasons, a text representation of the MEGACO protocol. This representation assumes the following token definitions: __________________________________________________ | TRAN | transToken | | ACPT | acceptToken | | MEGACO | megacopToken | | CTX | ctxToken | | ADD | addToken | | SUBTRACT| subtractToken | | MODIFY | modifyToken | | TS | TSToken (TerminationState) | | LT | LTToken (LocalTerminationDescriptor) | | RT | RTToken (RemoteTerminationDescriptor)| |_________|_______________________________________| Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 51] Internet draft MEGACO Protocol April 16, 1999 5.5.1. Example Add transaction: TRAN 12345678 MGC1.network.com:12345 MEGACOP 1.0 CTX= -1 ADD= circuitgroup1/5 LS= {m=recvonly } ADD= RTP/ANY LS= {m=sendrecv } LT= {v=0 c=IN IP4 100.100.100.089 m=audio ANY RTP/AVP 0 } RT= {v=0 c=IN IP4 200.200.200.133 m=audio 4321 RTP/AVP 0 } 5.5.2. Example response to Add transaction: ACPT 12345678 MG1.network.com:12345 MEGACOP 1.0 CTX= 12344321 ADD= circuitgroup1/5 ADD= RTP/7777 LT= {v=0 c=IN IP4 100.100.100.089 m=audio 3456 RTP/AVP 0 } 5.5.3. Example Modify transaction: TRAN 12345672 MGC1.network.com:12345 MEGACOP 1.0 CTX= 12344321 MODIFY= circuitgroup1/5 LS= {m=sendrecv } 5.5.4. Example Subtract transaction: TRAN 12345673 MGC1.network.com:12345 MEGACOP 1.0 CTX= 12344321 SUBTRACT= circuitgroup1/5 SUBTRACT= RTP/7777 Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 52] Internet draft MEGACO Protocol April 16, 1999 5.6. Transaction Response Codes All MegacoP transactions return a transaction response code which ack- nowledges the command(s) sent and returns a code indicating the success or failure of the command. The transaction response code is an integer number, the first digit of which indicates the class of the Response Code. 2xx: Success -- the transaction was successfully received, understood, and all commands were executed; 4xx: Protocol reject -- the transaction received could not be understood; 5xx: Execution reject -- the transaction received could not be executed; MEGACOP Transaction Response Codes are extensible. MEGACOP applica- tions are not required to understand the meaning of all registered response codes, though such understanding is obviously desirable. How- ever, applications MUST understand the class of any response code, as indicated by the first digit, and treat any unrecognized response code as being equivalent to the x00 response code of that class. 5.6.1. Transaction Response Success Codes Success = "200" ; The requested transaction was executed nor- mally 5.6.2. Transaction Response Reject Codes Protocol-Reject = "400" ; Bad Request Protocol-Reject = "400" ; Bad Request / "401" ; Unauthorized / "411" ; Length Required / "415" ; Incorrect identifier / "416" ; The transaction refers to an unknown ContextId / "418" ; Unsupported or unknown Package / "422" ; No such Event or signal / "423" ; Unknown action or illegal combination of actions / "425" ; Unknown TerminationID / "427" ; Missing RemoteTerminationDescriptor / "484" ; Action Incomplete / "485" ; Action Ambiguous Execution-Reject = "500" ; Internal Gateway Error / "501" ; Not Implemented / "502" ; Not ready. Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 53] Internet draft MEGACO Protocol April 16, 1999 / "503" ; Service Unavailable / "504" ; Gateway Time-out / "505" ; MEGACOP Version not supported / "509" ; Resource Conflict / "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 / "519" ; Gateway does not have a digit map / "520" ; Termination is "ServiceChangeing" / "526" ; Insufficient bandwidth / "581" ; Does Not Exist 6. Transport The transport mechanism for MEGACOP has not been chosen. It is likely that TCP will be an option. If the SIGTRAN transport mechanism is suit- able for MEGACO, that may be specified. It may be necessary to specify a transport protocol in this specification. Either the SIGTRAN mechan- ism or a MEGACO specified mechanism will be optional on the MG and required on the MGC. 6.1. Transport capabilities, and relationship to Transport Layer Requirements for transport of the MEGACO protocol include: 1) Reliable delivery of commands/responses. 2) Ordered delivery of commands/responses to a particular "control stream", this implies ordered delivery of commands to/from a par- ticular Termination or Context, but not necessarily ordered across Terminations or Contexts. 3) Limited maximum time to deliver commands. 4) Rapid detection of failure in a control stream. 5) Ability to achieve very high fanout from MGC to MGs. 6) Ability to handle multiple MGCs controlling individual MGs in a distributed system and vice versa. However this must be optional so that smaller/simpler systems can be efficiently implemented. 7) Ability for the application to initiate flushing of messages Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 54] Internet draft MEGACO Protocol April 16, 1999 successfully sent through the transport, for example to back off for failover handling. Since transport needs are the same in all application states and independent of what particular commands are being sent, it is logical to think of the reliable transport as a separate layer, as shown below. However, there is no accepted IETF protocol which focuses on the needs of real time control as is needed by the MEGACO protocol. Therefore, the mechanisms to provide the required characteristics of the reliable tran- sport should be directly included in the MEGACO protocol layer. However, It might be desirable to standardize the transport interface (marked in the figure by - . - . - ). This is discussed in section [4.z.z]. MEGACO Protocol layer: Gateway control | Termination-related signalling - . - . - . - . - . - . - . - . - . - . - . - . - Reliable transport ------------------------------------------------- UDP ------------------------------------------------- IP ------------------------------------------------- Ethernet, ATM, SONET, ... Any message goes between one MG and one MGC. This has implications on MG or MGC "farms". 7. Event Packages and Termination Classes Termination Classes are defined by: * A plain text description of the purpose of the Termination Class, * An SDP profile describing which SDP attributes are used in the the Local and Remote Termination descriptors, * A default value for the Local and Remote Termination descriptions, * The definition of statistics that can be collected on the Termina- tion, * A list of Events and Signals that are defined for the Termination, The Events and Signals are grouped in "Event Packages", some of which may apply to different Termination Classes. The list of Events and Sig- nals applicable for a Termination Class must thus be defined by the list of applicable Event Packages. Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 55] Internet draft MEGACO Protocol April 16, 1999 In this section, we will describe the most common Event Packages, and then the most common Termination Classes. More Packages and Classes can be defined in additional documents. 7.1. Basic Event Packages The list of basic Event Packages includes the following: _________________________________________ | Package | name | |______________________________|_________| | Generic Media Package | G | | DTMF Package | D | | MF Package | M | | Trunk Package | T | | Line Package | L | | Handset Package | H | | RTP Package | R | | Network Access Server Package| N | | Announcement Server Package | A | | Script Package | Script| |______________________________|_________| In the tables of Events for each Package, there are five columns: Symbol: the unique symbol used for the Event Definition: a short description of the Event R: an x appears in this column is the Event can be Requested by the call agent. S: if nothing appears in this column for an Event, then the Event cannot be signaled on command by the call agent. Otherwise, the following symbols identify the type of Event: OO On/Off Signal. The Signal is turned on until commanded by the call agent to turn it off, and vice versa. TO Timeout Signal. The Signal lasts for a given duration unless it is superseded by a new Signal. BR Brief Signal. The Event has a short, known duration. Duration: specifies the duration of TO Signals. 7.1.1. Generic Media Event Package Package Name: G Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 56] Internet draft MEGACO Protocol April 16, 1999 The generic media Package group the Events and Signals that can be observed on several types of Terminations, such as trunking gateways, access gateways or residential gateways. ______________________________________________________________________ | Symbol | Definition | R | S Duration | |__________|_____________________________|_____|______________________| | mt | Modem detected | x | | | fn | CalliNg Fax tone detected | x | | | fd | CalleD Fax tone detected | x | | | ld | Long duration connection | x | | | pat(###) | Pattern ### detected | x | OO | | rt | Ringback tone | | TO | | rbk(###) | ring back on connection | | TO 180 seconds | | cf | Confirm tone | | BR | | cg | Network Congestion tone | | TO | | it | Intercept tone | | OO | | pt | Preemption tone | | OO | | of | report failure | x | | |__________|_____________________________|_____|______________________| The Signals are defined as follow: The pattern definition can be used for specific algorithms such as answering machine detection, tone detection, and the like. Ring back tone (rt) an Audible Ring Tone, a combination of two AC tones with frequen- cies of 440 and 480 Hertz and levels of -19 dBm each, to give a combined level of -16 dBm. The cadence for Audible Ring Tone is 2 seconds on followed by 4 seconds off. See GR- 506-CORE - LSSGR: SIGNALING, Section 17.2.5. Ring back on connection A ring back tone, applied to the connection whose identifier is passed as a property. The "long duration connection" is detected when a connection has been established for more than 1 hour. 7.1.2. DTMF Event Package Package name: D Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 57] Internet draft MEGACO Protocol April 16, 1999 _______________________________________________________________ | Symbol | Definition | R | S Duration | |________|___________________________|_____|___________________| | 0 | DTMF 0 | x | BR | | 1 | DTMF 1 | x | BR | | 2 | DTMF 2 | x | BR | | 3 | DTMF 3 | x | BR | | 4 | DTMF 4 | x | BR | | 5 | DTMF 5 | x | BR | | 6 | DTMF 6 | x | BR | | 7 | DTMF 7 | x | BR | | 8 | DTMF 8 | x | BR | | 9 | DTMF 9 | x | BR | | # | DTMF # | x | BR | | * | DTMF * | x | BR | | A | DTMF A | x | BR | | B | DTMF B | x | BR | | C | DTMF C | x | BR | | D | DTMF D | x | BR | | L | long duration indicator | x | 2 seconds| | X | Wildcard, match | x | | | | any digit 0-9 | | | | T | Interdigit timer | x | 4 seconds| | of | report failure | x | | |________|___________________________|_____|___________________| The "interdigit timer" occurs when a long delay is observed after the end of a digit detection. The Event can only be observed if the Termi- nation is trying to acquire digits. Note that the definition of this timer requires further study. In fact, the timer should take two dif- ferent values, depending of the digit map and the digit string: - If the gateway can determine that at least one more digit is requested for the digit string to match any of the allowed patterns in the digit map, then the timer value should be set to a long duration, such as 16 seconds. - If the digit map specifies that a variable number of additional digits may be needed (the "." indication at the end of a string), then the timer value should be set to a medium duration, such as 8 seconds. - In some rare cases, such as optional additional digits, the timer should be set to a short duration, 4 seconds. The current digit map syntax does not allow for a distinction between the "medium" and "short" timer conditions, which implies that, in the current version, there is no way to request a short timer. Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 58] Internet draft MEGACO Protocol April 16, 1999 The "long duration indicator" is observed when a DTMF signal is produced for a duration larger than two seconds. In this case, the gateway will detect two successive Events: first, when the Signal has been recog- nized, the DTMF signal, and then, 2 seconds later, the long duration signal. Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 59] Internet draft MEGACO Protocol April 16, 1999 7.1.3. MF Event Package Package Name: M ________________________________________________________ | Symbol | Definition | R | S Duration | |________|____________________|_____|___________________| | 0 | MF 0 | x | BR | | 1 | MF 1 | x | BR | | 2 | MF 2 | x | BR | | 3 | MF 3 | x | BR | | 4 | MF 4 | x | BR | | 5 | MF 5 | x | BR | | 6 | MF 6 | x | BR | | 7 | MF 7 | x | BR | | 8 | MF 8 | x | BR | | 9 | MF 9 | x | BR | | X | Wildcard, match | x | | | | any digit 0-9 | | | | T | Interdigit timer | x | 4 seconds| | K0 | MF K0 or KP | x | BR | | K1 | MF K1 | x | BR | | K2 | MF K2 | x | BR | | S0 | MF S0 or ST | x | BR | | S1 | MF S1 | x | BR | | S2 | MF S2 | x | BR | | S3 | MF S3 | x | BR | | wk | Wink | x | BR | | wko | Wink off | x | BR | | is | Incoming seizure | x | OO | | rs | Return seizure | x | OO | | us | Unseize circuit | x | OO | | of | report failure | x | | |________|____________________|_____|___________________| The definition of the MF Package Events is as follow: Wink A transition from unseized to seized to unseized trunk states within a specified period. Typical seizure period is 100-350 msec.) Incoming seizure Incoming indication of call attempt. Return seizure: Seizure in response to outgoing seizure. Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 60] Internet draft MEGACO Protocol April 16, 1999 Unseize circuit: Unseizure of a circuit at the end of a call. Wink off: A Signal used in operator services trunks. A transition from seized to unseized to seized trunk states within a specified period of 100-350 ms. (To be checked) 7.1.4. Trunk Event Package Package Name: T _____________________________________________________________________ | Symbol | Definition | R | S Duration | |________|________________________________|_____|____________________| | co1 | Continuity tone (single tone,| x | OO | | | or return tone) | | | | co2 | Continuity test (go tone, | x | OO | | | in dual tone procedures) | | | | lb | Loopback | | OO | | om | Old Milliwatt Tone (1000 Hz) | x | OO | | nm | New Milliwatt Tone (1004 Hz) | x | OO | | tl | Test Line | x | OO | | zz | No circuit | x | OO | | as | Answer Supervision | x | OO | | ro | Reorder Tone | x | TO 30 seconds| | of | report failure | x | | |________|________________________________|_____|____________________| The definition of the trunk Package Signal Events is as follow: Continuity Tone (co1): A tone at 2010 + or - 30 Hz. Continuity Test (co2): A tone at the 1780 + or - 30 Hz. Milliwatt Tones: Old Milliwatt Tone (1000 Hz), New Milliwatt Tone (1004 Hz) Line Test: 105 Test Line test progress tone (2225 Hz + or - 25 Hz at -10 dBm0 + or -- 0.5dB). No circuit: (that annoying tri-tone, low to high) Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 61] Internet draft MEGACO Protocol April 16, 1999 Answer Supervision: Reorder Tone: Reorder tone is a combination of two AC tones with frequencies of 480 and 620 Hertz and levels of -24 dBm each, to give a combined level of -21 dBm. The cadence for Station Busy Tone is 0.25 seconds on followed by 0.25 seconds off, repeating continuously. See GR-506-CORE - LSSGR: SIGNALING, Section 17.2.7. The continuity tones are used when the call agent wants to initiate a continuity test. There are two types of tests, single tone and dual tone. The Call agent is expected to know, through provisioning informa- tion, which test should be applied to a given Termination. For example, the controller that wants to initiate a single frequency test will send to the gateway a command of the form: RQNT 1234 epx-t1/17@tgw2.example.net X: AB123FE0 S: co1 R: co1 If it wanted instead to initiate a dual-tone test, it would send the command: RQNT 1234 epx-t1/17@tgw2.example.net X: AB123FE0 S: co2 R: co1 The gateway would send the requested signal, and in both cases would look for the return of the 2010 Hz tone (co1). When it detects that tone, it must send the corresponding notification. The tones are of type OO: the gateway must keep sending them until it receives a new notification request. 7.1.5. Line Event Package Package Name: L Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 62] Internet draft MEGACO Protocol April 16, 1999 __________________________________________________________________________ |Symbol | Definition | R | S Duration | |_____________|______________________________|_____|_____________________| |adsi(string) | adsi display | | BR | |vmwi | visual message | | TO | | | waiting indicator | | | |hd | Off hook transition | x | | |hu | On hook transition | x | | |hf | Flash hook | x | | |aw | Answer tone | x | OO | |bz | Busy tone | | TO 30 seconds | |ci(string) | Caller-id | | BR | |wt | Call Waiting tone | | TO 30 seconds | |dl | Dial tone | | TO 16 seconds | |mwi | Message waiting ind. | | TO 16 seconds | |nbz | Network busy | x | OO | | | (fast cycle busy) | | | |rg | Ringing | | TO 180 seconds| |r0, r1, r2, | Distinctive ringing | | TO 180 seconds| |r3, r4, r5, | | | | |r6 or r7 | | | | |rs | Ringsplash | | BR | |p | Prompt tone | x | BR | |e | Error tone | x | BR | |sdl | Stutter dialtone | | TO 16 seconds | |v | Alerting Tone | | OO | |y | Recorder Warning Tone | | OO | |sit | SIT tone | | | |z | Calling Card Service Tone | | OO | |oc | Report on completion | x | | |ot | Off hook warning tone | | TO indefinite | |s(###) | Distinctive tone pattern | x | BR | |of | report failure | x | | |_____________|______________________________|_____|_____________________| The definition of the tones is as follow: Dial tone: A combined 350 + 440 Hz tone. Visual Message Waiting Indicator The transmission of the VMWI messages must conform to the require- ments in Section 2.3.2, "On-hook Data Transmission Not Associated with Ringing" in TR-H- 000030 and the CPE guidelines in SR-TSV- 002476. VMWI messages must only be sent from the SPCS when the line is idle. If new messages arrive while the line is busy, the VMWI indicator message must be delayed until the line goes back to the Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 63] Internet draft MEGACO Protocol April 16, 1999 idle state. The CA should periodically refresh the CPE's visual indicator. See TR-NWT-001401 - Visual Message Waiting Indicator Generic Requirements; and GR- 30-CORE - Voiceband Data Transmission Interface. Message waiting Indicator See GR-506-CORE, 17.2.3. Alerting Tone: a 440 Hz Tone of 2 second duration followed by 1/2 second of tone every 10 seconds. Rig splash Ringsplash, also known as "Reminder ring" is a burst of ringing that may be applied to the physical forwarding line (when idle) to indicate that a call has been forwarded and to remind the user that a CF subfeature is active. In the US, it is defined to be a 0.5(- 0,+0.1) second burst of power ringing. See TR- TSY-000586 - Call Forwarding Subfeatures. Call waiting tone Call Waiting tone is defined in GR-506-CORE, 14.2. Call Waiting feature is defined in TR-TSY-000571. By defining "wt" as a TO Sig- nal you are really defining the feature which seems wrong to me (given the spirit of MGCP), hence the definition of "wt" as a BR Signal in ECS, per GR-506-CORE. Also, it turns out that there is actually four different call waiting tone patterns (see GR-506- CORE, 14.2) so we should really have wt1, wt2, wt3, wt4, or some parameterization. Recorder Warning Tone: 1400 Hz of Tone of 0.5 second duration every 15 seconds. SIT tone: used for indicating a line is out of service. Calling Card Service Tone: 60 ms of 941 + 1477 Hz and 940 ms of 350 + 440 Hz (dial tone), decaying exponentially with a time constant of 200 ms. Distinctive tone pattern: where ### is any number between 000 and 999, inclusive. Can be used for distinctive ringing, customized dial tone, etc. Report on completion The report on completion Event is detected when the gateway was asked to perform one or several Signals of type TO on the Termina- tion, and when these Signals were completed without being stopped Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 64] Internet draft MEGACO Protocol April 16, 1999 by the detection of a requested Event such as off-hook transition or dialed digit. The completion report may carry as property the name of the Signal that came to the end of its live time, as in: O: L/oc(L/dl) Ring back on connection A ring back tone, applied to the connection whose identifier is passed as a property. We should note that many of these definitions vary from country to coun- try. The frequencies listed above are the one in use in North America. There is a need to accommodate different tone sets in different coun- tries, and there is still an ongoing debate on the best way to meet that requirement: * One solution is to define different Event Packages specifying for example the German dial-tone as "L-DE/DL". * Another solution is to use a management interface to specify on an end-point basis which frequency shall be associated to what tone. Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 65] Internet draft MEGACO Protocol April 16, 1999 7.1.6. Handset emulation Event Package Package Name: H __________________________________________________________________________ |Symbol | Definition | R | S Duration | |_____________|______________________________|_____|_____________________| |adsi(string) | adsi display | x | BR | |tdd | | | | |vmwi | | | | |hd | Off hook transition | x | OO | |hu | On hook transition | x | OO | |hf | Flash hook | x | BR | |aw | Answer tone | x | OO | |bz | Busy tone | x | OO | |wt | Call Waiting tone | x | TO 30 seconds | |dl | Dial tone (350 + 440 Hz) | x | TO 120 seconds| |nbz | Network busy | x | OO | | | (fast cycle busy) | | | |rg | Ringing | x | TO 30 seconds | |r0, r1, r2, | Distinctive ringing | x | TO 30 seconds | |r3, r4, r5, | | | | |r6 or r7 | | | | |p | Prompt tone | x | BR | |e | Error tone | x | BR | |sdl | Stutter dialtone | x | TO 16 seconds | |v | Alerting Tone | x | OO | |y | Recorder Warning Tone | x | OO | |t | SIT tone | x | | |z | Calling Card Service Tone | x | OO | |oc | Report on completion | x | | |ot | Off hook warning tone | x | OO | |s(###) | Distinctive tone pattern | x | BR | |of | report failure | x | | |_____________|______________________________|_____|_____________________| The handset emulation Package is an extension of the line Package, to be used when the gateway is capable of emulating a handset. The difference with the line Package is that Events such as "off hook" can be signalled as well as detected. Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 66] Internet draft MEGACO Protocol April 16, 1999 7.1.7. RTP Event Package Package Name: R _________________________________________________________________ | Symbol | Definition | R | S Duration| |_________|______________________________|_____|_________________| | UC | Used codec changed | x | | | SR(###) | Sampling rate changed | x | | | JI(###) | Jitter buffer size changed | x | | | PL(###) | Packet loss exceeded | x | | | qa | Quality alert | x | | | of | report failure | x | | |_________|______________________________|_____|_________________| Codec Changed: Codec changed to hexadecimal codec number enclosed in parenthesis, as in UC(15), to indicate the codec was changed to PCM mu-law. Codec Numbers are specified in RFC 1890, or in a new definition of the audio profiles for RTP that replaces this RFC. Some implemen- tations of media gateways may not allow the codec to be changed upon command from the call agent. codec changed to codec hexade- cimal ##. Sampling Rate Changed: Sampling rate changed to decimal number in milliseconds enclosed in parenthesis, as in SR(20), to indicate the sampling rate was changed to 20 milliseconds. Some implementations of media gateways may not allow the sampling rate to be changed upon command from a call agent. Jitter Buffer Size Changed: When the media gateway has the ability to automatically adjust the depth of the jitter buffer for received RTP streams, it is useful for the media gateway controller to receive notification that the media gateway has automatically increased its jitter buffer size to accommodate increased or decreased variability in network latency. The syntax for requesting notification is "JI", which tells the media gateway that the controller wants notification of any jitter buffer size changes. The syntax for notification from the media gateway to the controller is "JI(####)", where the #### is the new size of the jitter buffer, in milliseconds. Packet Loss Exceeded: Packet loss rate exceed the threshold of the specified decimal number of packets per 100,000 packets, where the packet loss number is contained in parenthesis. For example, PL(10) indicates packets Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 67] Internet draft MEGACO Protocol April 16, 1999 are being dropped at a rate of 1 in 10,000 packets. Quality alert The packet loss rate or the combination of delay and jitter exceed a specified quality threshold. 7.1.8. Network Access Server Event Package Package Name: N ____________________________________________________________ | Symbol | Definition | R | S Duration| |________|__________________________|_____|_________________| | pa | Packet arrival | x | | | cbk | Call back request | x | | | cl | Carrier lost | x | | | au | Authorization succeeded| x | | | ax | Authorization denied | x | | | of | Report failure | x | | |________|__________________________|_____|_________________| The packet arrival Event is used to notify that at least one packet was recently sent to an Internet address that is observed by an Termination. The Event report includes the Internet address, in standard ASCII encod- ing, between parenthesis: O: pa(192.96.41.1) The call back Event is used to notify that a call back has been requested during the initial phase of a data connection. The Event report includes the identification of the user that should be called back, between parenthesis: O: cbk(user25) Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 68] Internet draft MEGACO Protocol April 16, 1999 7.1.9. Announcement Server Event Package Package Name: A ___________________________________________________________________ | Symbol | Definition | R | S Duration| |________________|________________________|_____|__________________| | ann(url,parms) | Play an announcement | | TO variable| | oc | Report on completion | x | | | of | Report failure | x | | |________________|________________________|_____|__________________| The announcement action is qualified by an URL name and by a set of ini- tial properties as in for example: S: ann(http://scripts.example.net/all-lines-busy.au) The "operation complete" Event must be detected when the announcement is played out. If the announcement cannot be played out, an operation failure Event can be returned. The failure may be explained by a com- mentary, as in: O: A/of(file not found) Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 69] Internet draft MEGACO Protocol April 16, 1999 7.1.10. Script Event Package Package Name: Script ______________________________________________________________ | Symbol | Definition | R | S | Duration| |___________|________________________|_____|______|___________| | java(url) | Load a java script | | TO | variable| | perl(url) | Load a perl script | | TO | variable| | tcl(url) | Load a TCL script | | TO | variable| | xml(url) | Load an XML script | | TO | variable| | oc | Report on completion | x | | | | of | Report failure | x | | | |___________|________________________|_____|______|___________| The "language" action define is qualified by an URL name and by a set of initial properties as in for example: S: script/java(http://scripts.example.net/credit-card.java,long,1234) The current definition defines keywords for the most common languages. More languages may be defined in further version of this documents. For each language, an API specification must describe how the scripts can issue local "notificationRequest" commands, and receive the correspond- ing notifications. The script produces an output which consists of one or several text string, separated by commas. The text string are reported as a commen- tary in the report on completion, as in for example: O: script/oc(21223456794567,9738234567) The failure report may also return a string, as in: O: script/oc(21223456794567,9738234567) The definition of the script environment and the specific actions in that environment are for further study. Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 70] Internet draft MEGACO Protocol April 16, 1999 7.2. Basic Termination Classes We define the following basic Termination types and profiles: * DS0 Termination, * Analog Termination, * RTP Termination, * ATM Termination, * Network Access Termination. Editors' note: These are only the most basic Termination types. There is an obvious need to also define digital multiplexes (T1, E1, T3, E3) and the Events that they support. 7.2.1. DS0 Terminations DS0 Terminations are digital circuits, providing a 64kbits (8bit times 8 KHz) service. Such Terminations are commonly used for interoffice trunks. DS0 Terminations are always described in a symmetric fashion. The RemoteTerminationDescriptor parameter is never used. The LocalTerminationDescriptor may be used to specify the encoding of the media. This parameter is described using SDP, with the following conventions: * The connection data line is not used. A placeholder (c=LOCAL) can be used if this is required for compliance with the SDP syntax. * The "m=audio" property must specify a port number, which must always be set to 0, the type of protocol, always set to the keyword DS0, and the type of encoding, using the same conventions used for RTP (RTP payload numbers.) The type of encoding should normally be set to 0 (PCM, mu law) or to 8 (PCM, A law). * The "a=echo" attribute must specify whether the gateway performs echo cancellation. The property can have two values, "a:echo:on" (when the echo cancellation is requested) and "a:echo:off" (when it is turned off.) * The gain control attribute, encoded as the keyword "gc", followed by a colon a value which can be either the keyword "auto" or a decimal number (positive or negative) representing the number of Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 71] Internet draft MEGACO Protocol April 16, 1999 decibels of gain. An example of specification could be: v=0 c=LOCAL m=audio 0 DS0 0 a=echo:on The default configuration option is to use the mu-law encoding, with gain control set to auto, and to apply echo cancellation. (We could define a variant of the DS0 Class which would, by default, use A-law encoding.) Gateways are expected to be able to collect the following statistics on Terminations of the DS0 Class: Number of octets sent, number of octets received The number of octet sent or received is equal to the duration of the Termination, in seconds, multiplied by the sampling frequency, 8000 Hz. Terminations of the DS0 Class are expected to provide the following sup- port for Event Packages: _______________________________________________________________________ |Package | name | support in DS0 Class | |______________________|__________|___________________________________| |Generic Media Package | G | Mandatory | |Trunk Package | T | Mandatory | |DTMF Package | D | Optional (for credit cards, etc)| |MF Package | M | Optional (for MF trunks) | |Announcement | A | Optional (when gateway | |Server Package | | can play announcement on DS0) | |Script Package | Script | Optional | |______________________|__________|___________________________________| 7.2.2. Analog Terminations Analog terminations are analog circuits, typically connected through an RJ11 interface. Such Terminations are commonly found in residential gateways. Analog Terminations are always described in a symmetric fashion. The RemoteTerminationDescriptor parameter is never used. Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 72] Internet draft MEGACO Protocol April 16, 1999 The LocalTerminationDescriptor may be used to specify the encoding of the media. This parameter is described using SDP, with the following conventions: * The connection data line is not used. A placeholder (c=LOCAL) can be used if this is required for compliance with the SDP syntax. * The "m=audio" property is only used for conformance with the SDP syntax. It is set to a conventional value, specifying a null port, an ANALOG type and a null type of encoding. * The "a=echo" attribute must specify whether the gateway performs echo cancellation. The property can have two values, "a:echo:on" (when the echo cancellation is requested) and "a:echo:off" (when it is turned off.) * The gain control attribute, encoded as the keyword "gc", followed by a colon a value which can be either the keyword "auto" or a decimal number (positive or negative) representing the number of decibels of gain. An example of specification could be: v=0 c=LOCAL m=audio 0 ANALOG 0 a=echo:on The default configuration option is to apply echo cancellation, and to have gain control set to auto. Gateways are expected to be able to collect the following statistics on Terminations of the analog Class: Number of octets sent, number of octets received The number of octet sent or received is equal to the duration of the Termination, in seconds, multiplied by the sampling frequency, 8000 Hz. Terminations of the analog Class are expected to provide the following support for Event Packages: Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 73] Internet draft MEGACO Protocol April 16, 1999 ____________________________________________________________________ | Package | name | support in analog Class | |_______________________|__________|________________________________| | Generic Media Package | G | Mandatory | | DTMF Package | D | Mandatory | | Line Package | L | Mandatory | | Handset Package | H | Optional (when gateway | | | | can set outgoing calls on | | | | the analog Termination) | | Announcement | A | Optional (when gateway | | Server Package | | can play announcements on the| | | | Termination) | | Script Package | Script | Optional | |_______________________|__________|________________________________| 7.2.3. RTP Audio Terminations RTP Terminations are use to describe the local Termination of packet connections established through the RTP, UDP and IP protocols. The RTP Audio Termination Class is applied when the RTP Terminations convey an audio media. (Other Termination Classes may be used for other media, such as video.) The encoding of the media in point to point RTP Terminations is described by two sets of properties, the LocalTerminationDescriptor and the RemoteTerminationDescriptor. Both are described using SDP, with the following conventions: * The IP address of the remote gateway (in commands) or of the local gateway (in responses), or multicast address of the audio confer- ence, encoded as an SDP "connection data" parameter. This parameter specifies the IP address that must be used to exchange RTP packets. * Media description field (m) specifying the audio media, the tran- sport port used for receiving RTP packets by the remote gateway (commands) or by the local gateway (responses) , the RTP/AVP tran- sport, and the list of formats that the gateway must accept. This list should normally always include the code 0 (reserved for G.711, mu law). * Optionally, RTPMAP attributes that define the encoding of dynamic audio formats, * Optionally, a packetization period (packet time) attribute (Ptime) defining the duration of the packet, * Optionally, an encryption key attribute ("k"), specifying the Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 74] Internet draft MEGACO Protocol April 16, 1999 encryption and the key for the RTP packets, as defined in SDP. * Optionally, an attribute defining the type of connection (sendonly, recvonly, sendrecv, inactive). Note that this attribute does not have a direct relation with the "Mode" property of the Termination. In fact, the SDP type of connection will most of the time be set to "sendrecv", regardless of the value used for the Termination. Other values will only be used rarely, for example in the case of information or announcement servers that need to establish one way connections. An example of specification could be: v=0 c=IN IP4 128.96.41.1 m=audio 3456 RTP/AVP 0 96 a=rtpmap:96 G726-32/8000 The default configuration for the LocalTerminationDescriptor is to use one of the IP addresses of the gateway, to select a UDP port for RTP, and to use the PCM mu-law algorithm. Gateways are expected to be able to collect the following statistics on Terminations of the RTP Class: Number of packets sent: The total number of RTP data packets transmitted by the sender since starting transmission on this connection. The count is not reset if the sender changes its synchronization source identifier (SSRC, as defined in RTP), for example as a result of a Modify com- mand. The value is zero if the connection was set in "receive only" mode. Number of octets sent: The total number of payload octets (i.e., not including header or padding) transmitted in RTP data packets by the sender since start- ing transmission on this connection. The count is not reset if the sender changes its SSRC identifier, for example as a result of a Modify command. The value is zero if the connection was set in "receive only" mode. Number of packets received: The total number of RTP data packets received by the sender since starting reception on this connection. The count includes packets received from different SSRC, if the sender used several values. The value is zero if the connection was set in "send only" mode. Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 75] Internet draft MEGACO Protocol April 16, 1999 Number of octets received: The total number of payload octets (i.e., not including header or padding) transmitted in RTP data packets by the sender since start- ing transmission on this connection. The count includes packets received from different SSRC, if the sender used several values. The value is zero if the connection was set in "send only" mode. Number of packets lost: The total number of RTP data packets that have been lost since the beginning of reception. This number is defined to be the number of packets expected less the number of packets actually received, where the number of packets received includes any which are late or duplicates. The count includes packets received from different SSRC, if the sender used several values. Thus packets that arrive late are not counted as lost, and the loss may be negative if there are duplicates. The count includes packets received from different SSRC, if the sender used several values. The number of packets expected is defined to be the extended last sequence number received, as defined next, less the initial sequence number received. The count includes packets received from different SSRC, if the sender used several values. The value is zero if the connec- tion was set in "send only" mode. This property is omitted if the connection was set in "data" mode. Interarrival jitter: An estimate of the statistical variance of the RTP data packet interarrival time measured in milliseconds and expressed as an unsigned integer. The interarrival jitter J is defined to be the mean deviation (smoothed absolute value) of the difference D in packet spacing at the receiver compared to the sender for a pair of packets. Detailed computation algorithms are found in RFC 1889. The count includes packets received from different SSRC, if the sender used several values. The value is zero if the connection was set in "send only" mode. This property is omitted if the connection was set in "data" mode. Average transmission delay: An estimate of the network latency, expressed in milliseconds. This is the average value of the difference between the NTP timestamp indicated by the senders of the RTCP messages and the NTP timestamp of the receivers, measured when this messages are received. The average is obtained by summing all the estimates, then dividing by the number of RTCP messages that have been received. This property is omitted if the connection was set in "data" mode. When the MG's clock is not synchronized by NTP, the latency value can be computed as one half of the round trip delay, as measured through RTCP. When the MG cannot compute the one way delay or the round trip Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 76] Internet draft MEGACO Protocol April 16, 1999 delay, the property conveys a null value. For a detailed definition of these variables, refer to RFC 1889. Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 77] Internet draft MEGACO Protocol April 16, 1999 Terminations of the RTP Class are expected to provide the following sup- port for Event Packages: _____________________________________________________________ | Package | name | support in RTP Class | |_______________________|__________|_________________________| | RTP Package | R | Mandatory | | Generic Media Package | G | Mandatory | | DTMF Package | D | Optional (e.g. in | | | | IVR units) | | Announcement | A | Optional (when gateway| | Server Package | | can play announcement | | | | on RTP) | | Script Package | Script | Optional | |_______________________|__________|_________________________| 7.2.4. ATM audio Terminations ATM Terminations are use to describe the local Termination of packet connections established over ATM networks. The RTP Audio Termination Class is applied when the RTP Terminations convey an audio media. (Other Termination Classes may be used for other media, such as video.) The encoding of the media in point to point RTP Terminations is described by two sets of properties, the LocalTerminationDescriptor and the RemoteTerminationDescriptor. Both are described using SDP, with the following conventions: * The "c=" property of SDP to specifies an address in the ATM family, the ATM addressing variant (NSAP, UNI, E.164) and the ATM address. * The "m=audio" property must specify the audio encoding and, if needed, the VPI and VCI. * Additional attributes properties (a=) will be used to specify the ATM coding variants, such as the type of adaptation layer and the error correction or loss compensation algorithms. An example of SDP payload for an ATM connection could be: v=0 c=ATM NSAP 47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.fe m=audio 5/1002 ATM/AVP G.711u a=connection_type:AAL2 The default configuration for the LocalTerminationDescriptor is to use Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 78] Internet draft MEGACO Protocol April 16, 1999 one of the ATM addresses of the gateway, to select a VPI and a VCI, and to use the PCM mu-law algorithm. Gateways are expected to be able to collect the following statistics on Terminations of the ATM Class: Number of packets sent: The total number of ATM cells transmitted since starting transmis- sion on this connection. Number of octets sent: The total number of payload octets transmitted in ATM cells. Number of packets received: The total number of ATM cells received since starting reception on this connection. Number of octets received: The total number of payload octets received in ATM cells. Number of packets lost: Should be determined as the number of cells lost, or set to zero if the adaptation layer does not enable the MG to assess losses. Interarrival jitter: The interarrival jitter between ATM cells. Average transmission delay: The MG may not be able to assess this property over an ATM network. It could simply report a null value. Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 79] Internet draft MEGACO Protocol April 16, 1999 Terminations of the ATM Class are expected to provide the following sup- port for Event Packages: _____________________________________________________________ | Package | name | support in ATM Class | |_______________________|__________|_________________________| | ATM Package | A | Mandatory | | Generic Media Package | G | Mandatory | | DTMF Package | D | Optional (e.g. in | | | | IVR units) | | Announcement | A | Optional (when gateway| | Server Package | | can play announcement | | | | on ATM) | | Script Package | Script | Optional | |_______________________|__________|_________________________| 7.2.5. Network access service Termination (Editor's note: this Package definition is really a place holder. It will most probably have to be extensively reworked by the WG.) A network access service (NAS) Termination describes the attachment of the Context to a network access service such as a generic Internet access or a tunnel to a private network server. The NAS Termination is described by a single LocalTerminationDescriptor parameter. The RemoteTerminationDescriptor parameter is not used. The LocalTerminationDescriptor is described using SDP with the following conventions: * Media description field (m) specifying the network access media, identified by the code "m=nas/xxxx", where "xxxx" describes the access control method that should be used for parameterizing the network access, as specified below. The field may also specify the port that should be used for contacting the server, as specified in the SDP syntax. * Connection address property (c=) specifying the address, or the domain name, of the server that implement the access control method. This property may also be specified at the session level. * Optionally, a bearer type attribute (a=bearer:) describing the type of data connection to be used, including the modem type. * Optionally, a framing type attribute (a=framing:) describing the type of framing that will be used on the channel. Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 80] Internet draft MEGACO Protocol April 16, 1999 * Optionally, attributes describing the called number (a=dialed:), the number to which the call was delivered (a=called:) and the cal- ling number (a=dialing:). * Optionally, attributes describing the range of addresses that could be used by the dialup client on its LAN (a=subnet:). * Optionally, an encryption key, encoded as specified in the SDP protocol(k=). The connection address shall be encoded as specified in the SDP stan- dard. It must be used in conjunction with the port specified in the media line to access a server, whose type must be one of: __________________________________________________________ | Method name| Method description | |____________|____________________________________________| | radius | Authentication according | | | to the Radius protocol. | | tacacs | Authentication according | | | to the TACACS+ protocol. | | diameter | Authentication according | | | to the Diameter protocol. | | l2tp | Level 2 tunneling protocol. | | | The address and port are those of the LNS.| | login | Local login. (There is normally | | | no server for that method.) | | none | No authentication required. | | | (The call was probably vetted | | | by the Call Agent.) | |____________|____________________________________________| If needed, the gateway may use the key specified in the announcement to access the service. That key, in particular, may be used for the estab- lishment of an L2TP tunnel. The bearer attribute is composed of a bearer name and an optional exten- sion. The bearer type specifies the type of modulation (modem name) or, in the case of digital connections, the type of ISDN service (8 bits, 7 bits). When an extension is present, it is separated from the bearer name by a single slash (/). The valid values of the bearer attribute are defined in the following table: Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 81] Internet draft MEGACO Protocol April 16, 1999 ____________________________________________________________________ | Type of bearer description | Example of values | |_________________________________|_________________________________| | ITU modem standard | V.32, V.34, V.90. | | ITU modem standard qualified | v.90/3com, | | by a manufacturer name | v.90/rockwell, | | | v.90/xxx | | Well known modem types | X2, K56flex | | ISDN transparent access, 64 kbps| ISDN64 | | ISDN64 + V.110 | ISDN64/V.110 | | ISDN64 + V.120 | ISDN64/V.120 | | ISDN transparent access, 56 kbps| ISDN56 | | Informal identification | (Requires coordination between | | | the Call Agent and the gateway)| |_________________________________|_________________________________| The valid values of the framing attribute are defined in the following table: _________________________________________________ | Type of framing description| Example of values| |____________________________|___________________| | PPP, asynchronous framing | ppp-asynch | | PPP, HDLC framing | ppp-hdlc | | SLIP, asynchronous | slip | | Asynchronous, no framing | asynch | |____________________________|___________________| The network access authentication property provides instructions on the access control that should be exercized for the data call. This optional attribute is encoded as: "a=subnet:"
"/" Where the properties "network type", "address type", and "connection address" are formatted as defined for the connection address property (c=) in SDP, and where the "prefix length" is a decimal representation of the number of bits in the prefix. Examples of SDP announcement for the network access service could be: v=0 m=nas/radius c=IN IP4 radius.example.net Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 82] Internet draft MEGACO Protocol April 16, 1999 a=bearer:v.34 a=framing:ppp-asynch a=dialed:18001234567 a=called:12345678901 a=dialing:12340567890 v=0 m=nas/none c=IN IP4 128.96.41.1 a=subnet:IN IP4 123.45.67.64/26 a=bearer:isdn64 a=framing:ppp-sync a=dialed:18001234567 a=dialing:2345678901 v=0 c=IN IP4 access.example.net m=nas/l2tp k=clear:some-shared-secret a=bearer:v.32 a=framing:ppp-asynch a=dialed:18001234567 a=dialing:2345678901 There is no default value of the properties defined for this Termination Class.(Editor's note: we may have to define more specific Classes, such as "Internet Access", for which the defaults would apply.) The following statistics can be collected on NAS Terminations: Number of packets sent: The total number of NAS packets transmitted since starting transmission on this connection. Number of octets sent: The total number of octets transmitted in NAS packets. Number of packets received: The total number of packets received since starting reception on this connection. Number of octets received: The total number of octets received in NAS packets. Terminations of the NAS Class are expected to provide the following sup- port for Event Packages: Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 83] Internet draft MEGACO Protocol April 16, 1999 ______________________________________________ | Package | name | support in NAS Class| |____________|________|_______________________| | NAS Package| N | Mandatory | |____________|________|_______________________| 8. Acknowledgements The authors would like to thank the fine crews of the numerous airlines that carried them around the world to a succession of interesting meet- ings, their family members whom they left alone during said meetings, their colleagues and their staff. We would also like to extend special thanks to the members of the MEGACO design team, Nancy-M Greene, Glen Freundlich, David Auerbach, Rex Col- dren, Dave Oran, Flemming Andreassen, Hong Liu, Michael Ramalho, Gur Kimchi, Graeme Gibbs, Brian Hill, Ike Elliott, Bob Bell, and Matt Hol- dredge. In fact, we would like to thank all the members of the MEGACO working group, and its chair, Tom Taylor. 9. References * Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996. * Schulzrinne, H., "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 1890, January 1996 * Handley, M, Jacobson, V., "SDP: Session Description Protocol", RFC 2327, April 1998. * Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, "Session Initiation Protocol (SIP)", RFC 2543, March 1999. * Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. * ITU-T, Recommendation Q.761, "FUNCTIONAL DESCRIPTION OF THE ISDN USER PART OF SIGNALLING SYSTEM No. 7", (Malaga-Torremolinos, 1984; modified at Helsinki, 1993) * ITU-T, Recommendation Q.762, "GENERAL FUNCTION OF MESSAGES AND SIG- NALS OF THE ISDN USER PART OF SIGNALLING SYSTEM No. 7", (Malaga- Torremolinos, 1984; modified at Helsinki, 1993) Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 84] Internet draft MEGACO Protocol April 16, 1999 * ITU-T, Recommendation H.323 (02/98), "PACKET-BASED MULTIMEDIA COM- MUNICATIONS SYSTEMS." * ITU-T, Recommendation H.225, "Call Signaling Protocols and Media Stream Packetization for Packet Based Multimedia Communications Systems." * ITU-T, Recommendation H.245 (02/98), "CONTROL PROTOCOL FOR MUL- TIMEDIA COMMUNICATION." * Atkinson, R., "Security Architecture for the Internet Protocol." RFC 2401, November 1998. * Atkinson, R., "IP Authentication Header." RFC 2402, December 1998. * Atkinson, R., "IP Encapsulating Security Payload (ESP)." RFC 2406, November 1998. * Crocker, D., P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. 10. Authors' Addresses Fernando Cuervo, Nortel Networks Ottawa, ON, Canada EMail: cuervo@nortelnetworks.com Christian Huitema Telcordia Technologies 445 South Street Morristown, NJ 07960 EMail: huitema@research.telcordia.com Keith Kelly NetSpeak Corporation 902 Clint Moore Road, Suite 104 Boca Raton, FL 33487 EMail: keith@netspeak.com Brian Rosen FORE Systems 1000 FORE Drive Warrendale, PA 15086 EMail: brosen@eng.fore.com Paul Sijben Lucent Technologies Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 85] Internet draft MEGACO Protocol April 16, 1999 PO box 18 1270 AA Huizen the Netherlands Phone: +31 35 687 4774 Email: sijben@lucent.com Eric Zimmerer Level3 Communications 1450 Infinite Drive Louisville, CO 80027 EMail: eric.zimmerer@level3.com Cuervo, Huitema, Kelly, Rosen, Sijben, Zimmerer [Page 86]