September 1997 - sg16-avd - lists.packetizer.com

Brief report from ITU-T Q9/16 - Accessability, Sunriver meeting.
by Gunnar Hellstrom 16 Sep '97

16 Sep '97

This is a brief report from the events in Sunriver seen from the Accessability view. A full report and the documents will show up in http://www.pi.se/~omnitor/index.html ITU - Telecommunication Standardization Sector Temporary Document 28 r2-E JOINT WORKING PARTIES 1 & 2/16 Original: English _______________________________ Sunriver , 12 September 1997 Question: 9/16 SOURCE: Gunnar Hellstrom, Swedish Administration, Rapporteur Q9/16 TITLE: Summary report from Q9/16 - Accessability to Multimedia for People with Disabilities The question has the following main items on its workplan: · Maintain the Text Telephone Automoding Recommendation V.18 · Develop recommendations for text conversation protocols in the Multimedia environment. · Provide information on Sign Language and Lip-reading use of Video communication for optimisation of videocoding for that application. A lot of work in the question is done in close collaboration with other questions and we are grateful for the excellent support we have got. Achievements since March 1997. 1. V.18 text telephone automoding Recommendation The text telephone automoding Recommendation V.18 is lab tested in more than 3000 successful connections with 11 different types of text telephones including V.18 itself. The experience of the testing is reflected in a revision of V.18 now proposed for determination, including support for the only known missing terminals - the plain V.23 (Minitel and Prestel). Accepted! A V.18 test specification was introduced by BT. It is a working document that can be developed into a Recommendation. 2. V.CHAT universal text conversation presentation level protocol. A presentation protocol V.CHAT for text conversation is developed together with Q3/16 and Q11/16. It is intended to be used in connection with all Multimedia protoocols and with V.18 text telephony. It is based on characterwise transmission of Unicode characters. It is now proposed for determination. Accepted! 3. T.CHAT= text conversation application protocol entity in data conferencing environment. A simple protocol for text conversation in the T.120 environment is developed in collaboration with Q3/16. With that, text chatting can be implemented in a uniform way in all multimedia environments supporting T.120. T.CHAT is now proposed for determination. Accepted as T.134! 4. H.CHAT= text conversation in H.324 terminals For implementations of H.324 not catering for T.120 protocols, procedures for carrying the V.CHAT protocol in a logical H.245 channel has been established in H.245 and H.324 now proposed for determination. Accepted! They have been developed in collaboration with Q11. Similar work also started in Q13/16 and Q14/16 for H.323. 5. Videocoding for sign language and lip-reading In collaboration with Q15/16, an informative appendix to H.263 has been drafted. It covers characteristics and requirements from Sign language and lip-reading application of video telephony and gives advice on optimisation for this application. Work will continue. The goals of H.263L has accepted to have Sign language and lip-reading as one application area. Plan for the time up to next SG16 meeting. Any feedback on the Draft Recommendations for determination will be handled. Q9 will continue developing the sign language documents and test sequences. The group asks for permission to hold one rapporteurs meeting in Europe late 1997 provided contributions are received. Accepted. Alistair Farquharson of BT is appointed editor of V.18. ------------------------------------------------ Gunnar Hellström Omnitor Alsnögatan 7, 4tr S-116 41 Stockholm SWEDEN Tel +46 701 100 501 Fax +46 8 556 002 06 E-mail: gunnar.hellstrom(a)omnitor.se WWW: public-www.pi.se/~omnitor ------------------------------------------------

1 0

Call ID
by gthom 16 Sep '97

16 Sep '97

All, APC-1315 indicates the following change: "When a version 1 endpoint calls a version 2 endpoint, it is the responsibility of the version 2 endpoint to generate a callIdentifier prior to sending ARQ to its gatekeeper." Can this be generalized to: "An endpoint receiving a Setup message which does not contain a callIdentifier shall generate one and use it when sending RAS or Q.931 messages related to this call." Comments, clarifications??? Thanks Gary ------------------------------------- Name: Gary Thom Company: Delta Information Systems, Inc. Phone: +1-215-657-5270 x23 Fax : +1-215-657-5273 E-mail: gthom(a)delta-info.com Date: 09/16/97 Time: 10:53:02 -------------------------------------

1 0

H.323 changes
by gthom 16 Sep '97

16 Sep '97

All, As approved at the meeting APC-1315 (BT) indicates a change to 7.2.2 on gateway registration. I propose the following text as a new paragraph after the first paragraph: "A Gateway or MCU may register a single Transport Address or multiple Transport Addresses. The use of multiple Transport Addresses may simplify the routing of calls to specific ports." Please comment or provide clarification. Thanks Gary ------------------------------------- Name: Gary Thom Company: Delta Information Systems, Inc. Phone: +1-215-657-5270 x23 Fax : +1-215-657-5273 E-mail: gthom(a)delta-info.com Date: 09/16/97 Time: 10:48:09 -------------------------------------

1 0

White contribution deadline
by gthom 16 Sep '97

16 Sep '97

To all Q12, Q13, and Q14 editors, Mr. Okubo asked me to remind you that White Contributions must be submitted to the TSB no later than Sept 26, 1997. (The meeting notice says Sept. 20 but Mr. Bigi indicated that Sept.26 would be ok). The sooner that they can be submitted the better, because of the large number of recommendations which need to be translated for this meeting. New documents which have never been translated, require only an electronic version of the final draft with no change marks. (H.235, H.246, H.332, H.450.x, H.222.0 Amend. 3 and 4) Documents which have been previously translated (H.321V2, H.245V3, H.323V2, and H.225.0V2) require three files: 1) a clean version of the final draft with no change marks. 2) a version of the final draft with change marks indicating the changes from the last translated version. 3) a "delta" document which describes the changes to be made to the last translated version to get to the final draft. #3 is the primary document for the translation, and translation cost is based on the size of this document. #1 and #2 are used as references to aid the translators. All appendices and annexes should be included in the main documents. That is, they are not submitted as separate draft recommendations. If you have any questions, please dont hesitate to contact me, the other rapporteurs, or Mr. Bigi. Thanks Gary ------------------------------------- Name: Gary Thom Company: Delta Information Systems, Inc. Phone: +1-215-657-5270 x23 Fax : +1-215-657-5273 E-mail: gthom(a)delta-info.com Date: 09/16/97 Time: 09:22:44 -------------------------------------

1 0

TDs from Sunriver
by gthom 16 Sep '97

16 Sep '97

Hi all, I hope every one had a good trip home from Sunriver. Could all of those people who generated TDs at the meeting, please post them to the ftp site, or send them to me by e-mail. In particular I need TD-13, 19, 20,23, 28, 34 and also updated text for H.323 Annex C. I need these as soon as posible so that I can prepare the H.323V2 white contribution by Sept. 20, 1997. Thanks for your help. Gary ------------------------------------- Name: Gary Thom Company: Delta Information Systems, Inc. Phone: +1-215-657-5270 x23 Fax : +1-215-657-5273 E-mail: gthom(a)delta-info.com Date: 09/16/97 Time: 09:17:01 -------------------------------------

1 0

new version of APC-1266 in Incoming
by Dale L. Skran 10 Sep '97

10 Sep '97

This version is wfw6.0 and call APC1266b.ww6 This is a proposal for using H.323 to set up Internet Fax calls. Dale Skran Ascend

1 0

unreadable APC-1266 now in Incoming on gctech ftp site
by Greg Goodknight 10 Sep '97

10 Sep '97

Dale, The very late submission, APC-1266 "Using H.323 call control for Fax over IP", dated "Tue Sep 10 15:49:00 1996" [1996 is not a typo on my part], APC-1266.doc, just now downloaded onto ftp://itu-t:sg15!avc@ftp.gctech.co.jp/Incoming/ is not readable by either my Wordviewer version 7.1 or by Word for Win 95 7.0. -Greg _____________________________________________________ Greg Goodknight Software Engineer Cisco Systems Global Alliance Engineering *****************ggoodkni(a)cisco.com***************** Direct: 408 527 9358 Home Office: 916 274 0443 San Jose,CA Nevada City, CA

1 0

Audio packetization schemes
by Smita Gupta x5499 10 Sep '97

10 Sep '97

I am looking for information on audio packetization schemes for H.323 terminals. In particular I would like to find out if RTP audio packetization schemes exist for any of the audio encoders - G.728, G.722, G.711, G.723.1, G.729 etc. and if so where can I find the documentation. Thanks Smita Gupta _________________________________________________________________ Smita Gupta VTEL Corp., 350 E. Plumeria Avenue Mail Stop 1-1R San Jose, CA 95134-1900 e-mail: smita(a)vtel.com Phone: (408) 922-5499 FAX: (408) 232-6165 __________________________________________________________________

2 1

Re: A scenario that cannot be solved without APC-1280 or deferred "Connect"
by Scott Petrack 09 Sep '97

09 Sep '97

Ben, Discussion in Sun River brought out that a careful reading of H.225, H.245, and H.323 implies the following: 1. It is allowed to start H.245 negotiation as soon as the CallSetup message is received. 2. Once H.245 negotiation begins, it can proceed to open logical channels at it's own pace. 3. Once an open logical channel is opened and acknowledged, media streaming should begin right away. So it seems to be entirely possible to do media streaming before a CONNECT message, and the CONNECT message can retain its usual Q.921 meaning. You can call this "deferred Connect", but it'd be better not to give it any special name. It's just a compliant H.323 implementation. The CONNECT isn't deferred, it comes at just the right time -- when the endpoint wants to signal that the call has connected.... This may or may not be after some media has been streamed. Scott Petrack Principal Technologist VocalTec Communications Ltd. petrack(a)vocaltec.com btang(a)LUCENT.COM on 09/09/97 04:50:36 PM Please respond to ITU-SG16(a)mailbag.jf.intel.com To: ITU-SG16(a)mailbag.jf.intel.com cc: (bcc: Scott Petrack) Subject: Re: A scenario that cannot be solved without APC-1280 or deferred "Connect" Gur, Your observation leads to the general question that whether it is necessary to support the opening of a media channel during the Q931 call signaling procedure. This concerns other scenario as well. For example, when an H323 endpoint calls a POTS user via a gateway, while the Q931 call signaling is in progress it may be required to have a voice channel opened between the endpoint and gatweay to forward a PSTN special announcement ("sorry, the number you dialed is not in service") back to the endpoint. As I remebered, a while ago there was a decision made from this subject group about h323 implementation, that no capability exchange will take place before the Q931 signaling is completed. I am not sure about the rational behind it, but maybe that can be brought up again for discussion. I looked at APC-1280 and found no descriptions for the procedure of using the Progress-UUIE which is proposed to solve the above-mentioned problem. Will this be added later on? Ben Tang Lucent Technologies btang(a)lucent.com

1 0

IRR Fields
by Lior Moscovici 09 Sep '97

09 Sep '97

I have some questions/remarks regarding the IRR fields as defined in H.225: There is an inconsistency between the ASN.1 definition and the textual description in 8.15.2. The ASN.1 is more up to date. Specifically, the perCallInfo field is missing in 8.15.2. According to the ASN.1 definition: can a single IRR really refer to more than one call? As perCallInfo is a SEQUENCE of SEQUENCES, one per call, it seems to be so, but the callIdentifier is outside the perCallInfo field, and thus there is only one of it. To which of the calls is it supposed to refer to? Sincerely, Lior Moscovici

1 0