Hi,
I'm trying to change the destination set of an request in a failure route using exec_dset(). My routing looks like
route { ... t_on_failure(1); ... }
failure_route[1] { revert_uri(); exec_dset("find-voicemail.pl"); t_relay(); break; }
unfortunately, that does not seem to work, i get the following error from SER when a request hits the failure_route[]:
Oct 1 14:33:17 graham /usr/sbin/ser[4814]: ERROR: t_forward_nonack: no branched for fwding Oct 1 14:33:17 graham /usr/sbin/ser[4814]: ERROR: w_t_relay (failure mode): forwarding failed
Simply adding a static destination by append_branch() works fine, but that's only the solution for an announcement... I'd need something like exec_append_branch() ...
So, is there another way to dynamically add branches? Any hints appreciated!
Alexander Mayrhofer nic.at
Hello,
are you sure that the script (find-voicemail.pl) returns any URIs when executed ? The error message means that no branches have been added.
Jan.
On 01-10 14:38, Alexander Mayrhofer wrote:
Hi,
I'm trying to change the destination set of an request in a failure route using exec_dset(). My routing looks like
route { ... t_on_failure(1); ... }
failure_route[1] { revert_uri(); exec_dset("find-voicemail.pl"); t_relay(); break; }
unfortunately, that does not seem to work, i get the following error from SER when a request hits the failure_route[]:
Oct 1 14:33:17 graham /usr/sbin/ser[4814]: ERROR: t_forward_nonack: no branched for fwding Oct 1 14:33:17 graham /usr/sbin/ser[4814]: ERROR: w_t_relay (failure mode): forwarding failed
Simply adding a static destination by append_branch() works fine, but that's only the solution for an announcement... I'd need something like exec_append_branch() ...
So, is there another way to dynamically add branches? Any hints appreciated!
Alexander Mayrhofer nic.at
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
On (01.10.03 22:05), Jan Janak wrote:
Hello,
are you sure that the script (find-voicemail.pl) returns any URIs when executed ? The error message means that no branches have been added.
Jan,
yes, it does return a new uri set. However, it does only return _one_ uri, while the original destination set may consist of more than one uri. So, does SER get confused about the dset being replaced at that stage of the transaction (in a failure_route)?
Note: If i return several destinations at this stage, eg:
print "sip:8005@193.171.3.10:5061\n"; print "sip:8001@193.171.3.10:5061\n"; print "sip:8003@193.171.3.10:5061\n"; print "sip:8000@193.171.3.10:5061\n";
SER does respond with a different error:
Oct 2 10:25:13 graham /usr/sbin/ser[4996]: ERROR: t_should_relay: status rewrite by UAS: stored: 408, received: 487
I'm now trying to increase debug level, any hint appreciated.
cheers
axelm
On (02.10.03 10:27), Alexander Mayrhofer wrote:
Note: If i return several destinations at this stage, eg:
print "sip:8005@193.171.3.10:5061\n"; print "sip:8001@193.171.3.10:5061\n"; print "sip:8003@193.171.3.10:5061\n"; print "sip:8000@193.171.3.10:5061\n";
of course, the @ should be escaped. Doesn't work with @, either.
cheers
axelm
On (01.10.03 22:05), Jan Janak wrote:
Hello,
are you sure that the script (find-voicemail.pl) returns any URIs when executed ? The error message means that no branches have been added.
I've found a (plain ugly) workaround to the problem.
It seems to me that in failure_route(), a call to exec_dset() _does_ replace the destination set, but does _not_ reset the branches status values.
Example:
destination set before exec_dset() in failure_route[]: * sip:user@ip (SER internal branch status: 487)
destination set after exec_dset(): * sip:voicemailxxx@ip (SER internal branch status: still 487?)
So, it seems to me that the status value is still set to the old value, and therefore that "new" branch is not being considered for relaying anymore, even if it has a new destination.
So, my workaround (which obviously works only when the user has registered exactly one location) is to return a dummy uri as first destination, and the voicemail uri as the second one, like:
After exec_dset: * sip:dummy@nowhere (status: 487) * sip:vvoicemailxxx@ip (status: -)
which seems to do it as a workaround right now. I don't expect that to be the final solution, imho the final solution would be to reset status values of _all_ branches if exec_dset is being called from within a failure route.
Another option would be to modify exec_dset's behaviour to not replace but rather extend the destination set if called from within a failure_route().
Can anyone comment if modifying exec_dset() to reset branch status values is the way to go [isn't the fact that it does _not_ happen probably a bug?] ?
comments?
cheers
axelm
-
Alexander Mayrhofer -
Jan Janak