[SR-Users] crash at 480 reply to INVITE

Daniel-Constantin Mierla miconda at gmail.com
Wed Feb 6 10:10:41 CET 2019


On 06.02.19 09:51, Juha Heinanen wrote:
> Juha Heinanen writes:
>
>> Thanks.  I don't think that this is db related issue.  Here is a
>> summary:
>>
>> - K receives INVITE at 17:43:28 and forwards it over udp to uas
>> - uas immediately responds with 183 followed by 180, which k forwards to UAC
>> - at 17:44:29 uas responds again with 180 and K forwards it to UAC
>> - at 17:44:44 K's invite timeout timer fires and it sends "408 request
>>   timeout" to uac, which responds with ack
>> - at that point K should also have send CANCEL to uas, but it didn't
>> - after that k goes to deep sleep, i.e., it does not react to any
>>   new incoming requests from anybody nor to several "480 request
>>   terminated" replies from the uas
>> - about 15 minutes later at 18:00:23, K wakes up and sends two cancel
>>   requests to uas
>> - uas replies to cancels with "481 transaction does not exist"
>> - then K sends several ACKs to the uas and crashes
> I misunderstood the pcap that I got.  It only contained packets of the
> call that caused invite timeout to fire and where CANCEL was not sent.
> So K did properly process other requests during the 15 minute period.
>
> In syslog there is this just before the crash:
>
> Feb  1 16:00:23 /usr/bin/sip-proxy[1348]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 18
>
> and before that during the same second:
>
> Feb  1 16:00:23 /usr/bin/sip-proxy[1327]: INFO: db_mysql [km_dbase.c:85]: db_mysql_submit_query(): driver error on ping: Lost connection to MySQL server during query
>
> So the crash may have something to do with db access, but why was cancel
> not sent 15 minutes ago? There is no mysql related messages in syslog at
> that time.


OK. There should be no crash no matter what caused the delay. I wanted
to sort out the freezing of entire kamailio for 15min, because that is
rather unusual to happen for all processes and then recover.

I will look more at the tm for this delay/blocking of a single process.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com
Kamailio Advanced Training - Mar 4-6, 2019 in Berlin; Mar 25-27, 2019, in Washington, DC, USA -- www.asipto.com




More information about the sr-users mailing list