RE: FW: [Serusers] failure route and ERROR: t_should_relay: status rewriteby UAS: stored: 408, received: 487

Sorry, I thought I did a "reply-all" but I didn't. To provide a little more info: To handle voice mail in the user doesn't answer the phone case, using a falure_route timeout is not the best way to go. You have no control

the time delay before the voice mail answers, on a per call/number basis. To overcome this problem, we append_branch a fork to the voice mail box (asterisk modified), right away. The asterisk looks up in a database

long to wait before answering. This works great, except for when the user is busy. In the case of the user busy, it still waits the delay time, before answering. Having the routing script be notified of a failure, if one fork fails, and allowing the script to decide if it should let the rest proceed, or cancel them and start new ones, would solve this problem. Should the UAC of the user be busy, and only on a busy response, you could then abort the other fork (the one waiting to answer), and place

new INVITE to the vm box, to tell it to answer right away. --Dave -----Original Message----- From: David R. Kompel [mailto:drk@drkngs.net] Sent: Friday, January 30, 2004 1:50 AM To: 'Jiri Kuthan' Subject: RE: [Serusers] failure route and ERROR: t_should_relay: status rewriteby UAS: stored: 408, received: 487 Not the idea of giving you N-1, but the ability if any one fails, to decide if you want to let the others go, or cancel them, and start new ones. Example: ... if(is_user_in("VM")) append_branch(); rewritehostport("<your voice mail server that waits to answer>"); t_on_failure("x"); }; ... failure_route[x]{ if(status =~ "^486") { if(t_other_forks() > 0) { t_cancle_all_forks(); }; prefix("special digits to tell vm server busy"); append_branch(); t_relay(); }; }; In other words, always pass script to failure_route, and let it decide if the other forks should be continued, or allow it to abort them and try something else. In the case of voice mail, w/ delayed answer, if the user was busy,

could get the VM instantly, not waiting for the time out, and in the case of some vm systems, could play the user busy greeting, rather then the user away greeting. --Dave -----Original Message----- From: Jiri Kuthan [mailto:jiri@iptel.org] Sent: Thursday, January 29, 2004 12:59 PM To: David R. Kompel; serusers(a)lists.iptel.org Subject: RE: [Serusers] failure route and ERROR: t_should_relay: status rewriteby UAS: stored: 408, received: 487 At 08:04 PM 1/29/2004, David R. Kompel wrote: forks if >any fork gets an error, and had a way to test for other existing

I am not sure if there is a benefit in forking to N destinations and giving on N-1 of them if one fails... what is the use case? (I naively thought you fork in parallel to try as many destinations as you wish and fall back to other alternative such as voicemail only if none of these original destinations succeded.) -jiri _______________________________________________ Serusers mailing list serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers