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

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
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-22 02:41 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.
====================================================================== 

---------------------------------------------------------------------- 
 (0103599) bamby (reporter) - 2009-04-22 02:41
 http://bugs.digium.com/view.php?id=14903#c103599 
---------------------------------------------------------------------- 
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. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-04-22 02:41 bamby          Note Added: 0103599                          
======================================================================