[Home]

Summary:ASTERISK-19968: TCP Session-Timers not dropping call
Reporter:Aaron Hamstra (ahamstra)Labels:
Date Opened:2012-06-06 11:05:19Date Closed:2016-07-22 16:08:30
Priority:MajorRegression?
Status:Closed/CompleteComponents:Channels/chan_sip/TCP-TLS
Versions:1.8.7.2 11.22.0 13.9.1 Frequency of
Occurrence		Constant
Related
Issues:
Environment:CentOS VMAttachments:( 0) debug.log-tcp
( 1) session-timersNonUDP_Asterisk11.patch
( 2) session-timersNonUDP_Asterisk12.patch
( 3) session-timersNonUDP_Asterisk13.patch
Description:If a call is setup with session-timers utilizing tcp for sip transport the server never disconnects the call.  We see the session-timers reinvite in the CLI, but with a network trace we never see it.  The issue is the call stays up.  With the sip transport set on UDP everything works as it should, it only occurs when switching to TCP.

Can be reproduced at any time for testing purposes.

Comments:By: Aaron Hamstra (ahamstra) 2012-06-06 11:06:18.970-0500

This is the debug log file during a test call.

1100203 was the extension that went unavailable and should have caused the session-timers to disconnect the call.
By: Aaron Hamstra (ahamstra) 2013-06-10 16:35:56.491-0500

Matt,

Do you have any ideas on this issue?  I have run into it again where it is causing me some major issues.  What further information can I provide if any?

Thank You
By: Matt Jordan (mjordan) 2013-06-10 18:29:32.765-0500

Your issue is in queue, please be patient, and we will get to it as time permits and developer resources become available.

Note that if you really need a fix for this issue, you may want to consider posting a bounty for the bug on the asterisk-dev mailing list.

More information on bug bounties can be found on the [Asterisk wiki|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Bug+Bounties]
By: Alexander Traud (traud) 2014-06-20 14:12:26.470-0500

Same here with my Asterisk 11 and Asterisk 12 on Ubuntu 14.04 LTS. SIP-over-TCP and SIP-over-TLS are affected.

*Workaround A*

I attached a patch which is more like a hack. Here, the patch works for three months already. However, the original submitter faced very low packet timeouts with this patch applied. Perhaps someone – involved in the merger of the TCP branch in January 2008 – is able to review it. Although everyone is welcome to comment on the proposed patch.

This issue unfolds into three issues:
# the Session-Timers re-INVITE was not placed into the scheduler, therefore the re-INVITE did not timeout, therefore Asterisk did not hang-up. That is why I had to remove that first if-clause.
# now, the re-INVITE would have been re-transmitted which does not make
sense for reliable transports. Not the SIP layer but the TCP layer of the
operating system handles this for TCP/TLS traffic already. That is why I
stopped the re-transmission = _just one_ TCP packet is send by Asterisk. Now your operating system does the re-transmitting.
# the 200 OK response of the UAC had to visit __sip_ack(), otherwise the
response would not be noticed by the Session-Timers code. Therefore, I had
to remove that UDP-only condition (effectively rolling-back ASTERISK-14830).

I do not understand which side effects are created by change 1. Here, I do see only benefits because TCP ports stopped to leak. Therefore, solving this issue could solve other issues as well. Would be more than happy to hear your results!

General observations while debugging this:
* my VoIP phones (Symbian/S60; Nokia Belle) ignore Asterisk keepalive and
close the TCP stream after 3*TimerB=192 seconds. Therefore, I went for a
rather low (sip.conf) {{session-expires=360}} (seconds).
* because the round-trip time (RTT) of mobile TCP (UMTS) is rather high, I
had to go for (sip.conf) {{timert1=2800}} (milliseconds):
timert1 < ( min( maxexpiry, session-expires) / 2) / TimerB


*Workaround B*

{{session-timers=accept}}
{{session-refresher=uac}}

*Workaround C*

{{session-timers=refuse}}