RFC 3261 - 16.10 (CANCEL processing in a Proxy)

[Iñaki Baz Castillo]

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.

[Vijay K. Gurbani]

On 04/19/2011 09:31 AM, Iñaki Baz Castillo wrote:
[...]

Post by Iñaki Baz Castillo
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).

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} / ***@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenanc

[Iñaki Baz Castillo]

Post by Vijay K. Gurbani
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.

[Vijay K. Gurbani]

Post by Iñaki Baz Castillo
Thanks Vijay. What you say makes lot of sense, however handling a
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
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.

Post by Iñaki Baz Castillo
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} / ***@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP spec

[Iñaki Baz Castillo]

Post by Vijay K. Gurbani
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.

Right, it says nothing about CANCEL.

Post by Vijay K. Gurbani
 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

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