Thanks Ankur and Olle Now its more clear to me. The transaction/transport layer is responsible for retransmitting the first issued PRACK until it has received a 200 OK for that PRACK. The application should ignore retransmitted provisional responses, since the first PRACK will be retransmitted until 200 OK is received (and by that time there will be no more retransmissions of the provisional response.
Regards, // Andreas From: ankur bansal [mailto:abh.an...@gmail.com] Sent: den 11 februari 2014 09:50 To: Olle E. Johansson Cc: Andreas Byström (Polystar); sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Double checking the behavior of PRACK The statement mentioned in RFC : In particular, a UAC SHOULD NOT retransmit the PRACK request when it receives a retransmission of the provisional response being acknowledged, although doing so does not create a protocol error. This suggests that PRACK is different from ACK as PRACK is any other non-INVITE request which should be not sent on getting prov response retransmission ACK is special request that being sent on getting final response retransmission. And coming to your question of PRACK being lost and not recieved by UAS , then UAC will also not get 200 ok for PRACK so it would be retransmitted in regular intervals as per sip timers .And one of the retransmitted PRACK would reach UAS if network itself not down .If UAS never get PRACK then UAC side ,PRACK transaction will timeout . So bottomline is that UAC dont need to retransmit PRACK for prov response retransmission ,as UAC will be doing it anyway as per normal sip timers. Thanks & regards Ankur Bansal On Tue, Feb 11, 2014 at 1:11 PM, Olle E. Johansson <o...@edvina.net<mailto:o...@edvina.net>> wrote: On 11 Feb 2014, at 08:30, Andreas Byström (Polystar) <andreas.byst...@polystar.com<mailto:andreas.byst...@polystar.com>> wrote: > Hi > > RFC3262 says the following about UAC: > > "Note that the PRACK is like any other non-INVITE request within a > dialog. In particular, a UAC SHOULD NOT retransmit the PRACK request > when it receives a retransmission of the provisional response being > acknowledged, although doing so does not create a protocol error. > > Once a reliable provisional response is received, retransmissions of > that response MUST be discarded. A response is a retransmission when > its dialog ID, CSeq, and RSeq match the original response. The UAC > MUST maintain a sequence number that indicates the most recently > received in-order reliable provisional response for the initial > request. This sequence number MUST be maintained until a final > response is received for the initial request. Its value MUST be > initialized to the RSeq header field in the first reliable > provisional response received for the initial request. > > Handling of subsequent reliable provisional responses for the same > initial request follows the same rules as above, with the following > difference: reliable provisional responses are guaranteed to be in > order. As a result, if the UAC receives another reliable provisional > response to the same request, and its RSeq value is not one higher > than the value of the sequence number, that response MUST NOT be > acknowledged with a PRACK, and MUST NOT be processed further by the > UAC. An implementation MAY discard the response, or MAY cache the > response in the hopes of receiving the missing responses. > " > > I interpret this as if the UAC receives a retransmitted reliable response it > should NOT send the PRACK again. If this is true, it means that if the first > PRACK is lost, the UAS will never receive it? The PRACK behaves like any other non-INVITE request. It is retransmitted by itself until timers expire or you get an answer. The text here states - in my opinion - that it is a standalone transaction, you should not retransmit PRACK if you get a retransmit of the 1xx message that caused it. /Olle _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu<mailto: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
