October 1998 - sg16-avd - lists.packetizer.com

Gateway Decomposition Call Summary and Next Meeting Request
by Mark Reid 28 Oct '98

28 Oct '98

Gateway Call Summary 10/20/98 11AM-1PM EDT Attendees registered for call *********************************** Bellcore, AT&T, Cisco, Nortel, Lucent, Intel, Siemens, Level 3, Ascend, 3COM, IBM, Telia, MCI, NEC, PictureTel, Sun Microsystems, RADVision, Accord, Selsius, Madge, AGCS, IDT/Net2Phone, VTEL, Dialogic, NetSpeak, Delta Information, Ricochet, Trillium Digital Systems, Teleogy Networks, Univ Bremen, Perey Consulting, VideoServer, others Call purpose summary *************************** The goal of the audio call was to identify the work items we need to complete heading into the November Q14 meeting on H.323 Gateways interworking with switched circuit networks. Agreements reached on call ********************************** 1) Interface A is a high priority item. It is a new protocol and the first item of work should be the definition of its scope and requirements. There was agreement that Interface A should be media related and not be associated with call setup. It was agreed that Interface A would deal with the allocation and management of resources used for packet/circuit media conversion (e.g. DSP's for modem, fax, transcoding, etc.) It was agreed to keep the scope of Interface A within the terms of reference outlined in paragraph 3.4.1 of TD89. For example, we are not trying to replace existing H.323 functionality with a new protocol. 2) We will specify the Interworking of H.323 to SS7/ISUP signaling (potentially something similar to Q.699) and the Interworking of H.323 to SCN FAS/NFAS signaling. This work will most likely be contained in an H.246 Annex. 3) We will complete H.246 Annex B - the media conversion of H.323 to voice/voiceband terminals. (e.g. DTMF to UUI, etc.) 4) We agreed to exclude the MC to MP communication definition from the work destined for determination at the next Study Group meeting. Active discussions ********************** 1) What should we do with Interfaces B, C, and D? Given that the messages passing across these interfaces must reflect all of the content of the signaling that the respective signaling functions receive from and send to external entities ... are these protocols modified or extended ISUP for Interface D, modified or extended Q.931 or QSIG for Interface C, and modified or extended H.225 for Interface B? ... or are they a new abstract protocol (ABP) that ISUP, FAS/NFAS, and H.225 are converted to? The proponents of the abstract protocol said it would allow the high level gateway control logic to be shielded from the H.225/FAS-NFAS/ISUP state machines. Others said that too much information would be lost in a conversion between H.225/FAS-NFAS/ISUP and an abstract protocol (ABP) and that the ABP would end up having all of the fields carried on the H.225, FAS-NFAS, and ISUP interfaces. No conclusion was reached for moving forward. Nortel suggested with look at specific call scenarios to drive the requirements of Interfaces B, C, and D. General information ********************** BellCore reported that IPDC and SGCP have merged their protocol proposals as MGCP. MGCP was introduced into the IETF on 10/19 and according to Nortel, a working group is being kicked off in the IETF. There was a discussion on how to get the IETF and ITU-T to work together on these protocols but no conclusion was reached. MGCP information will be posted to the ITU reflector. Next meeting *************** I would like to invite you to participate in an audio call, Tuesday November 3rd from 11AM to 1PM EST to discuss our continued work plan for gateway decomposition. Please send bridge port requests directly to me (mreid(a)videoserver.com) by Monday November 2nd at 12:00 Noon EST so that I can make the proper arrangements. I will send port assignments later that day. All comments on this summary are welcome! Mark

2 1

Re: Gateway Decomposition Call Summary and Next Meeting Request
by Roy Spitzer 27 Oct '98

27 Oct '98

Mark, I would like to participate in this teleconference. Regards, Roy Roy Spitzer Telogy Networks Phone (301) 515-6531 20250 Century Boulevard Fax: (301) 515-7954 Germantown, Maryland 20874 email: rspitzer(a)telogy.com -----Original Message----- From: Mark Reid [mailto:mreid@VIDEOSERVER.COM] Sent: Monday, October 26, 1998 2:02 PM To: ITU-SG16(a)mailbag.cps.INTEL.com Subject: Gateway Decomposition Call Summary and Next Meeting Request Gateway Call Summary 10/20/98 11AM-1PM EDT Attendees registered for call *********************************** Bellcore, AT&T, Cisco, Nortel, Lucent, Intel, Siemens, Level 3, Ascend, 3COM, IBM, Telia, MCI, NEC, PictureTel, Sun Microsystems, RADVision, Accord, Selsius, Madge, AGCS, IDT/Net2Phone, VTEL, Dialogic, NetSpeak, Delta Information, Ricochet, Trillium Digital Systems, Teleogy Networks, Univ Bremen, Perey Consulting, VideoServer, others Call purpose summary *************************** The goal of the audio call was to identify the work items we need to complete heading into the November Q14 meeting on H.323 Gateways interworking with switched circuit networks. Agreements reached on call ********************************** 1) Interface A is a high priority item. It is a new protocol and the first item of work should be the definition of its scope and requirements. There was agreement that Interface A should be media related and not be associated with call setup. It was agreed that Interface A would deal with the allocation and management of resources used for packet/circuit media conversion (e.g. DSP's for modem, fax, transcoding, etc.) It was agreed to keep the scope of Interface A within the terms of reference outlined in paragraph 3.4.1 of TD89. For example, we are not trying to replace existing H.323 functionality with a new protocol. 2) We will specify the Interworking of H.323 to SS7/ISUP signaling (potentially something similar to Q.699) and the Interworking of H.323 to SCN FAS/NFAS signaling. This work will most likely be contained in an H.246 Annex. 3) We will complete H.246 Annex B - the media conversion of H.323 to voice/voiceband terminals. (e.g. DTMF to UUI, etc.) 4) We agreed to exclude the MC to MP communication definition from the work destined for determination at the next Study Group meeting. Active discussions ********************** 1) What should we do with Interfaces B, C, and D? Given that the messages passing across these interfaces must reflect all of the content of the signaling that the respective signaling functions receive from and send to external entities ... are these protocols modified or extended ISUP for Interface D, modified or extended Q.931 or QSIG for Interface C, and modified or extended H.225 for Interface B? ... or are they a new abstract protocol (ABP) that ISUP, FAS/NFAS, and H.225 are converted to? The proponents of the abstract protocol said it would allow the high level gateway control logic to be shielded from the H.225/FAS-NFAS/ISUP state machines. Others said that too much information would be lost in a conversion between H.225/FAS-NFAS/ISUP and an abstract protocol (ABP) and that the ABP would end up having all of the fields carried on the H.225, FAS-NFAS, and ISUP interfaces. No conclusion was reached for moving forward. Nortel suggested with look at specific call scenarios to drive the requirements of Interfaces B, C, and D. General information ********************** BellCore reported that IPDC and SGCP have merged their protocol proposals as MGCP. MGCP was introduced into the IETF on 10/19 and according to Nortel, a working group is being kicked off in the IETF. There was a discussion on how to get the IETF and ITU-T to work together on these protocols but no conclusion was reached. MGCP information will be posted to the ITU reflector. Next meeting *************** I would like to invite you to participate in an audio call, Tuesday November 3rd from 11AM to 1PM EST to discuss our continued work plan for gateway decomposition. Please send bridge port requests directly to me (mreid(a)videoserver.com) by Monday November 2nd at 12:00 Noon EST so that I can make the proper arrangements. I will send port assignments later that day. All comments on this summary are welcome! Mark

1 0

Re: Gateway Decomposition Call Summary and Next Meeting Request
by Ami Amir 26 Oct '98

26 Oct '98

Mark Can you schedule the call for 9am EST instead of 11? Thanks Ami Mark Reid wrote: > > ---------- > > From: Mark Reid[SMTP:MREID@VIDEOSERVER.COM] > > Sent: Monday, October 26, 1998 9:02:23 PM > > To: ITU-SG16(a)mailbag.cps.intel.com > > Subject: Gateway Decomposition Call Summary and Next Meeting Request > > Auto forwarded by a Rule > > > Gateway Call Summary 10/20/98 11AM-1PM EDT > > Attendees registered for call > *********************************** > Bellcore, AT&T, Cisco, Nortel, Lucent, Intel, Siemens, Level 3, Ascend, > 3COM, IBM, Telia, MCI, NEC, PictureTel, Sun Microsystems, RADVision, Accord, > Selsius, Madge, AGCS, IDT/Net2Phone, VTEL, Dialogic, NetSpeak, Delta > Information, Ricochet, Trillium Digital Systems, Teleogy Networks, Univ > Bremen, Perey Consulting, VideoServer, others > > Call purpose summary > *************************** > The goal of the audio call was to identify the work items we need to > complete heading into the November Q14 meeting on H.323 Gateways > interworking with switched circuit networks. > > Agreements reached on call > ********************************** > 1) Interface A is a high priority item. It is a new protocol and the first > item of work should be the definition of its scope and requirements. There > was agreement that Interface A should be media related and not be associated > with call setup. It was agreed that Interface A would deal with the > allocation and management of resources used for packet/circuit media > conversion (e.g. DSP's for modem, fax, transcoding, etc.) It was agreed to > keep the scope of Interface A within the terms of reference outlined in > paragraph 3.4.1 of TD89. For example, we are not trying to replace existing > H.323 functionality with a new protocol. > 2) We will specify the Interworking of H.323 to SS7/ISUP signaling > (potentially something similar to Q.699) and the Interworking of H.323 to > SCN FAS/NFAS signaling. This work will most likely be contained in an H.246 > Annex. > 3) We will complete H.246 Annex B - the media conversion of H.323 to > voice/voiceband terminals. (e.g. DTMF to UUI, etc.) > 4) We agreed to exclude the MC to MP communication definition from the work > destined for determination at the next Study Group meeting. > > Active discussions > ********************** > 1) What should we do with Interfaces B, C, and D? > > Given that the messages passing across these interfaces must reflect all of > the content of the signaling that the respective signaling functions receive > from and send to external entities ... are these protocols modified or > extended ISUP for Interface D, modified or extended Q.931 or QSIG for > Interface C, and modified or extended H.225 for Interface B? ... or are they > a new abstract protocol (ABP) that ISUP, FAS/NFAS, and H.225 are converted > to? > > The proponents of the abstract protocol said it would allow the high level > gateway control logic to be shielded from the H.225/FAS-NFAS/ISUP state > machines. Others said that too much information would be lost in a > conversion between H.225/FAS-NFAS/ISUP and an abstract protocol (ABP) and > that the ABP would end up having all of the fields carried on the H.225, > FAS-NFAS, and ISUP interfaces. > > No conclusion was reached for moving forward. > > Nortel suggested with look at specific call scenarios to drive the > requirements of Interfaces B, C, and D. > > General information > ********************** > BellCore reported that IPDC and SGCP have merged their protocol proposals as > MGCP. MGCP was introduced into the IETF on 10/19 and according to Nortel, a > working group is being kicked off in the IETF. There was a discussion on how > to get the IETF and ITU-T to work together on these protocols but no > conclusion was reached. MGCP information will be posted to the ITU > reflector. > > Next meeting > *************** > I would like to invite you to participate in an audio call, Tuesday November > 3rd from 11AM to 1PM EST to discuss our continued work plan for gateway > decomposition. > > Please send bridge port requests directly to me (mreid(a)videoserver.com) by > Monday November 2nd at 12:00 Noon EST so that I can make the proper > arrangements. I will send port assignments later that day. > > All comments on this summary are welcome! > > Mark

1 0

Archives
by Juan C Uribe G 26 Oct '98

26 Oct '98

Hi, We are developing an H323 stack and we haver several questions. But before I ask any specific questions I would like to know: 1) Is there any archive with all the questions that have been posted to this list? 2) How do I subscribe to this list? Thanks a lot, Juan C Uribe G

1 0

question about video conferencing over a LAN
by Amr Ibrahim 22 Oct '98

22 Oct '98

i'm so sorry for bothering any body but if this subject concern you or you interested in help please do. we are students in the faculty of engineering (communication and electroniscs dep.)in the last year and we are doing now our final project it is about video conferencing over a LAN and we ant to help us in this certain subjects 1. any refrences such as books (name the book and author) , technical our tutorial sites , if you have any magazines not commercial one 2.what are the future trends and the present projects done with students nowdays 3.what is the best programming language to use (interface with desktop /interface with audio and video cards and cameras) 4.prices of of interface network cards ,cameras(what best fit parallel port or TV tuner). 5.what is the best compression used in audio and video (please give us tutorial or book) 6.what is the protocols used over a LAN to adopt video and video 7.if there is any demos or shareware products please tell us if there is anyhting i forget or you want to help us in this project please inform us and please don't hesitate in helping us we are really confused and don't know from where to start thanks very much for reading this please reply as soon as possible goodbye

1 0

Re: APC numbers.
by Sakae OKUBO 22 Oct '98

22 Oct '98

Dear Roni Even, > Please allocate an APC number for me. > The Title will be RTP Maximum Packet size. APC-1428 has been allocated to your contribution. Best regards, Sakae OKUBO (Mr.) *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** Documents for the Torino meeting (17-20 November 1998) ----------------------------------------------------------------------- APC- Source Provisional title ----------------------------------------------------------------------- 1426 India Internet traffic on the PSTN 1427 Korea Telecom Required functions of RTP receiver and packet forwarding procedure for Dynamic Multicast Network 1428 Accord Video Telecommunication RTP Maximum Packet size -----------------------------------------------------------------------

1 0

FW: Gk-GK Call signalling
by Tom-PT Taylor 20 Oct '98

20 Oct '98

> -----Original Message----- > From: Ericsson User [SMTP:etxjaeh@AL.ETX.ERICSSON.SE] > Sent: Thursday, October 15, 1998 4:31 AM > To: TIPHON(a)LIST.ETSI.FR > Subject: Re: Gk-GK Call signalling > > Jim, > It was written into the scope of Annex G that the Annex is only about > RAS. > > An Example: > If you have one Gatekeeper only. That Gatekeeper have a lot of > information about the user. This information is non-standardized > properties, e.g the language of the user, the maximum cost of a call to > PSTN / minute etc ... > further more the Gatekeeper has a lot of information about the Gateways > e.g. the cost for breaking out to PSTN. > > > An other example is the phone-to-phone case when ISUP is involved on > both sides. > The following parameters are missing or can not be transported > correctly: (i.e they are also impossible to re-generate in the Gateways) > > Access delivery information > Automatic congestion level > Backward call indicators > Call diversion information > Call history information > Calling party number (Presentation indicators can not be transported) > Calling party's category > Closed user group interlock code > Connected number(Presentation indicators can not be transported) > Connection request > Echo control information > Facility indicator > Forward call indicators > Freephone indicators > Generic digits > Generic number(Presentation indicators can not be transported if > required) > Generic reference > Hop counter > Information indicators @ > Information request indicators > Location number > MCID request indicator > MCID response indicator > Message compatibility information > MLPP precedence > Nature of connection indicators > Network specific facilities > Optional backward call indicators > Optional forward call indicators > Original called number > Origination ISC point code > Parameter compatibility information > Propagation delay counter > Redirecting number(Presentation indicators can not be transported) > Redirection information > Redirection number(Presentation indicators can not be transported) > Redirection number restriction > Service activation @ > Signalling point code @ > Subsequent number > Suspend/Resume indicators > > There are also a number of Messages that cant be interworked. > > /Best Regards Jan Holm > > > Jim Toga wrote: > > > > Jan, > > > > Being one of the contributors of some of the text.... There was no > intent > > to limit GK-GK communications to RAS or Call Control. The plan of > attack > > was to initially solve some specific issues with being able to complete > > Inter-zone calls. > > > > The fact that the messages are carried in RAS format was simply a > straw-man > > proposal. The content and logic was the important starting point. > > > > As is always the case, this work moves forward with contributions. > What > > specific functions do you want to acomplish? It might help me (and > others) > > to understand where the specific holes are, in order to figure out what > the > > next holes are (in the IP context) rather simply saying we need to port > > ISUP to GKs. > > > > Best Regards, > > jimt. > > > > At 01:39 PM 10/13/98 +0100, Ericsson User wrote: > > >Hello All, > > >I participated in the SG 16 meeting in Geneva in september. > > > > > >One thing that suprised me was that the ongoing work with Annex G > (GK-GK > > >signalling) did not consider call control, only the RAS signalling. > > > > > >When I asked why, they did not understand why any change is required. > > >After a while they understood that something could be needed, but it > was > > >postponed to future releases of H.323. > > > > > >Future releases must be version 4 or something (around year 2001 or > > >later ??). > > > > > >The conclusion is then (looking on TIPHON project plan) that H.323 > can't > > >be used between Gatekeepers in TIPHON compliant system. > > > > > >The question is then: What do we use then? ISUP? B-ISUP? SIP? Extended > > >subset of H.323? > > > > > > > > >/Jan Holm > > >Ericsson Telecom AB > > > > > >------------------------------------------------------------------- > > >ATTENTION !!! TIPHON list distribution parameters have changed: > > >==> if you REPLY to a TIPHON mail your mail will be sent to the > > >original sender only. > > >==> if you use REPLY ALL your mail will be sent to TIPHON and > > >to the original sender. > > >------------------------------------------------------------------- > > > > > > > ***************************************************** > > *** +1-503-264-8816(voice) Intel - Hillsboro, OR. > > *** > > *** mailto:jim.toga@intel.com mailto:james.toga@ties.itu.int > *** > > *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41 *** > > ***************************************************** > > > > ------------------------------------------------------------------- > > ATTENTION !!! TIPHON list distribution parameters have changed: > > ==> if you REPLY to a TIPHON mail your mail will be sent to the > > original sender only. > > ==> if you use REPLY ALL your mail will be sent to TIPHON and > > to the original sender. > > ------------------------------------------------------------------- > > ------------------------------------------------------------------- > ATTENTION !!! TIPHON list distribution parameters have changed: > ==> if you REPLY to a TIPHON mail your mail will be sent to the > original sender only. > ==> if you use REPLY ALL your mail will be sent to TIPHON and > to the original sender. > -------------------------------------------------------------------

1 0

[Fwd: SGCP+IPDC => MGCP]
by Hong Liu 20 Oct '98

20 Oct '98

Hi, all, I would like to inform you on the most recent development in converging SGCP and IPDC for IP device control. The merged protocol is called MGCP (or media gateway control protocol). This is an important step towards the realization of gateway decomposition for VoIP. I hope this will help the new work item within SG 16 on the same issue. Best regards, --Hong

1 0

Re: Gateway Decomposition Audio Conference
by Grant G. Paul Jr 20 Oct '98

20 Oct '98

Mark-- Sorry for the late response. Could I please be part of the conference? -- Grant Paul MITRE - ------------------------------------------------------------------------------- - ----------------------------- The based document can be found at ftp://standard.pictel.com/avc-site/9809_Gen/Tosco_WP2_report.zip The file is named Report Part1.doc > -----Original Message----- > From: Mark Reid [SMTP:mreid@VIDEOSERVER.COM] > Sent: Monday, October 19, 1998 3:02 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: Gateway Decomposition Audio Conference > > Dear Colleagues, > > The gateway audio call will be tomorrow Oct 20th from 11AM - 1PM EDT. > > The dial in numbers are: > > From the US: 1-800-857-5018 > From outside the US: 1-712-271-0925 > > The Confirmation Number is: 2304944 > Passcode: Mark Reid > > Let me know if you have any questions or problems, > > Mark Reid > VideoServer Inc > 1-781-505-2368 > > > -----Original Message----- > > From: Mark Reid [SMTP:mreid@VIDEOSERVER.COM] > > Sent: Friday, October 16, 1998 4:53 PM > > To: ITU-SG16(a)mailbag.cps.intel.com > > Subject: > > > > Dear Colleagues, > > > > I would like to invite you to participate in an audio call, > > Tuesday > > October > > 20th from 11AM to 1PM EST to discuss our work plan for the study > > of > > gateway > > decomposition as outlined in TD 89 (WP2). > > > > The goals of the audio call will be to identify what work items > we > > need to > > completed and in what order should we attack them. Once we have > an > > agreed to > > work plan, we can talk about building an architecture document > and > > the > > specific requirements of each interface. > > > > As a place to start the discussions, I think we need the > following > > (referenced to TD 89): > > > > New Protocols: > > ***************** > > Interface A - Device Control Interface > > > > New H.246 Annexes: > > ************************ > > 1) H.323 to Voice/Voiceband Terminals = The breakdown of the > > media. > > How DTMF > > is converted to/from UserInputIndication messages, etc. (There > is > > a > > draft of > > this in the current H.246 Annex B) > > 2) H.323 to SS7 (Similar to Q.699 - a Q.931 to ISUP conversion > > spec) > > 3) H.323 to Q.931 (Similar to the section in Annex A for H.320) > > > > Interface B, C, D > > ******************** > > For the Proposed Interfaces B, C, and D. Given that the messages > > passing > > across these interfaces must reflect all of the content of the > > signaling > > that the respective signaling functions receive from and send to > > extern > > entities, aren't these protocols modified or extended ISUP for > > Interface D, > > modified or extended Q.931 for Interface C, and modified or > > extended > > H.225 > > for Interface B? For C & D, can they be the real protocols if > > carried on a > > T1 and some derivation of them if running over TCP/IP? > > > > Please try and get all attendee requests in by Monday the 19th > at > > 12:00 Noon > > EST so that I can make the proper arrangements. I will send port > > assignments > > later that day. Here is a summary of attendees so far: > > > > 1) G. Thom > > 2) S. Nayak > > 3) R. Badri > > 4) P Kallur > > 5) K. Hedayat > > 6) R Spitzer > > 7) R Chopra > > 8) A Amir > > 9) R Even > > 10) H Liu > > 11) J Yeh > > 12) R Radhika > > 13) B Bell > > 14) T Taylor > > 15) G Freundlich > > 16) M Reid/B Hill/G Kajos > > > > All comments welcome, > > > > Mark Reid > > 1-781-505-2368 > > mreid(a)videoserver.com > > > > Bryan Hill > > 1-781-505-2159 > > bhill(a)videoserver.com

1 0

FW: IETF Device Control WG protocharter
by Nancy-M Greene 19 Oct '98

19 Oct '98

This will be relevant in the Gateway decomposition audio conference. Note that this charter is still being discussed in the IETF and the wording is not yet final. The new WG will be in place in time to hold its first meeting at the December IETF meeting in Orlando, the week of Dec 7, 1998. Nancy -------------------------------------------------------------------------- Nancy Greene (internally Nancy-M Greene) Internet & Service Provider Networks, Nortel NOTE NEW #'s: T:514-271-7221 (internally ESN853-1077) E:ngreene@nortel.com > ---------- > From: Greene, Nancy-M [CAR:6F13:EXCH] > Sent: Monday, October 19, 1998 9:49 PM > To: 'ss7-internet(a)baynetworks.com' > Subject: FW: IETF Device Control WG protocharter > > Here is the draft charter for the Device Control WG from Scott Bradner. > > A mailing list for the Device Control WG will be set up shortly. In the > meantime, please send any comments on this charter to the > ss7-internet(a)baynetworks.com mailing list (to join, as you know, send a > msg to majordomo(a)baynetworks.com with subscribe ss7-internet in the > message body). > > ---- > Network access server And Voice on IP DEvice Control (NAVDEC) > > Current Status: Proposed Working Group > > Chair(s): > > TBD > > Transport Directors: > Scott Bradner <sob(a)harvard.edu> > Vern Paxson <vern(a)ee.lbl.gov> > > Transport Area Advisor: > Scott Bradner <sob(a)harvard.edu> > > Mailing Lists: > General Discussion: > To Subscribe: > Archive: > > Description of Working Group: > > The working group will develop an informational RFC detailing the > architecture and requirements for controlling PSTN (Public Switched > Telephone Network) Media Gateways from external control elements > such as a media gateway controller. A PSTN media gateway is a > network element that provides conversion between the audio information > carried on telephone circuits and data packets carried over the > Internet or over other packet networks. This work will be done > in consultation with other IETF working groups looking at similar > issue. The working group will also ensure that good information > conduits exist with groups in other standards groups with expertise > in the relevant PSTN technology. > > This working group will also define standards track > protocol(s) for controlling PSTN (Public Switched Telephone > Network) Media Gateways from external control elements such > as a media gateway controller. . > > Examples of PSTN 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 gateway that provide traditional analog or 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 > where there is call control "intelligence" outside the > media gateways that is handled by a media gateway > controller. This allows for scalability and simplified > management: many media gateways within a domain can be > controlled by one 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. > > > Goals and Milestones: > > Oct 98 Announcement and establishment of mailing list > > Nov 98 IESG approval of charter > > Dec 98 Initial draft of architecture and requirements document > > Apr 99 Submit architecture and requirements document to IESG > Initial draft of protocol between MC and MG > > Jul 99 - Submit RFC protocol(s) between MC and MG to IESG > > Aug 99 - Working group closes > > ---- > > > Nancy > > >

1 0