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

[Jiri Kuthan]

I see. Well, I think a proper solution would be to have user-configurable
timers....that's something on our to-do list, if people are impatient, code
contributions are welcome.

-jiri

At 11:06 AM 1/30/2004, David R. Kompel wrote:
>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 over
>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 how
>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 a
>new INVITE to the vm box, to tell it to answer right away.
>
>--Dave
>
>-----Original Message-----
>From: David R. Kompel [mailto:drk at 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, they
>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 at iptel.org] 
>Sent: Thursday, January 29, 2004 12:59 PM
>To: David R. Kompel; serusers at 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:
>>I'm glad this issue was brought up when it was, cause I was just about
>>to post on it :) I am using the same trick for voice mail. The problem
>>is, if the user is busy, there is no way to detect it, since
>>t_on_failure doesn't call the failure_route[x], if only one of the
>forks
>>in the dset gets an error from the UAS.
>>
>>It would be nice to see a way that the failure_route could get called
>if
>>any fork gets an error, and had a way to test for other existing forks,
>>and cancel them, and then re-direct the call.
>
>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 at lists.iptel.org
>http://lists.iptel.org/mailman/listinfo/serusers

--
Jiri Kuthan            http://iptel.org/~jiri/