The Megaco Working Group met on Wednesday morning, December 13. Tom Taylor [taylor@nortelnetworks.com] chaired.
1. Agenda Bashing
The proposed agenda was as sent to the list (6/12/2000) with two additions: a brief presentation of work on Bearer Independent Call Control (BICC) and the proposed H.248 packages resulting from it, and presentation of draft-ietf-megaco-fmtdeterm-00.txt. The agenda as proposed was accepted.
2. ITU-T Study Group 16 Status Report =====================================
Tom Taylor provided an update on the status of work in Study Group 16.
He reported that the ITU-T has introduced a new alternative decision procedure -- like Last Call -- if all issues not resolved, fall back on existing procedure. Scott Bradner added that the purpose in part was to make it easier to synchronize ITU-T and IETF decision processes.
At the Study Group 16 meeting of 13-17 November the following items were decided under the old procedures: Annex F: Call discrimination, FAX, text telephony Annex G: User interface elements Annex H: SCTP transport Annex I: ATM transport Annex J: Dynamic tone generation Annex K: Announcements
In addition, the meeting approved the first issue of the H.248v1 Implementor's Guide.
Question 14/16 is now renamed Question 3/16 for the new Study Period. Q. 3/16 now has in hand the following additional official work items relating to H.248. There is no date set yet for completion of these items, but the two Annexes have been determined. -- H.248v2 -- Annex L: Error codes and ServiceChange reasons -- Annex M: Advanced audio server
The following additional work items have been accepted, but are in an early state of maturity: -- Annex N: load control package (APC-2000) -- Annex O: data transport on analogue lines -- SDL appendix (informative). The contributors are looking for more help. -- H.324 package.
Finally, the following H.248v2 items accepted, either at the Portland Rapporteur's meeting in August or at the November meeting: -- ServiceChange to indicate change of capabilities (APC-1911) -- Finer discrimination in audits (APC-1913) -- signal on ROOT. The APC numbers refer to document numbers on the informal SG 16 FTP site (ftp://standards.pictel.com/avc-site /<meeting place and date>) Tom noted that ITU-T versions are more like protocol extensions than protocol modifications. Successive versions are intended to be backwards compatible.
Tom asked a process question: do we republish decided material as Informational or Standards Track? If the latter, presumably IETF comments go into the ITU-T Implementor's Guide.
Flemming Andreasen [fandreas@cisco.com] identified the matter of how the IETF coordinates with the ITU-T in the development of H.248v2 as a major issue. This point should be considered in the rechartering discussion. Scott Bradner advised that no clear resolution of this point had been reached in discussions with Study Group 16 management.
Further process discussion elicited the view that decided items of interest to the IETF should be taken through the complete IETF process and targeted for Standards Track RFCs. The list should decide which items should go this route. Scott Bradner instructed the Chair to get explicit permission from the ITU-T TSB before republishing the decided material, since it is not clear whether our agreement on H.248 extends beyond the initial protocol document.
3. Completion Of Charter Items ==============================
(a) Megaco MIB ----------
Matt Holdrege [matt@IPVERSE.COM] provided a status report on the development of the Megaco MIB. He emphasized that the main purpose of the present draft was to get objects on the table for discussion. He estimated at least two recycles before the draft is in reasonable shape. He presented a long list of detailed issues to be worked through. [Presentation will be attached to published minutes]. There was no discussion at the meeting.
(b) NAS Package -----------
Tom Taylor briefly summarized the status of the NAS packages. [Presentation to be attached to final minutes.] He pointed out that complementary work on indication of TDM bearer capability remained to be done. In his opinion this would be an SDP extension in the spirit of the ATM SDP extension. The hum in favour of moving this work forward was practically imperceptible: it is left to the list to decide. The Chair will be soliciting comment from the list on whether this should be a Standards Track item.
4. Well-Aged Package Drafts ========================
Michael Brown [C.Michael.Brown@nortelnetworks.com] presented all drafts under this heading, as co-author. (The presentation was actually interrupted but is documented here as if it had proceeded according to original plan.)
(a) draft-boyle-megaco-tonepkgs-01.txt ----------------------------------
This document provides a number of specialized tone packages. [Presentation will be attached to minutes.] Michael noted that Study Group 11 (the BICC group) had asked for an optional directionality parameter for tones and announcements. Its use is to direct signals inwards to the context; it optimizes an operation which would otherwise require individual modification of all of the other terminations in the context or treatment of an announcement or tone source as a termination in its own right. The authors of draft-boyle-megaco-tonepkgs-01.txt propose to recycle the draft to include this parameter.
Brian Rosen [Brian.Rosen@MARCONI.COM] expressed his view that the use of a directionality parameter for signals should be approved on the list. Glen Freundlich [ggf@avaya.com] noted that Study Group 16 added such a parameter to the new Annex K announcement package.
The meeting agreed that the directionality parameter discussion is required, but otherwise the draft is ready for list Last Call.
(b) draft-boyle-megaco-alerting-00.txt ----------------------------------
This package provides capabilities related to CLASS signalling. There is an overlap in scope with the proposed Annex O, but the latter has a finer level of detail which in Michael's opinion may result in timing difficulties.
Brian Rosen asked if there had been coordination of approach between this work and automatic number identification (ANI/DNIS). Michael responded that the problems were similar, but not the same.
The meeting agreed that before this draft moves forward there should be a discussion and resolution on the list of the respective content of this draft and the SG 16 Annex O proposal. Action: Chair to arrange for publication of current draft of Annex O as an I-D to aid the discussion.
(c) draft-cornel-megaco-enhancedd-00.txt ------------------------------------
This draft defines an enhanced DTMF digit collection capability, designed particularly for mid-call digit collection. The package includes a modified digit map completion event.
Scott Bradner noted with respect to this and previous items that non-response is not enough to justify standardization. The Chair must solicit discussion if necessary before deciding to move forward.
(d) draft-scoggins-megaco-pktnetpkg-00.txt --------------------------------------
This package proposal is withdrawn in favour of packages included in the Q.1950 (BICC) work.
5. ITU-T Study Group 11 BICC Status ================================
Greg Ratta [gratta@lucent.com], SG 11 Vice Chairman in the area of IP-related signalling work, provided an introduction to Bearer Independent Call Control work dealing with IP networks. [Presentation charts will be attached to official minutes.] The presentation showed the basic architecture and listed two sets of packages: those picked up directly from H.248, and those developed by the BICC group specifically to suit their needs. The key architectural points are that call signalling is based on ISUP, with modifications to support an abstract interface to the media bearers. The protocol interface between the call server and lower-layer functions features a strict separation between bearer-related information and media-related information.
Brian Rosen commented that he had read the BICC documents quickly and had come away with the sense that they violated the spirit of the H.248 protocol. He thought that SG 11 might need more H.248 expertise. He looked for a way to share our knowledge, with the intent of preserving a single protocol. Greg responded by recalling to Brian that Frame Relay, as an example, eventually saw application far beyond its original conception. He was open to the use of channels for the exchange of information between the two groups. The time for Megaco to get involved is definitely now, given that the documents have been determined and a final editing meeting has been scheduled for the latter half of February.
Michael Ramalho [mramalho@cisco.com] seconded Brian's thoughts about the pooling of knowledge. However, he wondered why a project which seemed to be aimed at reproducing SS7 in the IP network should aim beyond that by emphasizing the separation between call control and bearer control. Greg responded that the main aim is to allow traditional networks to operate over new transport. The impetus for the call control/bearer control separation comes from the mobile area.
Michael Brown noted that he had been somewhat involved in Study Group 11's work on BICC. The architecture forces transport of information differently from how H.248 does it. He raised the possibility that an alternative architecture would allow H.248 to operate as usual. He advised those present that, besides draft Q.1950, they should look at draft Q.1990 and the BICC requirements and architecture documents. Q.1950 is the document which Study Group 11 has just determined, and which will be the subject of the February editing meeting.
Ian Rytina [ian.rytina@ericsson.com.au] warned that Megaco should not come barging into the midst of the BICC work shouting "All wrong!" without reflection. Study Group 16 people have been involved in BICC almost from the beginning.
6. ISDN ====
Bouwen Jan [jan.bouwen@alcatel.be] presented draft-bouwen-megaco-isdn-bcp-00.txt, draft-bouwen-megaco-isdn-data-00.txt, and draft-bouwen-megaco-isdn-pack-00.txt. [Presentation to be attached to official minutes.] The content has not changed significantly from the original draft, but it was broken into these three documents to make it easier to understand.
Brian Rosen, commenting on the -isdn-pack draft, suggested that we need group consensus on the use of signals vs. the use of properties for management-type functions. We should decide one way or the other and enforce the chosen style in package definitions. Action is on the Chair to initiate list discussion. Related items in Study Group 16 are the proposed signal on ROOT for heartbeat messages, and proposed audio segment management operations in draft Annex M (Advanced Audio Server).
Brian saw the BCP as a necessary document. However, naming patterns should go into profiles. He also wondered whether the modem descriptor should be used for D-channel data. The basic feeling was that the drafts other than the BCP document should move forward on Standards Track, but only after there had been more list discussion. The Chair undertook to focus discussion on the ISDN drafts in the coming week.
Peter Blatherwick [blather@nortelnetworks.com] wondered whether the BCP document should actually be a profile.
7. CAS Design Team Report ======================
Michael Brown reported. draft-manyfolks-megaco-caspackage is on its way. The interest in channel-associated signalling (CAS) is large; the design team grew through word of mouth after it had been set up.
The team sees the need for the following packages: - Basic CAS - Robbed bit signalling (wink/seizure) - MF generation and detection - Operator services The draft will be published shortly. List comment is encouraged.
8. Other Proposals ===============
(a) draft-rosen-megaco-namepatterns-00.txt --------------------------------------
Brian Rosen presented. The mechanism is intended to help control the volume of information retrieved on audits. The intent is that the MGC retrieve this one property on ROOT, then walk through the patterns to retrieve information on groups of terminations.
Tom Taylor noted that the mechanism allowed more precise designation than the one in the proposed NASROOT package. There is a need to reconcile the latter with Brian's proposals. Aside from the basic mechanism, a list debate is needed on whether ROOT packages should be defined in the manner of NASROOT to associate naming patterns with termination classes. This relates to the old problem of finding out about the MG's capabilities for ephemerals before any of the latter have been created.
Michael Brown noted that the naming pattern in the MG may be purely physical (e.g. shelf/slot), and may not relate to the type of card (hence the termination class) provisioned there.
(b) draft-cutler-megaco-recvpkg-01.txt ----------------------------------
Wayne Cutler [wayne.cutler@marconi.com] presented. The general intent is to allow the MGC to store state against individual terminations on MGs to allow a cleaner recovery from call failures.
Flemming Andreasen termed the proposal bizarre at first sight. He asked whether the data to be stored included call state. Wayne indicated not, but that the data would be call-related. Flemming asked what would happen if multiple MGCs were involved. Wayne asked for clarification of whether Flemming meant multiple MGCs acting as a single logical MGC. Flemming complained of lack of generality. Brian Rosen stepped in to point out that the proposal is general with respect to content. Obviously a length limit would be needed. Scott Bradner noted that the author is simply asking for a cookie mechanism. The only concern is that it is defined too specifically.
Clearly a matter for further discussion on the list.
(c) draft-levy-megaco-mgdiscovery-01.txt ------------------------------------
Thomas LEVY [thomas.levy@ms.alcatel.fr] presented. The draft is intended to provide further information from the MG in support of load balancing. He reviewed the available alternatives and came up with a specific recommendation. Brian Rosen suggested that this work had the same time frame as SDPng, and thus the latter is the preferred route to a solution. Thomas responded that the expected incompatibility between SDP and SDPng made it desirable to find a solution independent of either. Scott Bradner suggested that we check out other resource capability work being done in the IETF.
(d) draft-ietf-megaco-fmtdeterm-00.txt ----------------------------------
The Chair overlooked this item as the meeting was running out of time. It will be taken to the list for Last Call (Informational).
9. Interoperability ================
Brian Rosen reported on the results of the August interoperability event and gave some information on the next one.
10. Rechartering Discussion =======================
Scott Bradner led off discussion of the future of the Working Group by saying that WGs normally have a finite life. Working Groups are justified when they need meeting time to discuss open issues. He had not seen much evidence of such discussion at this meeting -- only a series of presentations.
Brian Rosen spoke of a need to continue our work on packages. The lack of controversy at the present meeting was because the packages presented were well-baked. He also saw the need for an official working group to provide impedance to Study Group 16. The WG itself should not be working on a new version of Megaco -- only on packages. Matt Holdrege picked up the argument that Megaco is needed to provide legitimacy because the work it is involved in reaches beyond the IETF.
Peter Blatherwick agreed that the group should continue its work on packages. He would also like to see more work on profiles, to provide rules for profile definition, how to do "inheritance", whether the MG can support multiple profiles at a time. This item was intentionally deferred earlier in the progress of WG, but there is serious risk of profiles getting out of control. Flemming Andreasen disagreed with this proposal.
Scott Bradner called for a show of hands on continuing the Working Group. There were a fair number in favour of continuation and none in favour of going dormant. Scott instructed the Chair to take a draft charter to the list. The IESG might consider extension of the group's life, but the charter must contain concrete deliverables.
Tom Taylor Ph. +1 613 736 0961 taylor@nortelnetworks.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com