[OpenSIPS-Users] Next branches error

[Andrew Mortensen]

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