Subject: [Megaco] Megaco 53 Minutes

From: "Tom-PT Taylor"<[email-masked]>
Date: Wed, 27 Mar 2002 17:31:58 -0500

Draft Megaco minutes, reported by Tom Taylor.
The charts presented at this meeting are available at
ftp://standards.nortelnetworks.com/megaco/docs/Current/IETF/Megaco53

The Megaco Working Group met Wednesday afternoon from 3:00 to 4:30.  Tom
Taylor <[email-masked]> 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
<[email-masked]> 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 <[email-masked]> 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 <[email-masked]> 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
 - 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]
 
Tom Taylor
[email-masked]
Ph. +1 613 736 0961 (ESN 396 1490)

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco