On 12/04/16 17:33, Marrold wrote:
Hi,
On 06/04/16 01:57, Marrold wrote: Hi Charles,
I can confirm that t_any_timeout(), and t_branch_timeout() return true when these un-ACKd transactions occur.
by un-ACKed, do you mean they didn't receive any response or they didn't receive the ACK following a response to an INVITE?
I mean specifically the response to an INVITE was not ACK'd
I've been doing some experimentation with t_any_timeout()
and t_branch_timeout(), and I've observed they return true if either the initial invite receives no response, or if the 200 OK >> is not acknowledged by the UAC.
Is there any way of differentiating between these scenarios?
If Kamailio matches the 200ok for transaction, then it should not give true for a timeout
check. But maybe there is a mismatch also in kamailio if the 200ok is sent to caller but it is no > ACK sent back. In such case, a sip network trace will be useful to investigate what happens there.
In this scenario a 200ok is sent to the caller, but no ACK is sent back. This appears to return true for timeout checks. I will grab a SIP trace.
As a side note / update I figure I can potentially add a flag / AVP when a response and / or ACK is received and figure out the cause of the timeout from there.
You can also run with debug=3 in kamailio config to get more log messages in syslog. If there are too many, then use debugger module and set debug level to 3 only for tm module, then you should see if tm is matching the 200ok to a transaction.
Cheers, Daniel