Subject: Summary of Megaco Meetings

From: Tom-PT Taylor <[email-masked]>
Date: Sun, 14 Nov 1999 20:12:06 -0600

This message summarizes the outcome of the Megaco meetings held Wednesday
and Friday mornings Nov. 10 and 12 respectively, plus design team and
informal activity held between those two meetings.

The Wednesday meeting opened with the announcement that we were still
tinkering with process.  Given that the Megaco protocol still has some
deficiencies, the latest proposal is to mark the completion of the work by
going to IESG last call and issuing a Proposed Standard BEFORE the ITU-T
decision meeting in February.  The intent is to achieve a cleaner handoff to
Study Group 16.  ITU-T management had been advised of this change in
procedure and had agreed with it.  Once H.248 has been decided, we can
revert to the original plan.

At the Wednesday meeting, Tom Taylor [[email-masked]] presented a
review of the protocol against our requirements document.  Tom will release
an I-D recording the results of that review shortly.  A number of
discrepancies were noted, some of which raise issues for the protocol.  In a
few cases the meeting agreed that the protocol had met intent and the
requirements needed clarification.  Many cases were noted where the
requirements will be met when work on package specification has been
completed.  Nancy Greene [[email-masked]] will issue a new
version of the requirements document within a week, with the intention that
this go for WG Last Call.   (As a result of a decision made at the IETF
plenary on Wednesday night, the requirement to support legal interception
will be deleted from the document.)

Brian Rosen [[email-masked]] presented the results of the Redbank
meeting.   He noted that despite a great deal of discussion in Redbank, we
still do not have a fully satisfactory description of the operation of
events and signals.  Following Brian's presentation, Mike Kallas
[[email-masked]] and Zacharias Bilalis
[[email-masked]] presented the status of the work on
packages, another incomplete work item.  Finally, Glenn Parsons
[[email-masked]] presented the status of work on FAX and modem
packages.  A separate design team has been formed under the leadership of
Glenn, Roy Spitzer [[email-masked]],  and James Rafferty
[[email-masked]], to create FAX and modem packages.  This team
was asked to coordinate with Gunnar Hellstrom [[email-masked]]
to ensure that text conversation was properly supported.

The Wednesday afternoon meeting of the protocol design team considered two
inter-related problems: how to differentiate between ephemeral terminations
with different transport (IP, ATM) when adding them, and how to determine
the capabilites afforded to ephemeral terminations before any such
terminations have been created in the MG.  The third topic of how to keep
audit response message sizes reasonable was also considered.  This meeting
came to some definite conclusions, but some of those conclusions were
refuted at the Friday morning meeting of the WG (see below).

The Thursday afternoon meeting of the protocol design team wrestled with the
question of how events operate within the protocol.  The meeting failed to
come to a conclusion.  Discussion was continued informally on Thursday
evening.

In the Friday meeting, Matt Holdrege [[email-masked]] drew attention to the
preliminary draft for a Megaco MIB and asked for further contributions.  In
discussion of this item, it was noted that a document is needed that
describes how all of the various MIBs that deal with MG operation fit
together.  Scott Bradner suggested that Megaco might provide a first cut at
such a document.  Chip Sharp [[email-masked]] noted that an annex
providing the option of Megaco/H.248 transport over SIGTRAN SCTP was in
preparation, for determination at the February SG 16 meeting (and decision
presumably in the fall).  The ITU-T is able to add annexes without reissuing
the whole protocol document.

Most of the remainder of the meeting was spent discussing open issues, and
particularly proposals arising out of the design meetings and informal
discussion the night before.

An important point noted in this discussion was that transport may vary per
stream, so that the same termination supports both Video/RTP/UDP/IP and
Voice/RTP/AAL5, for instance.  As a result, one cannot in general assume
that the terminationID carries any information about the type of transport
supported on the termination.  Two proposals to simplify audits were
accepted as worth consideration on the list.  One is to specify the naming
pattern for terminations on the MG as a string property of ROOT.  The other
is for syntax to request and receive aggregated (set union of) capabilities
for a group of terminations.

Proposals coming out of Thursday evening's informal discussion of events
were also discussed.  One of these proposals was to eliminate event
buffering except for the operation of digit maps, and to have the latter
then perform any buffering needed.  Michael Thomas [[email-masked]] pointed
out that the intent of quarantine buffers in MGCP was to capture ALL events,
not just those enabled in the current event descriptor, and hold those
events between the time a Notify is sent to the MGC and the time it sends an
update to the reporting termination.  This view differs from that understood
by the protocol design team, and needs to be considered in further work on
events.  It was also proposed that digit maps should be defined in packages
rather than as part of the basic protocol.  This drew unfavourable comment,
on the ground that it amounted to a structural change to the protocol as
currently defined and put an excessive amount of behaviour into a package.

The Chair noted that Megaco requires a number of extensions to SDP.  In his
view these extensions could be created following the process defined in RFC
2327 Appendix B on the basis of documentation produced by Megaco rather than
MMUSIC.  He will discuss this proposition with Joerg Ott
[[email-masked]], Chair of MMUSIC.

The Friday meeting concluded with a discussion of the future of Megaco.  The
general feeling was that there are definitely open issues which should be
tackled in H.248v2, but that work shouldn't start until we get some
implementation experience.  The advice provided by the closing speaker was
representative.  He suggested that the process from here on in should be
agreed on the list; that it would be more efficient to take future work to a
single body (probably the ITU-T), and that package development after the
basic set should be done by way of BOFs or, if sufficiently complex, by ad
hoc Working Groups.

Tom Taylor
Advisor -- IPConnect Standards
E-mail: [email-masked] (internally, Tom-PT Taylor)
Phone and FAX: +1 613 736 0961

---

From: Henry Sinnreich <[email-masked]>
Date: Mon, 15 Nov 1999 06:03:23 -0600

> preparation, for determination at the February SG 16 meeting
sorry, I missed that part, but wonder why the SIP option is not pursued
here, since a number of users and vendors have done work in the area of
inter-gateway signaling using SIP. A group of IETF authors have published
the revised draft

"SIP Best Current Practice for Telephony Interworking"
http://search.ietf.org/internet-drafts/draft-zimmerer-sip-bcp-t-00.txt

Tom, is there a reason why your WG report does not include this draft in the
options?
Could it be because SG.16 does not say so?

Henry

> -----Original Message-----
> From: Media Gateway Control (megaco)
> [mailto:[email-masked]]On Behalf Of Tom-PT Taylor
> Sent: Sunday, November 14, 1999 8:12 PM
> To: [email-masked]
> Subject: Summary of Megaco Meetings
>
>

---

From: Chip Sharp <[email-masked]>
Date: Mon, 15 Nov 1999 10:45:17 -0500

>Could it be because SG.16 does not say so?

1) Noone has proposed using SIP as a transport protocol.
2) The name of the draft is misleading (personal opinion)
3) SIP isn't a transport protocol

If you want to propose SIP as a transport for H.248, you are welcome to
write up an I-D or contribution for the next SG16 meeting describing the
hows and whys.

Chip

> > Phone and FAX: +1 613 736 0961

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------

---

From: Henry Sinnreich <[email-masked]>
Date: Mon, 15 Nov 1999 14:21:35 -0600

> If you want to propose SIP as a transport for H.248,
discussing only IETF work here Chip,

Henry

> [mailto:[email-masked]]On Behalf Of Chip Sharp
> Sent: Monday, November 15, 1999 9:45 AM
> Subject: Re: Summary of Megaco Meetings
>
>
> (and decision