Subject: [Sip] RFC 3261 - 16.10 (CANCEL processing in a Proxy)

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 19 Apr 2011 16:31:04 +0200

Hi, according to RFC 3261 - 16.10 CANCEL Processing (Proxy)

  If a response context is not found, the element does not have any
  knowledge of the request to apply the CANCEL to.  It MUST statelessly
  forward the CANCEL request (it may have statelessly forwarded the
  associated request previously).

In my case I do know that my proxy doesn't behave as a stateless proxy
so I see no reason to forward a CANCEL if it doesn't match a server
transaction. And I do know that such forwarded CANCEL will not success.

I've also told that such requeriment (statelessly forwarding a CANCEL
if not transaction is matched) would never work in some scenarios as
IMS.

Basically, if I do know that my proxy always behaves statefully there
is no use case in forwarding a CANCEL not matching a server
transaction. IMHO such "MUST" in 16.10 should be relaxed and local
policies allowed.

BTW, could an always-stateful proxy reply 481 upon receipt of a CANCEL
not matching a server transaction? or should it ignore it? (this is
not contemplated in RFC 3261 as it mandates statelessly forwarding of
the CANCEL, but I hope such requeriment should be removed/relaxed in a
future revision of SIP protocol).

Thanks a lot.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 19 Apr 2011 09:56:18 -0500

On 04/19/2011 09:31 AM, Iñaki Baz Castillo wrote:
[...]
> future revision of SIP protocol).

Consider what happens if a stateful proxy proxies an INVITE downstream
and then promptly crashes.  It is duly chastised and quickly brought up
again, and it now sees a CANCEL to the INVITE it had previously proxied
downstream before crashing (assume that all the transaction state was
wiped out when the proxy crashed).

What should it do now?  If it issues a locally generated 481, it allows
the downstream server that received the INVITE to continue processing
it.  If it sends the CANCEL statelessly, it may hit the same downstream
server and cease processing.

Regardless of the behaviour of the proxy, things will still tend to
work out okay since by the old SIP mantra, each transaction completes
independently of others.  So, regardless of whether the proxy generates
a 481 (CANCEL) or sends the CANCEL downstream allowing the downstream
server to generate a final response (say 2xx-class) for the CANCEL,
the state machinery of the upstream UAC remains idempotent with respect
to a reply.  That is, the 481 or 2xx for the CANCEL closes the pending
CANCEL transaction at the UAC, and it now waits for a final response
for the INVITE it send out earlier.

All this said, I believe that most SIP servers that operate statefully
simply send out a 481 on a CANCEL they cannot match to a pending
transaction.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web:   http://ect.bell-labs.com/who/vkg/

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 19 Apr 2011 17:23:03 +0200

> simply send out a 481 on a CANCEL they cannot match to a pending

Thanks Vijay. What you say makes lot of sense, however handling a
CANCEL after crashing is not the only problem in a proxy:

Your text assumes that the proxy doesn't store the transaction
state/data in a permanent backend so it can not recover it after
rebooting (sure this is true in 99% of the existing implementations).
So imagine that, after rebooting in the middle of a INVITE transaction
in proceeding state, the UAS sends a final response to the UAC:

According to RFC 6026 (which updates RFC 3261):

      When a response is received by an element, it first tries to
      locate a client transaction (Section 17.1.3) matching the
      response.  If a transaction is found, the response is handed to
      the client transaction.  If none is found, the element MUST NOT
      forward the response.

So the response wouldn't arrive to the UAC (which would also produce
several issues, similar as if the CANCEL sent by the UAC is not
forwarded to the UAS).

This is, originally RFC 3261 seems to handle the case in which a proxy
is rebooted (CANCEL forwarded stateless, responses statelessly
forwarded based on second Via...) but then RFC 6026 arrives an changes
it (basically to avoid DoS attacks, the same attack that can occur if
a proxy routes statelessly CANCEL's not matching a transaction). So it
seems it is not very clear which philosophy to follow, do you agree?
:)

Best regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 19 Apr 2011 10:45:19 -0500

> several issues, similar as if the CANCEL sent by the UAC is not

Ah, this is interesting.  More inline.

> seems it is not very clear which philosophy to follow, do you agree?

Since rfc6026 updates rfc3261, I would presume that rfc6026 takes
precedence insofar as sending a response statelessly is concerned.

However, I don't think that rfc6026 says much about whether or not
to generate a 481 to a CANCEL if the CANCEL does not match a pending
transaction.  So go crazy and generate it at a stateful proxy;
from the viewpoint of the UAC, it did receive a final response
for the CANCEL.  It may well never receive a final response
for the INVITE if the proxy
   implements rfc6026
     AND the proxy crashed after sending the INVITE
       AND the proxy did not store transaction state in persistent store
         AND the proxy was promptly brought up and was presented with a
         200 OK (INVITE) that did not match pending transactions

Thanks,

- vijay

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 19 Apr 2011 17:48:06 +0200

> to generate a 481 to a CANCEL if the CANCEL does not match a pending

Right, it says nothing about CANCEL.

>  So go crazy and generate it at a stateful proxy;

AND since the UAC would never receive the 200 it would not send the
ACK, so the UAS would terminate the dialog (sending a BYE) after ~32
seconds, which is "acceptable" (in the context of a crashing proxy).
:)

-- 
Iñaki Baz Castillo
<[email-masked]>