Subject: Re: [sipcore] Question regarding RFC 3262

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

Hi,

> It means that it must keep enough state to not return a 481.

That sounds like a stretch.

> (A UAS that 481s such a PRACK has not followed the requirement).

Returning 481 follows earlier text within the section (although some
vendors ignore the indication to process the PRACK according to RFC 3261
section 12.2.2).

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

---

From: Robert Sparks <[email-masked]>
Date: Fri, 9 Dec 2016 09:50:32 -0600

Hi Brett -

You cut away too much context.

> That sounds like a stretch.
No - I'm not trying to stretch the text  - that was exactly the intent 
of it.
> with a 481 (Call/Transaction Does Not Exist) status code and pass that to
And you are leaving out exactly the MUST from 3262 that was added to 
cover this edge condition (which is the one Jan was asking about).

Yes, if we were writing the text today, we could make it far clearer - 
as its written, you have to infer what "be prepared to process" means. 
But the overwhelming majority of implementations so far have been able 
to do so.

---

From: [email-masked] (Dale R. Worley)
Date: Sun, 11 Dec 2016 22:14:06 -0500

"Petersen, Jan 1. (Nokia - DE/Munich)" <[email-masked]>
writes:
> 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.

I don't see what the problem is.  RFC 3262 section 3 says:

   A matching
   PRACK is defined as one within the same dialog as the response, and
   whose method, CSeq-num, and response-num in the RAck header field
   match, respectively, the method from the CSeq, the sequence number
   from the CSeq, and the sequence number from the RSeq of the reliable
   provisional response.

   If a PRACK request is received by the UA core that does not match any
   unacknowledged reliable provisional response, the UAS MUST respond to
   the PRACK with a 481 response.  If the PRACK does match an
   unacknowledged reliable provisional response, it MUST be responded to
   with a 2xx response.

In the case you describe, the UAC has sent a PRACK, and UAS sees the
PRACK is "matching", and so the UAS MUST send a 200 response to the
PRACK.  The fact that the UAS has sent a final response to the INVITE
transaction is irrelevant.

I suppose there is some ambiguity if the UAS has terminated the *dialog*
before the PRACK arrives, because it might be argued that the PRACK
should receive a 481 response because it is within a terminated dialog.
But whether such a PRACK gets a 481 or a 200 response makes no
difference in practice.

Dale

---

From: Brett Tate <[email-masked]>
Date: Mon, 12 Dec 2016 08:22:00 -0500

Hi,

> I don't see what the problem is.  RFC 3262 section 3 says:

<snip>

> In the case you describe, the UAC has sent a PRACK, and
> UAS sees the PRACK is "matching", and so the UAS MUST
> send a 200 response to the PRACK.  The fact that the UAS
> has sent a final response to the INVITE transaction is
> irrelevant.

In my opinion, that requires the paragraph to be applied out of context
since the dialog has been terminated and RFC 3262 previously indicated
that RFC 3261 section 12.2.2 applies.

It seems like the debate falls into the usual division of those that
interpret RFC 3262 as though "PRACK is like any other request within a
dialog" and those that don't.  The "open issue" is mentioned within RFC
6337 section 2.3.

> I suppose there is some ambiguity if the UAS has terminated
> the *dialog* before the PRACK arrives, because it might be
> argued that the PRACK should receive a 481 response because
> it is within a terminated dialog.  But whether such a PRACK
> gets a 481 or a 200 response makes no difference in practice.

Unfortunately, sending 481 to PRACK causes at least one vendor to send
CANCEL or BYE (even if 481 was associated with an early dialog that does
not match the answered call).

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 12 Dec 2016 11:35:57 -0500

OK, there's some context I'm losing here.  Quoting from Jan
Petersen's original message:

> 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:
> ...
> this "late" PRACK is received. ...

As I read it, Jan is only discussing the case when the final response
for the INVITE is 2xx, i.e., the dialog becomes established.

(I believe that the issue is "What does a UAS do when it receives a PRACK
for a provisional response, when the provisional response's transaction
has completed?"  It seems to me that the plain answer in RFC 3262 is
that the UAS must send a 2xx response.)

> that RFC 3261 section 12.2.2 applies.

What I don't understand is the part about "the dialog has been
terminated".  It seems to me to be clear in Jan's case that the dialog
has *not* been terminated.

And there is a second part to this conversation:

> not match the answered call).

It seems to me that's the vendor's problem.  I'd think when the UAC
receives a 4xx response to a PRACK sent within an early dialog (which by
hypothesis is in the process of being terminated with a 4xx response to
the INVITE), then the UAC could terminate the early dialog but it must
leave the overall dialog unaffected.

Compare with when when the UAS sends a provisional response with an
answer:  Then the UAC can send an UPDATE with a new offer to the UAS
within the early dialog.  If the UAS doesn't like the offer, it can
reject the UPDATE with any of a number of 4xx responses.  But that
response doesn't terminate the early dialog with that UAS, nor the
overall dialog.  (RFC 3311, section 5.3)

Dale

---

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

Hi Robert,

> You cut away too much context.

Sorry; I re-added the question portion.  I also may have incorrectly
misinterpreting if you think the behavior is the same or different if the
dialog has been terminated.

>>>> 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?
>>>
> No - I'm not trying to stretch the text  - that
> was exactly the intent of it.

I agree if the dialog has not been terminated; otherwise ...

That interpretation ignores the earlier "PRACK is like any other request
within a dialog" text to process PRACK according to RFC 3261 section 12.2.2.

I always hesitate to discuss "intent" in regards to RFC 3262 since members
of the working group had vastly different interpretations about the validity
of a UAS to return responses other than 200 or 481.  See "open issue"
discussed within RFC 6337 section 2.3.

If your interpretation also applies on a terminated dialog, this seems like
the usual debate between those that think "PRACK is like any other request
within a dialog" and those that don't.  Does sipcore ever plan to close the
"open issue" through errata or rfc3262bis?

>> Returning 481 follows earlier text within the section (although
>> some vendors ignore the indication to process the PRACK according
>> to RFC 3261 section 12.2.2).
>>
>> 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."
>
> And you are leaving out exactly the MUST from 3262 that was
> added to cover this edge condition (which is the one Jan was
> asking about).

I agree if Jan was solely asking about situation where the dialog has not
been terminated; otherwise ...

As far as I know, the "MUST be prepared to process PRACK" text does mean the
potential to process PRACK like any other request within dialog (which might
include returning 481 if the dialog was terminated).