[SR-Users] setdebug() and 3.X

Sergey Okhapkin sos at sokhapkin.dyndns.org
Sat Oct 30 02:03:24 CEST 2010


The law didn't work this time, the patch works fine to me :-)

On Friday 29 October 2010, Daniel-Constantin Mierla wrote:
> On 10/29/10 5:40 PM, Sergey Okhapkin wrote:
> > 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 at 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 at 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 at 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 at lists.sip-router.org
> >>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
> 




More information about the sr-users mailing list