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@radvision.rad.co.il ***********************************************
-----Original Message----- From: Tim Chen [mailto:scc@TRILLIUM.COM] Sent: Tuesday, May 09, 2000 5:37 AM To: ITU-SG16@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@trillium.com http://www.trillium.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com