Subject: Re: Summary of Megaco Meetings

From: Tom-PT Taylor <[email-masked]>
Date: Mon, 15 Nov 1999 08:42:44 -0500

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 09:09:24 -0600

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] on behalf of Gardell, Steve
[[email-masked]]
Sent: Monday, November 15, 1999 8:02 AM
To: 'Gregory D. Girard'; [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

> From: Gregory D. Girard [mailto:[email-masked]]
> Sent: Tuesday, November 09, 1999 7:28 AM
> To: [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

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

    >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];

              > providing the option of Megaco/H.248 transport over SIGTRAN
SCTP was in

              Henry

Taylor
Wednesday
and
still
some
work by
ITU-T
      > Study Group 16.  ITU-T management had been advised of this change in
can
the
      > requirements needed clarification.  Many cases were noted where the
      > requirements will be met when work on package specification has been
new
IETF
interception
Redbank
Redbank, we
      > still do not have a fully satisfactory description of the operation
of
      > [[email-masked]] presented the status of the work
on
leadership of
This team
considered two
determine
      > terminations have been created in the MG.  The third topic of how to
keep
meeting
were
failed to
Thursday
      > discussion of this item, it was noted that a document is needed that
fit
      > such a document.  Chip Sharp [[email-masked]] noted that an annex
      > providing the option of Megaco/H.248 transport over SIGTRAN SCTP was
in
decision
issues, and
informal
      > stream, so that the same termination supports both Video/RTP/UDP/IP
and
assume
transport
      > supported on the termination.  Two proposals to simplify audits were
      > accepted as worth consideration on the list.  One is to specify the
naming
events
      > were also discussed.  One of these proposals was to eliminate event
latter
pointed
those
work on
protocol as
package.
should be
      > tackled in H.248v2, but that work shouldn't start until we get some
speaker was
should be
      > 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