27 Feb
2007
27 Feb
'07
11:53 p.m.
On Feb 26, 2007 at 12:09, Martin Hoffmann <hn(a)nvnc.de> wrote:
It forwards it statefully.
Andrei
Greger V. Teigre wrote:
It's mostly fixed in Ottendorf. There is still some race potential if
the CANCEL arrives after t_relay() started but before the message being
forwarded (e.g. during branch adding inside t_relay()).
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.
I seem to have missed this discussion, but shouldn't the race be between
the final reply and the CANCEL?
In SER, there is a race between the INVITE and the CANCEL: If the INVITE
processing hasn't been finished and the transaction for it has not yet
been established through t_relay() before the CANCEL arrives, things go
wonky. 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?
If you already have a transaction for the INVITE, you should be fine by
simply passing the CANCEL to tm by calling t_relay(). Don't remember
what tm does with a CANCEL it doesn't have a transaction for. IMHO it
should do nothing and give an error back. 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.
The state is there the moment a transaction is established. The problem
here is that SER doesn't CANCEL branches that have not yet received a
100 Trying since The Standard doesn't allow you to.
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)
As usual: Ignore. It's a borderline case, anyways. Most likely, it will
fix itself anyways because the person that receives the false call will
hang up and thus their UA will generate a BYE.
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?
This depends on what tm is doing with a CANCEL it can't find a
transaction for. If I understand the code right, it currently treats
such a CANCEL as if it were nothing special. This would actually be in
violation of 3261 which states that you MUST forward the CANCEL
statelessly. However, the reasoning is that this is because the proxy
may have forwarded the INVITE statelessly earlier. Since I never do
that, I would happily violate that MUST.
Regards,
Martin