[Asterisk-Dev] Re: Inestability with H323

[Paul Cadach]

Hi,


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

Plus 8 bytes - UDP header, 20 bytes - IP header, 14 bytes - EthernetII header. Totally - 79 bytes. When the same packet
goes through PPP it don't have EthernetII header and usually uses Van-Jacobson IP header compression (which compresses
IP header up to 4-8 bytes as I remember), plus PPP header/trailer (about 8 bytes, I don't remember).

>  Examine that frame with ethereal.
>    79 bytes on wire. This includes link layer usage

Yep, see before.

>   50 packets per second, ==> 31.600 bits/second.

Yep, it's "line" speed on Ethernet.

>  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

Ok, you saves 14 bytes per packet.

> 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

Continue your calculation. 33 bytes per frame * 8 bits per frame * 50 frames per second (one frame consists 160 samples,
or 20 ms of audio) = 13200 bits/sec. So, pointed link just says about CODEC bandwidth, not NETWORK bandwidth. Add all
header sizes (20 for IP, 14 for MAC, 8 for UDP and 12 for RTP) to your 33 bytes and you gets 87 bytes per packet for
Ethernet (or about 73 bytes for PPP link). So, consumed bandwidth for single frame GSM is 34800 bits/sec for ethernet
and about 29200 for PPP, not 13200 bps!!! To compare, the values for single-frame GSM over IAX/IAX2 is 31600 bps for
ethernet and 26000 bps for PPP (i.e. IAX/IAX2 saves about 3,2 kbps for you by using small headers).

Look before - I've got the same values as you get with Ethereal.

> > 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 had used GSM over IAX2 for long time, and it works fine on regular V.34+ connection (31.2-33.6 speeds). As calculated
before, both IAX2 and RTP will fit to this bandwidth (if you don't run something else together with VoIP traffic).

FYI, now I'm runs G.723.1 6,4K over RTP - it consumes about 17067 bps over PPP link (G.723.1 frame duration is 30 ms
packed into 24 bytes).

> ==================================
>
> I suspect, on reading your bug description, the threading bug just fixed
> was the one that caused your problem with callgenh323
>
> =====================================

I'll try to check it with latest CVS of OpenH323...

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

See my calculations above... ;-)'

> Yes, you need jitter buffer etc, but I have noted requests on this list
> for jitter buffers in asterisk.

Currently Asterisk doesn't have any jitter buffer at its RTP stack, which is not so important for endpoint-to-endpoint
connection (endpoint must eliminate all possible jitter rather than Asterisk).

> My view is that latency is important, but even more important is that your
> audio device is truly full duplex.

Most of new audio cards (including AC-97 compliant) are full-duplex, so it's not problem. Latency is not a big problem
too if end-to-end latency fits to 200-250 ms range (good sound quality). So, increasing frames/packet value
automatically increases latency, and if you goes out this range your sound quality will be noted as poor (but for
technical talks it's not so important).



WBR,
Paul.