Daniel-Constantin Mierla writes:
I'll look into it. Was there a possibility that
some operation could
have taken very long, for example writing accounting database record?
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
So it seems that crash is side effect of K not sending cancel to the uas
immediate. Instead it goes to sleep and doesn't feel well after waking
up 15 minutes later.
The real questions are why didn't K send the CANCEL immediately and went
to sleep instead. How to find out why it happened?
-- Juha