30 Nov
2016
30 Nov
'16
5:03 p.m.
We have a crash in kamailio 4.4.4 after t_next_contacts() has been called from failure
route, if at this very moment when kamailio is preparing new INVITE the caller sends a
cancel.
#0 build_res_buf_from_sip_req (code=3186024432, code@entry=487, text=0x25,
new_tag=0x7f8dcf5fb2b0 <tm_tag>, msg=0x7f8dbde6cf78,
returned_len=0xb7, bmark=0x4) at msg_translator.c:2395
#1 0x00007f8dcf35f7b2 in _reply (trans=0x7f8dbde70960, p_msg=0x7f8dbde6cf78, code=487,
text=<optimized out>, lock=1) at t_reply.c:712
#2 0x00007f8dcf3b5e8b in e2e_cancel (cancel_msg=0x7f8dbde6dff0,
cancel_msg@entry=0x7f8dd26bb750, t_cancel=0x25,
t_invite=0x7f8dbde70960) at t_fwd.c:1278
So the scheme is the following: proxy > INVITE < 486 > INVITE* < CANCEL
Victor has investigated this and found that the issue seems to be related to the reply
lumps added by append_to_reply when processing initial invite. In order to reproduce this
you need children>=2.
When first target replies 486 the proxy calls t_next_contacts() and starts preparing
invite to the next target and at this time another process receives cancel and destroys
the transaction, the process handling that invite message(*) gets crashed.
While we are investigating the possibility to move the append_to_reply calls to the branch
route, would it be possible to avoid crash by some kind of lock mechanism? The thing is
that it's not always possible to move append_to_reply to the branch route, e.g. our
proxy is deployed behind stateless lb with multiple interfaces and proxy needs to tell lb
which interface to use already in the 100 Trying reply it sends to lb as a first thing
when receiving a message.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/872