Does it happen that you create the transaction for INVITE with
t_newtran(), then add/remove headers and after that call t_suspend()?
Daniel
On 19/03/15 22:09, Alex Balashov wrote:
I have two core dumps from the last few days with the
same crash, and
I took a look at the call flows for both Call-IDs.
Both seem to play out the same way as the crash I sent you:
Mar 19 13:22:57 Proxy1 /usr/local/sbin/kamailio[21580]: INFO:
[R-OUTBOUND-VENDOR-ROUTE-TRY:e5e48a99-48dd-1233-96b7-782bcb13da6a] ->
Final request URI: sip:yyy@xxx:5060
Mar 19 13:22:57 Proxy1 /usr/local/sbin/kamailio[21580]: INFO:
[R-INVITE-OUTBOUND-HANDLER-POSTROUTE:e5e48a99-48dd-1233-96b7-782bcb13da6a]
-> Request processing delay: 27 ms
Mar 19 13:22:57 Proxy1 /usr/local/sbin/kamailio[21580]: INFO:
[R-OUTBOUND-VENDOR-ROUTE-TRY-BRANCH:e5e48a99-48dd-
1233-96b7-782bcb13da6a] Sending media through rtpproxy
Mar 19 13:22:57 Proxy1 /usr/local/sbin/kamailio[21572]: INFO:
[R-MAIN:e5e48a99-48dd-1233-96b7-782bcb13da6a] CANCEL received from xxx
(RURI=sip:yyy@xxx:5060)
Mar 19 13:22:58 Proxy1 /usr/local/sbin/kamailio[21569]: INFO:
[R-MAIN:e5e48a99-48dd-1233-96b7-782bcb13da6a] CANCEL received from xxx
(RURI=sip:yyy@xxx:5060)
Mar 19 13:23:00 Proxy1 /usr/local/sbin/kamailio[21566]: INFO:
[R-MAIN:e5e48a99-48dd-1233-96b7-782bcb13da6a] CANCEL received from xxx
(RURI=sip:yyy@xxx:5060)
They also have another common characteristic:
The normal call flow is to relay the INVITE on branch .0 to an LNP
gateway, then to capture the LRN from a redirect and relay the INVITE
to its actual destination via branch .1. In all cases, however, there
was a Redis cache hit on the LRN that did not require branch .0.
-- Alex
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda -
http://www.linkedin.com/in/miconda
Kamailio World Conference, May 27-29, 2015
Berlin, Germany -
http://www.kamailioworld.com