[Home]

Summary:ASTERISK-14278: [patch] reworked chan_ooh323
Reporter:Alexander Anikin (may213)Labels:
Date Opened:2009-06-07 18:51:00Date Closed:2011-01-04 16:09:15.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Addons/chan_ooh323
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) Changes-ooh323.eng
( 1) h323_log11
( 2) h323_sip.log
( 3) iax_test.txt
( 4) ooh323_segfault.txt
( 5) ooh323debug
( 6) ooh323-fullpatch-20090615
( 7) ooh323-fullpatch-20090622
( 8) ooh323-fullpatch-20090729
( 9) ooh323-fullpatch-20091020
(10) ooh323-patch-20090606
(11) ooh323-patch-20090609
(12) ooh323-patch-20090612
(13) ooh323-patch-20090615
(14) ooh323-patch-20090617
(15) ooh323-patch-20090622
(16) ooh323-patch-20090625
(17) ooh323-patch-20090626
(18) ooh323-patch-20090703
(19) ooh323-patch-20090710
(20) ooh323-patch-20090710-fixed
(21) ooh323-patch-20090729
(22) ooh323-patch-20090730
(23) ooh323-patch-20090731
(24) ooh323-patch-20091020
(25) ooh323-sip-patch-20090625
(26) test-patch-20090807
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.


****** ADDITIONAL INFORMATION ******

Reviewboard link:  https://reviewboard.asterisk.org/r/324/
Comments:By: Jason Parker (jparker) 2009-06-08 10:35:10

Assigned to Russell so he can poke at this when he can.
By: sles (sles) 2009-06-08 22:50:52

Hello!

Unfortunately, ooh323 doesn't work with gatekeeper (gnugk in my case) with this patch- I can't do outbound calls with it, as I see it even does not try to connect to gatekeeper, although it registers in gatekeeper.


By: Alexander Anikin (may213) 2009-06-09 05:56:54

Hello!

As you can see in Changes file gatekeeper mode is not tested.
Also i see one bug in ooh323 stack code (about opening logical channels).
But i have gnugk and will make next version of patch with corrected bug and tested gk mode in 1-2 days.
By: Sean (c0w) 2009-06-09 08:36:57

Hello,

the patch applied cleanly against 1.6.1.0 addons however i'm getting segfault on start.

attached ooh323_segfault.txt

Note:

that if i keep trying to start asterisk is will start eventually.

Hardware:
quad core xeon 4 gig of ram debian lenny 2.6.26.2 kernel


By: Alexander Anikin (may213) 2009-06-10 04:05:19

i uploaded additional patch (ooh323-patch-20090609) with corrected bug about opening logical channels, g.729b capability support and possible corrected ooGetLocalAddress segfault. It's incremental and must apply to patched by 20090606 patch ooh323 channel.

Please try it. I can't reproduce segfault but i think it is because unresolveable local host name.

GK mode still not tested, but there is workaround.
Use asterisk in peer mode and save asterisk ip in Gk config as permanent endpoint. Also describe your GK in ooh323.conf as peer/user or friend and change extensions.conf rules from OOH323/number to OOH323/number@gkname


By: Sean (c0w) 2009-06-10 04:11:17

Patch applied and i can't get it to segfault on start i'll continue testing now.

Note:
I was testing yesterday when it wouldn't segfault and it seems to perform very well.
By: Alexander Anikin (may213) 2009-06-14 16:12:54

uploaded two incremental (ooh323-patch-20090612 and  ooh323-patch-20090615) and full (ooh323-fullpatch-20090615) patches.  ooh323-fullpatch-20090615 is for original asterisk-addons-1.6.1.0

There are changes in read/write/native formats setting process and g.726/amr-nb codecs support (non standard codecs are supported by common code now).
amr-nb support is optionally compiled and compatible with patch from http://sip.fontventa.com/. I don't known right name of this codec for H.323 and i wrote "AMRNB".


channel format setting procces have this rules:
all formats are 0 when channel is created because we don't know which codec will be negotiated.
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.


By: Sean (c0w) 2009-06-15 03:34:22

The only issue i've seen thus far was fixed by your new patch.

every thing seems stable. this may actually be an upgrade path for me from 1.4 and chan_h323. =)

thanks for your work thus far.


By: Sean (c0w) 2009-06-16 04:08:14

h323 -> sip (possible problem)


PSTN -> (Ast1) -> (Ast2) -> oSIPS -> (Phone)
   ISDN     SIP      SIP       SIP

this works

PSTN -> (Ast1) -> (Ast2) -> oSIPS -> (Phone)
   ISDN     H323     SIP       SIP

This fails

I've attached the sip log (h323_sip.log) for the oSIPS (peer) which the phone is a local user.
By: Alexander Anikin (may213) 2009-06-16 15:34:58

I think it is not h323 issue, but SIP. I think it's because h323 channel have unknown initial format which transferred to sip_request.
Possible way is to setup codec list for peer 172.16.64.5 with disallow=all and list of allowed codec.
By: Sean (c0w) 2009-06-17 02:42:58

may,

the codec list is already setup this way. i will see if i can get some more testing done today (chan_h323 iax etc) using the same call path as above. do you want any particular trace/debug?

I've attached iax_test.log as well. all these channels seem to work bar ooh323. i'm leaning more towards ooh323 being at fault here.


By: Alexander Anikin (may213) 2009-06-18 17:00:54

c0w,

I had same trouble in playback application before answering channel (btw MusicOnHold don't have this trouble). It's because channel format is 0 initially. I solve it by adding Progress into priority 1 on incoming H323 calls.
Also Ringing, Playtones can help with it. These apps will send sound frames to channel and channel module will setup channel format.

Also i attach small path for incoming Progress signal proccessing.
By: Sean (c0w) 2009-06-19 03:03:04

Nope still no good.

you can get around this by basically answering the call then dialing the SIP extension, still not good tho we should be able to bridge i will see what i can find out, just very little time.
By: Alexander Anikin (may213) 2009-06-19 19:13:04

c0w, please try this patch, it can help.

--- channels/chan_ooh323.c      2009-06-17 22:11:14.000000000 +0400
+++ channels/chan_ooh323.c     2009-06-20 03:03:20.000000000 +0400
@@ -284,6 +284,7 @@

               /* ch->nativeformats = i->capability; */
               ch->nativeformats = 0;
+               fmt = i->capability;

               /* fmt = ast_best_codec(ch->nativeformats); */

@@ -294,10 +295,10 @@
                       ch->rings = 1;

               ch->adsicpe = AST_ADSI_UNAVAILABLE;
-               ch->writeformat = 0;
+               ch->writeformat = fmt;
               ch->rawwriteformat = 0;
               /* ch->rawwriteformat = fmt; */
-               ch->readformat = 0;
+               ch->readformat = fmt;
               ch->rawreadformat = 0;
               /* ch->rawreadformat = fmt; */
               ch->tech_pvt = i;
By: Sean (c0w) 2009-06-22 07:29:06

May213.

it hasn't made any difference i've even tried overriding the fmts with the int values 256 4 8 etc and it doesn't seem to make a difference.

i'm still looking i'll see if i can get more information. are you seeing the same problem when you try it?
By: Sean (c0w) 2009-06-22 10:51:03

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.
By: Alexander Anikin (may213) 2009-06-22 18:30:50

uploaded patch with corrected outgoing call processing (onOutgoingCall callback call move to another place and implemented callback function for filling caller id info), corrected q931cause value (if zero get it from ooQ931GetCauseAndReasonCodeFromCallClearReason function).

uploaded full patch also.
By: Alexander Anikin (may213) 2009-06-22 19:07:02

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 codecs 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.


By: Sean (c0w) 2009-06-23 02:34:56

May

I've installed the full patch (although it detected that it had already been patched, very odd).

the Sip phone rings and i get audio when answered however to me its still broken.

-- General --
          Name: OOH323/myuser1-2
          Type: OOH323
      UniqueID: 1245742172.4
     Caller ID: 1785717408
Caller ID Name: root
   DNID Digits: (N/A)
      Language: en
         State: Up (6)
         Rings: 1
 NativeFormats: 0x100 (g729)
   WriteFormat: 0x40 (slin)
    ReadFormat: 0x40 (slin)
WriteTranscode: Yes
 ReadTranscode: Yes

-- General --
          Name: SIP/proxy1-0236fdc8
          Type: SIP
      UniqueID: 1245742172.5
     Caller ID: 7469
Caller ID Name: (N/A)
   DNID Digits: (N/A)
      Language: en
         State: Up (6)
         Rings: 0
 NativeFormats: 0x100 (g729)
   WriteFormat: 0x40 (slin)
    ReadFormat: 0x40 (slin)
WriteTranscode: Yes
 ReadTranscode: Yes


both ends support g729 however are are transcoding them into (slin). if i get a chance today i will see how other channels negotiate the codecs.
By: Alexander Anikin (may213) 2009-06-23 03:01:30

Hi,

yes, it's problem. try

exten => ...,1,Progress;
exten => ...,2,Wait(1);
exten => ...,3,Dial(SIP/xxx);

this work as needed.
By: Alexander Anikin (may213) 2009-07-03 15:38:37

added 0625, 0626, 0703 patches. They are incremental and must be applied one by one.
Main goals of these patches are gatekeeper (gnugk tested) support and select to poll changes due to perfomance and 1024 fds limitation in select.
Also there is chan_sip patch which help to work with h323 channels and correct logic error in sip_request when request come with more than one bit is setting in format parameter.

additionally changed pipe to socket in cmdchannel, g729 is more preffered than g729a, OLC send after TCSAck and MSDAck from remote received only.


By: Alexander Anikin (may213) 2009-07-10 20:26:57

added patch with (0710) g726aal2 (G726r32) codec and inband/relaxinband dtmf support.
join caps in tempCapSetMsg into altCapSets by capability type (voice, video, dtmf).
By: sles (sles) 2009-07-12 22:43:17

Hello!

I can't apply your patches against asterisk-addons-1.6.1.0 :-(

patch -p0 <ooh323-fullpatch-20090622
patching file channels/chan_ooh323.c
Reversed (or previously applied) patch detected!  Assume -R? [n]
By: Leif Madsen (lmadsen) 2009-07-13 10:46:01

I've made issue 15046 related to this issue, as it is possible this issue causes 15046 to no longer be necessary, or it could just be related generally.
By: sles (sles) 2009-07-14 03:15:03

Yes, this patch has no problem described in issue 15046 (I tested just first version of this patch).
By: Alexander Anikin (may213) 2009-07-16 13:21:16

Hello!

Sorry, it's my mistake, fullpatch-20090622 must be applied as reversed with -R key.

There is no problem in 15046, because
ast_copy_string(tmp, data, sizeof(data)) replaced by
ast_copy_string(tmp, data, sizeof(tmp))
By: sles (sles) 2009-07-19 22:59:22

Hello!

I patched with -R, compiled, but then chan_ooh323 can't be loaded:

[Jul 20 08:54:33] WARNING[8159] loader.c: Error loading module 'chan_ooh323.so': /usr/lib/asterisk/modules/chan_ooh323.so: undefined symbol: clock_gettime
By: Alexander Anikin (may213) 2009-07-20 15:51:53

Hello,

please add string to addons/channels/Makefile:
chan_ooh323.so: ASTLDFLAGS+=-lrt
By: sles (sles) 2009-07-20 22:53:11

Hello!

There is strange problem with meetme with your patch.
Sometimes (often enough, I guess 1 time of 5) meetme can't play sound:

   -- Executing [6000@default:1] Set("OOH323/192.168.22.253-42", "CHANNEL(language)=ru") in new stack
   -- Executing [6000@default:2] MeetMe("OOH323/192.168.22.253-42", "6000,Tx") in new stack
 == Parsing '/etc/asterisk/meetme.conf':   == Found
   -- Created MeetMe conference 1023 for conference '6000'
[Jul 21 08:44:35] WARNING[16226]: file.c:924 ast_streamfile: Unable to open conf-onlyperson (format 0x0 (nothing)): No such file or directory
[Jul 21 08:44:36] WARNING[16226]: chan_ooh323.c:985 ooh323_write: Asked to transmit frame type 64, while native formats is 256 (read/write = 256/256)
 == Using SIP RTP CoS mark 5
 == Using UDPTL CoS mark 5

Usually (with patch) it looks like:
   -- Executing [6000@default:1] Set("OOH323/192.168.22.253-41", "CHANNEL(language)=ru") in new stack
   -- Executing [6000@default:2] MeetMe("OOH323/192.168.22.253-41", "6000,Tx") in new stack
 == Parsing '/etc/asterisk/meetme.conf':   == Found
   -- Created MeetMe conference 1023 for conference '6000'
   -- <OOH323/192.168.22.253-41> Playing 'conf-onlyperson.gsm' (language 'ru')
   -- Hungup 'DAHDI/pseudo-980880775'
 == Spawn extension (default, 6000, 2) exited non-zero on 'OOH323/192.168.22.253-41'
   -- Executing [h@default:1] Goto("OOH323/192.168.22.253-41", "-,1") in new stack
   -- Goto (default,-,1)
[Jul 21 08:43:50] ERROR[16220]: chan_ooh323.c:909 ooh323_hangup: No call to hangup


May be this is somehow codec related? I use g729.
By: sles (sles) 2009-07-22 22:37:50

btw, certanly, there is no such problem with ooh323 without patch.
unfortunately original ooh323 crash asterisk several times per day ( issue 0015473) :-(
By: Alexander Anikin (may213) 2009-07-28 18:18:36

Hello,

imho, original chan_ooh323 is not usable in production because single thread structure (which stop on creating outgoing connection) and others bugs.
problem with sound is related to my playing with read/write/native format change logic. This is fixed in latest patch (0729), please try it.
By: Alexander Anikin (may213) 2009-07-28 18:37:24

added ooh323-fullpatch-20090729 (it's full patch to original addons),
ooh323-patch-20090729 (it's incremental to previous 0710-fixed),
ooh323-patch-20090710-fixed (it replace 20090710 which have some bug).

main goal of this patch is t.38 support.
There are 3 modes - disabled (t.38 not supported), transparent - t.38 support inside ooh323 channel only and translated by spandsp signed linear fax sound outside of ooh323 channel, faxgw - chan_sip/xFax application compatible pass-through mode).
keyword t38support can be used in ooh323.conf in global or peer/user section with separate value for separate peers/users. Valid values are disabled, transparent, faxgw. Default is faxgw.
spandsp version 0.0.6 must be installed for compiling and working with chan_ooh323

another changes are
- correct formats of channel (read/write/native)
- processing requst mode/request mode ack h.323 command (it's needed for t38support)

at this point basic features are implemented and development of 1.6.1.0 version is done.
Next development will be on trunk version only in team/chan_ooh323_rework svn branch.


By: Alexander Anikin (may213) 2009-07-28 18:51:53

Additional info for transparent t.38 mode - timer interface in asterisk is needed. Tests results show what res_timing_pthread don't work good with faxing (i think due to precision in 10ms only) and res_timing_dahdi work normally.
By: sles (sles) 2009-07-28 23:40:31

Hello!

Latest patch works OK, but when I do call from sip phone to h323 I see many error messages in log:

[Jul 29 09:38:11] ERROR[31684] /usr/include/asterisk/lock.h: ooh323c/src/ooq931.c line 2135 (ooH323MakeCall): Error waiting on condition mutex 'Invalid argum
ent'                                                                                                                                                        
[Jul 29 09:38:12] ERROR[31684] /usr/include/asterisk/lock.h: ooh323c/src/ooq931.c line 2136 (ooH323MakeCall): mutex '&gmutex' freed more times than we've loc
ked!


By: Alexander Anikin (may213) 2009-07-29 04:59:41

it's possible i don't understand right how to work with ast_cond_timedwait which i use to synchronize outgoing call setup with gatekeeper reply for arq.
but in my environment it work good even with these messages and i see these messages not every time of outgoing calls.
By: Dmitry Andrianov (dimas) 2009-07-29 16:25:56

Wow. It looks to me you have no idea how to work with conditional variables :)
No offense, it is just a bit scary given the fact you are reworking something into threading mode...

If I understood your code, you just create new mutex each time you want to execute cond wait just because it needs the mutex as argument. This is WRONG. In the simplest case cond variable and mutex form a pair - they should be initialized and used together. And to signal/broadcast conditional variable you also must own the mutex. (The same you are locking when waiting). 'man pthread_cond_timedwait' should explain everything.

Sorry if I got you wrong - I did not really analyze the code - I just took a look at places you identified as possible problems yourself.
By: Dmitry Andrianov (dimas) 2009-07-29 16:40:06

Also, Digium people will definitely point you to coding style violation you are causing with patches like:

- if (gH323Debug) {
+   if(gH323Debug)
ast_verbose("---   close_rtp_connection\n");
- }

This piece does nothing but replaces proper formatting (space after if, braces around statement) with non-standard one. There are several similar places...
By: Gentian Bajraktari (gentian) 2009-07-30 08:02:42

so this patch is out of standards? is it wise to apply it as it is for the sake of getting more performance on h323 calls?
By: Dmitry Andrianov (dimas) 2009-07-30 08:12:21

Formatting standards even when not followed do not make patch dangeous or something. But the problem explained in my previous note (usage of conditional vaiables) actually makes me worry a lot :) _If_ i understood the code corectly then it is just wrong at these pleces and may cause serious problems.
By: Dmitry Andrianov (dimas) 2009-07-30 12:09:08

Btw, question to Digium ppl: shouldn't big changesets like this one go through reviewboard instead?
By: Leif Madsen (lmadsen) 2009-07-30 12:43:19

dimas: patches can be tracked, here and when it is ready for review, and be placed on reviewboard.

Reviewboard is not an issue tracker though.
By: Dmitry Andrianov (dimas) 2009-07-30 13:36:25

lmadsen: ok, I see...
I just have couple of comments regarding the patch - some things may be just written shorter and cleaner. And issue tracker is not the best place for comments like this either. It would be much easier doing that on reviewboard just by pointing pieces of code and putting comments.

Anyway, will post my thoughts here before issue goes to reviewboard :)
By: Alexander Anikin (may213) 2009-07-30 16:00:20

added 0730 patch. Changed ast_cond to semaphore for synchronize call thread with main stack thread which talk with gatekeeper in gk mode.
I think it's better and more correct. I think what warning about mutex/ast_cond variable is related to their creation in different threads.

To dimas: if you'll try to analyze code more detail you can see that mutex used in cond_timedwait is used only one time per call and gkWait cond variable is used only with him.
By: Dmitry Andrianov (dimas) 2009-07-30 16:59:16

Ok, I re-read it the patch and still do not get where am I wrong.
My point was that every time cond_wait is called you should be providing the same mutex. This means you should NOT init new mutex each time you are about to call timedwait on some conditional variable but should init the mutex once at the same place you are initializing your conditional variable. In your code it was violated.

Now you switched to semaphores and mutex is not used anymore so there is no such a problem. However:
1. I'm not sure about guidelines regarding using semaphores in Asterisk - I see dozen of files using conditional variables and only one usage of semaphore. You better check with Digium guys regarding that.
2. Note that sem_post is more like signal of conditional variable while your previous patch used broadcast not signal. I have no idea which one is correct in your case because I'm looking not at the whole code but at the patch only. So I'm just trying to attract your attention to the fact that sem_post/cond_broadcast behavior is very different.
3. Note that if you have any mutex locked before entering sem_timedwait, you will keem them locked for the whole duration of the call. So for example if another thread needs to grab call->Lock in order to progress and signal the semaphone - it won't be able. This is the task conditional variable solves - when entering cond_wait, the mutex you pass is released but it is guaranteed to be locked back before cond_wait returns.

By the way, whatever you use - conditional variables or semaphores, you better  be checking return value of timedwait...
By: sles (sles) 2009-07-30 22:42:32

Hello!

I can't make call with 0730 patch.

Here is what I see:
   -- Executing [3098@sipphones:1] Dial("SIP/6052-09f45f88", "OOH323/3098") in new stack
   -- Called 3098
[Jul 31 08:37:39] ERROR[16289]: chan_ooh323.c:987 ooh323_hangup: No call to hangup

There is nothing in gnugk control interface about this call...
By: Alexander Anikin (may213) 2009-07-30 23:28:59

Hello,

please set tracelevel=6 parameter in [general] section of ooh323.conf and provide /var/log/asterisk/h323_log.
also please check asterisk registration on gatekeeper it's like that asterisk is not registered on gk.
By: sles (sles) 2009-07-31 01:09:13

Hello!

There is registration:

GCF|192.168.22.19|asterisk|gateway;
RCF|192.168.22.19:1720|asterisk:h323_ID|gateway|6664_ast;
r
AllRegistrations
RCF|192.168.22.19:1720|asterisk:h323_ID|gateway|6664_ast

Here is debug output (tracelevel=6 produces no more output I posted before)

asterisk*CLI>  ooh323 set debug
OOH323 Debugging Enabled
 == Using SIP RTP CoS mark 5
 == Using UDPTL CoS mark 5
   -- Executing [3098@sipphones:1] Dial("SIP/6052-09c94360", "OOH323/3098") in new stack
---   ooh323_request - data 3098 format 0x100 (g729)
---   ooh323_alloc
+++   ooh323_alloc
---   find_peer "3098"
+++   find_peer "3098"
---   ooh323_new - 3098
+++   h323_new
---   onNewCallCreated 9db9f78: ooh323c_o_3
+++   ooh323_request
---   find_call
---   ooh323_call- 3098
+++   find_call
+++   ooh323_call
setting callid number 6052
   -- Called 3098
Outgoing call 3098(ooh323c_o_3) - Codec prefs - (g729)
asteriskAdding capabilities to call(outgoing, ooh323c_o_3)
Adding g729 capability to call(outgoing, ooh323c_o_3)
Adding g729A capability to call(outgoing, ooh323c_o_3)
Adding g729B capability to call(outgoing, ooh323c_o_3)
---   configure_local_rtp
+++   configure_local_rtp
+++   onNewCallCreated ooh323c_o_3
---   onCallCleared ooh323c_o_3
---   find_call
+++   find_call
+++   onCallCleared
---   ooh323_hangup
[Jul 31 11:06:05] ERROR[17404]: chan_ooh323.c:987 ooh323_hangup: No call to hangup
+++   ooh323_hangup
 == Everyone is busy/congested at this time (1:0/0/1)
   -- Auto fallthrough, channel 'SIP/6052-09c94360' status is 'CHANUNAVAIL'
---   ooh323_destroy
Destroying 3098
Destroying ooh323c_o_3
+++   ooh323_destroy
   -- Accepting call from '8023400' to '6051' on channel 0/1, span 1
   -- Executing [6051@default:1] Dial("DAHDI/1-1", "SIP/6051") in new stack
 == Using SIP RTP CoS mark 5
 == Using UDPTL CoS mark 5
[Jul 31 11:06:11] WARNING[17406]: app_dial.c:1518 dial_exec_full: Unable to create channel of type 'SIP' (cause 20 - Unknown)
 == Everyone is busy/congested at this time (1:0/0/1)
   -- Auto fallthrough, channel 'DAHDI/1-1' status is 'CHANUNAVAIL'
   -- Channel 0/1, span 1 got hangup request, cause 16
   -- Executing [h@default:1] Goto("DAHDI/1-1", "-CHANUNAVAIL,1") in new stack
   -- Goto (default,-CHANUNAVAIL,1)
   -- Hungup 'DAHDI/1-1'
By: Alexander Anikin (may213) 2009-07-31 01:36:55

tracelevel change message level in /var/log/asterisk/h323_log file.
Please provide content of this file.
By: sles (sles) 2009-07-31 02:16:59

I uploaded this file as  h323_log11
By: Alexander Anikin (may213) 2009-07-31 08:11:40

sles, please try lastest (0731) patch which correct synchronisation with gk reply.
Your gk generate reply with too long delay above 1 sec, in my environment gk generate reply with delay shorter than 20ms.


By: Alexander Anikin (may213) 2009-07-31 08:14:12

added 0731 patch. Change delay for waiting gk reply up to 24 sec, without reply call will cleared.
change generation of faststart response, will be sent one time per call only.
By: sles (sles) 2009-08-02 22:39:23

Hello!

Thank you! Quick test shows all is OK with 0731 patch.
About gatekeeper and long delay- gatekeeper doesn't know destination number, so it asks neigbhor gatekeepers , this is because we use secondary gatekeeper on all our gateways for availability, but ooh323 doesn't support secondary gatekeeper, so there is another gnugk installed on the same machine with asterisk...
By: sles (sles) 2009-08-03 02:26:43

Unfortunately 0731 patch results in very poor performance- I get 100% cpu load with about 10 users in meetme conference over ooh323, usually it was less then 10% :-( And cpu load stays at 100% after conference end, so I had to restart asterisk...
May be this problem is introduced by 0730 and I just had no chance...


By: Alexander Anikin (may213) 2009-08-03 05:17:47

Hello,
i think it is not ooh323 issue, 0730 and 0731 are small patches which are not related to peformance.
please test again and check 'core show threads' with active conference and after conference end.
By: sles (sles) 2009-08-04 02:57:00

I tested again- and I have the same result- 100% cpu load.

In core show threads  I see these threads , I had not before:

asterisk*CLI> core show threads
0x13d3b90 pbx_thread           started at [ 4045] pbx.c ast_pbx_start()
0x14c3b90 pbx_thread           started at [ 4045] pbx.c ast_pbx_start()
0x7914b90 pbx_thread           started at [ 4045] pbx.c ast_pbx_start()
0x8bd2b90 pbx_thread           started at [ 4045] pbx.c ast_pbx_start()

btw, I can't reproduce this problem with chan_ooh323 without 0730 patch.
certanly, I'll try ...
By: sles (sles) 2009-08-04 06:10:21

As I see now these additional threads always appears after meetme conference without latest ooh323 patches (may be this is a bug somewhere), but there is no 100% cpu load...
By: Leif Madsen (lmadsen) 2009-08-05 12:40:04

dimas: I certainly agree that this is a pretty major piece of code, and it wouldn't hurt for it to be on reviewboard, even at this point I don't think.

may213: One thing I did notice was the mention of adding T.38 support. It seems like you're adding new functionality while at the same time trying to clean up the code. That really seems like two separate projects, and adding new functionality while cleaning up the code probably makes it quite difficult for developers to review the patch to the point they are comfortable committing it (once you get that far).

May I suggest that you focus on just the cleanup portion first, get that committed, then go back and add the T.38 functionality after? In addition, I know a lot of work has gone on with T.38 recently in the code base for chan_sip -- is there any functionality you can use (if you're not already) so that you don't perform a different T.38 implementation from what already exists?

Thanks!
Leif.
By: Alexander Anikin (may213) 2009-08-06 17:23:24

Hello,

Code is on reviewboard now, request 324. Cleanup portion of code is not big and new functionality portion also. Main code difference is reworked existing code with changed data stucture and changed processing logic.
I think it will be more comfortabe to see this code as complete code, not a patch to source chan_ooh323 and ooh323 stack.

I think that main work for cleanup is done and functionality addition must be paused until code will reviewed.

About t.38. It work with 2 modes, in first mode t38 is hidden from bridged channel or application (outside of h.323 channel no t.38 packets but fax slinear audio) and second mode must be compatible with chan_sip implementation of t.38, it is compatible and work with t38 faxing applications at least.


By: Alexander Anikin (may213) 2009-08-06 18:57:40

sles: please try test-patch-20090807 where i revert back to ast_cond as before 0730 patch. I don't think that problem is here, but you can try.
By: sles (sles) 2009-08-10 02:23:11

Hello!

Thank you, first meetme conference was without problem with test-patch-20090807.
I think, tomorrow I'll know is problem is reproduceable with this patch or not.
By: sles (sles) 2009-08-11 02:06:19

Hello!

test-patch-20090807 works OK, there is no problem with high cpu load.
Thank you!
By: sles (sles) 2009-08-11 22:29:30

Hello!

As I wrote now I have no high cpu load after meetme conference.
But (I don't know is it related problem or completely different one) I have it after failed call, this is what I see in cdr:

"ast_h323","7500","6054","default","""igr-s111-1"" <7500>","OOH323/192.168.105.3-8","","Dial","SIP/6054","2009-08-12 06:02:02",,"2009-08-12 07:58:32",6990,0,
"FAILED","DOCUMENTATION","1250038922.43",""  

User dialed non-existant number 6054, but call was not dropped.
I don't know is it ooh323 or sip problem :-(
By: sles (sles) 2009-08-11 22:43:35

btw, if I do call sip to sip or pri to sip to  number 6054 (or any other number, which not exists) there is no high cpu load, but it is if I call from h323, always reproducable, I'm afraid bug is in ooh323...
By: Alexander Anikin (may213) 2009-08-12 10:34:06

Hello!

please set debug in ooh323 channel (ooh323 set debug) and attach debug output.
By: sles (sles) 2009-08-12 23:15:43

Hello!

I added debug as  ooh323debug.
But looks like problem is caused by my cisco, not by asterisk- when cisco receives reject from asterisk it tries to call using pri and ( I think) doesn't close h323 connection correctly, so I changed dialplan and added hangup:

exten=> _60xx,1,Dial(SIP/${EXTEN})                                                                                                                        
exten => _60xx,2,Hangup  

now all is OK, but ,certanly, I don't shure- I need more tests.

on the other hand as I remember yesterday high cpu load was caused once by call from addpac with fxs connection and it is impossible to have another call from this addpac from different channel...
By: Sean (c0w) 2009-09-17 06:04:52

So whats the status of this? for asterisk-addon 1.6.1 or should we be using another version everyone one i've tried with 1.6.1 has cpu problems.

Thanks
By: Balgansuren Batsukh (balgaa) 2009-09-30 09:59:15

Can I to test test-20090807 patch on Asterisk-1.4.21?
By: Alexander Anikin (may213) 2009-10-01 15:30:22

balgaa, all patches here are for 1.6 version, but i plan to make patch for 1.4 version on this weekend.

c0w, cpu problems related to ooh323 channel driver? trunk version of reworked channel is in svn tree /team/may/chan_ooh323_rework/
By: Balgansuren Batsukh (balgaa) 2009-10-01 23:36:53

I didn't test current patch with 1.6.1 version, that's why don't know cpu problem.

Because I tried to move 1.6.2 from 1.4, but unfortunately chan_dahdi callerid and chan_dahdi stability issue encounter to me.

Also I tried chan_ooh323 included in asterisk-addons-1.6.2, seems not working ring back tone well. Which is means called party network ring back tone not played by chan_ooh323 some reason.

If you give me 1.4 patch and available for full time testing for it.
By: ornix (ornix) 2009-10-02 01:29:35

may213, thank you for your patches.
Tell me please, can you upload the newest patch for addons-1.6.1.1, but without T.38 support? Because of some reasons i forced to use spandsp-0.0.5 with app_fax. I'm a little afraid to use whole asterisk from /team/may/chan_ooh323_rework/.
By: sman100 (sman100) 2009-10-06 10:20:08

may213
can you help me

I am trying get up peer with gatekeeper but it is required password authication. I filled clearTockens as same as chan_h323
and have succsessefull  registrationConfirm answer from gatekeeper.

With original ooh323 sometimes work , sometimes hang on aswer cmd.
with you patch I always have
[Oct  6 18:35:46] ERROR[24046]: chan_ooh323.c:987 ooh323_hangup: No call to hangup
By: Balgansuren Batsukh (balgaa) 2009-10-12 12:50:49

may213, is there any update on 1.4?
By: Alexander Anikin (may213) 2009-10-13 19:22:34

balgaa, this work in progress for now due to many other work, but i hope it will be done in few days.
By: Sean (c0w) 2009-10-15 08:39:03

May the trunk version does not build correctly.

  [CC] chan_ooh323.c -> chan_ooh323.o
In file included from chan_ooh323.h:54,
                from chan_ooh323.c:18:
/usr/src/test/asterisk/include/asterisk/rtp_engine.h:100: error: nested redefinition of ‘enum ast_rtp_options’
/usr/src/test/asterisk/include/asterisk/rtp_engine.h:100: error: redeclaration of ‘enum ast_rtp_options’
/usr/src/test/asterisk/include/asterisk/rtp_engine.h:102: error: redeclaration of enumerator ‘AST_RTP_OPT_G726_NONSTANDARD’
/usr/include/asterisk/rtp.h:60: error: previous definition of ‘AST_RTP_OPT_G726_NONSTANDARD’ was here
chan_ooh323.c:21:1: warning: "HAVE_SPANDSP_EXPOSE_H" redefined
In file included from /usr/src/test/asterisk/include/asterisk.h:21,
                from chan_ooh323.h:19,
                from chan_ooh323.c:18:
/usr/src/test/asterisk/include/asterisk/autoconfig.h:865:1: warning: this is the location of the previous definition
chan_ooh323.c:80: warning: function declaration isn’t a prototype
chan_ooh323.c:714: warning: no previous prototype for ‘find_friend’
chan_ooh323.c: In function ‘ooh323_digit_begin’:
chan_ooh323.c:805: warning: implicit declaration of function ‘ooRequestChangeMode’
chan_ooh323.c: In function ‘ooh323_call’:
chan_ooh323.c:922: warning: implicit declaration of function ‘isRunning’
chan_ooh323.c:924: warning: implicit declaration of function ‘ooRunCall’
chan_ooh323.c: In function ‘onOutgoingCall’:
chan_ooh323.c:1781: warning: format ‘%lx’ expects type ‘long unsigned int’, but argument 5 has type ‘struct OOH323CallData *’
chan_ooh323.c:1817: warning: implicit declaration of function ‘ooIsDailedDigit’
chan_ooh323.c: In function ‘onNewCallCreated’:
chan_ooh323.c:1844: warning: format ‘%lx’ expects type ‘long unsigned int’, but argument 5 has type ‘struct OOH323CallData *’
chan_ooh323.c:1847: warning: implicit declaration of function ‘ooh323c_start_call_thread’
chan_ooh323.c: In function ‘onCallCleared’:
chan_ooh323.c:2014: warning: implicit declaration of function ‘ooh323c_stop_call_thread’
chan_ooh323.c: In function ‘reload’:
chan_ooh323.c:2373: warning: implicit declaration of function ‘ooh323_reload’
chan_ooh323.c: In function ‘reload_config’:
chan_ooh323.c:2472: warning: implicit declaration of function ‘ooH323EpEnableMediaWaitForConnect’
chan_ooh323.c: In function ‘load_module’:
chan_ooh323.c:3119: warning: initialization from incompatible pointer type
chan_ooh323.c: At top level:
chan_ooh323.c:3925: warning: no previous prototype for ‘setup_udptl_connection’
chan_ooh323.c:3985: warning: no previous prototype for ‘close_udptl_connection’
chan_ooh323.c: In function ‘onModeChanged’:
chan_ooh323.c:4274: warning: passing argument 2 of ‘t38_gateway_init’ from incompatible pointer type
chan_ooh323.c:4223: warning: unused variable ‘f’
make[1]: *** [chan_ooh323.o] Error 1
make: *** [addons] Error 2

thanks
By: ornix (ornix) 2009-10-15 22:26:44

c0w, what version of spandsp do you use?
By: Sean (c0w) 2009-10-19 07:16:42

I've tried every version of spandsp and none of them seem to allow e to compile.
By: sles (sles) 2009-10-20 00:50:21

Hello!

I have following problem (don't know does this problem exists with original ooh323 or not) with addpac voip gateway when call is from addpac to asterisk (meetme):
it terminates call by t301 timeout (about 180 seconds by default), from it's debug:
197 <Time 1557> : T301 Call setup timer timeout.

as I see in next debug, there was only PROGRESS message:

114 <Q931 1572> : Received PROGRESS  
and no connect

Could you tell me what can be wrong?

btw, call from cisco has no such problem...

I think problem is not in ooh323, but what can I do to force ooh323 send connect? If I add Ringing to dialplan, I see in addpac debug that ooh323 sends alerting, I tried Answer, but there is no connect :-(

Well, I found right way to send connect:

exten => 6000,1,Set(CHANNEL(language)=ru)                                                                                                                    
exten => 6000,2,ringing                                                                                                                                      
exten => 6000,3,Answer                                                                                                                                      
exten => 6000,4,Meetme(6000)                                                                                                                                
exten => 6000,5,Hangup        


ringing, then answer, otherwise it will not work.
although this is not ooh323 bug I leave this comment- may be someone else will have this problem :-)


By: Leif Madsen (lmadsen) 2009-10-20 09:30:06

Is there a branch for this? I think that would make testing much easier if a branch can be pulled down as opposed to patching current trunk. Just a thought!
By: Alexander Anikin (may213) 2009-10-20 14:44:48

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 h245tunneling is disabled)

dtmf duplication filter based on signalType and duration in H245UserInput

threading model is changed to pool of threads. With previous model 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 it 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 are 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.


By: Alexander Anikin (may213) 2009-10-20 17:09:45

c0w, please try latest trunk or remove line in chan_ooh323.h

#include <asterisk/rtp.h>

There is no rtp.h in trunk version, but i have installed /usr/include/asterisk from older version than your and i not have this conflict declaration which you see in error message ;)
By: ornix (ornix) 2009-10-20 22:19:07

Good Morning!
I've patched asterisk-addons-1.6.1.1 (asterisk-1.6.1.4) with ooh323-fullpatch-20091020, compiled. But i can't load module chan_ooh323.so. There is the following error:

[Oct 21 10:09:08] WARNING[25034]: loader.c:417 load_dynamic_module: Error loading module 'chan_ooh323.so': /usr/lib/asterisk/modules/chan_ooh323.so: undefined symbol: t38_set_sequence_number_handling
[Oct 21 10:09:08] WARNING[25034]: loader.c:653 load_resource: Module 'chan_ooh323.so' could not be loaded.

I've tried with spandsp-0.0.6pre12 and spandsp-0.0.6(20091008).
Is it possible to compile chan_ooh323 without spandsp and T.38 support?


By: Alexander Anikin (may213) 2009-10-21 16:23:45

Hi,

OrNix, please check that chan_ooh323.so is linked with spandsp (ldd /usr/lib/asterisk/modules/chan_ooh323.so). Also i think i forget Makefile changes, please add this:

chan_ooh323.so: ASTLDFLAGS+=-lspandsp -lrt

T.38 transparent support and spandsp related code will be removed from chan_ooh323 in next version, it's needed for merging into trunk. This code work, but it must work in application not a channel driver.
By: ornix (ornix) 2009-10-21 22:39:51

> chan_ooh323.so: ASTLDFLAGS+=-lspandsp -lrt

Thank you, it helped. Today i'm going to test new version. Have you found an erron with 100% cpu-load on failed calls?
By: Alexander Anikin (may213) 2009-10-22 01:38:40

No, i have not found this error at any case.
By: Digium Subversion (svnbot) 2009-11-04 16:16:12.000-0600

Repository: asterisk
Revision: 227898

U   trunk/addons/Makefile
U   trunk/addons/chan_ooh323.c
U   trunk/addons/chan_ooh323.h
U   trunk/addons/ooh323c/src/context.c
U   trunk/addons/ooh323c/src/decode.c
U   trunk/addons/ooh323c/src/dlist.c
U   trunk/addons/ooh323c/src/encode.c
U   trunk/addons/ooh323c/src/errmgmt.c
U   trunk/addons/ooh323c/src/eventHandler.c
U   trunk/addons/ooh323c/src/eventHandler.h
U   trunk/addons/ooh323c/src/h323/H235-SECURITY-MESSAGESDec.c
U   trunk/addons/ooh323c/src/h323/H323-MESSAGESDec.c
U   trunk/addons/ooh323c/src/h323/MULTIMEDIA-SYSTEM-CONTROLDec.c
U   trunk/addons/ooh323c/src/memheap.c
U   trunk/addons/ooh323c/src/memheap.h
U   trunk/addons/ooh323c/src/ooCalls.c
U   trunk/addons/ooh323c/src/ooCalls.h
U   trunk/addons/ooh323c/src/ooCapability.c
U   trunk/addons/ooh323c/src/ooCapability.h
U   trunk/addons/ooh323c/src/ooCmdChannel.c
U   trunk/addons/ooh323c/src/ooCmdChannel.h
U   trunk/addons/ooh323c/src/ooCommon.h
U   trunk/addons/ooh323c/src/ooDateTime.c
U   trunk/addons/ooh323c/src/ooDateTime.h
U   trunk/addons/ooh323c/src/ooGkClient.c
U   trunk/addons/ooh323c/src/ooGkClient.h
U   trunk/addons/ooh323c/src/ooLogChan.c
U   trunk/addons/ooh323c/src/ooLogChan.h
U   trunk/addons/ooh323c/src/ooSocket.c
U   trunk/addons/ooh323c/src/ooSocket.h
U   trunk/addons/ooh323c/src/ooStackCmds.c
U   trunk/addons/ooh323c/src/ooStackCmds.h
U   trunk/addons/ooh323c/src/ooTimer.c
U   trunk/addons/ooh323c/src/ooUtils.c
U   trunk/addons/ooh323c/src/ooasn1.h
U   trunk/addons/ooh323c/src/oochannels.c
U   trunk/addons/ooh323c/src/oochannels.h
U   trunk/addons/ooh323c/src/ooh245.c
U   trunk/addons/ooh323c/src/ooh245.h
U   trunk/addons/ooh323c/src/ooh323.c
U   trunk/addons/ooh323c/src/ooh323.h
U   trunk/addons/ooh323c/src/ooh323ep.c
U   trunk/addons/ooh323c/src/ooh323ep.h
U   trunk/addons/ooh323c/src/ooports.c
U   trunk/addons/ooh323c/src/ooq931.c
U   trunk/addons/ooh323c/src/ooq931.h
U   trunk/addons/ooh323c/src/ootrace.c
U   trunk/addons/ooh323c/src/ootrace.h
U   trunk/addons/ooh323c/src/ootypes.h
U   trunk/addons/ooh323c/src/perutil.c
U   trunk/addons/ooh323c/src/printHandler.c
U   trunk/addons/ooh323c/src/printHandler.h
U   trunk/addons/ooh323c/src/rtctype.c
U   trunk/addons/ooh323cDriver.c
U   trunk/addons/ooh323cDriver.h

------------------------------------------------------------------------
r227898 | may | 2009-11-04 16:16:11 -0600 (Wed, 04 Nov 2009) | 15 lines

Reworked chan_ooh323 channel module.

Many architectural and functional changes.
Main changes are threading model chanes (many thread in ooh323 stack
instead of one), modifications and improvements in signalling part,
additional codecs support (726, speex), t38 mode support.
This module tested and used in production environment.

(closes issue ASTERISK-14278)
Reported by: may213
Tested by: sles, c0w, OrNix

Review: https://reviewboard.asterisk.org/r/324/


------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=227898