28 Feb
2007
28 Feb
'07
5:53 a.m.
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.