Subject: Re: Summary of Megaco Meetings

From: Tom-PT Taylor <[email-masked]>
Date: Mon, 15 Nov 1999 07:30:06 -0600

The SCTP transport is positioned here simply as an alternative to transport
over TCP or UDP/ALF, between the MG and MGC.  Megaco/H.248 is NOT working on
inter-MGC signalling.

> -----Original Message-----
> From: Henry Sinnreich [SMTP:[email-masked]]
> Sent: Monday, November 15, 1999 7:03 AM
> To:   Taylor, Tom-PT [CAR:B904-I:EXCH];
> [email-masked]
> Subject:      RE: Summary of Megaco Meetings
> Importance:   High
>
> > providing the option of Megaco/H.248 transport over SIGTRAN SCTP was in
> > 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
> >
> >
> > 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 07:34:29 -0600

RE: Summary of Megaco Meetings>The SCTP transport is positioned here simply
as an alternative to transport over TCP or UDP/ALF, between the MG and MGC.
Megaco/H.248 is NOT working on inter->MGC signalling.

Tom, would still like to know why you have not included SIP as an option.
"SIP Best Current Practice for Telephony Interworking"
http://search.ietf.org/internet-drafts/draft-zimmerer-sip-bcp-t-00.txt

Henry

  -----Original Message-----
  From: Tom-PT Taylor [mailto:[email-masked]]
  Sent: Monday, November 15, 1999 7:30 AM
  To: Henry Sinnreich; [email-masked]
  Subject: RE: Summary of Megaco Meetings

  The SCTP transport is positioned here simply as an alternative to
transport over TCP or UDP/ALF, between the MG and MGC.  Megaco/H.248 is NOT
working on inter-MGC signalling.

    -----Original Message-----
    From:   Henry Sinnreich [SMTP:[email-masked]]
    Sent:   Monday, November 15, 1999 7:03 AM
    To:     Taylor, Tom-PT [CAR:B904-I:EXCH];

    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

    Henry

Wednesday
    > deficiencies, the latest proposal is to mark the completion of the
work by
interception
    > meeting.   He noted that despite a great deal of discussion in
Redbank, we
of
team
two
determine
keep
meeting
    > question of how events operate within the protocol.  The meeting
failed to
decision
and
transport
naming
pointed
    > by the protocol design team, and needs to be considered in further
work on
package.
be
was
    > basic set should be done by way of BOFs or, if sufficiently complex,
by ad