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

[David R. Kompel]

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