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} / [email protected]
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 [email protected] for questions on how to develop a SIP
implementation.
Use [email protected] for new developments on the application of sip.
Use [email protected] for issues related to maintenance of the core SIP
specifications.
