Subject: Re: Summary of Megaco Meetings

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

OK, you've made a reasonable case for encapsulation of Megaco/H.248 within
SIP under some circumstances.  I think this is an idea worth pursuing, but I
don't think it falls within the current mandate of Megaco.  It's like your
paper on QOS and call signalling -- more architectural in nature.  Why don't
we start laying the groundwork for a BOF on the subject in Adelaide?

> -----Original Message-----
> From: Henry Sinnreich [SMTP:[email-masked]]
> Sent: Monday, November 15, 1999 10:09 AM
> To:   Taylor, Tom-PT [CAR:B904-I:EXCH];
> [email-masked]
> Cc:   [email-masked]
> Subject:      RE: Summary of Megaco Meetings
>
> >SIP is not a very good transport protocol...
>
> Service providers beg to differ. Please see the attached.
>
> >I would prefer to think of the Enhanced Services
> >platform as managing a set of connections,
> >some of which might involve MG's. e.g. a
> >network of SIP phones talking to each other
> >and to MG's.
>
> Steve, my apology for bringing you into this discussion, but the attached
> just came in handy.
>
> Henry
>
> From:  [email-masked]
> <mailto:[email-masked]> on behalf of Gardell,
> Steve [ [email-masked] <mailto:[email-masked]>]
> Sent: Monday, November 15, 1999 8:02 AM
> To: 'Gregory D. Girard'; [email-masked]
> <mailto:[email-masked]>
> Subject: RE: NEW TOPIC: Enhanced Services using SIP and  MGCP
>
> An insightful description and a good start
> at a list of basic requirements. I would
> prefer to think of the Enhanced Services
> platform as managing a set of connections,
> some of which might involve MG's. e.g. a
> network of SIP phones talking to each other
> and to MG's.
>
> Steven Gardell
> GTE Laboratories
> Voice: 781-466-2681, Fax: 781-466-3375
>
>
> > -----Original Message-----
> > From: Gregory D. Girard [ <mailto:[email-masked]>]
> > Sent: Tuesday, November 09, 1999 7:28 AM
> > To: [email-masked]
> <mailto:[email-masked]>
> > Subject: NEW TOPIC: Enhanced Services using SIP and MGCP
> >
> >
> > SIP versus MGCP for Interfacing Enhanced Services Platforms
> >
> > *** DISCLAIMER: The following post is long one aimed at solving a much
> > larger problem than that immediately addressed by SIP. Please
> > feel free to
> > ignore unless your interests lie in the interface between the
> > softswitch and
> > an Enhanced Services Platform (based upon SIP an other protocols) ***
> >
> > It is my observation that basic call completion and
> > management operations
> > supported by SIP are not up to the level of control supported by MGCP.
> > Collection of DTMF digits according to a digit map stands as
> > one example,
> > and while "possible" in SIP, is not a basic feature defined
> > for SIP. At the
> > same time, MGCP provides excellent switching-matrix-oriented
> > control over
> > low-level call control operations (including access to
> > physical endpoints in
> > a matrix and DTMF digit maps) but does not provide the
> > high-level signaling
> > required for more generalized "service-oriented"
> > functionality. For example,
> > MGCP cannot tell me ultimately who the call came from nor to
> > whom it was
> > directed, and is only capable of providing physical endpoint
> > addressing.
> > As a result, it would appear that as an integration layer,
> > neither SIP nor
> > MGCP alone would allow an enhanced services platform to
> > receive a call and
> > render a complex service. Neither protocol has all the parts
> > necessary to
> > support anything but the most simple, passively-activated
> > enhanced service
> > (i.e. voice mail).
> >
> > While it is understood that any number of SIP extensions
> > could be created to
> > support such operations, it would basically require
> > incorporating an MGCP
> > message set into SIP, along with some notion of local or virtual
> > "switching matrix" element to serve as a medium over which those
> > operations would be performed.
> >
> > At the same time, MGCP could be exended as well, but being a simple
> > client/server protocol with a 1:1 mapping of call agent
> > instance to MG, it
> > does not have all the relocation and proxy services of SIP.
> > Besides, MGCP
> > associates a controlling element with some physical switching matrix
> > resource, thus resource contention and scaling problems would
> > result by
> > presenting application-level call control as "bound" to some
> > specific device
> > under control of the Softswitch, and the control element would not be
> > interfacing and not the softswitch itself.
> >
> > ***It is my impression that it is generally agreed that
> > Enhanced Services
> > Platforms will work better if they talk to softswitches than MGs.
> >
> > Where does that leave someone who wishes to tightly integrate
> > an enhanced
> > services platform with a softswitch ? Does one extend one protocol to
> > incorporate features of the other ?  Does one establish and an MGCP
> > session for every SIP connection ? Is is feasible for SIP,
> > as will be specified in forthcoming embodiments, to
> > incorporate low-level
> > call control features contained within MGCP, perhaps on a
> > session-by-session basis ?
> >
> > Thus, for SIP-BCP-T to be useful as more than an inter-softswitch to
> > communictions mechanism for call setup/tear down, does it make sense
> > to rethink its mission in life with respect to enhanced
> > services, or is that
> > capability
> > already inherent in SIP ? To say that any "SIP implementer"
> > can add this
> > functionality
> > is not at all helpful because without general agreement of features it
> > becomes
> > impossible to promote vendor-specific extensions as any
> > "standard" at all.
> > I am aware of the SIP call control extensions exist for blind
> > transfer an
> > other such features.
> >
> > I am also aware that the basic problem in putting SIP and
> > MGCP together
> > relates to the fact that SIP is oriented to managing call sessions
> > whereas MGCP is oriented towards managing switching matrixes.
> > An Enhanced Service Platform needs to operate on both planes. But it
> > is the objective of my inquiry to avoid creating some ugly propriety
> > interface and instead rely upon standards as much as possible.
> >
> > Basic features required for Enhanced Services Platform (ESP)
> > intergration
> > with a softswitch include the following list below. This is an e-mail
> > message for general consideration written off the top of my head in 15
> > minutes and not an exhaustive treatment of the subject; so I
> > would ask that
> > commentary of the items below focus on the general control
> > issues as can
> > best be interpreted from the muddled presentation. The terms "call",
> > "connection" and "call leg" mean different things to
> > different technology
> > domains. Keep in mind below that the ESP may incorporate the
> > "announcement
> > server" in some cases, thus connections that require
> > play/record of prompts
> > will potentially terminate on ESP.
> >
> > 1- Originate/Answer/Disconnect voice connections between any
> > two network
> > addresses. Connections managed under control of Softswitch
> > and potentially
> > even terminating on ESP for IVR purposes; all connections
> > routed through a
> > MG under Softswitch control.
> >
> > 2- Monitor Q.931 (or equivelent) call state information for
> > specified call
> > session under
> > control of Softswitch
> >
> > 3- Collect DTMF digits on specified connection
> >
> > 4- Generate DTMF digits on a specified connnection (for pager dialing
> > interface, for example)
> >
> > 5- Create/Add/Remove full or half-duplex call leg to call
> > under control of
> > Softswitch, potentially terminating on ESP (all connections
> > routed MG under
> > Softswitch control)
> >
> > 6- Transfer one call/connection to another
> >
> > 7- Originate/Answer/Disconnect connection under control of
> > softswith with
> > media type of T.38 fax such fax image may be transmitted and
> > received using
> > DSP fax algorithms residing in certain MGs under control of
> > Softswitch.
> >
> > Any commentary of accomplishing this level of interface using
> > SIP would be
> > greatly appreciated. If nothing else, I offer to those
> > thinking about SIP
> > some relevent context for the application of their work. It
> > would seem that
> > interfacing
> > with ESP would be an important consideration for and future
> > revisions of
> > SIP, and
> > thus this inquiry may stimulate some discussion of the topic.
> >
> > Greg Girard
> > CTO
> > Iperia, Inc.
> >
> >
> >
> >
> >
> >
> >
>
>
>       -----Original Message-----
>       From: Media Gateway Control (megaco)
> [mailto:[email-masked]]On Behalf Of Tom-PT Taylor
>       Sent: Monday, November 15, 1999 7:43 AM
>       To: [email-masked]
>       Subject: Re: Summary of Megaco Meetings
>
>
>
>       SIP is not a very good transport protocol -- too much overhead.  In
> the SIP/ISUP case, it adds value by coordinating the delivery of ISUP and
> SDP, two different protocols.  It also provides an evolution path to pure
> SIP-based signalling.  In the Megaco case you don't have two protocols
> needing coordination, and for the moment, at least, proxies are irrelevant
> so that aspect of SIP is of no use.
>
>               -----Original Message-----
>       From:   Henry Sinnreich [SMTP:[email-masked]]
>       Sent:   Monday, November 15, 1999 8:34 AM
>       To:     Taylor, Tom-PT [CAR:B904-I:EXCH];
> [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.
>
>
>       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];
> [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 14:11:10 -0600

RE: Summary of Megaco Meetings>I think this is an idea worth pursuing
the only issue in this discussion is to mention SIP as an option for
inter-gateways signaling and not only to mention SIGTRAN alone. Suggest the
SIP WG paper as reference
"SIP Best Current Practice for Telephony Interworking"
< <http://search.ietf.org/internet-drafts/draft-zimmerer-sip-bcp-t-00.txt>>
 and any other from the SIP WG.

Can we get agreement and closure on mentioning both SIP and SIGTRAN? Or not
mention either...

Henry

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

    >network of SIP phones talking to each other

    Steve, my apology for bringing you into this discussion, but the
attached just came in handy.

    Henry

    From:  [email-masked]
<mailto:[email-masked]> on behalf of Gardell, Steve
[ [email-masked] <mailto:[email-masked]>]
    Sent: Monday, November 15, 1999 8:02 AM
    To: 'Gregory D. Girard'; [email-masked]
<mailto:[email-masked]>
    Subject: RE: NEW TOPIC: Enhanced Services using SIP and  MGCP

    Steven Gardell
    GTE Laboratories

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

      Henry

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

                        > 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

                        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

        > [ < <mailto:[email-masked]>>]On Behalf Of
Tom-PT Taylor
        > This message summarizes the outcome of the Megaco meetings held
Wednesday
        > and Friday mornings Nov. 10 and 12 respectively, plus design team
and
        > 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
        > 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
        > Brian Rosen [[email-masked]] presented the results of the
Redbank
        > meeting.   He noted that despite a great deal of discussion in
Redbank, we
operation of
        > events and signals.  Following Brian's presentation, Mike Kallas
        > [[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
        > 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).
        >
        > 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
        > 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
        > Most of the remainder of the meeting was spent discussing open
issues, and
        > particularly proposals arising out of the design meetings and
informal
        > An important point noted in this discussion was that transport
        > may vary per
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
        > 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
        > 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
        > 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
        > E-mail: [email-masked] (internally, Tom-PT Taylor)