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:-)
Because of the law, the
Murphy law ;-)
Probably I will test sometime next week if you don't do it before and
then backport.
Cheers,
Daniel
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