[Asterisk-Dev] Re: Inestability with H323

[Paul Cadach]

Hi again,

----- Original Message -----
>  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?

I had used callgen323 on single-CPU machine to make about 20 simultaneous calls to 2 asterisk's servers through GNU
gatekeeper (I don't remember about proxy mode used). Average statistic is next:
- without call setup handling Asterisk hangs after about 100-200 incoming calls (5-10 minutes before segfaults);
- after call setup re-design Asterisk hangs after about 10000-20000 incoming calls (once per 2-3 hours);
- GNU gatekeeper hangs after about 100000-200000 calls goes through it (GK works on SMP machine combined with one of
Asterisk server used for tests).

Call setup re-design is very simple - just callback asterisk not immediately after SETUP messages is received but after
PROGRESS message sent out by OpenH323 stack. I don't remember all details how I done it (it was done about half year
ago).


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

This is one more example on how it depends on "right-used" OpenH323. Also, full proxy mode on GK doesn't say that RTP
packets will be parsed by GK, just _forwarded_ between two endpoints. I.e. OpenH323 RTP stack isn't used yet.


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

All works fine on single-CPU hardware. When you uses SMP and/or HyperThreading (i.e. have more than one physical or
logical CPU) callgen323 just crashes randomly (for me - after 300-2000 outbound calls). So, it looks like improper
locking handling within OpenH323, because software on SMP/HT system works REALLY parallel, and is more dependent on
locking mechanism. It's my own IMHO.


> =================================
> The H323 protocol specifies RTP for sending the encoded audio frames.
> Thus, the rtp audio packets on the ethernet wire have a predefined format.

Just format of headers, not data is predefined...

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

Using large frames-per-packet values is not so much pretty as could seen due to increased packetization delays (total of
algorithmic and packetization delays for 1 frame/packet is about 20 ms but for 3 frames/packet is about 60 ms). Also,
long frames requires to have longer (it time dimension) jitter buffers and loosing of long packets is much more
sensitive for earth than loosing short packets.

Also, I don't think passing additional 10 kbps for 100 Mbit/s network is so significant.


> Reason:: there are about 30 bytes of header that the OS appends to each
> packet generated by iax before putting it on the wire.

Don't mix IAX and RTP. IAX/IAX2 uses fully different "transport" encoding (looks like compressed RTP) and consumes much
less bandwidth than regular uncompressed RTP (independedly on stack used for producing RTP packets - OpenH323 or
Asterisk's builtin).


> Thus, it is much more bandwidth efficient to put more than one audio frame
> into each ethernet packet.

See before. If you want to preserve bandwidth, use cRTP or IAX/IAX2 protocols with _small_ frames/packet ratio to bypass
audio streams over network rather than RTP with many frames per single 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.

Overhead for IAX/IAX2 is 4 bytes per short frame while RTP's header is 12 bytes per packet. For single frame/packet
IAX/IAX2 preserves about 17% of bandwidth for GSM.


> > 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 ?

GK just re-sends packets goes from one connection to other. It doesn't parse RTP headers/data any way.


WBR,
Paul.