[Devel] NEW FEATURE: error_route - automatic error handling

Daniel-Constantin Mierla daniel at voice-system.ro
Tue Jan 9 18:56:26 CET 2007


Hello,

today was introduced in development version a framework for automatic 
error handling. Based on past experiences and comments on the mailing 
lists, error handling was a bit deficient from the configuration file. 
Log files could get full of error messages when SIP messages were 
incorrect, the processing continued even it should have stopped.

With the new framework, the administrator can write a error_route block 
and there decide what to do when an error is encountered. Right now, 
error_route is executed for parsing errors in sip requests - one can 
send back now the appropriate reply. I use this email to start a 
discussion about how to extend it, there could be system errors (e.g., 
memory, database access, ...) or errors in replies (here we can use same 
route block and check the type of sip message not to force reply to 
reply - a new more flexible and easier way to access pseudo-variables is 
underway).

In the error_route are available 4 new pseudo-variables:
- $err.class - the class of error (now is ‘1’ for parsing errors)
- $err.level - severity level for the error
- $err.info - text describing the error
- $err.rcode - recommended reply code
- $err.rreason - recommended reply reason phrase

With the new sl_reply() from sl module you can reply with the 
appropriate code and reason from error_route[] - here is an example:

  error_route {
     xlog("--- error route class=$(err.class) level=$(err.level)
            info=$(err.info) rcode=$(err.rcode) rreason=$(err.rreason) ---\n");
     xlog("--- error from [$si:$sp]\n+++++\n$mb\n++++\n");
     sl_reply("$err.rcode", "$err.rreason");
     exit;
  }

In addition to sl_send_reply(), append_to_reply() and xlog functions can 
be used in error_route. You have to use 'exit' if you do not want to 
continue the execution when an error occurred. Error level is meant to 
show if the processing can continue without any issue, or if the error 
allows to send reply or not. Please note that malformed SIP messages can 
still go through your proxy in the case the processing didn't discover 
it (OpenSER has an incremental parser, it parses only what it needs).

If no error_route is defined, the functionality is same as before.

Looking forward to feedback about this new automatic error handling.

Cheers,
Daniel




More information about the Devel mailing list