[Asterisk-Dev] Re: Inestability with H323

Paul Cadach paul at odt.east.telecom.kz
Sun Apr 18 19:09:50 MST 2004


Hi,

----- Original Message -----
> a)the lack of response from others on this list who have been involved
>   with chan_h323.c   There is knowledge there that I want to tap into.
>   To be honest, I am not keen to "reinvent the wheel". I want to learn
>   from others, and learn what trials/tribulations they had.
>
> b)I have an architecture reorganisation in my mind that will mean
>   chan_h323.c receives/sends encoded audio frames from/to the h323 stack
>   Currently, there appears to be the asterisk does all rtp handling. This
>    is not necessary, and is unwise in my view. I just need some clues as
>    to how to "connect" the encoded audio frames to asterisk.

"Successfullity" of any VoIP product could be pointed as count of simultaneous calls to be handled without degradation
of audio path. For H.323 (and many other protocols) audio streams goes through RTP stack, so keeping it simple as much
as possible increases "bandwidth" of the call server. RTP stack in OpenH323 is complex (usage of C++ gives additional
computational "overhead"), so usage of OpenH323's RTP is not best effort. Asterisk's RTP is much more simple, sometimes
ugly, but not had this "overhead" and used for other protocols like SIP, Skinny, so having cool (in the future) internal
RTP stack allows many features which is not possible when using other stacks (like timestamp calculations) and makes "
to share this stack between many protocols, not to be related to H.323 only.

OH323 module have OpenH323 AudioCodec stub implementation, so you could look there for starting point if you still want
to use OpebH323's RTP stack.


Also, chan_h323 needs some reorganization on call setup sequences to handle all signals at their "places", for example,
do not start ast_pbx() subroutine until PROCEEDING message is sent (otherwise it produces "interference" between
OpenH323 and Asterisk and, as result, causes crashes).

OpenH323 _requires_ to be "right-used" for getting stable results. One example is SMP/HyperThreading support... At least
I found callgen323 works fine in single-CPU environment but crashes while SMP and/or HyperThreading enabled. I don't
think this is Asterisk issue because callgen323 is fully independed from Asterisk and uses OpenH323 library only.


WBR,
Paul.





More information about the asterisk-dev mailing list