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

[Jiri Kuthan]

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

-jiri

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? 
>
>--Dave
>
>-----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
>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/ 

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