[Asterisk-Dev] Re: Inestability with H323
Derek Smithies
derek at indranet.co.nz
Mon Apr 19 01:36:48 MST 2004
Hi,
thankyou for that clarification.
However, and I should not try to have the last word, but,
> There's nothing in the protocol to stop you having multiple frames in
> the one packet.
There is a library, some white papers that are not complete. Nothing is
written down which explicitly states in English how the thing works. For
anyone investigating iax2, as I have done, there is a mountain of code to
read, and packet dumps. All the packet dumps I have seen so far are one
audio frame per packet.
So what are you referring to when you use the word "protocol"?
Derek.
On Mon, 19 Apr 2004, Adam Hart wrote:
> 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
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
>
> _______________________________________________
> 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