Hi Andrew,
Andrew Mortensen wrote:
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.
Actually next_branches() do return false (which is -1, not 0) - see my
previous email.
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.
That is true. We need some work here.
Regards,
Bogdan
andrew
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
Bogdan-Andrei Iancu
OpenSIPS Event - expo, conf, social, bootcamp
2 - 4 February 2011, ITExpo, Miami, USA
OpenSIPS solutions and "know-how"
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
