On Jan 29, 2011, at 11:53 AM, Brett Nemeroff wrote:
> All,
>
> I'm routing calls using 3XX redirects. I serialize the branches. I
> immediately call a next_branches() and arm a failure_route. In the failure
> route I do something like:
>
>
> if (!next_branches()) {
> t_reply("503","Service Unavailable ");
> exit;
> }
>
> To catch the end of the list of rollover options.
next_branches actually never returns false (0) as a result of SVN trunk commit
7248, so you'll never hit your t_reply call. (I'd post a link to the commit,
but SF.net's SVN host seems sad today for some reason.) I'm not sure what the
reason for the return code changes was here, but opensips now returns 2 if the
current branch is the last one, and returns 1 if there are more branches
available for processing.
> I see in my log:
> Jan 29 09:23:50 sip1 /usr/local/sbin/opensips[21262]: ERROR:core:do_action:
> next_branches failed
> ...
>
> Over and over. Is there some sort of test I should be doing prior to calling
> next_branches? or is the log level just too high on that message?
I suspect your serial_avp may be empty when you call next_branches from the
failure route. Bumping your log level to debug would show it for sure, since
you'd might then see messages like "DBG:core:serialize_branches: nothing to do
- all same q!" (from serialize_branches) and "DBG:core:next_branches: no AVPs
-- we are done!" (from next_branches).
The latter message will show up if, in next_branches, search_first_avp returns
nothing. It then jumps to an error handler returning a value of -1 to the
caller, which is why you're seeing the repeated "next_branches failed" message.
Given that an empty response from search_first_avp has been considered an error
from the very first commit of the next_branches code, it seems reasonable to
change the "no AVPs" log message to log at error level, which would at least
have the effect of informing the admin of the reason for the failure.
Alternatively, since an empty serial_avp seems very similar to an end of list
condition, a change in the logic when handling an empty serial_avp is worth
considering. It might be better in that case to pass control back to the config
for further processing.
andrew
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
