dslreports logo

QoS is used to route VoIP packets through and around congestion areas in the Internet, to maintain Call Quality (no choppiness, lag, ...). For QoS to "work", all components in the Internet need to support the particular QoS protocols being used. It is not sufficient for only your router and/or the ATA, and TBB equipment to support QoS. All intermediate routers in the ISP's network must also support QoS.

The QoS feature is disabled in the DVG firmware and TBB PSTN Gateways since there is no standardized QoS capability amongst ISPs at this time. The TOS1 and other bytes currently used to control QoS are ignored by most ISPs, thus providing no QoS capability.

Even with DVG QoS disabled, most TBB users will get great PSTN like call quality - notwithstanding network issues as described in Internet Connection and ISP which can lead to "choppy" audio. Any given TBB user will encounter a congestion free VoIP call, most of the time.

•However, call quality will suffer if you consistently maximize use of your Broadband bandwidth, or stress the DVG ATA.

For most VoIP users, the lack of QoS at the current time simply implies that when there is severe Internet congestion in the path that a VoIP call takes, there may be some degradation on the call - sound cutting out, or lag/delay. This may occur for only one second or it may be a larger amount of time (10secs+); as determined by the congestion itself. This is impossible to determine in advance as the Internet is inherently a distributed system, and congestion can occur at various times and places - much like traffic on a highway. Unlike rush hour highway traffic, your VoIP calls will NOT be a problem every evening - it all depends on what is going on in the path your VoIP call is taking. This will change with every call you make!


As quoted from a Primus post in the Forum:

In order for us to get full benefit from QoS, all the ISPs involved in passing the packet from you to us (or vice versa) would need to respect our TOS, Diffserv, or other settings. Most ISPs erase such things on the way in and out of their networks, which has been our experience in the Canadian market, unfortunately.

If this became doable, we'd certainly do it right away.

This was in response to user (Number6) providing the following details about the TOS byte in TBB VoIP packets from the ATA:

I have been working on ways to modify the QoS of my router to improve the quality and minimize the latency of VoIP packets being sent to/from my DVG gateway. During this tweaking I have noticed that although the TOS field of the packets originating from my DVG is set to 0xb8, the TOS field of packets being sent by Primus is set to 0.

FYI, TOS decodes like this:

b7-b5: precedence
b4: minimize delay
b3: maximize throughput
b2: maximize reliability
b1: minimize cost
b0: unused

0xb8 (on outgoing packets) decodes to 10111000 which is:
- precedence of 101 (5)
- minimize delay
- maximize throughput

Although I can't comment on the value of the precedence field, the other bits look to be set correctly on outgoing packets.

My question is why isn't Primus setting the TOS field on the packets being sent to my gateway? As was mentioned in another post, it looks like ISPs are starting to offer QoS priority at the downstream buffer of their access links. If Primus doesn't set the TOS field correctly, this will make it hard, if not impossible, for an ISP to treat VoIP packets in a special manner in the downstream direction, which is by far the most important direction in the case of residential service.

1TOS - Type of Service


Expand got feedback?

by canoe See Profile
last modified: 2005-07-18 14:24:57