Here is a brief on what I was trying to achieve…

______

Starting point... 3 levels/categories....
VoIP - gets maximum preference -
OTHER - (Uncategorised) traffic gets medium preference -
P2P - file sharing gets low preference -
So, what this would mean (in my mind, at least) is that if the connected computer is idle, but file sharing via azureus etc, then that traffic would get all the available bandwidth UNTIL the PC starts to be used (Internet browsing, email, online gaming etc... (All these items fall into the OTHER category)) Whereby these processes get preference over the P2P traffic, which would begin to slow...
Finally, if a VOIP call is made/received, then both the OTHER and P2P would back-off, giving maximum most of the bandwidth to VoIP , a small amount to the OTHER traffic, and P2P would be a trickle, if at all, until the VoIP traffic ends.

______

And here is what I have come up with, so far…

  • Firstly… Set VoIP Priority to Premium.

  • Now for Prioritization of P2P and ANY other traffic… I use TCP and UDP 45021 for my P2P application.

You should note the LOW priority chosen for the P2P application entries.

This should give P2P traffic a lower priority over any other traffic LEAVING the router for the internet (LAN to WAN)

Note: Any unspecified traffic gets MEDIUM priority by default. Therefore in this example it is only necessary to address the P2P traffic

  • Finally Some IP Throttling, just so some ’guaranteed’ bandwidth is available to VoIP.. Firstly I need to explain that these rate limit values are based on a 256/1500 plan.

Now, one thing you probably should do, using your ISP’s FTP server… (Normally the ISP has at least one, the one you FTP your personal website to/from) is test what the maximum upload and download throughputs are for your connection. That is to say, how close to the theoretical 1500kbps can you get? And can you SEND at 256kbps? Many factors including distance from the exchange, will factor into your real upload /download rate.

Outbound…. Not going to do anything here, as it is believed this can be better handled by addressing MTU pack size… later in the document.

All Inbound traffic, excluding VoIP traffic to the Internal ATA of the router has been limited to1344kpbs… (42 * 32 kbps)

This number is a bit less than what I actually measured my FTP downloads to be, it was suggested to build some “headroom” or “FAT” into the calculations. This is because we want OUR router to start to drop packets as we hit the rate limits, rather than running the link at 100% or having the ISP end controlling the throughput throttling, by us having chosen too high a value.

For those with a maths ‘bent’, Cisco have a very good article on calculating how much bandwidth will be used by the different VoIP codecs

Adjusting MTU packet size, taken from Whirlpool forums.

I recently purchased a brand new Billion 7404VGO to go with my 1500/256kbps ADSL from Internode and Nodephone VoIP. Unfortunately, I soon discovered that despite the automatic QOS for VoIP on the router, I was still transmitting poor quality audio when other activities were taking place on my line. It seemed that the QOS wasn't working.
I notice a lot of people are requesting features such as automatic throttling to combat such problems though yet more seem to think that there is no problem at all. I believe i've discovered what the issue is...
If you have a slow upload speed (anything that you can get on a Telstra ADSL port) and default maximum packet sizes (MTU=1500Bytes or thereabouts), the time taken to transmit a large packet is quite significant. Thus, if such a packet (e.g. from a file sharing app) is being transmitted when your VoIP packet arrives at the router, your comparatively tiny VoIP packet has to wait. As VoIP is very latency sensitive, this will quickly ruin the quality of your call.
Since I set my MTU to 576, i've had fine call quality despite leaving uploads maxing the connection (either ftp to Internode webspace, torrents or both). With a smaller MTU, large packets are broken up and queued, rendering the QOS mechanism effective in quickly prioritising VoIP packets.
The price you pay for this is a higher overhead (due to the increased number of packets). My reported speed on the Internode speed test dropped from 1289/215 with MTU=1500 to 1160/194 at MTU=576. However, as I see that a lot of people are reserving up to 128kbps bandwidth for VoIP, I doubt they'll miss the smaller decrease that this involves...after all, a loss of 21kbps upload speed is vastly preferable to a loss of 128kbps.
For anyone who wants to try this, the MTU setting is in the ISP page of the WAN settings on the router.

You need to be disconnected to change it.

For the record, i'm using the G.729 as I found I didn't notice a significant difference in quality and it's more fault tolerant than G.711a (it also uses less bandwidth, but that's not why I changed to using it). Apparently you shouldn't set the MTU to a value less than 576...it works fine for me at this level anyway...


edit: just some numbers in case anyone wants a bit more of an idea about the kind of latency i'm talking about...
On a 256kbps line (with 215kbps usable capacity), a 1500Byte packet takes a little over 1/20th of a second to send. DOUBLE that for 128kbps and again for 64 and you'll see how this could cause troubles...