VoIP: UDP Packet compression to save bandwidth...

I am running VoIP services on 1.2Mb realtime link (anything above the bandwidth will be dropped). The voip protocol is proprietary (by Etrali telecom), not anywhere close to other industry standards. These are not the typical VoIP phones either; specialized broker 'turrets', that can handle 2 handsets and 6 so-called open broadcasts (OBs), which are audio channels 'assigned' directly to the device. Should trader hit the button on the other end, voice will be heard on the OB channel. Otherwise, it's quiet. To make things more complicated, there is bandwidth used, no matter if there is audio present on the OBs. It's like they transmit 'empty' data. Etrali does not use any voice compression (why?), which results 80Kbps per channel with overhead. I have done some dumps with Ethereal to analyze the UDP packets (that's how the voice is being sent). The size of a typical packet is 302 bytes total (260 data) 75% of the time, the remaining 25% is 542 bytes (500 data). I believe, the difference in size depends on how many OBs has been placed on the client's turret; important to say is, that the packets sizes should not exceed 600 bytes. A typical small-size packet looks like this: (i have marked the start of the data part by ***), there were concurrent 2/3 conversations active at the time of the probe.

0000 00 11 93 bc 28 43 00 06 47 30 03 39 08 00 45 b8 ....(C.. G0.9..E. 0010 01 20 f1 bf 00 00 40 11 28 4d c0 a8 04 84 42 09 . ....@. (M....B. 0020 57 d3 10 00 10 e0 01 0c 00 00***90 17 3c 8f 3f ec W....... ....
Reply to
Loading thread data ...

I doubt very much that the 2950's have compression facilities.

Compression is very CPU intensive and the high packet rate typical of voice will put quite a load on a small router.

Compression itself ads latency (jitter too?) which is often detrimental to voice. If you had the equipment I would say give it a try.

A very common voice scheme is to use 64kbps of voice data in the form of 256 level (8 bit) samples at 8kbps. This is quite possibly what they have used.

It is very close to RTP with a header extension. You have 240 bytes of voice data, one sample I have has


Some analysis. Sorry for the long lines, hope you can fix it. I took out most of the ASCII since it is meaningless in this context.

0000 00 11 93 bc 28 43 00 06 47 30 03 39 08 00 is IP 45 b8 ....(C.. IP DSCP=b8 0010 01 20 f1 bf 00 00 40 11 28 4d c0 a8 04 84 42 09 . ....@. IP len 288 11=UDP

0020 57 d3 10 00 10 e0 01 0c 00 00 UDPsrc 4096 dst 4320 len 268 ***90 17 3c 8f 3f ec W.......

***90 = RTP with Header Extension 0030 dc 16 5e 59 5f ff If RTP 01 81 00 01 02 00 00 00 RTP extension??? 2 x 32 bits

d7 d7

0040 d6 d7 d7 d4 55 55 54 54 54 54 54 55 d5 d4 d4 d4
Reply to

Agreed. but little ciscos (26/28xxs) support a data compression AIM add on.

depends - it takes time to compress / decompress the packet - true.

but - the reduced delay to send the packet may more than offset the compression latency.

(seen this on old Bay ASNs with hardware compressors, where end to end latency goes down with compression across a 2 Mbps link).

compression is about reducing the space used by repeatable bit strings

thing to watch for is purely random data isnt very compressible, and pre compressed data is even worse - most compression schemes have a worst case set of data patterns where they are worse than no compression.....

if they the app sents "silent" voice data, then that is potentially very compressible.

Reply to

use "juniper" in former times "peribit"

formatting link
's really great. we use it with success.

best regards hans

Reply to
hans m42

Do you use CIFS (SMB) (Windows shares) across these boxes? What are the results?

May I mail you directly? My source e-mail address does not work.

Reply to

no. we use nfs. every user can access his data on every location. the home-server is sharing the fs, all others are mounting it. we user samba to access to this fileshares on every location localy.

we are satified. we have 2 mbit leased lines. peribit ( now juniper ) does an increasement of 2.5 till 3.3 in average. so we have an 6 mbit line. but without qos even a 20 mbit line wouldn't work.

compression ( which is fantastic ) and acceleration are well things but qos is the best one. i think, there are no alternatives for qos except you have the money for dark fibre.

yes you can. my e-mail for newsnet is temporary and short of live, but real.

best regards hans

Reply to
hans m42

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.