hi ,

Please see my comments below:

-Archana

...

                          (CRASH)     RELCOMPLETE
       EP2 <--------------  GK   <------------  EP1
      (SCTP/DDP)           (SCTP/DDP)         (SCTP/DDP)

EP1 sends a RELCOMPLETE to EP2 via the GK.

           | H.323 layer of GK|
           |  |            ^  |
           |  |            |  |
           ---|------------|---

Outgoing | | DDP/SCTP | | RELCOMP<--------- ------------ Incoming RELCOMP | | --------------------

This is what most likely will happen with DDP/SCTP:

Without receiving a RELCOMP, EP2's H.323 layer will time-out and resend RELEASE, and the resend will prompt DDP layer at EP2 to detect the faulted GK and route the resent RELEASE to the alternate GK. Of cause, the alternate GK needs to be able to fetch the call state info of this call from, for example, a shared network memory containing checkpointed call state data and continue the call release sequence of this call. This re-sent RELEASE may surprise EP1 a little; it appears as a duplicate to EP1. But EP1 simply needs to reply another RELCOMP to EP2, DDP will route it through the alternate GK of cause.

From application's view, except a time-out at EP2 and a duplicate RELEASE at EP1, the call flow continues. The take-over is carried out transparently by DDP and SCTP.

I think you are confusing the RELCOMPLETE here with the RELCOMPLETE as used in Q.93B. In H.323 there is no RELEASE message..there is only RELEASE COMPLETE. So in the above example, EP1 is the end that wants to release the call and sends a RELEASE COMPLETE (instead of RELEASE as in Q.93B)and no response is required to this RELEASE COMPLETE. So the moment EP1 's SCTP delivers the RELEASE COMPLETE message to the GK, the EP1 considers the call released. And this is exactly the problem we were trying to point out- the problem of no ACKs. Like you pointed out , if there had been a pair (RELEASE /RELEASE COMPLETE)for every message, the problem would have been sorted out by itself. There are also other H.245 messages which have no ACKs where we will have a similar problem.

So we need an ACK for every message at the H.323 layer also.

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