[SR-Users] Detecting calls with missing ACK (Lazy SIP scanners)

[Daniel-Constantin Mierla]

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

-- 
Daniel-Constantin Mierla
http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, Berlin, May 18-20, 2016 - http://www.kamailioworld.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20160413/6f36b353/attachment.html>