25 Jul
2005
25 Jul
'05
5:51 p.m.
Thanks, Bogdan. So it's still better to process CANCEL the same as
INVITE to avoid this race condition.
My next question is about ACK processing. In my observations if one
uses statefull processing ACKs are either loose_routed or absorbed by
t_relay(). In my test scenarios I've never seen otherwise. So, again, my
question is if the following is OK:
if (loose_route()) { #in-dialog ACKs are forwarded here
do something
t_relay();
exit;
}
if (is_method("ACK")) { #out-of-dialog ACKs are absorbed here
t_relay();
exit;
}
if (uri==myself) {
do lookups that rewrite RURI
t_relay();
}
Thank you,
Michael
On Monday 25 July 2005 07:39 am, you wrote:
Hi Michael,
that is correct. just note you may encounter some races between INVITEs
and CANCELs in the case of a fast CANCEL (CANCEL follows the INVITE
almost instantly) - when one process is still handling the INVITE (the
transaction may not be build yet), another process receives the CANCEL
and it will not be able to match it to a transaction in this case, the
CANCEL will be forward based on its RURI without any info from INVITE.....
regards,
bogdan
Michael Ulitskiy wrote:
Hello,
I have a question about CANCEL processing.
I read on the mailing list that CANCEL will be automatically matched by t_relay
to transaction it's cancelling, if needed transformation to RURI will be automatically
applied and then it will be automatically send to correct destination.
I'm experimenting with openser 0.10.x and it seems to be true, but I'd like to
confirm
that the following is OK:
if (loose_route()) {
do something
t_relay();
break;
}
if (is_method("CANCEL")) {
t_relay();
break;
}
if (uri==myself) {
do lookups that rewrite RURI
t_relay();
}
Thank you,