Indeed, Andres is right, that's what should be done in this place.
The root reason is that 'status' is not intended for use in failure_route. (I hope we never advertised it was.) We should obviously make it impossible to avoid confusion. I think that enabling t_check_status from reply_route and removing 'status' will do it.
Note there is a great difference between what status and t_check_status do. 'status' refers to currenlty received reply in onreply_route. failure_route is very different -- failure_route returns to processing of the original request, with which several replies may be associated. t_check_status thus first does a branch picking process, selects a branch SER would use if you did nothing else, and that's what you receive.
-jiri
At 09:16 PM 5/27/2004, Andres wrote:
You can try something like:
failure_route[1] { if ( t_check_status("486") ) { . do whatever .
}}
Zeus Ng wrote:
failure_routes process the initial request, not the reply which caused the failure.
I'm not trying to process reply which caused the failure. Instead, I want to process the failure on the initial request. The problem is, a reply, no matter it's 1xx, 2xx, 3xx will always goes through reply route first. Then goes to failure route.
E.g.
UA1 -> SER -> UA2
If UA2 reply "486 Busy" to SER, the reply will be processed by reply route first (due to t_on_reply()) and then failure route (due to t_on_failure()). What I expected is any reply code >= 400 should be processed by failure route only.
Daniel
On 5/27/2004 3:35 PM, Zeus Ng wrote:
I have the following logic.
route { ... t_on_reply("1"); t_on_failure("1"); t_relay(); }
onreply_route[1] { xlog("L_NOTICE", "Reply status %rs: Reason %rr\n"); }
failure_route[1] { xlog("L_NOTICE", "Reply status %rs: Reason %rr\n"); if (status=="408") { do something 1 } else if (status=="480") { do something 2 } else if (status=="486") { do something 3 } }
When a reply with 4xx comes in, it first goes through
onreply_route[1]
and get the result printed to syslog. The message is then passed to failure_route[1]. But it seems that the status code and reason are gone. I get a <null> for both values in the failure route.
How should I
change the script to get that.
Zeus Ng
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Andres Network Admin http://www.telesip.net
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/