[Asterisk-Dev] Re: New h.323 channel driver

[Craig Southeren]

On Thu, 12 May 2005 10:10:15 +0600
"Paul Cadach" <paul at odt.east.telecom.kz> wrote:

..deleted

> > In my past experience, these kinds of problems with OpenH323
> > applications have been caused by subtle race conditions in the
> > application code associated with call shutdown.
> 
> You're right. 90% of all existing problems caused by application design and OS-specific "features". OpenH323 itself is
> very solid and mostly stable for basic call handling, when application is native OpenH323. But for Asterisk there is
> many problems caused chan_h323/chan_oh323/etc. isn't native OpenH323 application.

The word "application" in my previous email referred to "OpenH323
application", which in this context would mean chan_h323/chan_h323 etc
 
> > I've not seen any problems in the OpenH323 cleanup thread for many years.
> > That code has been tested and reviewed sixteen different ways from zero,
> > and I know of many companies who use OpenH323 for 100+ simultaneous
> > calls with application run-times measured in months without any problems
> 
> Just try to run callgen323 to callgen323 with tracing on both ends under VMware, where context switches is much more
> costly than under real CPU. You can easily get very high CPU load (15-30 on about 20-50 simultaneous calls), then you
> will raise all sort of misoperations the library and an application.

I agree that turning on full debugging certainly does consume a lot of
CPU and will reduce the number of simultaneous calls that can be handled

However, it should not cause the stack to crash. If you are getting such
a crash, and you are sure it is not in the application, then lets get it
fixed.
 
> Probably cleaner thread problems caused by verbose tracing used to debug threads/VMware/etc only. Cleanup thread is
> single thread while call handling uses much more threads and therefore have most of CPU time used by call handling. On
> call cleanup there is one time-consuming place when cleaner thread terminates H.245 thread and waits up to 10 seconds
> for exhanging of final messages. Under high load and slow context switches list of calls to be cleaned enlarges too
> much, application eats all available file descriptors and being to have problems.

See above. 

I agree that running high call volumes with full debugging will cause
the stack to run slower, because it introduces hundreds of
synchronisation points. I don't see any way to avoid that.

   Craig

-----------------------------------------------------------------------
 Craig Southeren      craigs at postincrement.com / craigs at voxgratia.org

 Phone:  +61 243654666      ICQ: #86852844
 Fax:    +61 243673140      MSN: craig_southeren at hotmail.com
 Mobile: +61 417231046   Jabber: craigs at jabber.voxgratia.org

 Post Increment - Consulting & Services    http://www.postincrement.com
 Vox Gratia - The Open Source VoIP portal  http://www.voxgratia.org
 Raving Of A Strange Mind - the VoIP blog  http://www.southeren.com/blog