[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:                russell
====================================================================== 
Project:                    Asterisk
Issue ID:                   15285
Category:                   Addons/chan_ooh323
Reproducibility:            random
Severity:                   feature
Priority:                   normal
Status:                     assigned
Asterisk Version:           1.6.1.0 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-06-07 18:51 CDT
Last Modified:              2009-06-22 10:51 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.

====================================================================== 

---------------------------------------------------------------------- 
 (0106815) c0w (reporter) - 2009-06-22 10:51
 https://issues.asterisk.org/view.php?id=15285#c106815 
---------------------------------------------------------------------- 
May213

ok i've found the problem.

i started from scratch just to make sure i didn't have extra code.

so asterisk-addons
patched with p0 ooh323-fullpatch-20090615 

uncomment out line 283
ch->nativeformats = i->capability;

the nativeformats fixes the problem however i need to investigate a bit
more because it selects ulaw over g729

---   ooh323_update_writeformat 0x100 (g729)
---   find_call
+++   find_call
Writeformat before update 0x40 (slin)
+++   ooh323_update_writeformat
---   setup_rtp_connection
---   find_call
+++   find_call
+++   setup_rtp_connection
[Jun 22 16:42:18] WARNING[14606]: chan_sip.c:5365 sip_write: Asked to
transmit frame type 256, while native formats is 0x4 (ulaw)(4) read/write =
0x4 (ulaw)(4)/0x4 (ulaw)(4)
[Jun 22 16:42:18] WARNING[14606]: chan_sip.c:5365 sip_write: Asked to
transmit frame type 256, while native formats is 0x4 (ulaw)(4) read/write =
0x4 (ulaw)(4)/0x4 (ulaw)(4)
[Jun 22 16:42:18] WARNING[14606]: chan_sip.c:5365 sip_write: Asked to
transmit frame type 256, while native formats is 0x4 (ulaw)(4) read/write =
0x4 (ulaw)(4)/0x4 (ulaw)(4)
[Jun 22 16:42:18] WARNING[14606]: chan_sip.c:5365 sip_write: Asked to
transmit frame type 256, while native formats is 0x4 (ulaw)(4) read/write =
0x4 (ulaw)(4)/0x4 (ulaw)(4)
[Jun 22 16:42:18] WARNING[14606]: chan_sip.c:5365 sip_write: Asked to
transmit frame type 256, while native formats is 0x4 (ulaw)(4) read/write =
0x4 (ulaw)(4)/0x4 (ulaw)(4)
[Jun 22 16:42:18] WARNING[14606]: chan_sip.c:5365 sip_write: Asked to
transmit frame type 256, while native formats is 0x4 (ulaw)(4) read/write =
0x4 (ulaw)(4)/0x4 (ulaw)(4)
[Jun 22 16:42:18] WARNING[14606]: chan_sip.c:5365 sip_write: Asked to
transmit frame type 256, while native formats is 0x4 (ulaw)(4) read/write =
0x4 (ulaw)(4)/0x4 (ulaw)(4)
[Jun 22 16:42:18] WARNING[14606]: chan_sip.c:5365 sip_write: Asked to
transmit frame type 256, while native formats is 0x4 (ulaw)(4) read/write =
0x4 (ulaw)(4)/0x4 (ulaw)(4)
[Jun 22 16:42:18] WARNING[14606]: chan_sip.c:5365 sip_write: Asked to
transmit frame type 256, while native formats is 0x4 (ulaw)(4) read/write =
0x4 (ulaw)(4)/0x4 (ulaw)(4)
[Jun 22 16:42:18] WARNING[14606]: chan_sip.c:5365 sip_write: Asked to
transmit frame type 256, while native formats is 0x4 (ulaw)(4) read/write =
0x4 (ulaw)(4)/0x4 (ulaw)(4)
[Jun 22 16:42:18] WARNING[14606]: chan_sip.c:5365 sip_write: Asked to
transmit frame type 256, while native formats is 0x4 (ulaw)(4) read/write =
0x4 (ulaw)(4)/0x4 (ulaw)(4)

forced the native format to be g729

ch->nativeformats = 256;

and all works with no errors like above and both channels using g729
codec. i'll try and get more work to fix the nativeformat selecting the
correct codec but it does work. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-06-22 10:51 c0w            Note Added: 0106815                          
======================================================================