6 Feb
2019
6 Feb
'19
3:51 a.m.
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.
-- Juha