[Asterisk-Dev] Re: Inestability with H323
Derek Smithies
derek at indranet.co.nz
Sun Apr 18 19:41:41 MST 2004
Paul,
thanks for your input.
I do appreciate your comments on the reorganisation required in
chan_h323.c Is it possible for you to detail what must be done?
Or, point me to a doc which states what order things have to happen in?
> 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.
thanks for this.
I am intrigued by your comment on "right-used".
Openh323 has had a number of people looking over the source. There was a
fix recently which fixed a race condition in the code. Indeed, the time
to the last one was ages - my view is that there are very few races left
in openh323. I mean, people are getting 70 concurrent calls through
openh323 gatekeepers (running in full proxy mode).
Certainly, when playing with a multithreaded program like openh323, you do
need to code correctly - and there is your "right-used" comment.
I don't remember any comments about callgenh323 failing. OK. I will look
into that.
=================================
The H323 protocol specifies RTP for sending the encoded audio frames.
Thus, the rtp audio packets on the ethernet wire have a predefined format.
Thus, if the encoded audio frames are sent by asterisk, or by openh323,
there is no different to the packet size.
What you will find is that openh323 will put 3 gsm audio frames into one
ethernet packet. This gives a bandwidth of 20kbit/sec
Asterisk will put 1 gsm audio frame into one ethernet packet. This will
lead to a bandwith of over 30kbit/sec.
Reason:: there are about 30 bytes of header that the OS appends to each
packet generated by iax before putting it on the wire.
Thus, it is much more bandwidth efficient to put more than one audio frame
into each ethernet packet.
Now, my point.
a)It does not matter if asterisk or openh323 sends the h323 audio packet.
the format is unchanged.
Sure, asterisk needs to send iax packets.
b)the iax protocol is bandwith inefficient, because it just puts one
encoded frame in an ethernet packet.
I apologise, I forget the exact numbers. I did the work at one stage,
and showed that iax has a bandwidth over 30kbits/sec for each audio
stream.
There are web pages detailing openh323's usage. I have measure that, and
it is below 20kbits/sec for each audio stream.
======================================
> RTP stack in OpenH323 is complex (usage of C++ gives additional
> computational "overhead"), so usage of OpenH323's RTP is not best
> effort.
Maybe. If the stack in openh323 for rtp handling has these difficulties,
how is that an openh323 gatekeeper can successfully be a full proxy for
the the audio and data streams from 70 concurrent calls ?
Derek.
===========================================================================
On Mon, 19 Apr 2004, Paul Cadach wrote:
> 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.
>
>
> _______________________________________________
> Asterisk-Dev mailing list
> Asterisk-Dev at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-dev
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-dev
>
>
>
--
Derek Smithies Ph.D. This PC runs pine on linux for email
IndraNet Technologies Ltd. If you find a virus apparently from me, it has
Email: derek at indranet.co.nz forged the e-mail headers on someone else's machine
ph +64 3 365 6485 Please do not notify me when (apparently) receiving a
Web: http://www.indranet-technologies.com/ windows virus from me......
More information about the asterisk-dev
mailing list