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

TD-13a, TD-28a, TD-29a
by Scott Petrack 19 Sep '97

19 Sep '97

Okubo-san, You may remember that there were last minute changes to VocalTec's three TD's that were made to facilitate consensus. I have uploaded the final versions of these three TDs to the Incoming directory of the gctech.co.jp ftp site, in case they are of interest. Each final version has the letter "a" appended to the number: TD-13a.doc TD-28a.doc TD-29a.doc Yours sincerely, Scott

1 0

Q9 documents from Sunriver meeting
by Gunnar Hellstrom 19 Sep '97

19 Sep '97

The documents from Q9-Accessability from the Sunriver Meeting are available from http://www.pi.se/~omnitor/standd.htm Among them the determined draft recommendations for text chatting in multimedia. Gunnar Hellström ------------------------------------------------ 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

reRouteIndication
by Pete Cordell 18 Sep '97

18 Sep '97

Dear All, It has been mentioned that when a gatekeeper performs a re-route it would be good for the client to know about it. After much investigation, there seems to be no message in Q.931 that handles this case. In the text that I proposed in Sunriver I suggested that a Facility message with a H.450 ctComplete should be sent. However, this is not much use to an entity that does not support supplementary services. Therefore it might be useful to add can extra case to the H323-UU-PDU to cover this, e.g.: H323-UU-PDU ::= SEQUENCE { h323-message-body CHOICE { setup Setup-UUIE, callProceeding CallProceeding-UUIE, connect Connect-UUIE, alerting Alerting-UUIE, userInformation UI-UUIE, releaseComplete ReleaseComplete-UUIE, facility Facility-UUIE, ..., progress Progress-UUIE, dummy NULL, reRouteIndication ReRouteIndication }, nonStandardData NonStandardParameter OPTIONAL, ..., h4501SupplementaryService SEQUENCE OF H4501SupplementaryService OPTIONAL } ReRouteIndication ::= SEQUENCE { display IA5String (SIZE( 0..255) ), endpointInfo EndpointType, ... } This could then be sent by a gatekeeper when a re-route has been done. Any comments? Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 =================================

1 0

TD19 and TD20
by Sakae Okubo 18 Sep '97

18 Sep '97

Dear Mr. Kajos, >>I tried to upload the above TDs last night. It doesn't seem to have >>worked. They are enclosed in this mail, instead. I have uploaded your TD-19 and TD-20 to the Incoming directory. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151 Japan ********************************************************************

1 0

Call for Joint Researches
by Doohyun Kim 18 Sep '97

18 Sep '97

Dear Sir/Madam, We are very pleased to contact you in terms of cooperation in the teleconferencing area you are very actively involved in in terms of creation of international standards. Electronics and Telecommunications Research Institute(ETRI) in Korea has been on the development of not only T.120 but also H.323 during recent three years. This project is planned to finish at the end of this year and the technology transfer to industries will be started two months before the end of the project. Now we find that we need more study and development on T.130 which is now being documented by the international standard body. Korean government lately announced the plan for supporting of international research with the fund of at most 1 million US$ per year for the domestic organization participated in the project. The project may continue three years. In this background we are looking for partnership who would like to join this new project and share the idea and technologies. However, each organization should search for their own fund, but the technologies developed are going to be shared between participants. Our activities may include the development of the standard specifications, the design and development of the software, and the interoperability test. We hope you to join this T.130 development project and share idea and technologies. We appreciate you in advance. Sincerely Yours, Sanghwan Kung Head of Distributed Multimedia Research Section Multimedia Department Computer Research Division ETRI Tel : +82-42-860-6634 Fax : +82-42-860-6671 Email : shkung(a)hama.etri.re.kr

1 0

Draft meeting report and TDs
by Sakae Okubo 17 Sep '97

17 Sep '97

Dear SG16 colleagues, The following files have been uploaded to the Incoming directory: APC-1327 draft meeting report (please return comments, corrections, additions in a week time) TD-01 TD-02 TD-03 TD-04 TD-06 TD-08 TD-17 TD-18 TD-22 TD-24 TD-25 TD-30 TD-31 TD-32 TD-33 TD-34 TD-39 Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151 Japan ******************************************************************** Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151 Japan ********************************************************************

1 0

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