Andreas Granig wrote: Ok, it happend again on another server, and it's, similar to the last time, a CANCEL which locks up the processes. Below you can find a backtrace, but I do also have a core file if needed. I attached to different children and they all have the same backtrace with the same SIP message which causes the lock. Thanks, Andy (gdb) backtrace #0 0x400f4587 in sched_yield () from /lib/libc.so.6 #1 0x4031796d in t_retransmit_reply (t=0x41097918) at fastlock.h:170 #2 0x40312a90 in t_newtran (p_msg=0x8132ac8) at t_lookup.c:1096 #3 0x4030ddbc in t_relay_to (p_msg=0x8132ac8, proxy=0x0, proto=0, replicate=0) at t_funcs.c:224 #4 0x403207af in w_t_relay (p_msg=0x8132ac8, _foo=0x0, _bar=0x0) at tm.c:889 #5 0x0804f296 in do_action (a=0x8126a08, msg=0x8132ac8) at action.c:610 #6 0x08050990 in run_actions (a=0x8126a08, msg=0x8132ac8) at action.c:718 #7 0x0806d984 in eval_elem (e=0x8126a38, msg=0x8126a08) at route.c:605 #8 0x0806c128 in eval_expr (e=0x8126a38, msg=0x8132ac8) at route.c:654 #9 0x0806c0f9 in eval_expr (e=0x8126a68, msg=0x8126a38) at route.c:670 #10 0x0804f183 in do_action (a=0x8126e88, msg=0x8132ac8) at action.c:586 #11 0x08050990 in run_actions (a=0x8126e88, msg=0x8132ac8) at action.c:718 #12 0x0804f055 in do_action (a=0x811aac8, msg=0x8132ac8) at action.c:375 #13 0x08050990 in run_actions (a=0x811aac8, msg=0x8132ac8) at action.c:718 #14 0x0804f055 in do_action (a=0x811a1f8, msg=0x8132ac8) at action.c:375 #15 0x08050990 in run_actions (a=0x811a1f8, msg=0x8132ac8) at action.c:718 #16 0x08069119 in receive_msg ( buf=0x80cba40 "CANCEL sip:042422115963@voip.inode.at SIP/2.0\r\nVia: SIP/2.0/UDP 81.223.38.106:5060;branch=z9hG4bKd84073c10\r\nMax-Forwards: 16\r\nContent-Length: 0\r\nTo: sip:042422115963@voip.inode.at\r\nFrom: Anonymous <si"..., len=474, rcv_info=0xbffffc00) at receive.c:165 #17 0x0807a1ae in udp_rcv_loop () at udp_server.c:472 #18 0x0805b635 in main_loop () at main.c:1056 #19 0x0805c916 in main (argc=16, argv=0x0) at main.c:1592