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

[Asterisk Bug Tracker]

The following issue has been SUBMITTED. 
====================================================================== 
http://bugs.digium.com/view.php?id=14903 
====================================================================== 
Reported By:                bamby
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   14903
Category:                   Channels/chan_sip/General
Reproducibility:            sometimes
Severity:                   major
Priority:                   normal
Status:                     new
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-15 03:29 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.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-04-15 03:29 bamby          New Issue                                    
2009-04-15 03:29 bamby          Asterisk Version          => 1.4.24          
2009-04-15 03:29 bamby          Regression                => No              
2009-04-15 03:29 bamby          SVN Branch (only for SVN checkouts, not tarball
releases) => N/A             
======================================================================