- sg16-avd - lists.packetizer.com

APC1800-APC1801 finally found!
by /Q11, Q12, Q13 09 May '00

09 May '00

I am sorry for the e-mail i sent. I finally found it after a page reload.. Ameneh Zahir ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: List of registered contributions- Looking for APC1800-APC1801
by /Q11, Q12, Q13 09 May '00

09 May '00

Hello, I am looking for Tom's Taylor new version of H248 which should be APC 1800 and APC1801. I can't find in the pictel site. Could someone tell me where I could find it??? Thank you Ameneh Zahir Alcatel ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: [Robustness] End to End Acknowledgement Contribution
by Sasha Ruditsky 09 May '00

09 May '00

Tim I just went through the "Message lost" list and I believe that at least some of the messages in the list may be lost without causing any problem. Let start from the *********Communication Mode Command. This command used to ask remote terminal to use new set of outgoing channels. As result the remote terminal will close and/or open new ones. The terminal does this using explicit logical channel signaling. So the MC that sent the communication mode command actually has the acknowledgement for the command. The communication mode command by itself does not cause H.245 state change and may be retransmitted without problem, so the MC that is uncertain whether the message has been delivered or not may always resend it. *********Multipoint Mode Command Multipoint Mode Command is almost the same it actually causes the terminal to comply with the "requestMode"s. The only problem ,I may think about, that may be caused by lost Multipoint Mode Command is request Mode rejection. When this happens MC may safely retransmit Multipoint Mode Command and try request Mode again. *********RELEASE COMPLETE This is correct that this message has no acknowledge and I believe that the reason for this is that it is almost always acknowledge by itself. It is in most cases the last message in the end to end message sequence. In case we have H.245 in the call this sequence may be started by the end session command exchange. For call independent signaling connections procedures in H.450 the RELEASE COMPLETE message always or almost always goes immediately after some other end to end message in opposite direction so may be defined acknowledge to it. Even if such definition is impossible I cannot see the problem that may caused by lost RELEASE COMPLETE message in this case. The real problem with lost RELEASE COMPLETE message may be in the case of fast start signaling. For this specific case we need to find solution. The possible solutions may be: Using RELEASE message (as you proposing) Defining special "End Of Fast Start" message (this does not necessarily requires new syntax let say Facility with empty fast start sequence may be defined to do this). Using STATUS exchange for fast start calls (as we proposing) Preventing usage of fast start on robust system. *********User Input Indication The behavior of the system that receives User Input Indication is not defined in standard. I believe that the recovery from the loss of the message should not be defined in standard too. In addition User Input Indication defined in the way that assumes sending DTMF digits to PSTN where they may be lost even H.323 segment delivers them reliably. In some cases, especially when there is different mechanism to acknowledge User Input Indication delivery, controlling User Input Indication resend on the protocol level may even cause problems. For example there are games where the video/audio streams are broadcasted by TV and the player controls the game over telephone line using DTMF. In case system does not respond properly player tries to correct this sending new DTMFs. If in addition the system tries to resend the lost ones the behavior may be funny. The PSTN systems that currently exist use DTMF to deliver user input. DTMF is by definition is something that may be lost and I believe that there are no mechanisms to acknowledge DTMF that are built into PSTN. So I assume that there are application level methods to solve the problem. What I want to say is that recovery from User Input Indication lost is the application problem and the level and method of recovery shall be defined by the application. *********************************************** Alexander(Sasha) Ruditsky RADVision Ltd. 24 Raul Wallenberg St. Tel Aviv 69719 Israel Tel: +972-3-645-5220 Fax: +972-3-645-6464 Direct: +972-3-645-5273 sasha(a)radvision.rad.co.il *********************************************** -----Original Message----- From: Tim Chen [mailto:scc@TRILLIUM.COM] Sent: Tuesday, May 09, 2000 5:37 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: [Robustness] End to End Acknowledgement Contribution Hi, Please find attached our write-up on end to end acknowledgement. As discussed in our last Robustness Group Conference Call, adding these acknowledgements at H.323 level to messages which invoke no responses will prevent call state mismatch should these messages be lost. We hope the group will give some response during Tuesday's conference call. The list of messages that need to be acknowledged shown in the document is preliminary and we would welcome comments and suggestions. Regards, Tim Chen ------------------------------------------------------------ Tim Chen Trillium Digital Systems, Inc. Phone: +1 310 442 9222 Fax: +1 310 442 1162 email: tim(a)trillium.com http://www.trillium.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

APC-1858 uploaded
by Rich Bowen 09 May '00

09 May '00

Colleagues, APC-1858 "Support for Dynamic Parameter Changes in RAS" has been uploaded to the incoming directory. Regards, Rich -------------------------------------------------------------------- Richard K. Bowen Cisco Systems, Inc. rkbowen(a)cisco.com Research Triangle Park, NC -------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

AVC-1798 and AVC-1799 - H.248 Annex F uploaded
by Gunnar Hellstrom 09 May '00

09 May '00

Hello All, The following documents have been placed in ftp://standard.pictel.com/avc-site/Incoming/ and are expected to appear soon in the 0005-Osa directory: APC- 1798 Editor (Gunnar Hellström LM Ericsson) H.248 draft Annex F, Facsimili, Text Conversation and Call Discrimination packages APC- 1799 Editor (Gunnar Hellström LM Ericsson) H.248 Annex F Issues Regards Gunnar ------------------------------------------ Gunnar Hellstrom LM Ericsson E-mail gunnar.hellstrom(a)omnitor.se Tel +46 8 556 002 03 Mob +46 708 204 288 fax +46 8 556 002 06 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

[Robustness] End to End Acknowledgement Contribution
by Tim Chen 09 May '00

09 May '00

Hi, Please find attached our write-up on end to end acknowledgement. As discussed in our last Robustness Group Conference Call, adding these acknowledgements at H.323 level to messages which invoke no responses will prevent call state mismatch should these messages be lost. We hope the group will give some response during Tuesday's conference call. The list of messages that need to be acknowledged shown in the document is preliminary and we would welcome comments and suggestions. Regards, Tim Chen ------------------------------------------------------------ Tim Chen Trillium Digital Systems, Inc. Phone: +1 310 442 9222 Fax: +1 310 442 1162 email: tim(a)trillium.com http://www.trillium.com

2 1

[Robustness] draft document for discussion
by Terry L Anderson 09 May '00

09 May '00

Attached is a draft for APC-1830 describing our alternative robustness architectures, referring to the contributions of Motorola and RadVision and more details of our shared-state solution. Let's discuss this in our call on Tues and I will modify before sending into the ftp site. -- ------------------------------------------------------- Terry L Anderson, DMTS tla(a)lucent.com Lucent Technologies /INS/ Voice over IP Access Networks Rm 2B-121, 600 Mountain Ave, Murray Hill, NJ 07974 Voice:908 582-7013 FAX:908 582-6729 Pager:800.759.8352 pin 1704572 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla -------------------------------------------------------

1 0

Osaka meeting information
by Sakae OKUBO 08 May '00

08 May '00

To Osaka meeting participants from the meeting host, Please note the following: 1) The meeting fee is now fixed at exactly 20,000 Yen. Cash or credit card (Visa or MasterCard) is accepted. 2) We will have a working dinner on Wednesday at Rihga Royal Hotel. It will start at 19:00. Some more information will follow later today. 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

APC 1788-1795, 1815, 1837, and 1849 Uploaded
by Paul E. Jones 08 May '00

08 May '00

Colleagues, I have uploaded the following documents for the upcoming meeting into the Incoming directory of the AVC site: APC-1788 - Draft H.323v4 APC-1789 - Draft H.323v3 Implementers Guide APC-1790 - Indicating Frames/Samples per RTP Packet APC-1791 - Call Proceeding / Facility Issues APC-1792 - Empty fastStart versus fastConnectRefused APC-1793 - When to include perCallInfo in an IRR APC-1794 - New Proposed LRJ reason "resourcesNotAvailable" APC-1795 - URQ to contain Alternate Gatekeeper Information APC-1815 - Indicating Support of Annex E for Alternate Endpoints APC-1837 - Usage of Expanded T.35 Country Codes in Recommendations H.225.0, H.245, H.283, and H.341 APC-1849 - Errors in H.225.0 Version 3 ASN.1 Best Regards, Paul E. Jones ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 1

Uploaded contributions
by Rich Bowen 08 May '00

08 May '00

Dear Mr. Okubo, I have uploaded the following contributions to the Incoming directory: APC-1856.zip Editor (R Bowen) Draft H.225.0 v4 APC-1859.doc Cisco Systems Proposal to Support the Redirecting Number IE APC-1860.zip Cisco Systems DNS SRV record query text update APC-1861.zip Cisco Systems Gateway Capacity Reporting Enhancements APC-1862.zip Cisco Systems Issue regarding Calls through NAT Devices Regards, Rich -------------------------------------------------------------------- Richard K. Bowen Cisco Systems, Inc. rkbowen(a)cisco.com Research Triangle Park, NC -------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0