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

Jiri Kuthan jiri at iptel.org
Mon Feb 2 10:21:33 CET 2004

I guess you can check status value of 408 (unless a forked transaction
had a branch with status which takes precedence over 408).


At 08:30 PM 1/31/2004, David R. Kompel wrote:
>If this is the case, how would one, right now, test in the
>"failure_route[x]" for a timeout condition? 
>-----Original Message-----
>From: Jiri Kuthan [mailto:jiri at iptel.org] 
>Sent: Friday, January 30, 2004 8:51 AM
>To: David R. Kompel; serusers at lists.iptel.org
>Subject: Re: FW: [Serusers] failure route and ERROR: t_should_relay:
>status rewriteby UAS: stored: 408, received: 487
>I see. Well, I think a proper solution would be to have
>timers....that's something on our to-do list, if people are impatient,
>contributions are welcome.
>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
>>the time delay before the voice mail answers, on a per call/number
>>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
>>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.
>>-----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
>>        if(is_user_in("VM"))
>>                append_branch();
>>                rewritehostport("<your voice mail server that waits to
>>                t_on_failure("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.
>>-----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
>>>in the dset gets an error from the UAS.
>>>It would be nice to see a way that the failure_route could get called
>>>any fork gets an error, and had a way to test for other existing
>>>and cancel them, and then re-direct the call.
>>I am not sure if there is a benefit in forking to N destinations and
>>on N-1 of them if one fails... what is the use case? (I naively thought
>>fork in parallel to try as many destinations as you wish and fall back
>>other alternative such as voicemail only if none of these original
>>Serusers mailing list
>>serusers at lists.iptel.org
>Jiri Kuthan            http://iptel.org/~jiri/ 

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

More information about the sr-users mailing list