Subject: [sipcore] Question regarding RFC 3262

From: "Petersen, Jan 1. (Nokia - DE/Munich)" <[email-masked]>
Date: Mon, 21 Nov 2016 18:38:30 +0000

Hello SIP Experts and RFC 3262 authors,

I am wondering how the race condition between provisional and final responses to the INVITE request that may occur based on this rfc 3262 is to be solved.

I have checked Errata and subsequent rfcs (such as RFC 5407), but was not able to find any solution to this specific race condition.

The issue occurs if the UAS is responding with an (subsequent) provisional response to the INVITE request, using 100rel, while the shortly afterwards the UAS is actually sending the final response to the INVITE, before the PRACK to the provisional response has been received by the UAS:

The UAS MAY send a final response to the initial request before
having received PRACKs for all unacknowledged reliable provisional
responses, unless the final response is 2xx and any of the
unacknowledged reliable provisional responses contained a session
description.  In that case, it MUST NOT send a final response until
those provisional responses are acknowledged.  If the UAS does send a
final response when reliable responses are still unacknowledged, it
SHOULD NOT continue to retransmit the unacknowledged reliable
provisional responses, but it MUST be prepared to process PRACK
requests for those outstanding responses.

So as a result, the UAC may receive the provisional response to the INVITE, immediately followed by the final response 2xx to the INVITE. However, the UAC may still send the PRACK for the provisional response here, but the UAS has already terminated the transaction when this "late" PRACK is received. Consequently the UAS responds to this "late" PRACK with a 481 Call/Transaction Does Not Exist, which in turn causes the UAC to terminate the already established and ongoing SIP session.

Can you please clarify how SIP UAs (UAC and UAS and even SIP Proxies) should handle and solve such a race condition? Especially, is the PRACK transaction directly affecting the corresponding SIP dialog, such that a late negative response to the PRACK received on UAC side (after the 2xx final response to the INVITE has been received already before) is justifying to execute the release of the already successfully established session by the UAC?

What exactly is meant by "... but[the UAS] MUST be prepared to process PRACK requests for those outstanding responses"? Does "process" refers to respond with a 2xx, or to provide any final response, i.e. even a negative response - compared to just dropping it without any response?

Many thanks in advance!

Jan Petersen, NOKIA

email: [email-masked]<mailto:[email-masked]>

---

From: Robert Sparks <[email-masked]>
Date: Tue, 22 Nov 2016 12:05:26 -0600

On 11/21/16 12:38 PM, Petersen, Jan 1. (Nokia - DE/Munich) wrote:
> I am wondering how the race condition between provisional and final 
> responses to the INVITE request that may occur based on this rfc 3262 
> is to be solved.
> I have checked Errata and subsequent rfcs (such as RFC 5407), but was 
> not able to find any solution to this specific race condition.
> The issue occurs if the UAS is responding with an (subsequent) 
> provisional response to the INVITE request, using 100rel, while the 
> shortly afterwards the UAS is actually sending the final response to 
> the INVITE, before the PRACK to the provisional response has been 
> received by the UAS:
> So as a result, the UAC may receive the provisional response to the 
> INVITE, immediately followed by the final response 2xx to the INVITE. 
> However, the UAC may still send the PRACK for the provisional response 
> here, but the UAS has already terminated the transaction when this 
> “late” PRACK is received. Consequently the UAS responds to this “late” 
> PRACK with a 481 Call/Transaction Does Not Exist, which in turn causes 
> the UAC to terminate the already established and ongoing SIP session.
> Can you please clarify how SIP UAs (UAC and UAS and even SIP Proxies) 
> should handle and solve such a race condition? Especially, is the 
> PRACK transaction directly affecting the corresponding SIP dialog, 
> such that a late negative response to the PRACK received on UAC side 
> (after the 2xx final response to the INVITE has been received already 
> before) is justifying to execute the release of the already 
> successfully established session by the UAC?
> What exactly is meant by “…but[the UAS] MUST be prepared to process 
> PRACK requests for those outstanding responses”? Does “process” refers 
> to respond with a 2xx, or to provide any final response, i.e. even a 
> negative response – compared to just dropping it without any response?
It means that it must keep enough state to not return a 481. (A UAS that 
481s such a PRACK has not followed the requirement). The expectation is 
that the PRACK would get a 200. The "In that case" sentence defends 
against the real problems with the race condition you're looking at. The 
remaining situations where there wouldn't be a 200 to the PRACK are 
places where context requires another response (like a 500 or a failure 
due to use or attempted use of an extension).

> Many thanks in advance!
> Jan Petersen, NOKIA
> email: [email-masked] <mailto:[email-masked]>
>
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore