[asterisk-bugs] [Asterisk 0015285]: [patch] reworked chan_ooh323

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=15285 
====================================================================== 
Reported By:                may213
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   15285
Category:                   Addons/chan_ooh323
Reproducibility:            random
Severity:                   feature
Priority:                   normal
Status:                     confirmed
Target Version:             1.6.x Version Tracker
Asterisk Version:           SVN 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-06-07 18:51 CDT
Last Modified:              2009-10-20 14:44 CDT
====================================================================== 
Summary:                    [patch] reworked chan_ooh323
Description: 
There is patch to asterisk-addons-1.6.1.0 for reworked version of 
chan_ooh323 channel module.

main subject of changes is performance and scalability improvement.
one processing thread is replaced with many threads (one for cmdChannel
of EndPoint, one for incoming call creation, one for call processing).

chan_ooh323 with this reworking is more stable and have good performance
in compare with chan_h323.
chan_h323 have memory leaks in all my asterisk systems (which have
versions from 1.2 up to 1.6.1) and grow more than 2Gb virtual memory after
proccessing about 200000 calls. After many years of solving this trouble i
cancel this work and begin work on chan_ooh323.

asterisk 1.6.1 with this version of chan_ooh323 have uptime 4 days and
proccess about 400 000 calls and have 98Mb virtual memory with 4 active
channels and no memory leak detected by asterisk malloc debug system.
(all modules include OOH323 stack code are compiled with MALLOC_DEBUG
options)
Before testing 1.6.1 i work with 1.4 version and had 8 days uptime
asterisk with more than 1000000 calls processed without leaks.

Also there is small changes for new options - incoming call limit, 
numbering of calls, t35country code and vendor/version identification
(albania code is not liked for me ;))

More detail list of changes/improvements is in Changes-ooh323.eng.

======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0015046 [patch] Data truncated in ooh323_reques...
====================================================================== 

---------------------------------------------------------------------- 
 (0112491) may213 (reporter) - 2009-10-20 14:44
 https://issues.asterisk.org/view.php?id=15285#c112491 
---------------------------------------------------------------------- 
added ooh323-patch-20091020 (it's incremental to patch-20090731) and 
ooh323-fullpatch-20091020 (patch to original asterisk-addon).

main changes are

speex codec support (compatible with openh323)

cisco/rtp dmtf support and dtmf codec setup separately for
peer/user/global

jitter buffer configuration (only global)

rtpmask parameter for peer/user. It's regexp for addresses of rtp
channels. If rtpmask is set and ip of rtp channel doesn't match to rtpmask
then call is hangup.
It can be useful for selection different choices over one carrier.

H.245 correction (propose h.245 address and open h245listener on sending
progress or alerting if there h245tunneling is disabled)

dtmf duplication filter based on signalType and duration in H245UserInput

threading model is changed to pool of threads. In previous call thread
exit after call is done and new thread is started for each new call. 
Now thread is started for call processing, work with him up to hangup,
delete current call and wait signal to processing new call or delay
expiration. If there is new call thread is work with it, otherwise thread
exit.
New thread is started if there no idle threads.
Delay for waiting new call is hardcoded in ooh323cDriver.c (#define
SEC_TO_HOLD_THREAD 24)
with this model i have load average decrease from 14-16 to 3-4 with volume
of call attempts about 8-9 per sec on Core2Duo 1.86Ggz server. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-10-20 14:44 may213         Note Added: 0112491                          
======================================================================