2.7.7 Media Gateway Control (megaco)

NOTE: This charter is a snapshot of the 44th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 11-Feb-99

Chair(s):

Tom Taylor <taylor@nortelnetworks.com>

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
Vern Paxson <vern@ee.lbl.gov>

Transport Area Advisor:

Scott Bradner <sob@harvard.edu>

Mailing Lists:

General Discussion:megaco@baynetworks.com
To Subscribe: majordomo@baynetworks.com
In Body: subscribe megaco
Archive: ftp://standards.nortelnetworks.com/megaco

Description of Working Group:

The working group will develop an informational RFC detailing the architecture and requirements for controlling Media Gateways from external control elements such as a Media Gateway Controller. A media gateway is a network element that provides conversion between the information carried on telephone circuits and data packets carried over the Internet or over other IP networks. This work will be done in consultation with other IETF working groups looking at similar issues. The working group will also ensure that good information conduits exist with groups in other standards groups with expertise in the relevant PSTN technology. Other IETF working groups include PINT, IPTEL and SIGTRAN. In addition the working group will ensure that reasonable liaisons exist with similar activities in other standards bodies such as the ITU-T and ETSI.

This working group will also define standards track protocol(s) for controlling media gateways from external control elements such as a media gateway controller.

Examples of media gateways are:

* Trunking gateways that interface between the telephone network and a Voice over IP network. Such gateways typically manage a large number of digital virtual circuits. * Access gateways that provide traditional analog or Primary Rate (PRI) line interfaces to a Voice over IP network. * Network Access Servers that can attach a "modem" to a telephone circuit and provide data access to the Internet.

This working group assumes a separation of call control so the call control "intelligence" is outside the media gateways and handled by a media gateway controller. This group will NOT work on media gateway controller to media gateway controller protocols, nor on media gateway to media gateway protocols.

The working group will ensure that the security issues relating to the use of the standards track protocol in hostile environments are fully understood and that the protocol will will include security mechanisms to protect against attacks on the protocol and to ensure confidentiality where needed.

Planned output:

* Architecture & Requirements informational RFC

* Standards Track RFC for the protocol between a media gateway controller and a media gateway.

* Standards Track RFC for the MG and MC MIBs

* Informational RFC for application programming interface for the MC to MG protocol

Goals and Milestones:

Jan 99

  

Submit Initial draft of architecture and requirements document

Feb 99

  

Initial draft of protocol between MC and MG

Apr 99

  

Submit architecture and requirements document to IESG

Apr 99

  

Updated draft of protocol between MC and MG

Apr 99

  

Initial draft of MG and MC MIBs

Apr 99

  

Initial draft of Application Programming Interface (API) for the protocol between the MC and the MG

Jul 99

  

Submit protocol(s) between MC and MG to IESG for publication as RFCs

Jul 99

  

Submit RFC MIBs for MC and MG to IESG for publication as RFCs

Jul 99

  

Submit API for the protocol to the IESG for publication as an RFC

Aug 99

  

Close Working Group

Internet-Drafts:

No Request For Comments

Current Meeting Report

MEGACO WG - 44th IETF
March, 15-16, 1999

Chair: Tom Taylor (taylor@nortelnetworks.com)
Reported by Matt Holdrege (matt@ascend.com)
Total attendance on the blue sheet was 314 (about 220 per day, obviously with large overlap).

1. Agenda bashing.

2. Review of General Requirements

3. Specialized requirements

Fax - Glenn Parsons (gparsons@nortelnetworks.com)
MSF - Matt Holdrege

4. Deltas from ETSI TIPHON, ITU-T SG16

5. Terminology

The agenda was accepted. (Note that item 5 was replaced by presentation of a jointly-agreed connection model and associated commands.)

2. General Requirements

Brian Rosen (brosen@eng.fore.com) gave the status of the current requirements draft (draft-ietf-megaco-reqs-01.txt). The document still needs to be reorganized. They need to nail down definitions, NAS requirements, ATM requirements, SG16 requirements, TIPHON requirements, and leave out discussion of how an MG or MGC should be architected. But they hope to leave section 4 to describe what an MG does. They also want to work on the wording for how an MGC accesses an MG.

The work plan is to issue a new draft by the first week in April 1999. Then go for WG last call by the end of April.

Tom Taylor stepped through the summary of MEGACO requirements.
98. Support reservation of bearer endpoints and media resources for use by a particular call and support their subsequent release
99. may be implicit or explicit depending on the protocol and context

This was accepted.

100. Allow release of all resources associated with a given call in a single transaction.

This was accepted within the context of a single media gateway. It was reinforced that all of these requirements were in the context of a single media gateway.

101. Support connections involving packet and circuit bearer endpoints in any combination

This was accepted.

102. Support connections involving TDM, Analog, ATM, IP or FR transport in any combination

This was accepted.

103. Support unidirectional, symmetric bidirectional, and asymmetric bidirectional flows of media

This was accepted.

104. Support multiple media types in the protocol

This was accepted.

105. Support point to multipoint connections

This was accepted.

106. Support multipoint conferencing

The degree that we support multipoint conferencing should be discussed on the list.

107. Support inclusion of media resources into connections as required. Depending on the protocol and resource type, media resources may be implicitly included, class-assigned, or individually assigned.

It was suggested that we spell out individual requirements in this class.

We will take this to the list and discuss the definition of resource.

108. Support the establishment of ATM, IP, and FR bearer channels with a specified QOS

There was no objection to this requirement.

109. Allow the MGC to set QOS thresholds and allow either the MG or MGC to terminate the connection.

This requirement is complex and will be taken to the list.

110. Support unambiguous connection of parallel flows of the same medium (e.g. maintaining channel designation for stereo audio)

This requirement could be ambiguous and will be discussed further

111. If the protocol permits multiple connections to pass through the same point, it must provide unambiguous specification of which media flows pass through the point and which are blocked at any point in time.

There were no objections to this requirement.

112. Support mediation of flows between different types of transport

This requirement should be worded better and will be discussed on the list. Nx64 should be considered.

113. Support invocation of additional processing such as echo cancellation, the need for which is related to the type of transport involved.

This was accepted in principal, but the editors need to continue to specify this requirement.

Support mediation of flows between different content encodings (codecs, encryption/decryption)

There were no objections to this requirement.

114. Allow the MGC to specify whether DTMF and FAX/data modem tones are to be terminated at the MG or passed on in the media flow.

The wording on this requirement will be worked on to separate the DTMF methods. Further wording will be required.

We should try to express things in a abstract method rather than enumerating specific items.

115. Allow the MGC to specify for DTMF that it be extracted and encoded in a separate RTP stream
116. Allow the MGC to enable/disable monitoring for specific supervision events at specific circuit endpoints

There was no objection to this requirement.

117. Allow the MGC to enable/disable monitoring for specific events within specified media streams

There was no objection to this requirement.

118. Allow reporting of detected events. The protocol should provide the means to minimize the messaging required to report commonly-occurring event sequences.

There was no objection to this requirement.

Allow the MGC to specify other actions specifically related to event processing (besides reporting) that the MG should take upon detection of specified events

We should provide for a general, yet optional scripting capability. We will discuss the gradations of complexity surrounding scripting on the list.

The AD said extensibility is not an aim. Discipline is an aim. We don't want to facilitate incompatibility.

119. Allow the MGC to specify events (supervision, ringing, e.g.) to be applied at circuit endpoints

There were no objections to this requirement.

120. Allow the MGC to specify tone signalling events to be inserted into specified media flows or other media flows.

There were no objections to this requirement.

121. Allow the MGC to specify content of extended duration (announcements, continuous tones) to be inserted into specified media flows

This requirement was referred to the list.

The general requirements discussion was stopped at this point to give time for Glen Parsons to present a Real Time Internet Fax (T.38) summary. That presentation is reported below under "3. Specialized Requirements". There was no discussion following the Fax requirements presentation and the general requirements discussion resumed.

122. Allow the MGC to specify alternative conditions (detection of specific events, timeouts) under which the insertion of extended-duration content should cease

There was no objection to this requirement.

123. Support the performance of specified variants of PSTN continuity testing, in the either the forward or backward forms.

This requirement was accepted, but it was noted that several other types of testing need to be explored on the list.

124. Support 105 test line operation. We may also need to support 103 and 108 test line.

The meeting broke at this time and resumed the next day, March 16, 1999.

125. Support collection of specified accounting information from trusted MGs, at end of call and in mid-call upon polling
126. start and stop time, by media flow
127. volume of content carried, by media flow
128. QOS statistics, by media flow

There was no objection to this requirement except for further refinement on accounting specification.

129. Allow the MGC to specify where messages from specific facility-associated signalling channels should be sent

Details of this requirement will be discussed on the list.

130. Allow the MG to report changes in status of physical entities supporting bearer endpoints, media resources, and facility-associated signalling channels, due to failures, recovery, or administrative action

There was no objection to this requirement.

131. Allow the MG to report impending resource exhaustion

This requirement should be further discussed on the list.

- Allow the MGC to block and unblock the use of specified sets of circuit endpoints

This requirement should be further discussed on the list to cover all the scenarios.

General: provide the means to minimize duration of loss of control

There was no objection to this requirement.

Support detection and recovery from loss of contact
132. due to failure/congestion of communication links
133. due to MG or MGC failure

There was no objection to this requirement.

134. Support detection and recovery from loss of synchronized view of resource and connection states between MGCs and MGs

There was no objection to this requirement.

MG MIB should provide information on
135. mapping between resources and supporting physical entities
136. statistics on quality of service on the control and signaling backhaul interfaces
137. statistics required for traffic engineering within the MG

It was suggested that the MEGACO WG only work on the MEGACO protocol MIB.

Discussion of whether the MGC uses SNMP to discover resources will be done on the list.

Provide defense against the following threats:
138. denial of service attacks
139. unauthorized use of resources
140. modification of message content
141. loss of confidentiality of user service
142. non-repudiation of commands

This requirement was accepted in concept, but needs to be further refined on the list.

It was noted that we need to have a fully developed security section in the requirements document.

143. Reliable delivery of messages

There was no objection to this requirement.

144. Sequenced delivery of messages associated with the same transaction or the same source of events

There was no objection to this requirement in concept, but transaction needs a better definition.

145. Ability to abort delivery of obsolete messages

This is being discussed in the SLUMS BOF. We will discuss the wording of this on the list.

146. Support of priority messages

There was no objection to this requirement.

147. An MGC should be able to support a large fan-out of MG's.

There was no objection to this requirement.

148. Transaction-oriented, with multiple operations possible per application [issue: semantics]

The wording of this requirement needs work.

149. Extensible according to clear rules.

There was no objection to this requirement.

150. Flexible in allocation of intelligence between MG and MGC

This requirement is useful, but there was concern on what metrics would be used to measure suc a requirement.

151. Scalable from very small to very large MGs

There was no objection to this requirement.

152. Scalable from very small to very large MGC span of control

There was no objection to this requirement.

153. Allows independent upgrade of MG, MGC

There was no objection to this requirement, but we need to further define what upgrade means.

3. Specialized Requirements

Glenn Parsons (gparsons@nortelnetworks.com) presented a summary of new ITU-T Recommendation T.38, for real-time Internet FAX. T.38 was defined by ITU-T Study Group 8 who collaborated with the IETF Fax WG on store & Forward fax over IP (T.37 and RFC 2305). Glen's charts are attached as file FAXReq.PDF. <<FAXReq.PDF>>

Call establishment for T.38 is H.323 fast call setup.

Requirements for Real Time Internet Fax:
154. Fax tone detection for calling tone or answer tone.
155. Capabilities negotiation.

The Multi-Service Switching Forum (MSF) requirements were discussed. It was made clear that the MSF was providing this draft (draft-ietf-megaco-msf-reqs-00.txt) as input to the MEGACO requirements process. Tom Taylor particularly questioned the requirement that accounting data provided by the MG include MG resource utilization statistics. Brian Rosen assured the meeting that service providers at the MSF were particularly insistent upon this point, difficult as it may be for vendors to support.

The MSF requirements will be further discussed on the list for one week and then included in the base MEGACO requirements document. It was mentioned that we should take care to make sure that each of the MSF requirements are truly MEGACO requirements and not MG or MGC requirements.

4. ETSI TIPHON, ITU-T Study Group 16

Gur Kimchi (Gur_Kimchi@vocaltec.com), Chair of ETSI TIPHON Working Group 3 (Protocols and Call Flows) presented the latest (very preliminary) view of the ETSI architecture. The initial draft of the TIPHON architecture document may be found at http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg2/DTS0200 3/ >From the Megaco point of view, this architecture is not intended to be normative, but it does show a given architecture that the MEGACO protocol will be used in. The ETSI requirements document (not reviewed in detail at this meeting) can be found at http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg2/DTS0200 5/. Please note that the copyright boilerplate included on this and other TIPHON drafts was put there by mistake and will be removed in subsequent drafts.

The discussion of the Megaco relationship with the ITU-T Study Group 16 work on H.GCP which had been proposed in the meeting agenda was omitted because this relationship is being discussed at higher management levels of the IETF and ITU.

5. Connection Model Agreement

A design team consisting of the authors of MGCP and MDCP along with interested parties was appointed to meet offline and come up with a compromise protocol proposal. They succeeded in establishing the principles of such a proposal in time for Brian Rosen to present them at this meeting.

They agreed to document an agreed upon connection model. They used totally new terminology in order to avoid any previous biases. Rather than use endpoints or edgepoints, they use the word "terminations". In this model, context connects terminations in a star fashion.

They have created a draft series of atomic commands.

Connect
Disconnect
Modify
Move
Program
Restart
Notify
Audit termination
Audit context

It was noted that the disconnect command need only use names. This will be further discussed on the list. It was noted that it is desirable to initiate an event and delete an event with one command.

It was noted that the Modify command cannot change the list of termination names.

It was noted the move command should be able to have a list of move commands.

The Editors of the follow-up document will be Brian Rosen (brosen@eng.fore.com), Paul Sijben (sijben@lucent.com), Christian Huitema (huitema@research.telcordia.com), Fernando Cuervo (cuervo@nortelnetworks.com), & Eric Zimmerer (eric.zimmerer@level3.com). (Keith Kelly -- keith@netspeak.com -- was subsequently added to this list.)

Slides

None received.