- sg16-avd - lists.packetizer.com

Re: TDs from Sunriver
by gthom 17 Sep '97

17 Sep '97

Simao, >Gary, > >are you sure you want TD20? - that was for Q.11 (Annex E to H.324). I >have it, so if that the one you need, please let me know. > >Simao > I am sorry, I was refering to the Q11, 12, 13 Rapporteur meeting TDs. 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/17/97 Time: 15:29:22 -------------------------------------

1 0

Re: Call ID
by gthom 17 Sep '97

17 Sep '97

Mark, > >Hi, > >In the strict sense ... doesn't this change imply that a version 1 endpoint >"shall" do this in a call between two version 1 endpoints? I realize that >is not the intent .... but without the version numbers as in the first >paragraph it is not clear. > > Mark > > >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 > I was trying to avoid using version numbers, because they are not used anywhere else in the document. Since this text is only in the Version 2 document, it should not be a requirement for Version 1 endpoints ??? 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/17/97 Time: 08:29:27 -------------------------------------

2 1

REH.225.0 protocol identifier
by gthom 17 Sep '97

17 Sep '97

Glen, Will you be changing the protocolIdentifier value for version 2 to: {itu-t (0) recommendation (0) h (8) 2250 version (0) 2} And is this the prefered method to detect the difference between a version 1 and a version 2 terminal??? 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/17/97 Time: 11:12:20 -------------------------------------

1 0

RSVP and CloseLogicalChannel
by gthom 17 Sep '97

17 Sep '97

In the H.323 appendix on RSVP it states: "Before sending out a CloseLogicalChannel message for a given traffic stream, an endpoint should send a PathTear message if it is a sender or ResvTear message if it is a receiver, if an RSVP session has been previously created for that stream. When an endpoint , whether sender or receiver, receives a CloseLogicalChannel for a given traffic stream, it should also send a PathTear if it is a sender or ResvTear message if it is a receiver, if an RSVP session has been previously created for that stream." Isn't it true that only the sender can issue a CloseLogicalChannel ??? If that true, should the text read: "Before sending out a CloseLogicalChannel message for a given traffic stream, a sending endpoint should send a PathTear message if an RSVP session has been previously created for that stream. When a receiving endpoint , receives a CloseLogicalChannel for a given traffic stream, it should send a ResvTear message if an RSVP session has been previously created for that stream." 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/17/97 Time: 09:42:18 -------------------------------------

1 0

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