Internet Engineering Task Force Peter Blatherwick INTERNET DRAFT Fernando Cuervo Nancy Greene Category: Graeme Gibbs Expires: August 26, 1999 Nortel Networks A Proposal for a two-ended connection model for MGCP Fernando Cuervo, Graeme Gibbs, Nancy Greene February 26, 1999 Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working docu- ments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working docu- ments 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 list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract The connection model in MGCP grew from a half-connection model, to, more recently, a model that allows a second edgepoint to be specified [3]. In this document, we have taken the connection model a step further, making it symmetrical, identifying the difference between external connections and an MG- connection, allowing signalling related commands to be asso- ciated with either edgepoint, or with both edgepoints in an MG. While the half-connection model may work best for the simple case of MGs with an external IP connection on one side, the proposed more general connec- tion model adapts easily when the MG is for packet to packet connec- tions, when the MG is TDM on one side and IP on the other, as well as when the external connections are ATM on either side of an MG. Table of Contents Blatherwick, Cuervo, Greene, Gibbs [Page 1] Internet draft MEGACO Requirements 26 February 1999 1.0 Introduction 2.0 Two-ended connection model for MGCP 2.1 Edgepoints and Media Descriptors 3.0 Alias model 4.0 Transport capabilities of MGCP, and relationship to Transport Layer 5.0 Proposal for Way Forward 6.0 References 7.0 Authors' Addresses Appendix A A1.0 Proposed Commands A2.0 Call flow for Tom's Case 1: DTMF line dialing into VoIP Gateway A3.0 Call flow for a hairpin connection on an MG A4.0 Call flows with ATM as the backbone network A5.0 Mapping of the proposed commands to MGCP commands in [3] A6.0 Table comparing this proposal to [1] and [3] 1.0 Introduction The connection model in MGCP grew from a half-connection model, to, more recently, a half-connection model that allows a second edgepoint to be specified ([3], see appendix A in that draft). In this document, we have taken the connection model a step further, making it symmetrical, iden- tifying the difference between external connections and an MG- connection, allowing signalling related commands to be associated with either edgepoint, or with both edgepoints in an MG. While the half- connection model may work best for the simple case of MGs with an exter- nal IP connection on one side, the proposed more general connection model adapts easily when the MG is for packet to packet connections, when the MG is TDM on one side and IP on the other, as well as when the external connections are ATM on either side of an MG. The extended con- nection model retains support for the half-connection model in [3]. 2.0 Two-ended connection model for MGCP The two-ended connection model is used to join two Edgepoints. The ele- ments of the model are: * 1-an MGConnection, which explicitly establishes that two edgepoints in an MG are connected, * 2-the edgepoint MediaDescriptors and their corresponding External- ConnectionIds. These describe the media streams at the edgepoints. Blatherwick, Cuervo, Greene, Gibbs [Page 2] Internet draft MEGACO Requirements 26 February 1999 ExternalConnectionIds identify the assignment of a MediaDescriptor to an edgepoint, The ExternalConnectionId can only be modified when the edgepoint is reset. * 3-the CallId that is used to link edgepoints and their Medi- aDescriptors, ExternalConnectionIds and MGConnections. It is possi- ble to modify MediaDescriptors, remove or add edgepoints and MGCon- nections without changing the CallId. ingress MG egress MG +----+ +----+ E1ExternalConnId | | E2ExternalConnId | | +E1MediaDescriptor| | +E2MediaDescriptor | | | E1 E2 | | | V | | V | | ----------------o o - - - - - - - - -- o o------------ | | | | +----+ +----+ ^ | MG-ConnectionId (labels the internal connection between E1 & E2) Figure 1: Two ended MG-connection 2.1 Edgepoints and Media Descriptors Edgepoint: An edgepoint is identified locally by an edgepoint identifier (i.e., EdgepointId) and a Network Address (as specified in the c= part of SDP). If it is useful, the EdgepointId may be equal to its network address but this is not necessary. In order to efficiently support a half-connection model, an edgepoint may have one or more "aliases". This can be inter- preted as the edgepoint having multiple points of presence in multiple networks. (This addresses the issue that has been raised with an RTP port being "artificial"). Media Descriptor: The media capabilities of an edgepoint are described by a MediaDescrip- tor. This descriptor may change with every new connection and may also have some predetermined characteristics. These characteristics may, how- ever, be altered upon realization of a connection. For instance u-Law, Blatherwick, Cuervo, Greene, Gibbs [Page 3] Internet draft MEGACO Requirements 26 February 1999 G.711 and echo cancellation can be the base characteristics of a TDM edgepoint. When the edgepoint is used in a connection, its definition is enhanced by a MediaDescriptor that contains (for instance): * bandwidth * TOS bits * c= type information about the other end of the connection (c= is SDP terminology) * one or more m= for the definition of the media streams that it handles (m= is SDP terminology). Notice that all pieces of this information are eventually optional, since whether it is needed or not depends on the edgepoint type or pro- visioning. The values of several of these fields are defined in the SDP standard [5]. For some of the fields, it may state exactly one value, or it may provide a loose specification, such as a list of allowed encoding methods, or a range of packetization periods. If the edgepoint has one or more aliases, then the media description is added for each alias. The media adaptation that takes place in the MG is derived from the MediaDescriptors for the edgepoint and the aliases. The use of aliases implements the half-connection model presented in MGCP. In this case, the edgepoint and the aliases share the same Exter- nalConnectionId. For the more general model with two edgepoints, each edgepoint in the connection is described by a MediaDescriptor. An MG-ConnectionId is issued to uniquely identify a connection between two edgepoints in the MG. Again, any media transformation to be done in the MG is derived from the MediaDescriptors configured for each edgepoint. 3.0 Alias model The purpose of the alias model is to realise a "half call connection model". It applies when a connectionless network is used between media gateways. For instance, the alias gives to an edgepoint (e.g., DS0s at E1 and Ea) an address that is significant to the network between the ingress and egress MGs. Once the addressing information (i.e., the alias) is complemented by media descriptors, the edgepoint is capable of Blatherwick, Cuervo, Greene, Gibbs [Page 4] Internet draft MEGACO Requirements 26 February 1999 performing bi-directional media adaptation. The directionality of the end-to-end flow is controlled by the "mode" of each one of the external connections involved in the call. ---send E1 alias (e.g. MG IP address, port, media descriptor)-- > < --receive Ea alias (e.g., remote MG IP address, port,..) --- ingress MG egress MG +----+ +----+ E1ExternalConnId | | | | EaExternalConnId +E1MediaDescriptor | | | | +EaMediaDescriptor | E1 | | Ea V | | | | ----------------o o - - - - - - - - - - o o------------ | | IP network | | +----+ +----+ e.g.,TDM network e.g., TDM network Figure 2: Edgepoints as aliases 4.0 Transport capabilities of MGCP, and relationship to Transport Layer Requirements for transport of gateway control and edgepoint-related sig- nalling (eg. Channel Associated Signalling / Edgepoint Associated Sig- nalling) include: * 1-Reliable delivery of command messaging. * 2-Ordered delivery of command messaging pertaining to a particular control stream. Assuming the connection/resource model described here, this implies ordered delivery of commands to/from a particu- lar edgepoint, but not necessarily ordered across edgepoints. This means that the application interface provided by the transport allows for differentiation between these control streams. * 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. However this must be optional so that smaller/simpler systems can be efficiently implemented. * 7-Ability for the application to initiate flushing of messages Blatherwick, Cuervo, Greene, Gibbs [Page 5] Internet draft MEGACO Requirements 26 February 1999 not successfully sent through the transport, for example to back off for failover handling. ISSUE: re requirement 6, do we need to support multiple MGCs controlling individual edgepoints within an MG. Since transport needs are the same in all application states and independent of what particular commands are being sent, it seems logical to think of Megaco transport as a separate layer, as shown below. Application layer: Gateway control | Edgepoint-related signalling ------------------------------------------------- Reliable transport ------------------------------------------------- UDP ------------------------------------------------- IP ------------------------------------------------- Ethernet, ATM, SONET, ... Note that in order to correctly track state transitions and handle fail- overs, it is expected that the application level would make use of com- mand responses as indicated in the command section. For example if a command is successfully passed to the far end through transport, but fails to complete due to resource limitations, this information would still be passed back to the sender. This is a separate issue from tran- sport. ISSUE: It is not clear however, if transport should be implemented as a separate protocol to Megaco, or if it should be directly included. There is currently no accepted IETF protocol which focuses on the needs of real time control as is needed by Megaco. Sigtran has similar needs as well. 4.1 Application Layer Assumptions Application layer is concerned only with command/response interactions between MGC and MG. Commands have corresponding responses to allow tracking of command execution at the application level. This is not tied to the underlying reliability mechanisms, to separate these con- cerns. Blatherwick, Cuervo, Greene, Gibbs [Page 6] Internet draft MEGACO Requirements 26 February 1999 The command embedding described here allows for individual commands to be sent or for commands to be embedded in an arbitrary way. In this way, commands that need to be sent together because of, for instance, fate sharing and ordering get the assurance of traveling on a single transport unit. The application level is responsible for deciding whether to initiate failover handling if it receives notification of transport failure. (Failover handling is a separate topic.) The application should be able to skip messages that are not processed. For instance, using the commands proposed in Appendix A, ApplySignal commands that do not get processed within an application required time might be flushed as a side effect of DeleteMGConnection or an Edgepoin- tReset, or directly by SignallingConfig command. ISSUE: It is unclear if command/transaction numbering would be required at the application level under these assumptions, since the transport layer would handle sequencing and separation of command streams to dif- ferent edgepoints. 4.2 Transport interface Interface to the transport protocol would include the following command semantics: * Open channel (stream identifier, UDP address/port) * Close channel (stream identifier) * Send (stream identifier, message) * Flush (stream identifier). Note under the current connection proposal in Appendix A, stream iden- tifier would be SigConnectionId. A mechanism is also assumed to indicate failure of a control stream, likely based on a callback. ISSUE: Need to be able to configure timeouts, window size, etc. Should this be per channel? What specific parameters can be configured depends on details of underlying protocol. ISSUE: Interface is not really a protocol issue, but needs to be dis- cussed somewhere to ensure everything hangs together. Blatherwick, Cuervo, Greene, Gibbs [Page 7] Internet draft MEGACO Requirements 26 February 1999 4.3 Reliable Transport protocol Simplest possible reliable transport protocol needs to be defined to accommodate requirements set out above. This can be similar to the pro- posal contained in [3], but should be expanded somewhat for improved efficiency. Properties of the reliable transport protocol are as follows: * Aggressive retransmit policy, interval initially very close to RTT (fairly well known in an engineered network). * Very limited retransmit attempts (say order of 3 - 5 tries). * Retransmits exponentially back off to avoid undue congestion. Max- imum duration of retransmit behaviour is therefore strictly lim- ited. * Re-ordering internal to the reliable UDP protocol handler, over a small window. * No adaptive behaviour. * Parameters could be set by the MGC (or through SNMP?) * Above parameters should be balanced so that maximum time before giving up (retransmits failed, link assumed broken) is around 1 - 2 sec. The impatient human in the loop will give up at around that time anyway. ISSUE: A specific proposal for reliable transport over UDP is required. 5.0 Proposal for Way Forward The intent of this document is to reduce the current debates of one Megaco protocol proposal versus another, and begin the process of compromising towards mutually agreeable solutions. As such, the draft attempts to focus on issues and separation of con- cerns, offering compromise positions between existing proposals. Our separation of concerns is based on logical decomposition of the problem space, topics which have been hotly debated on the list, and some which clearly need to be. The draft is work in progress, it does not cover all aspects of the protocol. Some of them may need debate, others can be taken from existing proposals. Therefore it leaving some areas open, to be filled in as agreeable solutions become apparent. Of course, these Blatherwick, Cuervo, Greene, Gibbs [Page 8] Internet draft MEGACO Requirements 26 February 1999 positions will not initially make everyone happy, but we hope to move this debate to issues and to meeting known requirements. 5.1 Why a new version of MGCP? The main issues we have changed with MGCP in its present state [3] are: * 1) it uses a half connection model in its CreateConnection command. The half connection model is appropriate when the transport network is IP, but for other transports, such as ATM, it is necessary to allow separate attributes on a second edgepoint in order to control it independently. [3] does allow a second edgepoint, but does not allow separate attributes to be assigned to that edgepoint. * 2) MGCP derives a lot of power from its ability to embed commands. We propose a more powerful method for this embedding, that allows simpler basic commands which can be combined more easily to build more complex commands. * 3) The way of telling an edgepoint to handle signalling has been improved. Methods such as scripts, digit maps, etc., are supported. In addition there is a capability to indicate signalling backhaul and a corresponding mechanism to allow the application to request ordered treatment of commands on a per edgepoint basis. * 4) An improved definition of the transport capabilities of MGCP, and their relationship to Transport Layer. 5.2 Role of appendix A The appendix of this document provides a message set and call flows for TDM to IP, TDM to TDM (hairpin), and for TDM to ATM. The TDM to IP call flow shows that the messages retain the simplicity found in [3] for the same call flow. The other call flows show the flexibility and strengths of the 2-edgepoint connection model for ATM. Embedded commands are used to ensure that commands are executed together or not at all. This con- cept is also used in [3], and [4]. It is proposed to use the alias concept as a way of consolidating the two connection models for MGCP (in [1] and [3]). As well, the message set proposed here provides new names and simplification of command structure for many of the messages found in [3]. The appendix ends with a table that compares command names and concepts in this proposal to those in [1], and [3]. Blatherwick, Cuervo, Greene, Gibbs [Page 9] Internet draft MEGACO Requirements 26 February 1999 6.0 References [1] MDCP: http://www.ietf.org/internet-drafts/draft-sijben-megaco-mdcp- 01.txt [2] Nortel's 2-ended connection model for MGCP: http://www.ietf.org/internet- drafts/draft-cuervo-megaco-mgcp-00.txt (this document) [3] Bellcore/Cisco's MGCP: http://www.ietf.org/internet-drafts/draft- huitema- megaco-mgcp-v0r1-0x.txt [4] http://www.ietf.org/internet-drafts/draft-huitema-megaco-mgcp- firewall- 00.txt [5] Session Description Protocol 7.0 Authors' Addresses Peter Blatherwick Nortel Networks Ottawa, ON, Canada Email: blather@nortelnetworks.com Fernando Cuervo Nortel Networks Ottawa, ON, Canada EMail: cuervo@nortelnetworks.com Graeme Gibbs Nortel Networks England Email: gibbs@nortelnetworks.com Nancy Greene Nortel Networks Ottawa, ON, Canada Email: ngreene@nortelnetworks.com Appendix A - proposed commands, and call flows A1.0 Proposed Commands Blatherwick, Cuervo, Greene, Gibbs [Page 10] Internet draft MEGACO Requirements 26 February 1999 A1.1 MediaAdaptationConfig: ExtConnectionId, MediaDescriptor, [ListOf: Alias, AliasMediaDescriptor] <--- MediaAdaptationConfig (CallId, EdgepointId, ExtConnMode, MediaDescriptor [ListOf: Alias, RemoteMediaDescriptor]) description of the command: The objective of the command is to indicate to the MG that the media flows entering or leaving the MG need media adaptation. The media adap- tation is resolved by the MG from the edgepoint MediaDescriptor and the alias and remote MediaDescriptors. The alias is an IP or transport address. As a result of the difference in the MediaDescriptors, the MG creates a fully formed media unit for the alias address type (i.e., an IP packet or an ATM PDU). CallId is an identifier assigned by the MGC EdgepointId is a string of local significance to the MGC-MG, i.e., "BlueEP". It denotes an interface. Alias is a network address. MediaDescriptors are extended SDP-type descriptors. ExtConnectionId is an MG assigned identifier that indicates a reset in the Media Adaptation Configuration of an edgepoint. A1.2 ModifyExtConnMode: <--- ModifyExtConnMode(ExternalConnectionId, ExtConnMode) description of the command: The objective of this command is to modify the mode of an external con- nection, it can take values such as loopback, send, receive, sndrecv. Blatherwick, Cuervo, Greene, Gibbs [Page 11] Internet draft MEGACO Requirements 26 February 1999 A1.3 SignallingConfig: [sigConnectionId] <--- SignallingConfig(RequestId, EdgepointId, CallAgentId, [SignallingDescriptor,] [embeddedApplySignal] ) description of the command: The objective of the command is to indicate to the MG that the CAS (or Edgepoint AS or Facility Associated Signalling) of an edgepoint is to be handled by a CallAgentId (i.e., the id of an MGC or a process within the MGC). The SignallingDescriptor is a way to describe the signallling (it could be a digit map or a pointer to a script, etc.). The embedded apply signal is used to generate a signal on the edgepoint upon loading the SignallingDescriptor. RequestId is used to correlate this request with the notifications that it triggers. Example of signalling descriptor: may include, signalling type: Q.931, digit map, script-pointer(URL?), signals, events, state machine, tran- sport: MDCP, Megaco, Sigtran, etc. SigConnectionId is a handle that allows the transport to identify com- mands that require relative ordering. It is not assumed that this exists or is used in all cases. A1.4 ApplySignal: <--- ApplySignal ([SigConnectionId,] EdgepointId, CallAgentId, SignalDescriptor) description of the command: Once an edgepoint is provisioned with a Signalling descriptor, the designated CallAgent can ask the edgepoint to apply signals (i.e., ring- ing). The signal descriptor is constrained by the SignallingDescriptor, which acts as a filter as defined in section A1.3. If available, the SigConnectionId is used by the application to indicate partial ordering to the reliable transport layer. Blatherwick, Cuervo, Greene, Gibbs [Page 12] Internet draft MEGACO Requirements 26 February 1999 A1.5 NotifyEvent: <--- NotifyEvent ([SigConnectionId,] RequestId, EdgepointId, CallAgentId, EventDescriptor) description of the command: once an edgepoint is provisioned with a Signalling descriptor, the designated edgepoint can generate events (i.e., off-hook) that its loaded SignallingDescriptor allows it to observe. If available, the SigConnectionId is used by the application to indicate partial ordering to the reliable transport layer. A1.6 CreateMGConnection: MGConnectionId, ExtConnection1Id, ExtConnection2Id, [SpecificEdgepoint1Id, [embeddedMediaAdaptationConfigResp], [embeddedSignallingConfigResp] ], [SpecificEdgepoint2Id, [embeddedMediaAdaptationConfigResp], [embeddedSignallingConfigResp] ] <--- CreateMGConnection(CallId, Edgepoint1Id, ExtConn1Mode, [embeddedMediaAdaptationConfig,] [embeddedSignallingConfig,] [embeddedApplySignal,] Edgepoint2Id, ExtConn2Mode, [embeddedMediaAdaptationConfig,] [embeddedSignallingConfig,] [embeddedApplySignal] ) description of the command: This command is only used to set direct connections between edgepoints that provide external connections. The external connection mode refers to loopbacks, directionality, etc. that can be applied at different points in the call to the edgepoints involved. Embedded media and Blatherwick, Cuervo, Greene, Gibbs [Page 13] Internet draft MEGACO Requirements 26 February 1999 signalling configurations are allowed for each edgepoint. Note that you don't use this command for IP core networks, the MediaAdaptationConfig is used in this case. ExtConnectionId remains unchanged between resets or outages of the edgepoint. It is also used to check synchronism between the controller and the MG. A1.7 ModifyMGConnection: <--- ModifyMGConnection(MGConnectionId, Embedded ModifyExtConnMode, [Embedded ModifyExtConnMode]) description of the command: changes only the modes of one or both of the external connections that are related to an MGConnection. EdgepointMode: Internal Loopback, External Loopback, Bothway Loopback, OutofService, Ready, Send, Receive, Sendrecv A1.8 DeleteMGConnection: <--- DeleteMGConnection(CallId, [MGConnectionId,] [embedded EdgepointReset, [embedded EdgepointReset] ] ) description of the command: Removes an MGConnection, notice that the external connections do not get removed unless the embedded EdgepointResets are provided for each edgepoint involved in the MGConnection, therefore, a delete connection does not undo the media adaptations, these need to be removed separately or by embedded edgepoint resets. A1.9 EdgepointReset: Blatherwick, Cuervo, Greene, Gibbs [Page 14] Internet draft MEGACO Requirements 26 February 1999 ExtConnectionId, [ListOf: MGConnectionId] <--- EdgepointReset(CallId, [EdgepointId], [embedded SignallingConfg,] [ListOf: Alias)]) description of the command: EdgepointReset undoes the work of the MediaAdaptationConf. With MediaAdaptationConf an edgepoint may be assigned an edgepoint Medi- aDescriptor and alias Mediadescriptors. The EdgepointReset, when only parametrized by a CallId, removes all edgepoints' media adaptations, external connections and MG- connections related to a call. When the EdgepointId is provided, it deletes media adaptations, external configurations and MG-connections that belong to the EdgepointId. When a list of aliases is passed only the aliases' media adaptations are removed, the external connection id remains active. A1.10 Issue: A command that deletes a call and all connection ids associated with that call is need. A2.0 Call flow for Tom's Case 1: DTMF line dialing into VoIP Gateway Blatherwick, Cuervo, Greene, Gibbs [Page 15] Internet draft MEGACO Requirements 26 February 1999 Calling Gateway Called Gatekeeper | 1. Off-hook -->| | | |<-- 2. Dial tone | | | |3. First digit-->| | | |<4. No dial tone | | | |5. Digit -->| | | ... |10. Digit -->| | | | | 11. Admission Request (ARQ)---->| | |<---12. Admission confirm (ACF) | | | 13. SETUP -->| | | | | 14. ARQ -->| | | |<-- 15. ACF | | |<-- 16. ALERTING | | |<-- 17. ringback | | | | |<-- 18. CONNECT | | |<- 19. cutthrough| | | ... | 20. On-hook -->| | | | | 21. RELEASE -->| | | |<-- 22. RLC | | ... Note that the syntax used to describe this call flow (and subsequent ones)is verbose to aid in the understanding of the flow. If text encod- ing is used for this protocol, then a more terse description of the com- mands and parameters, and a corresponding EBNF will be defined. 0a: SignallingConfig sent from MGC to MG SignallingConfig MEGACOP x.x RequestId:0123456789AB // to correlate the event with this config EdgepointId= edgepoint/1@mg-1235.something.net CallAgentId= ca@ca1.something.net SignallingDescriptor= lineside_package(hd, digit collection) 0b: SignallingConfigResp from MG to MGC SignallingConfigResp MEGACOP x.x 10a: NotifyEvent from MG to MGC NotifyEvent MEGACOP x.x RequestId=123456789AB CallAgentId=ca@ca1.something.net EventDescriptor= dialedNumber: 1234567 //observed events Blatherwick, Cuervo, Greene, Gibbs [Page 16] Internet draft MEGACO Requirements 26 February 1999 The number 1234567 is the number assigned to a friend's H.323 Client installation. 10b: NotifyEventResp from MGC to MG NotifyEventResp MEGACOP x.x 12a: MediaAdaptationConfig from MGC to MG MediaAdaptationConfig MEGACOP x.x CallId: abcdefg EdgepointId: edgepoint/1@mg-1234.something.net ExtConnMode:recvonly MediaDescriptor: L: p=10, a:G.711;G.726-32 ListOf:{ {Alias:*, RemoteMediaDescriptor: //***info on the egress side - blank for now } Alias is wildcarded. RemoteMediaDescriptor is blank. 12b: MediaAdaptationConfigResp MediaAdaptationConfigResp MEGACOP x.x ExtConnectionId:yyy MediaDescriptor: L: p=10, a:G.711;G.726-32 ListOf:{ {Alias:47.123.456.789:3456, AliasMediaDescriptor: v=0 c=IN IP4 47.123.456.789 m=audio 3456 RTP/AVP 0 96 a=rtpmap:96 G.726-32/8000 a=recvonly} Alias and AliasMediaDescriptor are now filled in. 16a: ApplySignal sent from MGC to MG ApplySignal MEGACOP x.x EdgepointId: edgepoint/1@mg-1235.something.net CallAgentId: ca@ca1.something.net SignalDescriptor:v Blatherwick, Cuervo, Greene, Gibbs [Page 17] Internet draft MEGACO Requirements 26 February 1999 ApplySignal with SignalDescriptor set to v applies alerting/ringback to the edgepoint. 16b: ApplySignalResp from MG to MGC ApplySignalResp MEGACOP x.x 18a: ModifyExtConnMode from MGC to MG ModifyExtConnMode MEGACOP x.x ExtConnectionId:yyy ExtConnMode: sendrecv Use ModifyExtConnMode to change the mode of the external connection to be sendrecv. 18b: ModifyExtConnModeResp from MG to MGC ModifyExtConnModeResp MEGACOP x.x 20a: NotifyEvent from MG to MGC NotifyEvent MEGACOP x.x RequestId=123456789AB CallAgentId: ca@ca1.something.net EventDescriptor:hu The MG has detected a hang-up event (hu). 20b: NotifyEventResp from MGC to MG NotifyEventResp MEGACOP x.x 22a: EdgepointReset from MGC to MG EdgepointReset MEGACOP x.x //for edgepoint1 CallId:abcdefg //passing only the CallId means call has terminated The EdgepointReset deletes the external connectionId yyy for the call CallId. Sending this command with only the CallId present means the call has terminated. 22b: EdgepointResetResp from MG to MGC EdgepointResetResp MEGACOP x.x Blatherwick, Cuervo, Greene, Gibbs [Page 18] Internet draft MEGACO Requirements 26 February 1999 A3.0 Call flow for a hairpin connection on an MG 0a: SignallingConfig sent from MGC to MG SignallingConfig MEGACOP x.x RequestId:0123456789AB // to correlate the event with this config EdgepointId= edgepoint/1@mg-1235.something.net CallAgentId= ca@ca1.something.net SignallingDescriptor= lineside_package(hd, digit collection) 0b: SignallingConfigResp from MG to MGC SignallingConfigResp MEGACOP x.x Configure signalling of first edgepoint. 0c: SignallingConfig sent from MGC to MG SignallingConfig MEGACOP x.x RequestId:0123456789AB // to correlate the event with this config EdgepointId= edgepoint/2@mg-1235.something.net CallAgentId= ca@ca1.something.net SignallingDescriptor= lineside_package(hd, digit collection) 0d: SignallingConfigResp from MG to MGC SignallingConfigResp MEGACOP x.x Configure signalling of second edgepoint. 10a: NotifyEvent from MG to MGC NotifyEvent MEGACOP x.x RequestId=123456789AB CallAgentId=ca@ca1.something.net EventDescriptor= dialedNumber: 1234567 //observed events In the NotifyEvent, the number 1234567 is that of a called party on the same MG. Blatherwick, Cuervo, Greene, Gibbs [Page 19] Internet draft MEGACO Requirements 26 February 1999 10b: NotifyEventResp from MGC to MG NotifyEventResp MEGACOP x.x 10c: CreateMGConnection from MGC to MG CreateMGConnection MEGACOP x.x CallId: A3C47F21456789F0 Edgepoint1Id: edgepoint/1@mg-1234.something.net ExtConn1Mode: sendrecv {embeddedMediaAdaptationConfig MediaDescriptor: v=0 c=LOCAL EPN edgepoint/2 m=audio 0 LOCAL 0 } {embeddedApplySignal SignalDescriptor: v} //ringback Edgepoint2Id: edgepoint/2@mg-1234.something.net ExtConn1Mode: sendrecv {embeddedMediaAdaptationConfig MediaDescriptor: v=0 c=LOCAL EPN edgepoint/1 m=audio 0 LOCAL 0 } {embeddedApplySignal SignalDescriptor: rg} In this case, the MGC assigns the two edgepoints of the call. Both edgepoints have loaded a signalling package for looking for on-hooks, off-hooks, etc. 10d: CreateMGConnectionResp from MG to MGC CreateMGConnectionResp MEGACOP x.x MGConnectionId=xxx ExtConnection1Id=yyy ExtConnection2Id=zzz 10e: NotifyEvent from MG to MGC NotifyEvent MEGACOP x.x RequestId=123456789AB EdgepointId= edgepoint/2@mg-1235.something.net CallAgentId=ca@ca1.something.net EventDescriptor= hd //observed events Blatherwick, Cuervo, Greene, Gibbs [Page 20] Internet draft MEGACO Requirements 26 February 1999 The MG sends a NotifyEvent when the second edgepoint picks up the phone (hd event). 10f: NotifyEventResp from MGC to MG NotifyEventResp MEGACOP x.x 10g: SignallingConfig sent from MGC to MG SignallingConfig MEGACOP x.x RequestId:0123456789AB // to correlate the event with this config EdgepointId= edgepoint/2@mg-1235.something.net CallAgentId= ca@ca1.something.net SignallingDescriptor= hu SignallingConfig is sent to program the MG to now look for a hang-up (hu) on edgepoint/2. Note - 10g would be needed if the hu was not in the package the edgepoint is using, and must be configured explicitly. 10h: SignallingConfigResp from MG to MGC SignallingConfigResp MEGACOP x.x 10i: SignallingConfig sent from MGC to MG SignallingConfig MEGACOP x.x RequestId:0123456789AB // to correlate the event with this config EdgepointId= edgepoint/1@mg-1235.something.net CallAgentId= ca@ca1.something.net SignallingDescriptor= hu SignallingConfig is sent to program the MG to now look for a hang-up (hu) on edgepoint/1. Note - 10i would be needed if the hu was not in the package the edgepoint is using, and must be configured explicitly. 10j: SignallingConfigResp from MG to MGC SignallingConfigResp MEGACOP x.x 10k: NotifyEvent from MG to MGC NotifyEvent MEGACOP x.x RequestId=123456789AB EdgepointId= edgepoint/2@mg-1235.something.net CallAgentId=ca@ca1.something.net EventDescriptor= hu //observed events Blatherwick, Cuervo, Greene, Gibbs [Page 21] Internet draft MEGACO Requirements 26 February 1999 NotifyEvent tells MGC that edgepoint/2 hung up (hu). 10l: NotifyEventResp from MGC to MG NotifyEventResp MEGACOP x.x 10m: DeleteMGConnection DeleteMGConnection MEGACOP x.x CallId: A3C47F21456789F0 {EmbeddedEdgepointReset EdgepointId= edgepoint/1@mg-1235.something.net} {EmbeddedEdgepointReset EdgepointId= edgepoint/2@mg-1235.something.net} The DeleteMGConnection causes the MGC to pull down the MGConnection and the 2 external connection ids and resets the edgepoints. It also readies the edgepoints to wait for the next call. The embedded EdgepointReset with no parameters causes all external connection ids to be deleted for the call. ExtConnectionIds just deleted are returned in the DeleteMGCon- nectionResp. 10n: DeleteMGConnectionResp DeleteMGConnectionResp MEGACOP x.x MGConnectionId=xxx ExtConnection1Id=yyy ExtConnection2Id=zzz The MGConnectionId, and the ExtConnectionIds just deleted are returned in the DeleteMGConnectionResp. A4.0 Scenarios with ATM as the backbone network We go through a few scenarios for the example where the ingress MG has PCM/TDM on one side, and an ATM network on the other side. Blatherwick, Cuervo, Greene, Gibbs [Page 22] Internet draft MEGACO Requirements 26 February 1999 ingress MG egress MG +----+ +----+ E1ExternalConnId | | E2ExternalConnId | | + E1Descriptor | | + E2 Descriptor | | | E1 E2 | | | v | | v | | ----------------o o - - - - - - - - - - o o------------ | | e.g.ATM network | | +----+ +----+ ^ | MG-ConnectionId (labels the internal connection between E1 & E2) e.g.,TDM/PCM network e.g., TDM network Figure A4.1: MG for TDM to ATM adaptation List of scenarios: * 1- dumb gateway: both edgepoints are chosen and their MediaDescrip- tors are clearly asserted. * 2- the less dumb gateway: both edgepoints are chosen but their "connection options" are somewhat open. * 3- the quasi-intelligent gateway: only one edgepoint is nailed down, the other is selected by the MG. A4.1 CASE 1: In case 1, each edgepoint is indicated by the MGC. In the MediaDescrip- tors, the MGC-CallAgent indicates the codec choices that are appropriate for the task. If the gateway is not so dumb, it can figure out from the codecs chosen for E1 and E2, what resources are needed for the media transformation. If the gateway is really dumb and it exposes some of its MediaDevices (or MediaResources), the needed MediaDevice is also indi- cated from the MGC-DeviceControl: The MediaDevice has two named edgepoints, E1a and E2a, and the transcoding function is indicated by a pair of codec ids, which match those of E1 and E2 respectively. This should be achievable with two CreateConnection commands. The price of being dumb!: Connect E1 to E1a, and connect E2 to E2a. Here is a look at the actual commands. It is assumed a SignallingConfig was sent out from the MGC to E1 in the MG, and that the MG has sent a NotifyEvent to the MGC. The MGC then seizes the incoming circuit, decides on the media Blatherwick, Cuervo, Greene, Gibbs [Page 23] Internet draft MEGACO Requirements 26 February 1999 conversions, configures the handling of signalling in the edgepoints, etc., using CreateMGConnection. For this purpose, CreateMGConnection command embeds a MediaAdaptationConfig and a SignallingConfig for each edgepoint. For instance, SignallingConfig is used to collect digits or watch for an on-hook transition. The following is sent from the MGC to the MG. With this command the MGC indicates to the MC that it wants an MG connection between E1 and E2, where E1 is a PCM trunk with echo cancellation and silence suppression. E2 is given a one profile number. The MGC should wait for the response before switching the edgepoints from "recv" to "sendrecv". CreateMGConnection MEGACOP x.x CallId: A3C47F21456789F0 E1: edgepoint/1@mg-1234.something.net ExtConn1Mode: recv {embeddedMediaAdaptationConfig MediaDescriptor: L: p:10, a:G.711 } E2: outputport:xx, VP/VCI:yy/zz ExtConn2Mode: recv {embeddedMediaAdaptationConfig MediaDescriptor: v=1 c=ATM m=audio AAL2 51 a=AAL2map: 51 {encoding1} } The MG immediately acknowledges the creation, sending back the identifi- cation of the newly created connection: two external connection Ids, and an MGConnectionId. Blatherwick, Cuervo, Greene, Gibbs [Page 24] Internet draft MEGACO Requirements 26 February 1999 200 1204 OK MGConnectionId:FDE234C7 E1ExtConnectionId:FDE234C8 E2ExtConnectionId:FDE234C9 {SpecificE1Id: edgepoint/1@mg-1234.something.net {embeddedMediaAdaptationConfigResp: MediaDescriptor: L: p:10, a:G.711 } {embeddedSignallingConfigResp: } } {SpecificE2Id: outputport:xx, VP/VCI:yy/zz {embeddedMediaAdaptationConfigResp: MediaDescriptor: v=1 c=ATM m=audio AAL2 51 a=AAL2map:51 {encoding1} } } where: * - ATM trunk identifier is expressed as 16-bit integer encoded as hexadecimal * - cid is expressed as 8-bit integer encoded as hexadecimal * - voice profile is expressed as decimal number in range 0-255 in accordance with ITU-T I.366.2 Annex P or is dynamically assigned in range 255-999. * NOTE: will need to define a means of defining dynamic voice profiles for AAL2. This would take similar form to RTP profiles under SDP (RFC2327) [5]. For example: * a=AAL2map: {encoding1} {encoding2} etc. where {encod- ing} takes form * ///// i.e. similar to I.366.2 AnnexP. The MGC is satisfied that the edgepoints will support the required codecs and proceeds to modify the edgepoint modes in the connection. Note, the Mode for both E1ExtConnectionId and E2ExtConnectionId will be Blatherwick, Cuervo, Greene, Gibbs [Page 25] Internet draft MEGACO Requirements 26 February 1999 changed to sendrecv when the MGC has received the ANM (if that is what is required). The ModifyMGConnection is used to change the modes. ModifyMGConnection MEGACOP x.x MGConnectionId:FDE234C7 {Embedded-ModifyExtConnMode ExtConnectionId: FDE234C8 ExtConnMode: Sendrecv } {Embedded-ModifyExtConnMode E2ExtConnectionId: FDE234C9 ExtConnMode: Sendrecv } The MG immediately acknowledges the modification: ModifyMGConnectionResp MEGACOP x.x OK The Mode for both E1ExtConnectionId and E2ExtConnectionId will be changed to sendrecv when the MGC has received the ANM (if that is what is required). A4.2 CASE 2: In case 2, the edgepoints are chosen, but the choice of codecs is sorted out by the MG. So for instance, E1 comes with choices a, and b, and E2 comes with choices a and c. Naturally, the best choice would be (E1,a) and (E2,a) - no transcoding. But assuming that because reasons only known to the MG (in most cases it won't have a choice), it chooses (E1,a) and (E2,c). Then we shall assume that the MG has also internally chosen the a<->c transcoder. The MGC need not worry about this. This is why the gateway is "less dumb". The following command is sent from the MGC to the MG. With this command the MGC indicates to the MC that it wants an MG connection between E1 and E2, where E1 is a PCM trunk with echo cancellation and silence suppression. E2 is given a number of profile choices. Until the MGC makes sure that the remote gateway has a compatible set of choices (i.e., there is at least one common codec), the edgepoints will remain in "recv": Blatherwick, Cuervo, Greene, Gibbs [Page 26] Internet draft MEGACO Requirements 26 February 1999 CreateMGConnection MEGACOP x.x CallId: A3C47F21456789F0 E1: edgepoint/1@mg-1234.something.net ExtConn1Mode: recv {embeddedMediaAdaptationConfig MediaDescriptor: L: p:10, a:G.711;G.726-32 } E2: outputport:xx, VP/VCI:yy/zz ExtConn2Mode: recv {embeddedMediaAdaptationConfig MediaDescriptor: v=1 c=ATM m=audio AAL2 I.366.2 51 52 53 a=AAL2map:51 {encoding1} a=AAL2map:52 {encoding2} a=AAL2map:53 {encoding3} } The MG immediately acknowledges the creation, sending back the identifi- cation of the newly created connection and the session description used to receive audio data, and the codecs chosen: CreateMGConnectionResp MEGACOP x.x MGConnectionId:FDE234C7 E1ExtConnectionId:FDE234C8 E2ExtConnectionId:FDE234C9 {SpecificE1Id: edgepoint/1@mg-1234.something.net {embeddedMediaAdaptationConfigResp: MediaDescriptor: L: p:10, a:G.711 } {embeddedSignallingConfigResp: } } {SpecificE2Id: outputport:xx, VP/VCI:yy/zz {embeddedMediaAdaptationConfigResp: MediaDescriptor: v=1 c=ATM m=audio AAL2 51 a=AAL2map:51 {encoding1} } } The MGC relays has a similar exchange with the egress gateway, when it ascertains that the codecs for the ATM leg will match, it sends the fol- lowing ModifyMGConnection. Note, the Mode for both E1ExtConnectionId and E2ExtConnectionId will be changed to sendrecv when the MGC has received the ANM (if that is what is required). Blatherwick, Cuervo, Greene, Gibbs [Page 27] Internet draft MEGACO Requirements 26 February 1999 ModifyMGConnection MEGACOP x.x CallId: A3C47F21456789F0 MGConnectionId:FDE234C7 {Embedded-ModifyExtConnMode E1ExtConnectionId: FDE234C8 ExtConnMode: sendrecv } {Embedded-ModifyExtConnMode E2ExtConnectionId: FDE234C9 ExtConnMode: Sendrecv } The MG immediately acknowledges the modification: ModifyMGConnectionResp MEGACOP x.x A4.3 CASE 3: In case 3, we assume that the first edgepoint is fully defined (assume there are options also): (E1, a or b). Also, to use the superior intel- ligence of the gateway, some additional description needs to be given to the gateway so it can turn (*, a or c) or (*,*) into, for instance, (E2,c). This is where SDP with the MediaDescriptor is set, depending on the actual capabilities of the network (i.e, whether it routes or sig- nals ATM or uses preset PVCs). So the fully phrased connection command would look like this. (E1,a or b) + (*,*) + (E2MediaDescriptor). CreateMGConnection MEGACOP x.x CallId: A3C47F21456789F0 E1: edgepoint/1@mg-1234.something.net ExtConn1Mode: recvonly {embeddedMediaAdaptationConfig MediaDescriptor: L: p:10, a:G.711;G.726-32 } E2: * ExtConn2Mode: recvonly {embeddedMediaAdaptationConfig MediaDescriptor: v=1 c=ATM } The gateway immediately acknowledges the creation, sending back the identification of the newly created connection and the session descrip- tion used to receive audio data. The gateway selects a port and a Blatherwick, Cuervo, Greene, Gibbs [Page 28] Internet draft MEGACO Requirements 26 February 1999 VP/VCI, an AAL2 cid and provides a choice of codecs. CreateMGConnectionResp MEGACOP x.x MGConnectionId:FDE234C7 E1ExtConnectionId:FDE234C8 E2ExtConnectionId:FDE234C9 {SpecificE1Id: edgepoint/1@mg-1234.something.net {embeddedMediaAdaptationConfigResp: MediaDescriptor: L: p:10, a:G.711;G.726-32 } {embeddedSignallingConfigResp: } } {SpecificE2Id: outputport:xx, VP/VCI:yy/zz {embeddedMediaAdaptationConfigResp: MediaDescriptor: v=1 c=ATM m=audio AAL2 I.366.2 51 52 53 a=AAL2map:51 {encoding1} a=AAL2map:52 {encoding2} a=AAL2map:53 {encoding3} } } The MG could provide different options for c&m here, and let the egress MG choose one. It would do this by offering multiple "c"&"m" lines in preferential order. This MG would find out what the egress MG chose in a ModifyMGConnection command. The MGC relays connection information to the egress gateway and receives information back. The MGC will relay the information to the ingress gateway, using a ModifyMGConnection command. destinationATMaddress, ATMTrunkId and cid will have been defined by the egress MG. The Mode for the connection will be changed to sendrecv when the MGC has received the ANM. A5.0 Mapping of the proposed commands to MGCP commands in [3] The following table is included here to help understand the relationship between this proposal and [3]: Blatherwick, Cuervo, Greene, Gibbs [Page 29] Internet draft MEGACO Requirements 26 February 1999 2-ended conn model Bellcore/Cisco's MGCP [2] MGCP [3] ---------------------------------------- ApplySignal = SignalRequest CallAgentId = NotifiedEntity SignallingConfig = NotificationRequest SignallingDescriptor = RequestedEvents (e.g. hu) SignalDescriptor = SignalRequest NotifyEvent = Notify MediaAdaptationConfig = EdgepointConfiguration + CreateConnection MediaDescriptor = LocalConnectionOptions, RemoteConnectionOptions ModifyExtConnMode = ModifyConnection CreateMGConnection = CreateConnection with 2 edgepoints ModifyMGConnection = ModifyConnection with 2 edgepoints DeleteMGConnection = DeleteConnection with 2 edgepoints RequestId = RequestIdentifier StateChangeNotification = RestartInProgress (this name change was proposed on the email list) A6.0 Table comparing this proposal to [1] and [3] (see Word file for this table: MGCPsCompared.doc - available at ftp://standards.nortelnetworks.com/megaco) -end- Blatherwick, Cuervo, Greene, Gibbs [Page 30]