On 04/19/2011 09:31 AM, Iñaki Baz Castillo wrote:
[...]
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} / [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.
