now i have got sip-router processes up and running without any serious
warnings and listening at correct ip addresses/ports, but when i send it
a register request, nat_uac_test gets called and sip-route reports the
following.
any ideas?
-- juha
Jun 2 19:04:12 localhost /usr/sbin/sip-router[20726]: ERROR: nathelper [nhelpr_funcs.c:179]: message body has length zero
Jun 2 19:04:12 localhost /usr/sbin/sip-router[20726]: ERROR: nathelper [nathelper.c:1429]: cannot extract body from msg!
Jun 2 19:04:12 localhost /usr/sbin/sip-router[20728]: ERROR: nathelper [nhelpr_funcs.c:179]: message body has length zero
Jun 2 19:04:12 localhost /usr/sbin/sip-router[20728]: ERROR: nathelper [nathelper.c:1429]: cannot extract body from msg!
this line
if (!t_relay("0x01")) {
gives error
0(6768) DEBUG: <core> [sr_module.c:515]: find_export_record: <t_relay> not found
0(6768) DEBUG: <core> [sr_module.c:515]: find_export_record: <t_relay> not found
0(6768) : <core> [cfg.y:2921]: parse error in config file, line 2884, column 21: unknown command, missing loadmodule?
how can i achieve the same effect in sr, i.e., do not generate
provisional response. also, how can the other flag values mapped? in
case of failure, does t_relay always return -1 or are the other negative
values as well?
-- juha
if i remember correctly, k told the config file line number where an
error occurred and also the name of the function that issued it. sr
doesn't do so. see previous message about deprecated pv syntax warnings
and now also this:
Jun 1 20:24:49 localhost /usr/sbin/sip-router[14871]: ERROR: utils [utils.c:244]: result pvar is not writeble
in general, how can i know where the problem occurred?
in this particular case, i know where the error comes from:
http_query("some_query", "$ru");
the same statement works fine in k. why is $ru not writeble? can i
replace it with some other form of request-uri variable?
-- juha
Hi Andrei,
could you please have a look at the tirpi/script_callbacks branch?
There are some modules that need to initialize their variables before,
or free/unlock/unref,... something after the script executions. This is
supported only for request and onreply routes, but it is necessary also
before/after failure routes in some cases. (For example db_ops needs to
free the query result.) So I started to add support for pre- and
post-script callbacks for failure routes. But instead of simply adding
another list to the core I generalized the API a bit to support any kind
of route blocks, and added hooks also for branch and onsend routes.
Please let me know whether I can merge my branch to the master.
Daniel: shall I add a hook around modules_k/htable/htable.c:187 for
event_route?
Thanks,
Miklos