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 chaired. 40 people attended. 1. Agenda ====== 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 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 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 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 draft-hss-megaco-control-association-state-machine-00.txt 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]