- sg16-avd - lists.packetizer.com

Requirements For Device Control
by Tom-PT Taylor 29 Oct '98

29 Oct '98

Please count me in on the next conference call. With the help of Paul Sijben of Lucent Technologies, I have put together a list of requirements for the device control interface. The ETSI TIPHON architectural working group (WG 2) has reviewed it and has agreed to put it into their current deliverable (DTS 2002). The entire document will be forwarded to the Turin meeting as a liaison, but in the meantime I have attached the device control requirements portion to this message. <<10TD121r1.doc>> Tom Taylor E-mail: taylor(a)nortel.com (internally Tom-PT Taylor) Tel.: +1 613 765 4167 (internally 395-4167) FAX: +1 613 763 7236 (internally 393-7236)

1 0

Revision of Mr. Tosco's report
by Sakae OKUBO 29 Oct '98

29 Oct '98

Dear Q.12-14/16 experts, This is a part of Mr. Tosco's message dated 27 0ct 1998 to Mr. Bigi, >Attached I send you the final version of the Report Part I of the >WP2/16 meeting. Compared to the previous version I sent you on 20 >October 1998, the only change is the insertion of a TD number (39) on >page 14. Mr. Tosco's report of Working Party 2/16 as revised above has replaced the previous one: ftp://standard.pictel.com/avc-site/9809_Gen/Tosco_WP2_report.zip or http://standard.pictel.com/ftp/avc-site/9809_Gen/Tosco_WP2_report.zip 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 ***********************************************************

1 0

APC number allocation
by Sakae OKUBO 28 Oct '98

28 Oct '98

Dear Mr. Kumar, Dear Mr. Hedayat, VK>Please allocate an APC number for "H.323 version 2 compliant VK>Profile". This profile is developed especially for those vendors VK>who are starting to implement H.323. It cuts down on the rich set VK>of choices offered by the H.323 set of recommendations and provides VK>a lean but effective H.323 version2 compliant profile for IP VK>Multimedia Telephony. KH>Please allocate four APC numbers for the following documents from KH>PictureTel Corporation. In response to your requests, APC numbers have been allocated to your contributions as attached. 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 1429 Intel H.323 version 2 compliant Profile 1430 Editor Draft H.283 1431 PictureTel Changes to draft H.323 related to recommendations H.282 and H.283 1432 PictureTel H.283 and H.323 Annex E harmonization 1433 PictureTel General comments on Annex E -----------------------------------------------------------------------

1 0

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

28 Oct '98

Hi Mark Include me too Ami Carle/Glen Wray wrote: > > ---------- > > From: Carle/Glen Wray[SMTP:WRAYG@AGCS.COM] > > Sent: Thursday, October 29, 1998 1:16:10 AM > > To: ITU-SG16(a)mailbag.cps.intel.com > > Subject: Re: Gateway Decomposition Call Summary and Next Meeting Request > > Auto forwarded by a Rule > > > Mark, > > Please include Pratima Shah and I in this teleconference. > Thanks. > > Regards. > > Glen. > > Mark Reid wrote: > > > <<<< snip >>>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 > > -- > =============================================================== > C. Glen Wray AG Communication Systems > Phone: (602) 582-7176 -A subsidiary of Lucent Technologies- > Fax: (602) 581-4636 2500 West Utopia Road > Email: wrayg(a)agcs.com Phoenix AZ 85027 > =============================================================== > "Expand The Power Of Your Network" > http://www.agcs.com > =========

1 0

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