[Asterisk-Dev] Re: Inestability with H323

Sun Apr 18 22:10:58 MST 2004

There's nothing in the protocol to stop you having multiple frames in 
the one packet. I just changed firefly to do 2 GSM frames per packet and 
it worked fine. Problem solved :)

Derek Smithies wrote:

>Hi,
> I did the numbers, again.
>
> I used firefly, in iax mode.
>
> I used ethereal to capture the data.
>
> 33 bytes for 20 ms of audio frame.
>
> 4 bytes of iax header.
>
> Examine that frame with ethereal.
>   79 bytes on wire. This includes link layer usage
>
>  50 packets per second, ==> 31.600 bits/second.
>
> Now, go to 65 bytes for the calculation, which is what you will have with
> ppp (such as on a dialup)  ==> 26,000 bits/sec
>
>
>Now, go to ::http://www.openh323.org/docs/bandwidth.html
>3 gsm audio frames/packet.  ==>13.200 bits/sec.
>  (This figure does not include link layer usage)
>
>So I think we have 13.2 to compare with 26
>
>==============================================================
>
>
>  
>
>>Also, I don't think passing additional 10 kbps for 100 Mbit/s network is so significant.
>>    
>>
>
>True.  However, try doing voip on a dialup connection, where neither end 
>is doing silence detection.
>I would far rather have both ends doing silence detection at a lower bit rate.
>My dialup connection is 40kbits/sec.
>  iax will not work on my dialup. But, gsm with h323 does work just fine.
>==================================
>
>I suspect, on reading your bug description, the threading bug just fixed 
>was the one that caused your problem with callgenh323
>
>=====================================
>
>  
>
>>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.
>>    
>>
>Not so.
> see above calculations.
>
>Yes, you need jitter buffer etc, but I have noted requests on this list 
>for jitter buffers in asterisk.
>
>My view is that latency is important, but even more important is that your
>audio device is truly full duplex.
>
>Derek.
>====================================================================
>
>On Mon, 19 Apr 2004, Paul Cadach wrote:
>
>  
>
>>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.
>>
>>
>>_______________________________________________
>>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
>>
>>
>>
>>    
>>
>
>  
>