On 11 Feb 2014, at 08:30, Andreas Byström (Polystar) <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 https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors