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
_______________________________________________
sr-dev mailing list
sr-dev@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
