From: "Ujjwal SIngh" <[EMAIL PROTECTED]> I am simulating a test environment with SIPP and my client UAC
UAC SIPp INVITE---------------------------------------> 180 <----------------------------------------- 200 OK <------------------------------------ 200 OK <------------------------------------ 200 OK <------------------------------------ 200 OK <------------------------------------ 200 OK <------------------------------------ 200 OK <------------------------------------ 200 OK <------------------------------------ ------------------------------------------------->ACK ------------------------------------------------->ACK these 7 200s OK got retransmitted within 500 msec both the ACKs come after the last 200 OK. is it valid. since RFC 3261 says for every 200 OK the UAC core should send ACK. The real rule is "the UAC must transmit at least one ACK after every 200 that it receives". That is what is needed to ensure reliable confirmation of 200s. In this case, since the UAC was prevented from transmitting any ACKs until after it received seven 200s, it can confirm all of them with one ACK -- that ACK was sent after all seven 200s were received. The question you want to answer is why your UAC took so long to get around to sending any ACK -- 500 msec is far too long. Dale _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
