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. - Support reservation of bearer endpoints and media resources for use by a particular call and support their subsequent release - may be implicit or explicit depending on the protocol and context This was accepted. * 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. o Support connections involving packet and circuit bearer endpoints in any combination This was accepted. o Support connections involving TDM, Analog, ATM, IP or FR transport in any combination This was accepted. o Support unidirectional, symmetric bidirectional, and asymmetric bidirectional flows of media This was accepted. o Support multiple media types in the protocol This was accepted. o Support point to multipoint connections This was accepted. o Support multipoint conferencing The degree that we support multipoint conferencing should be discussed on the list. o 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. o Support the establishment of ATM, IP, and FR bearer channels with a specified QOS There was no objection to this requirement. o 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. o 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 o 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. o 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. o 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. o 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. o Allow the MGC to specify for DTMF that it be extracted and encoded in a separate RTP stream o Allow the MGC to enable/disable monitoring for specific supervision events at specific circuit endpoints There was no objection to this requirement. o Allow the MGC to enable/disable monitoring for specific events within specified media streams There was no objection to this requirement. o 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. o Allow the MGC to specify events (supervision, ringing, e.g.) to be applied at circuit endpoints There were no objections to this requirement. o 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. o 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. o 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. o 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. o 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. o Support collection of specified accounting information from trusted MGs, at end of call and in mid-call upon polling - start and stop time, by media flow - volume of content carried, by media flow - QOS statistics, by media flow There was no objection to this requirement except for further refinement on accounting specification. o 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. o 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. o Allow the MG to report impending resource exhaustion This requirement should be further discussed on the list. o 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. o Support detection and recovery from loss of contact - due to failure/congestion of communication links - due to MG or MGC failure There was no objection to this requirement. o 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. o MG MIB should provide information on - mapping between resources and supporting physical entities - statistics on quality of service on the control and signaling backhaul interfaces - 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. o Provide defense against the following threats: - denial of service attacks - unauthorized use of resources - modification of message content - loss of confidentiality of user service - 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. o Reliable delivery of messages There was no objection to this requirement. o 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. o 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. o Support of priority messages There was no objection to this requirement. o An MGC should be able to support a large fan-out of MG's. There was no objection to this requirement. o Transaction-oriented, with multiple operations possible per application [issue: semantics] The wording of this requirement needs work. o Extensible according to clear rules. There was no objection to this requirement. o 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. o Scalable from very small to very large MGs There was no objection to this requirement. o Scalable from very small to very large MGC span of control There was no objection to this requirement. o 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: -- Fax tone detection for calling tone or answer tone. -- 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.)