[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 19:07 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.

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

---------------------------------------------------------------------- 
 (0106831) may213 (reporter) - 2009-06-22 19:07
 https://issues.asterisk.org/view.php?id=15285#c106831 
---------------------------------------------------------------------- 
Hello c0w,

please try latest patch. I don't have trouble with him like transmitting
frames with incorrect format to sip channel.

trouble is related to asterisk algo for creating channel. It try to make
new channel with format from source channel and get it from nativeformat of
source channel. If source channel format is zero as i maked with previous
versions then asterisk call requester of new channel with 0xffff format
which incorrect interpret by chan_sip. Imho there is logical mistake in
chan_sip and i make patch for it, but with latest chan_ooh323 it's not
needed.

In result we can't set native format to zero when we interact from ooh323
channel to non-ooh323 channel. I set AST_FORMAT_SLINEAR there.
I think that it's incorrect logically for H.323 (until sound channels are
activated we don't known right nativeformat of H.323 connection), but it's
only way for existing asterisk codec architecture.

SLINEAR is best format for this because all codec translator work from/to
signed linear.

I see there one small trouble with sip-h323 interact when SIP is called
from H323 channel before media channel are started in H323 connection. If
both channels have same native format they have read/write format to SLIN
and there 
will be double codec translations (g729 on SIP -> SLIN -> SLIN -> g729 on
H323 as example).
resoluntion is call sip after start of media channels. It can be Progress
or Ringing or PlayTones and Wait(1), i do so.

Now channel format setting procces have this rules:
read/write formats are 0 when channel is created, nativeformat is SLINEAR
OLC of write channel set native format and adopt writeformat.
OLC of read channel do nothing because all read channels call OLC
functions before codec negotiation.
ooh323_write adopt writeformat if needed.
ooh323_read set native format if it changed from rtp side.

i tested this variant in both direction sip->h323, h323->sip, same codecs,
different codecs. All work good for me. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-06-22 19:07 may213         Note Added: 0106831                          
======================================================================