Draft IETF49 Megaco Minutes

Tom-PT Taylor taylor at NORTELNETWORKS.COM
Fri Dec 15 23:35:23 EST 2000

The Megaco Working Group met on Wednesday morning, December 13.  Tom Taylor
[taylor at 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
 -- 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 at 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

3. Completion Of Charter Items

(a) Megaco MIB

Matt Holdrege [matt at 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 at 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 at MARCONI.COM] expressed his view that the use of a
directionality parameter for signals should be approved on the list.  Glen
Freundlich [ggf at 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 at 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 at 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 at 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.


Bouwen Jan [jan.bouwen at 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 at 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 at 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 at 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

(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

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 at nortelnetworks.com

For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com

More information about the sg16-avd mailing list