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,