RE: [Serusers] setflag question

-----Original Message----- From: serusers-bounces(a)lists.iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Java Rockx Sent: Thursday, 30 September 2004 12:01 AM To: 'ser users' Subject: RE: [Serusers] setflag question Hello All. I may have stumbled upon the problem. It has to do with not properly handling CANCEL messages. In my ser.cfg I have: modparam("acc", "db_flag", 1) modparam("acc", "db_missed_flag", 1) modparam("acc", "log_fmt", "fisum") modparam("acc", "report_ack", 1) modparam("acc", "log_level", 1) modparam("acc", "failed_transactions", 1) modparam("acc", "report_cancels", 1) modparam("acc|auth_db|domain|group|uri_db|usrloc", "db_url", "mysql://ser:pwd@sipdb01.mycompany.com/ser") route { ... the usual stuff here # BUSY and NOANSWER go to voice mail t_on_failure("1"); # Make sure we handle nathelper stuff t_on_reply("1"); # Enable accounting for this transaction setflag(1); if (!t_relay()) { sl_reply_error(); }; } failure_route[1] { log(1, "Failover to voicemail"); rewritehostport("vm01.mycompany.com:5060"); append_branch(); append_urihf("CC-Diversion: ", "\r\n"); t_relay(); } onreply_route[1] { if (isflagset(6) && status =~ "(183)|2[0-9][0-9]") { fix_nated_contact(); force_rtp_proxy(); } else if (nat_uac_test("1")) { fix_nated_contact(); }; } I'm thinking that the problem is that a BUSY and CANCEL will both follow the same logic and execute failure_route[1]. I don't want CANCEL messages to do this because failure_route[1] is intended for sending BUSY or NOANSWER replies to the voicemail server. How can I determine if the negative value returned by t_relay() is caused by a CANCEL versus a BUSY message? Regards, Paul