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

["Vijay K. Gurbani" <[e-mail]>]

On 04/19/2011 10:23 AM, Iñaki Baz Castillo wrote:
> 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).

Ah, this is interesting.  More inline.

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

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
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / [e-mail]
Web:   http://ect.bell-labs.com/who/vkg/