List of registered contributions- Looking for APC1800-APC1801

[/Q11, Q12, Q13]

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 at radvision.rad.co.il
***********************************************




-----Original Message-----
From: Tim Chen [mailto:scc at TRILLIUM.COM]
Sent: Tuesday, May 09, 2000 5:37 AM
To: ITU-SG16 at 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 at trillium.com     http://www.trillium.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com