No, 200OK retransmission is stopped until ACK's arrival or 64*T1. PRACK has no impact on this. Check RFC3261 sec 13.3.1.4
fyi -Rockson -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Siddhardha Garige Sent: Thursday, November 06, 2008 3:16 PM To: [email protected] Subject: [Sip-implementors] controlling 200OK retransmissions. Hello all, I have a question regarding retransmission of 200OK. Proxy can send 100 Trying to stop retransmission on invites on UAC is there any way to control retransmission of 200OK from UAS? Is this a valid senario? Will PRACK stop retransmission of 200Ok messages? UAC ---------------Proxy --------------------------UAS --------Invite---------------------------------------------> <------------------------------100 trying----------------- <--------------------------------180 ringing-------------- <--------------------------------200 Ok--------------------- ------------PRACK----------------> <-------------200 OK (prack------ -----------------------------------ACK--------------------> <-------------------------------rtp---------------------------> RFC 3262 The reliability mechanism works by mirroring the current reliability mechanisms for 2xx final responses to INVITE. Those requests are transmitted periodically by the Transaction User (TU) until a separate transaction, ACK, is received that indicates reception of the 2xx by the UAC. The reliability for the 2xx responses to INVITE and ACK messages are end-to-end. In order to achieve reliability for provisional responses, we do nearly the same thing. Reliable provisional responses are retransmitted by the TU with an exponential backoff. Those retransmissions cease when a PRACK message is received. The PRACK request plays the same role as ACK, but for provisional responses. There is an important difference, however. PRACK is a normal SIP message, like BYE. As such, its own reliability is ensured hop-by-hop through each stateful proxy. Also like BYE, but unlike ACK, PRACK has its own response. If this were not the case, the PRACK message could not traverse proxy servers compliant to RFC 2543 [4]Any help is appreciated. Thanks Sid _______________________________________________ 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
