- sg16-avd - lists.packetizer.com

Audio Codec
by Martin 21 Nov '00

21 Nov '00

Hi, As it is very clear that any End Point may operate in specified set of capabilities depending on the policies or bit rate or whatever. When the call is in proceed on a particular codec, what are the factors which decide on changing to a new codec ? Is user allowed to change codec when the call is in proceed ? ( Assuming that the other end point indicated MaxPendingReplacementFor capability ) Can anyone help me in this regard ? thanks Martin D.

1 0

AW: questions concerning H.450 Supplementary Services
by Horvath Ernst 20 Nov '00

20 Nov '00

Dear Mr. Bandow, regarding your first question, the H.323 terminal will ignore the complete H4501Apdu if it has no H.450 support at all. If it supports H.450.1 but not the specific feature, the content of the H4501Apdu will be unknown to the terminal. In this case the reaction depends on the interpretationPdu field; default is to send a rejectApdu (see H.450.1 for details). regarding your second question, it is certainly allowed to divert to a terminal behind a gateway. Whether the gateway performs any checks is an implementation matter, H.450.3 leaves it optional. Regards, Ernst Horvath Siemens AG > -----Ursprüngliche Nachricht----- > Von: Wolfgang Bandow [mailto:wolfgang.bandow@DETEWE.DE] > Gesendet am: Montag, 20. November 2000 10:20 > An: ITU-SG16(a)mailbag.cps.intel.com > Betreff: questions concerning H.450 Supplementary Services > > Dear H.450-Experts, > > let me please put 2 questions concerning the H.450 Supplementary > Services. > > H.323 says that the support of H.450 is optional. > How shall a H.323 terminal not supporting a particular H.450 service > react on receiving an unexpected signal > or apdu respectively? > > Is H.450 Call Diversion restricted to H.323 terminals or is it also > permitted to divert a call > to a terminal which can exclusively be reached via a gateway? > In the latter case: shall the gateway omit any restriction > checks, going > > on the assumption that the > diverted-to telephone number is correct / reasonable? > > Regards, > Wolfgang Bandow CT-B Berlin > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

questions concerning H.450 Supplementary Services
by Wolfgang Bandow 20 Nov '00

20 Nov '00

Dear H.450-Experts, let me please put 2 questions concerning the H.450 Supplementary Services. H.323 says that the support of H.450 is optional. How shall a H.323 terminal not supporting a particular H.450 service react on receiving an unexpected signal or apdu respectively? Is H.450 Call Diversion restricted to H.323 terminals or is it also permitted to divert a call to a terminal which can exclusively be reached via a gateway? In the latter case: shall the gateway omit any restriction checks, going on the assumption that the diverted-to telephone number is correct / reasonable? Regards, Wolfgang Bandow CT-B Berlin

1 0

Positive decisiions in ITU-T SG 16 complete the basic work with Total Conversation
by Gunnar Hellstrom 19 Nov '00

19 Nov '00

A meeting in ITU-T SG16 Multimedia Systems and Services, was closed on November 17, 2000, marking the end of a successful four year long study period and the beginning of a new. It has been a pleasure to lead Question 9, "Accessibility to Multimedia" to good achievements in a stimulating and co-operative environment. I want to thank the experts in all SG16 groups for the work during the study period leading to the situation that: -We have real time text conversation specified in all major multimedia protocol environments. (H.320,H.323,H,324,T.120) -We have a service description for Total Conversation, being conversational multimedia including video, text and voice,(F.703). -We have one universal presentation protocol for real time text conversation (T.140), also applicable to the IP environment (IETF RFC2793). -We have maintained and improved the Recommendation for text telephony modems created during the previous study period, so that it now forms the natural base for harmonising Text Telephony, (v.18) -We have a service description recognizing Text Telephony (F.703). -We have the specification of how gateways connecting text conversation in different environments can be controlled (H.248 Annex F) -We have brought awareness about the needs in video communication for sign language and lip reading to the video coding and multimedia system experts. (H series Supplement 1 ) All these achievements are intended to be useful for all, and essential for people who have no or little use of voice communication because of a disability in hearing or speech. With these basic Recommendations for accessibility completed, we are now prepared to accept proposals for new work with Accessibility to Multimedia services, systems and terminals. ---------------------------------------------------------------------------- ---------------- Report from the meeting ----------------------- For Q9/16, "Accessibility to Multimedia", this meeting resulted in a set of positive decisions, that mark the end of a series of actions intended to enable higher accessibility to conversational multimedia. Q9 is seen as a "Horisontal" question, and will be transformed to Question H/16 "Accessibility to Multimedia" in the new study period. "Horisontal" means that most work items are performed in close co-operation with other questions handling specific technologies. The decisions related to Q.9 accessibility goals in this meeting were: 1. Text telephone modem Recommendation V.18 ---------------------------------------------------------------------------- --------- Q.9 own work item. Version 3 of V.18 Operation and Interworking procedures for the DCE:s in the text telephone mode. Main improvements: Use full V.8 connection procedure, for better opportunities to negotiate the connection, and include the changes earlier published in implementor guides and appendices. 2. Gateway control packages H.248 Annex F ---------------------------------------------------------------------------- -- With Q.14 and "Q.Fax": H.248 Annex F, Text Conversation, Facsimile and Call Discrimination packages. The control of a Media Gateway capable of handling Fax, multimedia Text Conversation and Text Telephony, with general call discrimination between different modem type connections. 3. Multimedia service descriptions; F.700, F.703 ---------------------------------------------------------------------------- -- With Q.1: F.700 revision of Annex A to include a definition of the medium conversational text. F.703 Multimedia Conversation Service Description Inclusion of a Description of Total Conversation as a combination of Video, Text and Voice. Inclusion of a Description of Text Telephony as real time character by character text conversation with optional opportunity to use voice. 4. Managed objects for modems; V.59 ---------------------------------------------------------------------------- --------- With Q.4: V.59 Managed objects for modems Inclusion of message definitions for V.18 management. 5. DCE control; V.250 ---------------------------------------------------------------------------- --------- With Q.7: V.250 Implementors guide Revision of the commands and responses for control of V.18 modems. ---------------------------------------------------------------------------- --------- The group has only one open issue, about an alternative proposal for simultaneous voice and text in PSTN text telephony. A usability report is expected. The full report is in document TD73(plen) of the meeting. Thank you all! **************************************** Gunnar Hellström Ericsson Radio Systems AB tel +46 708 204 288 ***************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Request of uploading
by Sakae OKUBO 17 Nov '00

17 Nov '00

Dear Editors, Could you please upload the final edited documents for decision, approval, "consent", "previously intended determination" to the PictureTel site and announce through the reflector? Best regards, Sakae OKUBO *********************************************************** 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 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Updated presentation - H.323 overview
by Tam, Mimi 16 Nov '00

16 Nov '00

Dear Boaz, If I may ask you a question, how did you get a web page in the http://people.itu.int space? I am with the SG16 and have been a ties member for quite a while. Is it possible for me to get a web page there as well? Sorry to bother you. I'd greatly appreciate your help. Thanks very much...Mimi Tam Mimi Tam Davox Corp. Technical Director 6 Technology Park Drive Westford, MA 01886 +1 978 952 0695 -----Original Message----- From: Boaz Michaely [mailto:boaz.michaely@TIES.ITU.INT] Sent: Wednesday, November 15, 2000 10:04 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Updated presentation - H.323 overview Dear experts, I've updated the H.323 overview presentation on my ITU page. Please take a moment to review it, and notify me of mistakes and omissions. (note specific slides about changes in H.323 and H.225.0 v4) Thanks, Boaz Michaely http://people.itu.int/~michaely ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

List Status: Worst is over?
by Meyer, Greg W 15 Nov '00

15 Nov '00

The ITU-SG16 list shut down yesterday because of all the virus alerts. After freeing the list today, several more alerts came in but they appear to be ones that were queued, not new ones. I've changed some characteristics of the list to stem the chances of this happening again. First, as Chip Sharp pointed out, the Reply-To field will now point to the Sender (originator) of the message, not the list. Also, for a temporary period, I will moderate the list to insure more virus alerts and any inappropriate mail does not get sent to the entire list. Again, I apologize for the inconvenience and appreciate your patience. If anyone has other suggestions about managing the list, let me know directly. I can gather the suggestions and we can all vote on them. Then we can recount the votes. Then we can hand count the votes, but only from some countries. Then we can go to court. Then, well, you get the idea. :) Thanks, Greg Meyer Intel Corporation mailto:greg.w.meyer@intel.com +1.503.264.9506 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Updated presentation - H.323 overview
by Boaz Michaely 15 Nov '00

15 Nov '00

Dear experts, I've updated the H.323 overview presentation on my ITU page. Please take a moment to review it, and notify me of mistakes and omissions. (note specific slides about changes in H.323 and H.225.0 v4) Thanks, Boaz Michaely http://people.itu.int/~michaely ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Virus Alerts & Loops
by Meyer, Greg W 15 Nov '00

15 Nov '00

Hello: You probably noticed that your mailboxes are full of virus alerts from various companies' mail servers. The incident started with an inappropriate conference notice (not directly ITU-SG16 related). The sender has been notified. You should heed the virus notice and not open that attachment. The Bosch (Tenovis) mail server created an infinite loop so I was forced to restrict the ITU-SG16 list so that only subscribers can post mail. I apologize for any inconvenience. I will re-enable the list for public posting when things settle down. Thanks, Greg Meyer Intel Corporation mailto:greg.w.meyer@intel.com +1.503.264.9506 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Please fix this list server
by Chip Sharp 14 Nov '00

14 Nov '00

One way to avoid cascading auto-mail meltdowns is to change the list server so it does not replace the "Reply-To" address with the list name address. Thus, anyone that selects "reply" to an email will send the reply back to the original sender. "reply all" will send the reply to the original sender and the list. It seems that many companies have now instituted anti-virus filters that automatically generate a message back to the "Reply-To" address when they receive a virus. Can this list setup be changed to this mode? Thanks, Chip At 01:49 AM 11/15/00 +0000, you wrote: >****** Message from InterScan E-Mail VirusWall NT ****** > >Sent >>> RCPT TO:<Marek.Przybyszewski(a)DE.BOSCH.COM> >Received <<< 550 5.7.1 Unable to relay for Marek.Przybyszewski(a)de.bosch.com > >Could not deliver mail to this user. > >***************** End of message *************** >Received: (from uucp@localhost) > by gwa.fe.bosch.de (8.9.1/8.9.1) id CAA02481 > for <Marek.Przybyszewski(a)DE.BOSCH.COM>; Wed, 15 Nov 2000 02:48:37 > +0100 (MET) >Received: from mailbag.cps.intel.com( 192.102.199.72) by gwa.fe.bosch.de >via smap (V2.1) > id xma002473; Wed, 15 Nov 00 02:47:33 +0100 >Received: from mailbag.intel.com (mailbag.cps.intel.com [192.102.199.72]) > by mailbag.cps.intel.com (8.9.3/8.9.1/d: relay.m4,v 1.6 > 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id RAA28705; > Tue, 14 Nov 2000 17:41:22 -0800 (PST) >Received: from MAILBAG.INTEL.COM by MAILBAG.INTEL.COM (LISTSERV-TCP/IP release > 1.8d) with spool id 1468 for ITU-SG16(a)MAILBAG.INTEL.COM; Tue, > 14 Nov > 2000 17:41:21 -0800 >Received: from gwa2.fe.bosch.de (gwa2.fe.bosch.de [194.39.218.2]) by > mailbag.cps.intel.com (8.9.3/8.9.1/d: relay.m4,v 1.6 1998/11/24 > 22:10:56 iwep Exp iwep $) with ESMTP id RAA27895 for > <ITU-SG16(a)mailbag.cps.intel.com>; Tue, 14 Nov 2000 17:31:19 -0800 > (PST) >Received: (from uucp@localhost) by gwa2.fe.bosch.de (8.10.2/8.10.2) id > eAF1TCw09153 for <ITU-SG16(a)mailbag.cps.intel.com>; Wed, 15 Nov 2000 > 01:29:12 GMT >X-Authentication-Warning: gwa2.fe.bosch.de: uucp set sender to > <virus-protection(a)bosch.com> using -f >Received: from fez8017.fe.internet.bosch.com(virus-in.fe.internet.bosch.de > 10.4.4.17) by gwa2.fe.bosch.de via smap (V2.1) id xma008913; > Wed, 15 > Nov 00 01:29:05 GMT >InterScan-Notification: yes >MIME-Version: 1.0 >Content-Type: multipart/mixed; > boundary="----=_NextPart_000_974251217_B78506032.R82506026" >Message-ID: <200011150129.eAF1TCw09153(a)gwa2.fe.bosch.de> >Date: Wed, 15 Nov 2000 02:20:17 +0100 >Reply-To: Mailing list for parties associated with ITU-T Study Group 16 > <ITU-SG16(a)mailbag.cps.intel.com> >Sender: Mailing list for parties associated with ITU-T Study Group 16 > <ITU-SG16(a)mailbag.cps.intel.com> >From: virus-protection(a)BOSCH.COM >Subject: InterScan eManager Content Management Notification! (Attachment > Removal) >Comments: To: ITU-SG16(a)mailbag.cps.intel.com >To: ITU-SG16(a)mailbag.cps.intel.com > >Content-Type: text/plain; > charset="iso-8859-1" >X-MIME-Autoconverted: from 8bit to quoted-printable by >mailbag.cps.intel.com id RAA28705 > >******Message from InterScan E-Mail VirusWall NT****** > >The following mail was blocked by InterScan eManager Content Management. > >Source mailbox: <ITU-SG16(a)mailbag.cps.intel.com> >Destination mailbox(es): ><Bjoern.Soelch(a)TENOVIS.COM>,<Axel.Niebuhr(a)TENOVIS.COM> >Policy: Attachment Removal >Attachment file name: Navidad.exe - application/x-msdownload >Action: Replaced with text > >Attached files with executable extension have been deleted, (i.e. *.exe). >Ausführbare Attachments wurden gelöscht (z.B. *.exe) > >******************* End of message ******************* >Received: (from uucp@localhost) > by gwa.fe.bosch.de (8.9.1/8.9.1) id CAA26146; > Wed, 15 Nov 2000 02:28:57 +0100 (MET) >Received: from mailbag.cps.intel.com( 192.102.199.72) by gwa.fe.bosch.de >via smap (V2.1) > id xma026048; Wed, 15 Nov 00 02:28:53 +0100 >Received: from mailbag.intel.com (mailbag.cps.intel.com [192.102.199.72]) > by mailbag.cps.intel.com (8.9.3/8.9.1/d: relay.m4,v 1.6 > 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id RAA27603; > Tue, 14 Nov 2000 17:20:47 -0800 (PST) >Received: from MAILBAG.INTEL.COM by MAILBAG.INTEL.COM (LISTSERV-TCP/IP release > 1.8d) with spool id 1414 for ITU-SG16(a)MAILBAG.INTEL.COM; Tue, > 14 Nov > 2000 17:20:43 -0800 >Received: from netsys.kaist.ac.kr (netsys.kaist.ac.kr [143.248.148.90]) by > mailbag.cps.intel.com (8.9.3/8.9.1/d: relay.m4,v 1.6 1998/11/24 > 22:10:56 iwep Exp iwep $) with ESMTP id RAA27507; Tue, 14 Nov 2000 > 17:10:37 -0800 (PST) >Received: from nice.etri.re.kr (nice.etri.re.kr [129.254.17.14]) by > netsys.kaist.ac.kr (8.9.3/8.9.3) with ESMTP id JAA21427 for > <pv_99(a)netsys.kaist.ac.kr>; Wed, 15 Nov 2000 09:05:35 +0900 >Received: from ghlee (ghlee.etri.re.kr [129.254.72.107]) by nice.etri.re.kr > (8.9.3/8.9.3) with SMTP id JAA10399 for <pv_99(a)netsys.kaist.ac.kr>; > Wed, 15 Nov 2000 09:21:33 +0900 (KST) >MIME-Version: 1.0 >Content-Type: multipart/mixed; > boundary="----=_NextPart_000_002B_01C04EEB.2D813F20" >X-Priority: 3 (Normal) >X-MSMail-Priority: Normal >X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) >X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 >Importance: Normal >Message-ID: <NEBBKFGEOLBEAFHGPDNAEEEBCAAA.ghlee(a)nice.etri.re.kr> >Date: Wed, 15 Nov 2000 10:02:35 +0900 >Reply-To: Mailing list for parties associated with ITU-T Study Group 16 > <ITU-SG16(a)mailbag.cps.intel.com> >Sender: Mailing list for parties associated with ITU-T Study Group 16 > <ITU-SG16(a)mailbag.cps.intel.com> >From: ghlee <ghlee(a)NICE.ETRI.RE.KR> >Subject: Extension of paper submission deadline of PV2001 (Nov. 30, 2000) >Comments: To: "pv(a)netsys.kaist.ac.kr" <pv_99(a)netsys.kaist.ac.kr> >To: ITU-SG16(a)mailbag.cps.intel.com ------------------------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems "The best way to pick a lock is with a key." http://www.netaid.org ------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0