Summary:	ASTERISK-13959: [patch] RTP timeout problem
Reporter:	Andriy I Pylypenko (bamby)	Labels:
Date Opened:	2009-04-15 03:29:59	Date Closed:	2011-06-07 14:03:17
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) fix_rtp_timeout.diff
Description:	I've recently started to use the rtptimeout parameter with the chan_sip and encountered a problem. I've set this parameter to 15 seconds but the following scenario appeared regularly. The call is set up, ringing takes place for several seconds and then when called party answers, the call terminates very quickly with the message 'Disconnecting call 'XXX' for lack of RTP activity in 16 seconds'. However many of such sessions lasted from 200 OK to BYE several seconds, and even time from INVITE to BYE frequently was less than 15 seconds. I've seen the sessions that had their duration even 10 seconds in total where time from 200 OK to BYE was only one second. But nevertheless the log message reported always no less than 16 seconds RTP timeout. Scrutinizing the do_monitor() function from the sip_chan.c, I've noticed that the timeout is calculated based on the current time which is recorded before scanning the iflist. It is recorded once and is not changed during the scan. However it seems that some operations inside the loop can take significant amount of time and so the time recorded before the loop can expire and thus the comparisons that is performed after such delays can become invalid. I didn't try to locate the delays, instead I've modified the code to use the fresh current time before each comparison. After this change the problem disappeared completely. I've been monitoring my system for a week and no more false disconnects occur since the change, while before this problem happened several times a day.
Comments:	By: Joshua C. Colp (jcolp) 2009-04-20 08:28:49 What is your rtptimeout value set to? What sort of channel capacity do you see when this is happening (how many channels are up)? I would really like to know what is blocking for so long. Do you have working nameservers configured on the machine? By: Andriy I Pylypenko (bamby) 2009-04-22 02:41:38 The problem doesn't exist in fact. This was incorrect interpretation of the call logs and coincidental improvement of network conditions. The ticket can be closed. I'm sorry for disturbance. By: Joshua C. Colp (jcolp) 2009-04-22 07:45:18 Closed per reporter.