Issue in H.323 robustness not addressed by SCTP/DDP

[Archana Nehru]

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 at mailbag.intel.com