MSF Ia Megaco.003.01 Final

H.248 Implementation Agreement Between a Call Agent and an IP Trunking Gateway MSF-IA-MEGAC0.003.
01-FINAL
MSF-IA-MEGACO.003.01-FINAL H.248 Implementation Agreement Between a Call Agent and an IP Trunking Gateway
MultiService Forum Implementation Agreement

Contribution Number: msf2004.073.07 Document Filename: MSF-IA-MEGAC0.003.01-FINAL Working Group: Protocol and Control Title: H.248 Implementation Agreement Between a Call Agent and an IP Trunking Gateway Editors: Umesh Bhavsar Siemens Network Convergence umesh.bhavsar@siemens.com Working Group Chairperson: Chris Gallon, Fujitsu Date: 4 May 2006 Abstract: This is the MSF Implementation Agreement for the H.248 interface between a Call Agent and Trunk media gateway. This contribution updates/replaces the previous GMI2002 Implementation agreement for Megaco/H248 for a Media Gateway Controller/Trunking gateway using IP trunks (document: MSF-IA-MEGACO.003-FINAL) and has been amended and updated to include interoperability issues seen at GMI 2004. The goal of the MSF is to promote multi-vendor interoperability as part of a drive to accelerate the deployment of next generation networks. To this end the MSF looks to adopt pragmatic solutions in order to maximize the chances for early deployment in real world networks. To date the MSF has defined a number of detailed Implementation Agreements and detailed Test Plans for the signaling protocols between network components and is developing additional Implementation Agreements and Test Plans addressing some of the other technical issues such as QoS and Security to assist vendors and operators in deploying interoperable solutions. The MSF welcomes feedback and comment and would encourage interested parties to get involved in this work program. Information about the MSF and membership options can be found on the MSF website http://www.msforum.org/ DISCLAIMER The information in this publication is believed to be accurate as of its publication date. Such information is subject to change without notice and the MultiService Forum is not responsible for any errors or omissions. The MultiService Forum does not assume any responsibility to update or correct any information in this publication. Notwithstanding anything to the contrary, neither the MultiService Forum nor the publisher make any representation or warranty, expressed or implied, concerning the completeness, accuracy, or applicability of any information contained in this publication. No liability of any kind whether based on theories of tort, contract, strict liability or otherwise, shall be assumed or incurred by the MultiService Forum, its member companies, or the publisher as a result of reliance or use by any party upon any information contained in this publication. All liability for any implied or express warranty of merchantability or fitness for a particular purpose is hereby disclaimed. The receipt or any use of this document or its contents does not in any way create by implication or otherwise: Any express or implied license or right to or under any MultiService Forum member companys patent, copyright, trademark or trade secret rights which are or may be associated with the ideas, techniques, concepts or expressions contained herein; nor Wayne Cutler Marconi wayne.cutler@marconi.com
2006 MultiService Forum. All Rights Reserved.
2 of 28
MSF-IA-MEGACO.003.01-FINAL H.248 Implementation Agreement Between a Call Agent and an IP Trunking Gateway Any warranty or representation that any MultiService Forum member companies will announce any product(s) and/or service(s) related thereto, or if such announcements are made, that such announced product(s) and/or service(s) embody any or all of the ideas, technologies, or concepts contained herein; nor Any commitment by a MultiService Forum company to purchase or otherwise procure any product(s) and/or service(s) that embody any or all of the ideas, technologies, or concepts contained herein; nor Any form of relationship between any MultiService Forum member companies and the recipient or user of this document. Implementation or use of specific MultiService Forum Implementation Agreements, Architectural Frameworks or recommendations and MultiService Forum specifications will be voluntary, and no company shall agree or be obliged to implement them by virtue of participation in the MultiService Forum. For addition information contact: MultiService Forum 39355 California Street, Suite 307 Fremont, CA 94538 USA Phone: +1 510 608-5922 Fax: +1 510 608-5917 info@msforum.org http://www.msforum.org
3 of 28
TABLE OF CONTENTS
MULTISERVICE FORUM ............................................................................................. 6 1 2 2.1 2.2 2.3

2.3.1
APPLICABILITY AND SCOPE......................................................................... 7 MEGACO PROTOCOL BEHAVIOR ............................................................... 8 DEVICE CONTROL PROTOCOL .............................................................................. 8 MEGACO COMMANDS ....................................................................................... 8 MEGACO PACKAGES ............................................................................................ 8
User Agent Signals and Events Requirements ............................................................................. 9
2.3.1.1 Generic (g) .............................................................................................. 9 2.3.1.2 Continuity (ct)......................................................................................... 9 2.3.1.3 Network(nt)............................................................................................. 9 2.3.1.4 TDM Circuit package(tdmc)................................................................. 10 2.3.1.5 Basic DTMF Generator package(dg).................................................... 10 2.3.1.6 DTMF detection package(dd) ............................................................... 10 2.3.1.7 Call Progress tones generator package(cg) ........................................... 10 2.3.1.8 Call Type Discrimination package(ctyp) .............................................. 11 2.3.1.9 Base Root Package(root)...................................................................... 11 2.3.1.10 RTP Package(rtp).............................................................................. 12 2.3.1.11 Inactivity Timer Package(it) ............................................................. 12 2.3.1.12 Overload Control Package(ocp)........................................................ 12 2.4 TERMINATION NAMING CONVENTIONS .............................................................. 12 2.5 TOPOLOGY DESCRIPTOR .................................................................................... 12 2.6 SERVICE CHANGE DESCRIPTOR.......................................................................... 13 2.7 HEARTBEAT ....................................................................................................... 13 2.8 STARTUP SEQUENCES ........................................................................................ 13 2.9 NULL TRANSACTION ID ..................................................................................... 13 2.10 TRANSACTION TIMERS ....................................................................................... 14 2.11 TRANSPORT........................................................................................................ 14 2.12 SECURITY........................................................................................................... 14 2.13 ENCODING ......................................................................................................... 14 2.14 TIMESTAMP ........................................................................................................ 14 3 4 5 6 7 VOICE CODECS................................................................................................ 14 ECHO CANCELLATION ................................................................................. 14 MODEM, FAX AND TTY SUPPORT.............................................................. 15 DTMF DIGITS AND TELEPHONY TONES ................................................. 15 NAT AND FIREWALL TRAVERSAL ............................................................ 15
4 of 28
8 8.1 9 9.1 9.2 10
REDUNDANCY AND RESILIENCE .............................................................. 16 TIMING CONSIDERATIONS .................................................................................. 16 MANAGEMENT INFORMATION MODEL ................................................. 16 TRUNKING GATEWAY ........................................................................................ 16 CALL AGENT...................................................................................................... 17 REFERENCES.................................................................................................... 18
5 of 28
MultiService Forum
The goal of the MSF is to promote multi-vendor interoperability as part of a drive to accelerate the deployment of next generation networks. To this end the MSF looks to adopt pragmatic solutions in order to maximize the chances for early interoperability in real world networks. To date the MSF has defined a number of detailed Implementation Agreements and detailed Test Plans for the signaling protocols between network components and is developing additional Implementation Agreements and Test Plans addressing some of the other technical issues such as QoS and Security to assist vendors and operators in deploying interoperable solutions. In 2004, the MSF held a Global MSF Interoperability 2004 (GMI 2004) event that tested interoperability between next generation network elements situated in Asia, Europe and North America. GMI 2004 validated the MSF release 2 architectural framework and Implementation Agreements by subjecting them to interoperability testing based on realistic network scenarios. Global MSF Interoperability 2004 (GMI 2004) demonstrated a deployable and operationally ready IP telephony network with Network Management, enhanced Quality-of-Service (QoS) and security features. GMI2004 also demonstrated a service layer with application server, media server, and service broker functionality. GMI2004 provided an industry showcase that: Assisted carriers achieve their goal: to deploy flexible, best of breed products. Assisted vendors achieve their goal: to market products more cost effectively. Displayed the global interoperability of the MSF architecture as referenced in the Release 2 architecture document. Demonstrated a network scenario that was managed to specific quality standards.
The MSF welcomes feedback and comment and would encourage interested parties to get involved in this work program. Information about the MSF and membership options can be found on the MSF website http://www.msforum.org/
6 of 28
Applicability and Scope
This Implementation Agreement was created to describe the interface between a Call Agent and Trunking gateway when using Megaco as a signaling protocol in preparation for GMI 2004 in a VoIP Network. Additional changes have subsequently been made based on operational experience in the GMI event. This document updates the specification Implementation Agreement for MEGACO/H.248 Profile for a Media Gateway Controller/Trunking Gateway using IP Trunks (MSF-IA-MEGACO.003-FINAL). The document MSFIA-MEGACO.003-FINAL was written sometime ago and since than some of the drafts have expired and a subset has been incorporated in to ITU H248 series. In addition this document adds more details in terms of events/parameters for each package. Figure 1 shows the MSF architecture diagram for GMI 2004 and highlights the applicable MEGACO interfaces for this IA.
Application Server Media Server Bandwidth manager STUN Server
Service Broker
ENUM Server
Session Border Control
Application Server
Service Broker
Media Server
Edge Router
Service Broker
Application Server Media Server
Call Agent/ SIP Server
Call Agent/ SIP Server IP Network Service Provider 2 Bandwidth manager
Call Agent/ SIP Server IP Network Service Provider 3 Bandwidth manager Edge Router
Edge Router
Edge Router
Edge Router
IP Network Service Provider 1 Signaling Gateway Trunking Gateway
Session Border Controller Edge Router Access Conc Last Mile

Sub Gwy CPE Bridge/ Router
Signaling Gateway Trunking Gateway PSTN Class 5 Switch
Access gateway
Access gateway
CPE
MGCP or H.248 IP SIP Phone PBX This IA addresses this interface
Figure 1: Architecture diagram indicating applicable interfaces for this IA in Service Provider 1 This IA addresses the interface between the Call Agent and the Trunking gateway. The Trunking gateway provides bearer interface between the Class 5/4 switch and the IP Network. This IA will support the following types of interface to the Class5/4 switch T1/E1 ISUP trunk interface.
Trunking Gateways these are devices resident at either Central Office or Remote Cabinet locations. These devices support TDM interfaces (T1/E1) for inter-connecting to the PSTN. The number of such interfaces may vary from card to card. Typically, multiple T1/E1s are supported on a single card. On the packet/ IP side, they are typically ethernet. They are trusted devices in the sense that they are owned by the N/W Operator and are thus are part of the Operators private IP address space. Therefore, NAT & FW control are not appropriate for such devices
7 of 28
2 2.1
MEGACO Protocol Behavior Device Control Protocol
MEGACO Version 2 shall be supported as specified in ITU document H248.1(05/2002). The H.248 profile specified by this IA shall be named as MSF TGW version 1. The profile and its version number shall be included by the MG in the ServiceChangeProfile parameter with the format MSF TGW/1.
2.2
MEGACO Commands
Based on the H248.1 the following commands shall be supported. MEGACO Command Add MEGACO Parameters TerminationId M: MediaDescriptor SG:SignalDescriptor E:EventDescriptor TerminationId M: MediaDescriptor SG:SignalDescriptor E:EventDescriptor TerminationId TerminationId Auditdescriptor TerminationId ServiceChangeDescriptor TerminationId ObservedEventsDescriptor Notes
Modify
Subtract Audit Value ServiceChange Notify
Statistics may be returned in the response. Context and Termination id wildcarding supported
2.3
Megaco Packages
For this profile the following mandatory and optional packages are required to be supported by both the Trunking gateway and the Call Agent. Package Name / Id Generic / g Base Root / root Basic Continuity Package / ct Network package / nt TDM Circuit package/tdmc Fax,Text,Modem Detection Package/ ftmd Call progress tone generator package / cg Basic DTMF Generator package / Defined In [1] [1] [1] [1] [1] [2] [1] [1] Status / Comments Mandatory Mandatory Mandatory Mandatory Mandatory Optional Mandatory Mandatory..
8 of 28
MSF-IA-MEGACO.003.01-FINAL H.248 Implementation Agreement Between a Call Agent and an IP Trunking Gateway dg DTMF detection package / dd Overload Control Package / ocp Inactivity Timer / it Call Type Discrimination package / ctyp RTP / rtp Quality Alert Ceasing / qac [1] [7] [8] [2] Mandatory. Mandatory.. Mandatory. Mandatory. Note that fax/modem supported by G711 in the GMI2004 event (i.e. T38 optional) and thus the ftmd package could suffice. Mandatory. Optional
[1] [10]
2.3.1
User Agent Signals and Events Requirements
There are a set of events and signals that are defined for each package. For the purpose of a ISUP Trunking gateway, the following subsections define the mandatory event and signals that should be supported by the Trunking gateway for the set of mandatory packages.
2.3.1.1 Generic (g) Attribute Subfield
Mandatory/ Remarks Optional/ Not Required M M
Events
Signal Completion (sc) Cause (cause)
2.3.1.2 Continuity (ct) Attribute Subfield
Mandatory/ Remarks Optional/ Not Required M M M
Events Signals
Completion(cmp) Continuity test(ct) Respond(rsp)
2.3.1.3 Network(nt)
Attribute Subfield Mandatory/ Optional/ Not Required O Remarks
Properties
Maximum Jitter buffer(jit)
9 of 28
MSF-IA-MEGACO.003.01-FINAL H.248 Implementation Agreement Between a Call Agent and an IP Trunking Gateway Events Network failure (netfail) Quality alert(qualert) Statistics Duration(dur) Octets sent(os) Octets received(or) O O M M M Note_1
Note_1: ITU H248.8 Error Code #: 530 (Temporary Network failure) and Error Code #: 531 (Permanent Network failure ) can be used instead of the Eventid:netfail. In case autonomous failure discovery, the gateway can send ServiceChange message.
2.3.1.4
Attribute
TDM Circuit package(tdmc)

Subfield Mandatory/ Optional/ Not Required M M Remarks
Properties
Echo cancellation(ec) Gain Control(gain)
2.3.1.5
Attribute
Basic DTMF Generator package(dg)

Subfield Mandatory/ Optional/ Not Required M Remarks
Signals
DTMF character 0-DTMF character D (d0-dd)
2.3.1.6
Attribute
DTMF detection package(dd)

Subfield Mandatory/ Optional/ Not Required M M Remarks
Events
DTMF digits (d0-do) DigitMap Completion event(ce)
2.3.1.7
Attribute
Call Progress tones generator package(cg)

Subfield Mandatory/ Optional/ Not Required NR M Remarks
Signals
Dial tone (dt) Ringing Tone(rt)
Line side only
10 of 28
MSF-IA-MEGACO.003.01-FINAL H.248 Implementation Agreement Between a Call Agent and an IP Trunking Gateway Busy tone(bt) Congestion Tone(ct) Special information tone(sit) Warning Tone(wt) Payphone recognition tone(prt) Call waiting Tone(cw) Caller waiting tone(cr) O O NR O NR NR NR Line side only Line side only Line side only Line side only
Busy Tone/Cong Tone would not typically be connected via the TGWMG since the condition would be signalled in ISUP REL with appropriate cause.
2.3.1.8
Attribute
Call Type Discrimination package(ctyp)

Subfield Mandatory/ Optional/ Not Required O O O O O M O O O O O Used for text used for text used for text Remarks
Properties
calltyp ttyp V8bsup probemsg probeorder
Events Signals
dtone v8sig ans callsig v8bs V18prob
2.3.1.9
Attribute
Base Root Package(root)

Subfield Mandatory/ Optional/ Not Required O O O Remarks
Properties
maxNumberOfContexts maxTerminationsPerContext normalMGCExecutionTime
11 of 28
MSF-IA-MEGACO.003.01-FINAL H.248 Implementation Agreement Between a Call Agent and an IP Trunking Gateway provisionalResponseTimerValue O
2.3.1.10 RTP Package(rtp)

Attribute Subfield Mandatory/ Optional/ Not Required M M M M M O Remarks
Statistics
ps pr pl jit delay
Events
pltrans
2.3.1.11 Inactivity Timer Package(it)

Attribute Subfield Mandatory/ Optional/ Not Required M Remarks
Events
ito
2.3.1.12 Overload Control Package(ocp)

Attribute Subfield Mandatory/ Optional/ Not Required M Remarks
Events
mg_overload
2.4
Termination Naming Conventions

ds/<unit-type1>-<unit #>/<unit-type2>-<unit #>/.../<channel #>
For digital trunks, it is proposed that the termination take the following format:-
The <unit-type> identifies the particular hierarchy level (e.g. E1, STM1) and the <unit #> is a decimal number which is used to reference a particular instance of a <unit-type> at that level of the hierarchy. As stated in H248.1, the format of Termination identifiers is case- insensitive: It is further recommended that MGs and Call Agents be flexible in terms of their naming conventions to facilitate inter-working.
2.5
Topology Descriptor
A gateway conforming to this profile is not required to implement Topology and MGCs expecting to control gateways meeting this specification shall not assume Topology is implemented.
12 of 28
2.6
Service Change Descriptor
The Gateway shall allow one primary and one or more secondary MGCs to be provisioned for registration. The MGC SHALL be able to control multiple MGs simultaneously. Support of virtual MGs as defined in H.248.1 Section 11.1 is optional.
2.7
Heartbeat
In order to detect loss of communication between MGC and MG, the Inactivity Timer package [8] shall be used. This mechanism is only used by the MG to detect loss of communication with MGC. Loss of communication can be due to: Loss of communication path between the MGC and MG MGC becoming Out Of Service
On startup, the MG will initialize the timer to 0. The MGC shall use the Maximum Inactivity Time event to arm the MG. A value of 30 seconds is recommended for this timer. A value of 0 will disable the inactivity timer. Each time, the MG receives any message; it will restart the Inactivity timer. If the MGC has no messages to send, in order to prevent the inactivity timer expiring, the MGC may send an Audit on the root termination. This will be the only keep alive mechanism used. On the inactivity timer expiring, on the MG, the following actions shall be performed: MG shall send Notify on Root, with event=ito to the primary MGC. If a Reply to the Notify is received, than the MG will restart the Inactivity timer and consider the MGC still accessible. If no Reply to the Notify is received then the MG will send ServiceChange=Root with Method=disconnect, Reason=MGC impending failure to the primary MGC. If a Reply to ServiceChage is received (without ServiceChangeMgcId of new MGC), than the MG will restart the Inactivity timer and consider the MGC still accessible. If no Reply is received then the MG will send ServiceChange=Root with Method=disconnect to the secondary MGC (if configured on the MG). The MG will periodically send . ServiceChange=Root with Method=disconnect to the primary and secondary MGC until it receives a Reply with ServiceChange=Root. .
Note if necessary once the communication to MGC is restored , the MGC can audit the status of each calls and retrieve information on all active contexts by auditing each termination.
2.8
Startup Sequences
In order to avoid excessive messaging on startup, the following mechanism shall be supported: On MG restart, it shall send ServiceChange=Root, Method=Restart. On detecting MG restart, the MGC will send Reply ServiceChange=Root The MGC shall audit the status of all Terminations. To determine the status of physical terminations, the MGC shall send AuditValue on any terminationid. of each physical termination. For example to determine the status of all E1s the MGC shall send AuditValue=DS/S_01/STM1_01/E1_01/1 for each E1. The MG shall respond with Reply, Auditvalue=<terminationid>, ServiceState=InService or OutOfService. based on the ServiceState, the MGC shall build the status of all physical terminations.
2.9
Null Transaction Id
All TransactionReply shall have transaction id with the following exception:
13 of 28
MSF-IA-MEGACO.003.01-FINAL H.248 Implementation Agreement Between a Call Agent and an IP Trunking Gateway If the receiver cannot determine a valid transaction id, than it will send with null transaction id and a single error descriptor 403. Please refer to section 8.2.2 of [1].
2.10 Transaction Timers

Gateways and MGCs SHALL keep application level transaction timers as outlined in Section 8 of ITU 248.1
2.11 Transport
Gateways shall implement UDP and optionally implement SCTP1 transport of H.248. MGCs SHALL implement UDP and optionally SCTP transport of H.248. Gateways and MGCs conforming to this profile are expected to transport H.248 signaling over IP.
2.12 Security
This release of the IA does not utilize security.
2.13 Encoding
Conforming Gateways SHALL support text encoding.
2.14 Timestamp
A timestamp SHALL be sent on every Notify message.
Voice Codecs
G.711 (A-law or mu-law)
For this IA, support for following codecs is mandatory :-
Support for additional codecs (e.g. G.723, G.729E) is optional. The Trunking Gateway must support the packetization periods of 10, 20 or 30ms, except where the packet size is explicitly defined by the codec, e.g. G.723 (30ms). The packetization period may vary for each codec, for example G.726-32 could use 20ms and G.711 could use 10ms. Support for other packetization periods is optional. Silence suppression is optional although recommended unless it forms part of the codec (e.g. G.729B). For the low bit rate codecs, e.g G.729, which are not capable of transmitting DTMF digits, telephony tones and signals in-band, digits, tones and signals shall be carried as RTP packets as specified in RFC 2833. The Call Agent shall specify the codecs requested for the call in the Local and remote descriptors. The SDP parameter for codecs shall be specified using the Payload Type encodings specified in Table 4 of [4]. All codecs shall be identifed either by their fixed payload type (if applicable) or else their registered codec name (if using a dynamic type). See also [5].
Echo Cancellation
Trunking Gateways shall support echo cancellation in the receive direction (i.e. canceling echoes generated at the Gateways end of the call). This is also known as near end echo cancellation. Typical lengths for the echo tail required are dependent on the subsequent path taken through the PSTN but a figure of 128mS is reasonable to cover
IETF RFC2960
14 of 28
MSF-IA-MEGACO.003.01-FINAL H.248 Implementation Agreement Between a Call Agent and an IP Trunking Gateway all occurences. Echo Cancellation shall be applied to all voice calls, but turned off for voiceband data calls using G.711 upon detection of a 2100 Hz tone with phase reversal as per section 4.1 of G.168. The Call Agent is responsible for ensuring far end echo cancellation occurs. Echo Cancellation is best performed as close to the echo source as possible and in many cases will be supported by an International Gateway, IntraLATA tandem switch or far-end User Agent. The Call Agent determines where the echo cancellation can be performed, for example via negotiation using SS7 signaling.
Modem, Fax and TTY Support
Trunking Gateways shall detect the presence of voiceband data, i.e. modem or fax. This is detected by monitoring for the presence of the 2100 Hz tone defined in V.25 and the modified, amplitude modulated 2100 Hz tone defined in V.8. Trunking Gateways are required to detect the 2100 Hz tone with phase reversal as per section 4.1 of G.168 to ensure that echo cancellation and silence suppression is turned off. In addition, Gateways shall be able to detect fax/modem tones both on their circuit side and packet side. Upon detection of the voiceband data, Trunking Gateways shall immediately switch to using the G.711 voice encoding until the end of the call. The codec switchover will be done by changing the RTP payload type for the RTP packets. When setting up the connection the Trunking Gateways and Call Agent shall ensure that G.711 is a supported codec in the session descriptor (SDP). In addition if there is an Notify command for fax or modem tones, the Trunking Gateways shall send a notification request. If G.711 is not included as a supported codec in the SDP then autonomous switchover does not occur. As an option, Trunking Gateways and Call Agents may support T.38 fax transfer or V.152 modem transfer as an alternative to fallback to G.711. If fallback to G.711 occurs, the Call Agent is responsible for ensuring that G.711 codec is used end-end for the call. Note, the latency in sending a Notification command for a fax/modem tone to the Call Agent followed by the Call Agent instructing the Trunking Gateways to switch codec is too long for modem calls to equalize at the maximum speed, hence the requirement for the Trunking Gateways to autonomously switch codecs as soon as it detects a fax or modem tone.
DTMF Digits and Telephony Tones
DTMF in-band digit support is out of scope for the GMI and thus section is optional. If supported, DTMF digits shall be handled as specified in section 9 of [5]. In summary this specifies Media Gateways shall have the capability to transport DTMF digits using [6] or in-band in the codec or both. Media Gateways shall also support notification of DTMF digits or tones via MEGACO Notify commands. Digits are reported only to the Call Agent and are not sent in the RTP stream. Codec negotiation is used to determine whether DTMF digits should be transported via [6] or in-band. Support for [6] is specified using the RTP payload format telephone-event. If this payload format is specified in the SDP descriptor then [6] should be used if supported, otherwise in-band transport is used.
NAT and Firewall traversal
Not applicable. Trunking Gateways are trusted elements within the Operators network.
15 of 28
Redundancy and resilience
The Call Agent must support redundancy. This is required to match the existing PSTN five-nines level of reliability. There are at least two ways to implement a redundant Call Agent with regards to the MEGACO signaling Implement a primary and secondary Call Agent as separate components in the network Primary and backup Call Agents have different domain names Implement a Call Agent with no single point of failure and full redundancy
To support the first scheme, Trunking Gateways must support fail over to a secondary Call Agent if it detects a failure of the primary Call Agent, using the procedures described in section 11 of [1]. This procedure involves the Trunking Gateways having two or more Call Agents configured. In the event of losing contact with the primary Call Agent, the Trunking Gateways attempts to connect to the backup Call Agent(s) typically using a ServiceChange command. Synchronization and replication of data between the Primary Call Agent and Secondary Call Agent is outside the scope of this IA. In the second scheme, the Call Agent has its own redundant components that share the same Domain name or IP address and the Trunking Gateways will be unaware that a failover has occurred. In the case of the Trunking Gateway itself, the resilience requirements are dependent on the size of the card and thus the number of T1/E1s affected by the loss of such a card. Thus, if a card supports a few T1/E1s, then the individual T1/E1s can be distributed across different Trunk Groups such that loss of the card causes a small loss of capacity across a number of different interfaces. If the card supports many T1/E1s e.g. an OC-12/STM-1 then there must be some resilience built into the system (1+1 or 1:N redundancy of cards) since the loss of such a link would be unacceptable.
8.1
Timing Considerations
User Agents, Call Agents and Trunking Gateways need to derive their timing from the network. This is particularly vital to ensure that fax and modem traffic can be transported across the VoIP access network. In the case of a Trunking Gateway, timing is typically received from an external source running over a physical interface. In addition, Trunking Gateways may also support an internal clock source (Stratum 3 or higher).
9 9.1
Management Information Model Trunking Gateway

User Agent Fully Qualified Domain Name or IP address DHCP or fixed IP address typically Trunking Gateways would have a fixed IP address. If DHCP is not used IP address Subnet mask Default IP gateway
The following items must be configurable on the Trunking Gateway:
Name of Primary Call Agent UDP Port to send MEGACO signaling to Primary Call Agent (default 2944)
Name of Secondary Call Agent (optional) UDP Port to send MEGACO signaling to Secondary Call Agent (default 2944)
Heartbeat Timer value
16 of 28
MSF-IA-MEGACO.003.01-FINAL H.248 Implementation Agreement Between a Call Agent and an IP Trunking Gateway UDP Port to receive MEGACO signaling from Call Agent (default 2944) DSCP (TOS) byte value for MEGACO signaling traffic DSCP (TOS) byte value for RTP voice traffic
9.2

Call Agent
Fully Qualified Domain Name DHCP or fixed IP address If DHCP is not used IP address Subnet mask Default IP gateway
The following items must be configurable on the Call Agent
UDP Port to receive MEGACO signaling from User Agents (default 2944) DSCP (TOS) byte value for MEGACO signaling traffic DSCP (TOS) byte value for RTP voice traffic For each supported Trunking Gateway Trunking Gateway Domain Name or IP address
UDP Port to send MEGACO signaling to User Agent (default 2944)
17 of 28
10 References
[1] [2] ITU-T H248.1: gateway Control Protocol Version 2 ITU-T H248.2: Gateway control protocol: Facsimile, text conversation and call discrimination packages IETF RFC 2327 SDP: Session Description Protocol, April 1998 IETF RFC 3551 RTP Profile for Audio and Video Conferences with Minimal Control, July 2003 MSF-SDP-001-FINAL IA for SDP Usage & Codec Negotiation IETF RFC 2833 RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals, May 2000 ITU-T H248.11: Media Gateway Overload Control Package ITU-T H248.14: Inactivity Timer Package ITU-T H248.8: Error Code & Service Change Reason Description. ITU-T H248.13: Quality Alert Ceasing Package
[3] [4]
[5] [6]
[7] [8] [9] [10]
18 of 28
Appendix A
MEGACO Call Flows
This appendix contains some example MEGACO call flows for various scenarios. MG Registration (Service Change Root) Service Change ROOT Fail over Ingress Call Egress Call Call Disconnect COT Incoming call Modem Call Fax Call Inactivity Timer
19 of 28
A.1
MG Registration (Service Change Root)
Media Gateway Controller
Media Gateway
Media Gateway Boots up
MEGACO/1 [10.17.4.16]:2944 Transaction =1{Context={ServiceChange=ROOT{Services{Method=Restart, Version=2}}}}
MEGACO/2 [10.17.1.74]:2944 Reply=1{Context={ServiceChange=ROOT{Services{Version=2}}}}
MEGACO/2 [10.17.1.74]:2944 Transaction =2 { Context=*{ AuditValue=DS/SL_05/STM1_01/E1_01/*{ Audit{Media}}}} MEGACO/2 [10.17.4.16]:2944 Reply=2{ Context=-{ AuditValue=DS/SL_05/STM1_01/E1_01/*{ Media{TerminationState{ ServiceStates=InService}}}}} MGC audits each one of the E1/DS1configured after the registration
20 of 28
A.2
Service Change ROOT Fail over
Media Gateway Controller Secondary
Media Gateway Controller Primary
Media Gateway
Media Gateway has been armed with non zero Maximum Inactivity Time value.
No message received for 30s MG notifies of inactivity timer expiring MEGACO/1 [10.17.4.16]:2944 Transaction=118 {Context=Notify=ROOT{ObserverdEvent=567890{it/ito}}} MEGACO/2 [10.17.4.16]:2944 Transaction=119 {Context={Servicechange=ROOT {Services { Method=Disconnect, Reason=MGC Impending Failure}}}} No reply
MEGACO/2 [10.17.4.16]:2944 Transaction=2 {Context=- {Servicechange=ROOT {Services { Method=Restart,Version=2}}}}
MEGACO/2 [10.17.1.74]:2944 Reply=2 {Context=- {Servicechange=ROOT {Services {Version=2}}}}
Secondary MGC takes over.
21 of 28
A.3
Ingress Call

MEGACO/2 [10.17.1.74]:2944 Transaction=1 {Context=$ {Add=DS/S_11/DS3_01/DS1_02/01 { Media {LocalControl {Mode=SendReceive,TDMC/EC=ON,TDMC/ GAIN=0}}}, Add=$ {Media {Local { v=0 c=IN IP4 $ b=AS:64 m=audio $ RTP/AVP 4 a=fmtp:4 annexa=no a=ptime:30},
Media Gateway
LocalControl {Mode=IN,NT/JIT=30}}}}} MEGACO/2 [10.17.4.16]:2944 Reply=1 {Context=20000 {Add=DS/S_11/DS3_01/DS1_02/ 01, Add=A013e8 {Media {Local { v=0 c=IN IP4 172.16.6.61 m=audio 4000 RTP/AVP 4 }}}}} MEGACO/2 [10.17.1.74]:2944 Transaction=3 {Context=20000 {Modify=DS/S_11/DS3_01/DS1_02/01 { Media {LocalControl {Mode=SendReceive,TDMC/EC=ON,TDMC/GAIN=0}}}, Events=50331910 {DD/STD {TL=[D0:DD]},CTYP/DTONE}}, Modify=A013e8 {Media {Local { v=0 c=IN IP4 172.16.6.61 m=audio 4000 RTP/AVP 4 a=fmtp:4 annexa=no a=ptime:30 },Remote { v=0 c=IN IP4 172.16.6.62 m=audio 4000 RTP/AVP 4 a=fmtp:4 annexa=no a=ptime:30}, LocalControl {Mode=SendReceive}}}}} MEGACO/2 [10.17.4.16]:2944 Reply=3 {Context=20000 {Modify=DS/S_11/DS3_01/DS1_02/ 01, Modify=A013e8}}
Call Connected
22 of 28
A.4
Egress Call
Media Gateway
MEGACO/2 [10.17.1.74]:2944 Transaction=2 {Context=$ { Add=DS/S_11/DS3_02/DS1_01/01 { Media {LocalControl {Mode=SendReceive,TDMC/EC=ON,TDMC/GAIN=0}}} Events=50331910 {DD/STD {TL=[D0:DD]},CTYP/DTONE}}, Add=$ {Media {Local { v=0 c=IN IP4 $ b=AS:64 m=audio $ RTP/AVP 4 a=fmtp:4 annexa=no a=ptime:30 },Remote { v=0 c=IN IP4 172.16.6.61 m=audio 4000 RTP/AVP 4 a=fmtp:4 annexa=no a=ptime:30 },LocalControl {Mode=SendReceive,NT/JIT=30}}}}}
MEGACO/2 [10.17.4.16]:2944 Reply=2 {Context=20001 {Add=DS/S_11/DS3_02/DS1_01/ 01, Add=A013e9 {Media {Local { v=0 c=IN IP4 172.16.6.62 m=audio 4000 RTP/AVP 4 }}}}}
Call Connected
23 of 28
A.5
Call Disconnect
Media Gateway
MEGACO/2 [10.17.1.74]:2944 Transaction = 4 {Context = 20000 { Subtract = DS/S_11/DS3_01/DS1_02/01, Subtract = A013e8 { Audit {Statistics}}}}
MEGACO/2 [10.17.4.16]:2944 Reply = 4 {Context = 20000 { Subtract = DS/S_11/DS3_01/DS1_02/01, Subtract = A013e8 {Statistics {nt/or = 80960,nt/os = 81120,rtp/delay = 1,rtp/jit = 0,rtp/pl = 0,rtp/pr = 506,rtp/ps = 507}}}}
Call Disconnected
24 of 28
A.6
COT Incoming call
hiG1200 Media Gateway
MEGACO/2 [10.17.1.74]:2944 Transaction=6 {Context=$ { Add=DS/S_11/DS3_01/DS1_01/01 { Media {LocalControl {Mode=Loopback,TDMC/EC=OFF,TDMC/GAIN=0}}, Signals {CT/RSP}},Add=$ {Media {Local { v=0 c=IN IP4 $ b=AS:2147483647 m=audio $ RTP/AVP 8 a=ptime:20 },LocalControl {Mode=IN,NT/JIT=30}}}}}
MEGACO/2 [10.17.4.16]:2944 Reply=6 {Context=20001 { Add=DS/S_11/DS3_01/DS1_01/01, Add=A013e9 {Media {Local { v=0 c=IN IP4 172.16.6.61 m=audio 4010 RTP/AVP 8 }}}}}
TDM termination is looped back
25 of 28
A.7
Modem Call
Media Gateway
Call connected Modem detected

MEGACO/2 [10.17.4.16]:2944 Transaction = 90 { Context = 20007{ Notify = DS/S_11/DS3_01/DS1_20/01{ ObservedEvents = 4882208{ctyp/dtone {dtt = ANSBAR}}}}}
MEGACO/2 [165.218.172.97]:2944 Reply = 90{Context = 20007{ Notify = DS/S_11/DS3_01/DS1_20/01}}
MEGACO/2 [10.17.1.74]:2944 T = 31111{Context = 20000{ Modify = DS/S_11/DS3_01/DS1_02/01{ Media{LocalControl{Mode = Sendreceive,TDMC/EC = OFF,TDMC/GAIN = 0}}}, Modify = A013e8{Media{Local{ v=0 c = IN IP4 172.16.6.61 m = audio 40 00 RTP/AVP 8 a = ptime:20 },Remote{ v=0 c = IN IP4 172.16.6.62 m = audio 4000 RTP/AVP 8 a = ptime:20 },LocalControl{Mode = Sendreceive}}}}}
Connection attribiutes are changed for the modem call
MEGACO/2 [10.17.4.16]:2944 Reply = 31111{Context = 20000{ Modify = DS/S_11/DS3_01/DS1_02/01, Modify = A013e8}}
26 of 28
A.8
Fax Call
Media Gateway
Call connected Fax detected

MEGACO/2 [10.17.4.16]:2944 Transaction=90 {Context=20007 { Notify=DS/S_11/DS3_01/DS1_20/01 { ObservedEvents=4882208 {ctyp/dtone {dtt = V21flag}}}}}
MEGACO/2 [165.218.172.97]:2944 Reply=90 {Context=20007 {Notify=DS/S_11/ DS3_01/DS1_20/01}}
MEGACO/2 [10.17.1.74]:2944 Transaction=31111 {Context=20000 { Modify=DS/S_11/DS3_01/DS1_02/01 { Media {LocalControl {Mode=SendReceive,TDMC/EC=ON,TDMC/GAIN=0}}}, Modify=A013e8 {Media {Local { v=0 Connection attribiutes are c=IN IP4 172.16.6.61 changed for the fax call m=audio 40 00 RTP/AVP 8 a=ptime:20 },Remote { v=0 c=IN IP4 172.16.6.62 m=audio 4000 RTP/AVP 8 a=ptime:20 },LocalControl {Mode=SendReceive}}}}} MEGACO/2 [10.17.4.16]:2944 Reply=31111 {Context=20000 { Modify=DS/S_11/DS3_01/DS1_02/01, Modify=A013e8}}
27 of 28
A.9
Inactivity Timer
Media Gateway Controller Primary
Media Gateway
Media Gateway Registered
MEGACO/2 [10.17.1.74]:2944 Transaction=1117 {Context=- {Modify=ROOT {Events=567890 {it/ito {mit=3000}}}}} Inactivity time is set to 30s MEGACO/2 [10.17.4.16]:2944 Reply=1117 {Context=- {Modify=ROOT }}
Note: 1. mit value can be 0, 10, 20... 65535 2. Default mit value in MG is 0. 3. Setting mit value of 0 disable the inactivity timing
When no message to send, MGC shall send Audit message on ROOT as a sign of life
MEGACO/2 [10.17.4.16]:2944 Transaction=1118 {Context=- { Notify=ROOT { ObservedEvent=567890 {it/ito}}}}
No message received for 30s MG Notifies the inactivity
MEGACO/1 [10.17.4.16]:2944 Transaction=1119 {Context={Servicechange=ROOT {Services {Method=Disconnect, Reason= MGC Impending Failure}}}}
No new message or Notify Reply from primary MGC within x (30) secs
MEGACO/1 [10.17.1.74]:2944 Reply=1119 {Context=- {Servicechange=ROOT {Services }}}
28 of 28

MSF Ia Megaco.003.01 Final

Uploaded by

Copyright:

Available Formats

MSF Ia Megaco.003.01 Final

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MSF Ia Megaco.003.01 Final

Uploaded by

Copyright:

Available Formats

H.248 Implementation Agreement Between a Call Agent and an IP Trunking Gateway MSF-IA-MEGAC0.003.

MultiService Forum Implementation Agreement

2006 MultiService Forum. All Rights Reserved.

2006 MultiService Forum. All Rights Reserved.

MULTISERVICE FORUM ............................................................................................. 6 1 2 2.1 2.2 2.3

2006 MultiService Forum. All Rights Reserved.

8 8.1 9 9.1 9.2 10

2006 MultiService Forum. All Rights Reserved.

2006 MultiService Forum. All Rights Reserved.

Applicability and Scope

Application Server Media Server Bandwidth manager STUN Server

Application Server Media Server

Call Agent/ SIP Server

Call Agent/ SIP Server IP Network Service Provider 2 Bandwidth manager

IP Network Service Provider 1 Signaling Gateway Trunking Gateway

Session Border Controller Edge Router Access Conc Last Mile

Signaling Gateway Trunking Gateway PSTN Class 5 Switch

MGCP or H.248 IP SIP Phone PBX This IA addresses this interface

2006 MultiService Forum. All Rights Reserved.

MEGACO Protocol Behavior Device Control Protocol

Subtract Audit Value ServiceChange Notify

2006 MultiService Forum. All Rights Reserved.

User Agent Signals and Events Requirements

2.3.1.1 Generic (g) Attribute Subfield

Mandatory/ Remarks Optional/ Not Required M M

Signal Completion (sc) Cause (cause)

2.3.1.2 Continuity (ct) Attribute Subfield

Mandatory/ Remarks Optional/ Not Required M M M

Completion(cmp) Continuity test(ct) Respond(rsp)

Maximum Jitter buffer(jit)

2006 MultiService Forum. All Rights Reserved.

TDM Circuit package(tdmc)

Echo cancellation(ec) Gain Control(gain)

Basic DTMF Generator package(dg)

DTMF character 0-DTMF character D (d0-dd)

DTMF detection package(dd)

DTMF digits (d0-do) DigitMap Completion event(ce)

Call Progress tones generator package(cg)

Dial tone (dt) Ringing Tone(rt)

Line side only

2006 MultiService Forum. All Rights Reserved.

Call Type Discrimination package(ctyp)

calltyp ttyp V8bsup probemsg probeorder

dtone v8sig ans callsig v8bs V18prob

Base Root Package(root)

maxNumberOfContexts maxTerminationsPerContext normalMGCExecutionTime

2006 MultiService Forum. All Rights Reserved.

2.3.1.10 RTP Package(rtp)

2.3.1.11 Inactivity Timer Package(it)

2.3.1.12 Overload Control Package(ocp)

Termination Naming Conventions

2006 MultiService Forum. All Rights Reserved.

Service Change Descriptor

All TransactionReply shall have transaction id with the following exception:

2006 MultiService Forum. All Rights Reserved.

2.10 Transaction Timers

For this IA, support for following codecs is mandatory :-

2006 MultiService Forum. All Rights Reserved.