Rev..3 RE: [wg5-3: 2134] q11h17/apc1457 rev. 2

Yoshihiro Kikuchi kiku at EEL.RDC.TOSHIBA.CO.JP
Wed Nov 25 06:06:36 EST 1998


This message has been cross-posted to the Bellcore SGCP list, the ITU SG16
AVC list, and the TIPHON list.  All follow-ups to navdec at BayNetworks.COM,
please.  To join the navdec list (probably soon to be renamed megaco), send
a message to majordomo at baynetworks.com with "subscribe navdec" (no quotes)
in the body.

At the bottom of this message is the device control working group charter as
it currently stands.  We can tweak it a bit in the December meeting.  I am
still working up the agenda and document list for that meeting, which will
be on Friday morning, Dec. 11.  In the meantime, I would like consideration
given to the following:

  1. What is the minimum we can put into a first protocol draft?  I don't
want us to drag this out for two years before we get our first
standards-track RFC.  Let me put this on the table: the core functionality
is connection making and media stream manipulation.  Event detection,
insertion, and scripting are follow-up items.  We might spend some of our
time considering what kinds of connections and what kinds of media stream
transformations the first protocol RFC should support.  If people want to
work in parallel on RFCs for specific applications, that's fine.

 2. Scott appointed me partly because of my strong interest in trying to
keep ETSI TIPHON, ITU-T Study Group 16, and our own working group working
together.  The other groups are particularly interested in trunking gateways
in an H.323 context.  SG 16 is interested in multimedia, not just audio.  I
would like suggestions on how we and they can organize our work to minimize
conflict and maximize commonality.

3. Nancy Greene has done a lot of work on architecture and requirements in
the past.  I propose that she be Document Editor for the architecture and
requirements RFC on our work list.

More later.

Tom Taylor
taylor at nortelnetworks.com
Ph. +1 613 765-4167

> -----Original Message-----
> From: Steve Coya [SMTP:scoya at ns.cnri.reston.va.us]
> Sent: Monday, November 23, 1998 12:05 PM
> To:   IETF-Announce
> Cc:   new-work at ietf.org
> Subject:      Proposed IETF Working Group: MEdia GAteway COntrol (megaco)
>
> A new IETF working group has been proposed in the Transport Area.
> The IESG has not made any determination as yet.
>
> The following Description was submitted, and is provided for
> informational purposes:
>
>
> The working group will develop an informational RFC detailing the
> architecture and requirements for controlling Media Gateways from
> external control elements such as a Media Gateway Controller. A media
> gateway is a network element that provides conversion between the
> information carried on telephone circuits and data packets carried over
> the Internet or over other IP networks.  This work will be done in
> consultation with other IETF working groups looking at similar issues.
> The working group will also ensure that good information conduits exist
> with groups in other standards groups with expertise in the relevant
> PSTN technology.  Other IETF working groups include PINT, IPTEL and
> SIGTRAN.  In addition the working group will ensure that reasonable
> liaisons exist with similar activities in other standards bodies such as
> the ITU-T and ETSI.
>
> This working group will also define standards track protocol(s) for
> controlling media gateways from external control elements such as a
> media gateway controller.
>
> Examples of media gateways are:
>
>  * Trunking gateways that interface between the telephone
>    network and a Voice over IP network. Such gateways
>    typically manage a large number of digital virtual circuits.
>  * Access gateways that provide traditional analog or Primary
>    Rate (PRI) line interfaces to a Voice over IP network.
>  * Network Access Servers that can attach a "modem" to a
>    telephone circuit and provide data access to the
>    Internet.
>
> This working group assumes a separation of call control so the call
> control "intelligence" is outside the media gateways and handled by a
> media gateway controller. This group will NOT work on media gateway
> controller to media gateway controller protocols, nor on media gateway
> to media gateway protocols.
>
> Planned output:
>
>   * Architecture & Requirements informational RFC
>
>   * Standards Track RFC for the protocol between a media
>     gateway controller and a media gateway.
>
>   * Standards Track RFC for the MG and MC MIBs
>
>   * Informational RFC for application programming interface
>     for the MC to MG protocol



More information about the sg16-avd mailing list