Greger V. Teigre wrote:
I forward this from the serusers list:
A CANCEL is being sent from a UAC before having established a route set, thus the CANCEL has no Route header and is not caught by loose routing. The below thread shows that this case is difficult to understand. Jiri and Bogdan had a discussion on serusers regarding the race condition where the provisional reply from UAS and the CANCEL cross each other.
Q1: This situation can be handled in 0.9.x by sending CANCEL through handling the CANCEL as an INVITE. Has this changed in SER 2.0?
No.
Q2: At what point will t_reply be able to match the CANCEL against the state in tm? I assume only when the provisional reply has been received from UAS.
TM will be able to match the CANCEL agains the state created by INVITE even if no provisional reply has been received from downstream. It's just that it will not forward it down the branch.
Q3: Jiri and Bogdans' discussion seems to conclude that the proxy should not do anything, but is the responsibility of the UAC. This seems strange to me as a missing CANCEL (that in fact could have been routed correctly) is likely to result in an OK, then a BYE, and (as the thread below suggest) is often not handled properly by UACs. So: What is the best way to practically handle this? (i.e. sysop's perspective)
Q4: From a user's perspective, sending all CANCELs to t_relay() would be very appealing. It is natural to assume that tm could match the dialog and appropriate routing. Is this possible for 2.0? If not, is this feasible?
Yes, it would be possible, you could have a catch-all-CANCELs code at the very beginning of your configuration file, but it won't cover the cases when no INVITE transaction exist. In such a case t_relay will relay the CANCEL which would enter a forwarding loop because the Request-URI does not change.
Jan.