Inline On 9/22/2010 7:18 AM, abhishek chattopadhyay wrote: > Hi Implementors, > > In 3261 the re-transmission of INVITE is stopped by 1xx responses. So to > stop the re-trnasmission of 200 OK, ACK is sent. > (Albait it would be worth considering that ACK is used for a lot of other > purposes.) > > Further form 3261 only, it is clear that for other methods the request would > be re-transmitted till a 200 is received. The entity sending a 200 OK would > understand that the 200 has been successfully received if the Method is not > re-transmitted again. > > > My question is, > Why at all a 3 way handshake is implimented for INVITE.
INVITE is "special" in that it can take a long time before it is answered, due to alerting. There is a desire not to keep retransmitting while that goes on. So the retransmits are quenched, and then the ACK is required. The other methods are required to complete quickly, so this process isn't used for them. Another reason is to support INVITEs that don't contain an offer. Thanks, Paul > And > 100 trying is not restricted for any Method inside a dialog, so if a 100 > Trying is issued for say UPDATE then why it is not the same case as of the > Re-INVITE's arriving inside the same dialog. > > > Thanks > Abhishek. > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors