INVITE is a long running transaction because a human is often involved in the loop. The primary purpose of ACK is to support a "split transaction" model. Hence, the UAS can answer with a provisional 100 or 180 response and send the final response later (after the human picks up the phone). At that time, the UAS needs confirmation that the UAC that initiated the call is still there ( it could have disconnected silently without sending BYE, for example, if the person on the other end takes too long to answer ). This is what the ACK is doing.
I think it would have made SIP simpler if all Dialog-initiating transactions required a three way handshake but unfortunately, they don't. This leads to complications in Subscribe/Notify dialog setup for example. Ranga On Mon, 2006-09-18 at 14:46 +0000, [EMAIL PROTECTED] wrote: > Hi, > > What was the intention behind proposing the need for sending ACK after > 200OK of INVITE under SIP. > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
