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

Reply via email to