Subject: Re: [sipcore] Question regarding RFC 3262

From: Brett Tate <[email-masked]>
Date: Fri, 9 Dec 2016 10:06:56 -0500

> 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.

Since the dialog has been terminated, returning 481 sounds acceptable
(although some vendors completely ignore the RFC 3261 section 12.2.2
mandate).

RFC 3262 section 3: "PRACK is like any other request within a dialog, and
the UAS core processes it according to the procedures of Sections 8.2 and
12.2.2 of RFC 3261."

RFC 3261 section 12.2.2: "If the UAS wishes to reject the request because
it does not wish to recreate the dialog, it MUST respond to the request
with a 481 (Call/Transaction Does Not Exist) status code and pass that to
the server transaction."

> 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?

Before deciding to send BYE or CANCEL because of 481 response to PRACK,
you should be aware of forking and potential to send 481 on a known
dialog.

Similar to CANCEL processing, a 481 response can be sent for PRACK even
though the UAS is still aware of the dialog.  Thus if you receive 481, you
might not want to send BYE for the specific dialog.  If I recall
correctly, RFC 5057 discusses 481 for CANCEL but neglects to indicate the
same behavior for PRACK.

Because of forking, a 481 response to PRACK does not necessarily justify
cancelling the INVITE or releasing the call.  For instance during a
forking situation where the PRACK was associated with a different dialog,
releasing an answered call because received 481 for PRACK on non-answered
dialog does not seem to be justified.  Similarly even if you didn't want
the call to be answered on the dialog associated with 481, you might want
to still allow the call to be answered on one of the other dialogs.

> What exactly is meant by ". but[the UAS] MUST be prepared to
> process PRACK requests for those outstanding responses"?

In my opinion, it means that it is an expected situation and don't ignore
the PRACK.  For example during forking, a CANCEL sent by proxy/b2bua may
have already caused delivery of 487/ACK for INVITE.  The UAS likely won't
wait indefinitely for the PRACK.  Some vendors think RFC 3261 section
12.2.2 applies to the late PRACK (i.e. they return 481).  Other vendors
continue to time for PRACK (or wait indefinitely) and are willing to
somehow comply with the SDP offer/answer rules (i.e. they return 2xx).

Also my recollection is that RFC 3261 (section 16.6?) allows call stateful
proxies to reject requests for unknown dialogs.  Thus they might return
481 for PRACK.

---

From: Brett Tate <[email-masked]>
Date: Mon, 12 Dec 2016 13:48:11 -0500

Hi,

Sorry about that.  My answer involved PRACK being received on the
non-answered terminated dialog (e.g. after 487/ACK) during a forked INVITE
situation.  Jan's question may have been only associated non-forking
situation involving late PRACK received on the answered/confirmed dialog.

-brett