18 Dec
2010
18 Dec
'10
11 a.m.
On 12/18/10 9:34 AM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
Yours a bit different -- you send 503 from main route upon t_relay()
failure -- I will try it as well. I had:
branch_route[TEST] {
drop;
}
# Main SIP request routing logic
# - processing of any incoming SIP request starts with this route
route {
setflag(FLT_ACC);
setflag(FLT_ACCMISSED);
t_on_branch("TEST");
t_relay();
exit;
}
And the log was (102 calling 123):
11(30316) DEBUG: tm [t_reply.c:659]: DEBUG: reply sent out.
buf=0x83040c0: SIP/2.0 100 trying -..., shmem=0xb596c89c: SIP/2.0 100
trying -
11(30316) DEBUG: tm [t_reply.c:669]: DEBUG: _reply_light: finished
11(30316) ERROR: *** cfgtrace:
c=[/home/spider/work/sip/esr/sip-router/../etc/kamailio-3.1-debugger.cfg] l=370
a=3 n=drop
11(30316) DEBUG: tm [t_funcs.c:361]: ERROR:tm:t_relay_to:
t_forward_nonack returned error
11(30316) DEBUG: tm [t_funcs.c:369]: -6 error reply generation delayed
11(30316) ERROR: *** cfgtrace:
c=[/home/spider/work/sip/esr/sip-router/../etc/kamailio-3.1-debugger.cfg] l=386
a=3 n=exit
11(30316) DEBUG: tm [t_lookup.c:1532]: t_unref: delayed error reply
generation(-6)
11(30316) DEBUG: <core> [msg_translator.c:207]:
check_via_address(192.168.56.102, 192.168.56.102, 0)
11(30316) DEBUG: tm [t_reply.c:1464]: DEBUG: cleanup_uac_timers: RETR/FR
timers reset
11(30316) DEBUG: tm [t_hooks.c:288]: DBG: trans=0xb596b1d0, callback
type 128, id 0 entered
11(30316) NOTICE: acc [acc.c:275]: ACC: call missed:
timestamp=1292662280;method=INVITE;from_tag=500B2B26;to_tag=;call_id=1182353533(a)192.168.56.102;code=500;reason=Server
Internal
Error;src_user=102;src_domain=192.168.56.102;dst_ouser=123;ruri=sip:123@192.168.56.102;dst_user=123;dst_domain=192.168.56.102
11(30316) DEBUG: tm [t_reply.c:659]: DEBUG: reply sent out.
buf=0x830422c: SIP/2.0 500 I'm terr..., shmem=0xb596c89c: SIP/2.0 500
I'm terr
11(30316) DEBUG: tm [t_reply.c:669]: DEBUG: _reply_light: finished
I was wondering where you get 503 reply code since I get 500. I do
log_extra instead of db_extra, but fetching of the values is the same thing.
Cheers,
Daniel
--
Daniel-Constantin Mierla
Kamailio (OpenSER) Advanced Training
Jan 24-26, 2011, Irvine, CA, USA
http://www.asipto.com
I tried to reproduce, but didn't get it:
- call 123
- set accounting flags, including for missed calls
- set t_on_branch(test)
- in branch_route[test] i have drop
daniel,
did you have $ru in db_extra? i have:
modparam("acc", "db_extra", "translated_ruri=$ru;...")
Can you describe a bit more your case? Is it one
branch or more for
these calls? Are all dropped or some are forwarded. It seems that there
is a 503 reply processed while in the case of the single branch dropped
should be generated a 500.
i call t_relay only once before the crash happens and
there is only one
branch. script goes something like this:
setflag(ACC_FLAG);
setflag(ACC_MISSED_FLAG);
t_on_reply("REPLY");
t_on_failure("FAILURE");
while ($true) {
if (!next_gw()) {
send_reply("503", "Service not available");
exit;
};
t_on_branch("BRANCHES");
if (t_relay()) exit;
};
and in branch route i call drop.