Current Meeting Report
2.7.7 Media Gateway Control (megaco)
NOTE: This charter is a snapshot of the 53rd IETF Meeting in Minneapolis, MN USA. It
may now be out-of-date. Last Modified:
Tom Taylor <email@example.com>
Transport Area Director(s):
Scott Bradner <firstname.lastname@example.org>
Allison Mankin <email@example.com>
Transport Area Advisor:
Scott Bradner <firstname.lastname@example.org>
To Subscribe: email@example.com
In Body: subscribe megaco
Description of Working Group:
Note: There is an additional file storage area at
There is a Web interface (up to February 2001 only):
The Megaco media gateway control protocol, RFC 3015 (also published as
ITU-T Recommendation H.248), was developed by the Megaco Working Group
in close cooperation with ITU-T Study Group 16. The protocol responds
to the requirements documented in RFC 2805.
The Megaco Working Group has identified a large number of corrections
to the protocol specification in the year and a half since RFC 3015/Rec.
H.248 was approved. As guardians of the protocol specification, Study
Group 16 maintains a record of these corrections in the form of an
"Implementor's Guide". Study Group 16 now proposes to issue a new
version of Recommendation H.248 incorporating these corrections and a
limited number of new protocol features. The current charter includes
one package, on naming patterns. If the WG determines that other
packages are of general usefulness, an AD and IESG review is needed to
permit addition of the package to the charter.
The basic mandate of the Megaco Working Group is to cooperate with the
ITU-T in the continuing refinement and evolution of the Megaco/H.248
protocol. This specifically includes participation in the development
of H.248v2 and subsequent versions, creation of packages of general
usefulness to users of the protocol, and creation of documents
providing additional information to the development community on
specific aspects of the protocol.
The work of package development for specific applications is
specifically excluded from the Working Group's mandate. However, the
Megaco list will continue to be a place where such packages can be
discussed and refined before being submitted to the IESG for potential
publication as individually-submitted RFCs.
Goals and Milestones:
|Done||  || Submit Initial draft of architecture and requirements document|
|Done||  || Initial draft of protocol between MC and MG|
|Done||  || Updated draft of protocol between MC and MG|
|Done||  || Initial draft of MG and MC MIBs|
|Done||  || Submit architecture and requirements document to IESG|
|Done||  || Submit protocol(s) between MC and MG to IESG for publication as RFCs|
|Done||  || Submit protocol to ITU-T SG 16 for decision as Recommendation H.248|
|Feb 02||  || Submit RFC MIBs for MC and MG to IESG for publication as RFCs|
|Feb 02||  || Submit standards Track document reproducing the content of H.248v2 to the IESG|
|Mar 02||  || Submit Megaco/H.248 MIB to the IESG|
|Mar 02||  || Submit standards Track document, naming pattern package, to the IESG|
|May 02||  || Submit Informational document, example Megaco/H.248 call flows, to the IESG|
Request For Comments:
|RFC2805|| ||Media Gateway Control Protocol Architecture and
|RFC3015||PS||Megaco Protocol (With erratta folded in)
|RFC3054|| ||Megaco IP Phone Media Gateway Application Profile
Current Meeting Report
Megaco minutes, reported by Tom Taylor.
The MS PPT charts presented at this meeting are attached.
The Megaco Working Group met Wednesday afternoon from 3:00 to 4:30. Tom Taylor <firstname.lastname@example.org> chaired. 40 people attended.
Accepted without change.
2. Review of new charter, potential new work items
Tom Taylor presented charts summarizing the new Megaco charter. The key point is that the Working Group can only work on enhancing the base protocol, in cooperation with SG 16. The Megaco E-mail list does NOT face a similar constraint, so we can continue new package work and the like there. We currently have three work items besides H.248v2:
- a naming patterns package
- the Megaco MIB
- an Informational call flows document.
A brief discussion of other possible work items ensued. Brian Rosen <email@example.com> mentioned that he had had requests to resubmit his draft on packages for ATM. The Chair noted that others had made submissions or planned to do so on this topic. Nevertheless, it seemed doubtful that the IESG would interpret this work as falling within the scope of the new charter. He promised to discuss the matter with Scott Bradner.
Christer Holmberg <firstname.lastname@example.org> brought up two work items. One was to define changes needed to negotiate the use of SDPng rather than SDP. He remarked that it was not desirable to indicate SDPng support through choice of transport address, since this could multiply the number of ports used. The other work item is to define SDP for various transports beyond IP and ATM.
3. Review of SG 16 Results
Tom Taylor presented a chart summarizing the outlook for work at Study Group 16. The three major points covered were the probability of an H.248v3 at the next full Study Group meeting in October, changes in management of Question 3/16, and the renumbering of H.248 and its Annexes. Tom paid tribute to Glen Freundlich, whose determination had undoubtedly reduced the time until issuance of H.248v1 by at least half a year. He explained that The H.248.x series was being created so that the Annexes could be versioned independently of the main protocol specification.
Kevin McCandless <KMcCandless@Illuminet.com> expressed his concern about continued creation of new versions of H.248. There should not be any more version of H.248 developed until implementation experience is gained and the data from that experience is analyzed. Succeeding versions should be backwards compatible. Finally, on the editorial level, each new draft version of H.248 should separately list the corrections to the previous version and the new enhancements added. After several additional comments from other meeting participants, it was agreed that the Chair would send a message to SG 16 conveying the Megaco Working Group's strong concern that the ITU-T not move ahead with further versions until we get deployment experience.
Tom's presentation also included charts showing the changes to H.248 made at the Geneva meeting. These were separated into changes affecting both v1 and v2, and changes affecting v2 only. Tom highlighted the largest changes, most of which had been passed to the Megaco E-mail list for comment before final approval.
The largest changes affecting both v1 and v2 included
- modification of the definition of BR signals to make duration irrelevant
- addition of text in Modify, Subtract, and Move on side-effects of Multiplex Descriptors, consistent with the text in Add
- clarification of the effect of omitting a descriptor and individual properties from a command
- retention of the restriction that a single session description within a Local or Remote Descriptor contain no more than one m= line
- adding the ability to disable the start timer in a digit map by setting it to 0; applicable to the case where it is necessary to listen for new tones throughout a call
- clarification of the disposition of outstanding replies during switchover
- the idea that when a parameter or property is unspecified the default may be a specified value or it may be a different behaviour, such as not executing a procedure in which that parameter or property is used
- extension of the scope of the TDM package in Annex E to apply also to non-TDM transport (e.g. ATM AAL 2).
The list of changes affecting v2 only included both changes presented at IETF 52 and new changes introduced as a result of work in Dublin and in Geneva itself. The post-IETF-52 changes include:
- deprecation of the Modem Descriptor; an appropriate SDP/Annex C attribute should be used instead
- Nx64K multiplex type added and described
- can specify topology for individual streams
- added ability for duration of long tones (Z qualifier) to be overridden in the digit map
- added digit buffering after the digit map completion event has completed
- can have more parameters for digit map completion event (triggering timer, extra digit)
- removed section 7.3 -- original content covered in Annex L and earlier in document
- protocol version is 2
- Initial ServiceChange for association always uses version 1 format
- new sections on profiles
- corrected examples in Appendix.
Taking particular note of changes to digit map operation, Brian Rosen suggested that Megaco and SG 16 should try to prevent needless divergence between Megaco/H.248 and MGCP.
4. Control Associations
Tom Taylor presented a series of charts concerning control association states and the use of ServiceChange. These were provided in the hopes of continuing the work begun by
At the outset, the proposal that states should be analyzed separately from the MG and MGC points of view rather than considering a joint association state met with some agreement. It was also agreed that a hot switchover is by definition transparent to the peer and preserves all transactions in progress, while a warm switchover or reboot results in a Stale state as defined in the charts.
Tom made the point that it is important for the MGC to know what state an MG registering with it is in when it registers. He pointed out that the existing specification generally does not indicate what ServiceChangeReason to use when reestablishing a control session, and suggested that this property is therefore available to indicate the MG's state. He proposed that where not otherwise specified the MG use 901 Cold Boot to indicate that the MG was in Initialized state as defined in the charts, and 902 Warm Boot to indicate that the MG was in Stale state.
On the MGC side, there is not the same necessity to indicate state to the peer.
The analysis shown in the charts is incomplete, but it turned out that the charts provided too much technical detail for the audience to comment upon and work with on the spot. It was agreed to adjourn the meeting early rather than continue in design session. [Guess I've learned my lesson -- apologies for not making the material available well in advance of the meeting. PTT]