I can't test now - high volume traffic is running. But I looked at the diff, it seems to me OK, I see no reason why it could not work:-)

On Friday 29 October 2010, you wrote: > On 10/29/10 4:33 PM, Daniel-Constantin Mierla wrote: >> On 10/29/10 4:09 PM, Sergey Okhapkin wrote: >>> I just realized that 3.1 executes main routing block when broken SIP >>> message >>> is received! But sanity_check() function returns 0 on failed checks >>> and script >>> execution stops, my favorite xlog() is not executed. >> >> OK, that can be fixed very easy. Iirc, in some cases you don't get the >> sip message in the config if it is really broken, but I am not sure if >> error_route was executed for that case anyhow. > > I committed on git master, id: > > 39a8108c62a2beafba18417613b9660a8abef86a > > > Can you take the patch and test it on 3.1? If all is fine, then I can > backport - even the default cfg expects non-drop behavior since it > attempts to print a log message there. > > Cheers, > Daniel > >> Cheers, >> Daniel >> >>> Oct 29 09:48:54 west /usr/local/sbin/kamailio[12225]: ERROR:<core> >>> [parser/msg_parser.c:177]: ERROR: get_hdr_field: bad to header >>> Oct 29 09:48:54 west /usr/local/sbin/kamailio[12225]: INFO:<core> >>> [parser/msg_parser.c:351]: ERROR: bad header field [To: Chi Nhung<sip: >>> ] >>> Oct 29 09:48:54 west /usr/local/sbin/kamailio[12225]: ERROR:<core> >>> [parser/msg_parser.c:177]: ERROR: get_hdr_field: bad to header >>> Oct 29 09:48:54 west /usr/local/sbin/kamailio[12225]: INFO:<core> >>> [parser/msg_parser.c:351]: ERROR: bad header field [To: Chi Nhung<sip: >>> ] >>> Oct 29 09:48:54 west /usr/local/sbin/kamailio[12225]: ERROR:<core> >>> [parser/msg_parser.c:177]: ERROR: get_hdr_field: bad to header >>> Oct 29 09:48:54 west /usr/local/sbin/kamailio[12225]: INFO:<core> >>> [parser/msg_parser.c:351]: ERROR: bad header field [To: Chi Nhung<sip: >>> ] >>> Oct 29 09:48:54 west /usr/local/sbin/kamailio[12225]: ERROR:<core> >>> [msg_translator.c:1946]: ERROR: build_res_buf_from_sip_req: alas, >>> parse _headers failed >>> Oct 29 09:48:54 west /usr/local/sbin/kamailio[12225]: WARNING: sanity >>> [sanity.c:253]: sanity_check(): check_required_headers(): failed to s >>> end 400 via sl reply >>> >>> On Friday 29 October 2010, Daniel-Constantin Mierla wrote: >>>> On 10/29/10 11:53 AM, Sergey Okhapkin wrote: >>>>> Daniel, I think this could be implemented without re-introduction of >>>>> error_route, >>>> >>>> it will not be re-introduced for sure, we have now a different core >>>> framework which care reuse event_route mechanism. >>>> >>>> In the past the error route was executed when the error was >>>> discovered, so it several places of the code, and I am not sure that >>>> the core can continue up to config execution of something is really >>>> broken. >>>> >>>> I will have it in mind when I get some spare time. >>>> >>>> Cheers, >>>> Daniel >>>> >>>>> what about core parameter route_on_error=yes/no (default no)? If >>>>> route on error is enabled, then sanity module will do the trick: >>>>> >>>>> route{ >>>>> if(!sanity_check("1159")) { >>>>> xlog("L_INFO","Bad message from >>>>> $proto:$si:$sp\n$mb\n"); >>>>> break; >>>>> } >>>>> .... >>>>> >>>>> It will be up to script writer what to do in main routing block if >>>>> message parsing fails. >>>>> >>>>> On Friday 29 October 2010, Sergey Okhapkin wrote: >>>>>> It would be nice to get error_route back. The route was trivial in >>>>>> my cfg file: >>>>>> >>>>>> error_route { >>>>>> xlog("L_INFO","Bad message from $proto:$si:$sp\n$mb\n"); >>>>>> drop(); >>>>>> } >>>>>> >>>>>> On Friday 29 October 2010, Daniel-Constantin Mierla wrote: >>>>>>> On 10/28/10 1:41 PM, Sergey Okhapkin wrote: >>>>>>>> I've found one more feature missed in 3.1 - error_route is >>>>>>>> eliminated >>>>>>>> and sanity module added. But if received SIP message is >>>>>>>> malformed and >>>>>>>> can't be parsed, routing script is not executed and I have no >>>>>>>> way to >>>>>>>> log the message to kamailio log. I did it in error_route before. >>>>>>>> >>>>>>>> This logging is important to me to support customers. SIP ALG in >>>>>>>> routers often breaks Via line :-( >>>>>>> >>>>>>> Since I developed error_route, I remember that it handled just >>>>>>> sporadic >>>>>>> cases, but I can add an event_route to pass the buffer and some >>>>>>> hints >>>>>>> to configuration file in case the initial parsing fails and the >>>>>>> message >>>>>>> is dropped before getting to config file. >>>>>>> >>>>>>> It is good to know that someone use such case, introduction of >>>>>>> sanity >>>>>>> was clearly mentioned and so far there was no complain. >>>>>>> >>>>>>> Cheers, >>>>>>> Daniel >>>>>>> >>>>>>>> On Thursday 28 October 2010, Daniel-Constantin Mierla wrote: >>>>>>>>> On 10/26/10 2:22 PM, Sergey Okhapkin wrote: >>>>>>>>>> setdebug() function is no longer provided by core. How to >>>>>>>>>> change debug level dynamically in the script to trace execution >>>>>>>>>> of a few statements only? >>>>>>>>> >>>>>>>>> seems was lost in transition to 3.0, I will check to see what >>>>>>>>> can be >>>>>>>>> done with the new architecture. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Daniel >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users >>>>>>>> mailing list sr-users(a)lists.sip-router.org >>>>>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >>>>>> >>>>>> _______________________________________________ >>>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing >>>>>> list >>>>>> sr-users(a)lists.sip-router.org >>>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >>>>> >>>>> _______________________________________________ >>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing >>>>> list >>>>> sr-users(a)lists.sip-router.org >>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >>> >>> _______________________________________________ >>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing >>> list sr-users(a)lists.sip-router.org >>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users