[asterisk-bugs] [Asterisk 0017255]: [patch] UDP ports not freed/ports leaking

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17255 
====================================================================== 
Reported By:                kvveltho
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   17255
Category:                   Core/General
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     acknowledged
Asterisk Version:           1.6.2.7-rc2 
JIRA:                       SWP-1410 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-04-28 06:23 CDT
Last Modified:              2011-01-26 23:37 CST
====================================================================== 
Summary:                    [patch] UDP ports not freed/ports leaking
Description: 
The following is not fixed:

These release candidates resolve an issue with UDP ports not being freed,
per
issue https://issues.asterisk.org/view.php?id=16774
(https://issues.asterisk.org/view.php?id=16774)

======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0016774 [patch] [regression] 1.6.1.13 and 1.6.1...
related to          0018121 Early bind of UDPTL ports can create a ...
====================================================================== 

---------------------------------------------------------------------- 
 (0131093) rgagnon (reporter) - 2011-01-26 23:37
 https://issues.asterisk.org/view.php?id=17255#c131093 
---------------------------------------------------------------------- 
More info for anyone that wants it.  I've found under 1.6.2.16.1 that it
only APPEARS that the ports are leaking when session-timers are in use. 
This actually looks more like a potential DoS problem for high-use servers
where AGI is in play, and the a UAC sends a large value for
"Session-Expires" (IE: 3600).

If you wait long enough, the session refresh timer will eventually go off
and close the ports.  My thinking is there is a reference to the dialog
some place that is not decrementing if AGI (or some other force) tells a
dialog to end.

Imagine this scenario:
sip.conf: (defaults)
session-timers=accept
session-expires=1800
session-mine=90
session-refresher=uas

Server receives a call, with headers requesting a 3600 second session
timer (both min-se and session-expires set to 3600)

RTP channels are bound (along with RTCP, UDPTL, and maybe a video and chat
UDP port as well)--- Up to 7 UDP ports are bound to the dialog.

Under RFC4028, asterisk properly picks 3600 as the session interval.

chan_sip will do an ast_sched_add from start_session_timer() with a "when"
of 900,000 ms (3600 * 1000 / 2)

Now, the call is denied...  Maybe your AGI decides it doesn't like the
calling party, or there is congestion on all routes.

UAC is told to drop, UAC stops sending SIP traffic.

All those UDP ports that were bound to the dialog earlier are NOT free'd. 
Only after the 900,000ms (15 minutes) goes by, are the ports free'd.

So.  They are not leaking, but they aren't able to be used.

In my case, all available UDP ports are exhausted really quick if all our
clients start using session timers, and we need to deny access to some of
them via AGI.... but then they come back with another call request for some
other destination, and another 3 ports are tied up (one RTP, one RTCP, and
one UDPTL for T38).

Repeat this loop 15,000 times in an hour, and it doesn't take long at all
to lose all ability to bind a UDP port.

I'm still investigating this on my side for a solution, but I wanted to
leave this analysis here for anyone else doing the same. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-01-26 23:37 rgagnon        Note Added: 0131093                          
======================================================================