Paul,
Thanks for replying. Please seem my comments below:
-Archana
The ACK packet certainly follows the line of thinking that I had. However, one issue with implementing this approach is that there are no fields in H.323 to provide a "sequence number". I suppose this could easily be overcome.
Well, if you are concerned about retransmissions, may be the endpoints could just look at the "callId" in the ACK, look at the "session-state" and conclude that the packet is just a retransmission.
Here's a thought: how about introducing a new session layer between the transport and below the H.323 application? This session layer would actually encode messages in a special format for transmission on the wire. For example, for TCP, we could modify the TPKT header and the payload to carry not only the H.323 message, but also sequencing data and other information. We can allow fail-over addresses to be carried in this layer and allow this layer to completely handle connection recovery.
Well let me put it this way. What do we gain by doing this?. Wouldnot it be simpler to modify H.323 procedures by introducing an ACK message itself (probably use some modified FACILITY?) and do it in a clean manner. Anyway, all we need in H.323 is an ACK from the peer, if the requester indicates that it needs an ACK. This could be decided as part of the connection set up procedure itself..so an endpoint would know before hand whether "a particular" node supports robustness or not. The message we decide to use will be optional and existing applications would just have to learn to ignore it, if they dont want to support robustness. That is not a big change..is it?..
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com