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

[Iñaki Baz Castillo <[e-mail]>]

2011/4/19 Vijay K. Gurbani <[e-mail]>:
> 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. 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
<[e-mail]>