[asterisk-bugs] [Asterisk 0014903]: [patch] RTP timeout problem

[Asterisk Bug Tracker]

The following issue requires your FEEDBACK. 
====================================================================== 
http://bugs.digium.com/view.php?id=14903 
====================================================================== 
Reported By:                bamby
Assigned To:                file
====================================================================== 
Project:                    Asterisk
Issue ID:                   14903
Category:                   Channels/chan_sip/General
Reproducibility:            sometimes
Severity:                   major
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.4.24 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-04-15 03:29 CDT
Last Modified:              2009-04-20 08:28 CDT
====================================================================== 
Summary:                    [patch] RTP timeout problem
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.
====================================================================== 

---------------------------------------------------------------------- 
 (0103447) file (administrator) - 2009-04-20 08:28
 http://bugs.digium.com/view.php?id=14903#c103447 
---------------------------------------------------------------------- 
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? 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-04-20 08:28 file           Note Added: 0103447                          
2009-04-20 08:28 file           Status                   assigned => feedback
======================================================================