[WXC/VFX] Voice Breakup on VFX service during heavy downloads

Forums › One New Zealand (including Vodafone, WxC, Farmside) › [WXC/VFX] Voice Breakup on VFX service during heavy downloads

grant_k

3539 posts

Uber Geek

Trusted

#10229 11-Nov-2006 01:32

numberonekiwi: I still believe that I may not have the correct settings as I used to get a better quality without QoS from a UK VOIP on my DG834G with supira SPA1001 (no Qos)

Did you manage to get this problem sorted?

If so, I'd be interested to hear how you did it, or any other comments you may have on this issue.

Thanks,
Grant.

maverick

3594 posts

Uber Geek

Trusted

WorldxChange

#51960 11-Nov-2006 09:52

Yes we have a bit of feedback on this as this was a concern when reported,

Just a quick point for everyone one the WAG54gp2v2 and the WRTP54g and the QOS capabilities of these 2 devices, both of these boxes have inbuilt QOS for the voice module and do not require changes to the QOS settings on the box. hopefully you will see this by the below example

Symptoms

The problem the customer complained of was very bad quality calls at night whilst downloading and also with no downloads in progress no difference in call quality , also this customer has a second provider on his device and the call quality was also bad for this service.

Below is the 3 calls that were made to our Network at the time and show very bad packet loss, I agree the call quality would have been very bad.

P-RTP-Stat: PS=382,OS=16044,PR=336,OR=10752,PL=215,JI=26,LA=0,DU=12,EN=G729a,DE=G729a

P-RTP-Stat: PS=442,OS=18564,PR=397,OR=12704,PL=183,JI=33,LA=0,DU=14,EN=G729a,DE=G729a

P-RTP-Stat: PS=176,OS=7364,PR=216,OR=6912,PL=16,JI=18,LA=0,DU=6,EN=G729a,DE=G729a

Testing

I have had the customer restest and do a couple of basic tests for me the following morning during a quieter traffic period , this will hopefully show you the QOS in progress, I had the customer make a few calls whilst doing the same downloads and then with out the downloads , also at the same time from a PC behind the router ping a Network device on our Network, results below show the results with no download and then the results with heavy downloading. Notice the ping results vastly different, you would expect at this stage to possibly see bad quality calls, however here are the packet results from all the calls made while the download was in progress (see below), you will see not a single dropped packet yet the latency went up for the ping Tests i.e. non priority traffic...What this shows is that the QOS in the device is working perfectly and assigning the the appropriate priority to the Voice packets, the customer reported Call quality was good fro all calls.

No Downloads In Progress - Results
Numberonekiwi$ ping -t 120 58.28.20.150

PING 58.28.20.150 (58.28.20.150): 56 data bytes

64 bytes from 58.28.20.150: icmp_seq=0 ttl=59 time=54.667 ms

64 bytes from 58.28.20.150: icmp_seq=1 ttl=59 time=53.866 ms

64 bytes from 58.28.20.150: icmp_seq=2 ttl=59 time=57.086 ms

64 bytes from 58.28.20.150: icmp_seq=3 ttl=59 time=53.670 ms

64 bytes from 58.28.20.150: icmp_seq=4 ttl=59 time=57.213 ms

64 bytes from 58.28.20.150: icmp_seq=5 ttl=59 time=55.769 ms

64 bytes from 58.28.20.150: icmp_seq=6 ttl=59 time=56.301 ms

64 bytes from 58.28.20.150: icmp_seq=7 ttl=59 time=52.137 ms

Download in Progress - Results
Numberonekiwi$ ping -t 120 58.28.20.150

PING 58.28.20.150 (58.28.20.150): 56 data bytes

64 bytes from 58.28.20.150: icmp_seq=0 ttl=59 time=58.360 ms

64 bytes from 58.28.20.150: icmp_seq=1 ttl=59 time=55.867 ms

64 bytes from 58.28.20.150: icmp_seq=2 ttl=59 time=62.790 ms

64 bytes from 58.28.20.150: icmp_seq=3 ttl=59 time=92.586 ms

64 bytes from 58.28.20.150: icmp_seq=4 ttl=59 time=283.321 ms

64 bytes from 58.28.20.150: icmp_seq=5 ttl=59 time=297.075 ms

64 bytes from 58.28.20.150: icmp_seq=6 ttl=59 time=298.362 ms

64 bytes from 58.28.20.150: icmp_seq=7 ttl=59 time=287.394 ms

64 bytes from 58.28.20.150: icmp_seq=8 ttl=59 time=289.014 ms

64 bytes from 58.28.20.150: icmp_seq=9 ttl=59 time=289.501 ms

64 bytes from 58.28.20.150: icmp_seq=10 ttl=59 time=290.274 ms

64 bytes from 58.28.20.150: icmp_seq=11 ttl=59 time=290.748 ms

64 bytes from 58.28.20.150: icmp_seq=12 ttl=59 time=193.090 ms

Call Stats
P-RTP-Stat: PS=237,OS=9954,PR=342,OR=10944,PL=0,JI=8,LA=0,DU=7,EN=G729a,DE=G729a
P-RTP-Stat: PS=738,OS=30996,PR=1091,OR=34912,PL=0,JI=7,LA=0,DU=22,EN=G729a,DE=G729a
P-RTP-Stat: PS=274,OS=11508,PR=394,OR=12608,PL=0,JI=7,LA=0,DU=8,EN=G729a,DE=G729a
P-RTP-Stat: PS=203,OS=8526,PR=303,OR=9696,PL=0,JI=0,LA=0,DU=6,EN=G729a,DE=G729a
P-RTP-Stat: PS=245,OS=10290,PR=365,OR=11680,PL=0,JI=0,LA=0,DU=7,EN=G729a,DE=G729a
P-RTP-Stat: PS=222,OS=8154,PR=329,OR=10528,PL=0,JI=0,LA=0,DU=6,EN=G729a,DE=G729a

CONCLUSIONS

From the testing and the results seen I am concluding that the bad quality actually stems from the ADSL link itself or the ISP's network performance, the packets loss reported by the Router Call stats is actually reporting correctly and the packets actually never arrived and were dropped before being delivered to the customers router henec the bad quality that effect the calls to our Network and the calls to the other provider configured on the device, this appears to have been a problem during peaks times and not observed during a lighter traffic period. So

I hope this explains the results, findings and conclusions.

Yes I am a employee of WxC (My Profile) ... but I do have my own opinions as well

https://www.facebook.com/wxccommunications

grant_k

3539 posts

Uber Geek

Trusted

#52008 11-Nov-2006 19:30

Great post Phil!

Thanks for the considerable time and effort you put into answering my question. You really do go beyond the call of duty

.

Your test results clearly establish that QoS is doing its job in prioritising outgoing packets, over which the router has full control.

What do you think about the incoming packets where it is the upstream router (at the start of the "last mile" link to the end user) which makes the decision as to which packets receive priority?

Is there any way to prioritise those so effectively as the outgoing packets?

maverick

3594 posts

Uber Geek

Trusted

WorldxChange

#52041 12-Nov-2006 08:36

Grant17: Great post Phil!

Thanks for the considerable time and effort you put into answering my question. You really do go beyond the call of duty .

Your test results clearly establish that QoS is doing its job in prioritising outgoing packets, over which the router has full control.

What do you think about the incoming packets where it is the upstream router (at the start of the "last mile" link to the end user) which makes the decision as to which packets receive priority?

Is there any way to prioritise those so effectively as the outgoing packets?

This is the main issue and unfortunately will not be solved, it stems around the fact that we have a number of providers using a single network, QOS works on th basis that you assign a priority to the packet (TAG) and the network understands that packet tag and gives it the preference it needs, however if I send a voice packet out via our connection to Telecom with a Priority TAG and then it gets handed off to Slingshot in this case the Packet has gone through 3 networks, Now no carrier interconnect will honor any Tag from another Carrier, will Slingshot give WxC priority for it's connection because it has a priority TAG.... no it does not work across networks so the best we can do is use hardware that can easily prioritise Voice Traffic with out 2 much user intervention at the local end (hence one of the reasons we selected the hardware we did)......

Now I'm off to watch the AB's kick some French butt........can I vote for Ritchie McCaw for PM now

Yes I am a employee of WxC (My Profile) ... but I do have my own opinions as well

https://www.facebook.com/wxccommunications

sbiddle

30853 posts

Uber Geek

Retired Mod

Trusted

Biddle Corp

Lifetime subscriber

#52055 12-Nov-2006 10:43

In Australia there are now several ISP's who also provide VoIP services charging a premium for plans with 802.1p support. It's a shame we're unlike to see the same here until we get providers taking advantage of ULL and installing their own gear.

grant_k

3539 posts

Uber Geek

Trusted

#52296 14-Nov-2006 15:55

Steve and Phil:

You may remember that I had difficulties prioritising outgoing VoIP packets?
(it was mentioned on the original humungous VFX thread). I have just managed to get this sorted...

After reading the manual for my router again, I realised that the order of the Bandwidth Management rules is important i.e. you have to place the most restrictive rules earlier in the table than the less restrictive rules e.g. the "Catchall" rule.

Having got those rules in the correct order, I can now give the outgoing VoIP packets from my PAP2 a higher priority than packets sent from my PC and there is now absolutely no degradation in outgoing call quality even while sending large e-mail attachments

.

It just goes to show that QoS WILL do its job for the outgoing packets so long as you have it set up correctly (exactly as Steve suggested earlier

).

In my case, I have had to do this by prioritising all traffic from a specific IP address, but other routers may be able to prioritise the VoIP traffic simply by using SIP recognition. For some reason, on my router, this used to work with iTalk, but it doesn't work with VFX. I suspect it is because iTalk used port 5060 (the standard SIP port).

Anyway, with this latest tweak to my setup, I now have VoIP prioritisation fully implemented in both directions. Thanks to you both for your helpful suggestions.

Cheers,
Grant.

maverick

3594 posts

Uber Geek

Trusted

WorldxChange

#52306 14-Nov-2006 17:35

Grant17: Steve and Phil:

You may remember that I had difficulties prioritising outgoing VoIP packets?
(it was mentioned on the original humungous VFX thread). I have just managed to get this sorted...

Having got those rules in the correct order, I can now give the outgoing VoIP packets from my PAP2 a higher priority than packets sent from my PC and there is now absolutely no degradation in outgoing call quality even while sending large e-mail attachments .

It just goes to show that QoS WILL do its job for the outgoing packets so long as you have it set up correctly (exactly as Steve suggested earlier ).

Cheers,
Grant.

Good to hear Grant,

Yes you correct thats exactly what was happening with your device , the PAP2 / SPA range of products that actually sit behind routers will require QOS setup if you are having issues. #1kiwis issue was that he has the inbuilt VOIP Router WAG54gp2v2 , QOS is already inbuilt but he still had Call Quality issues, I hoped I have explained why this would have occurred and where the problem lies, I also think it shows pretty well how the QOS works on this particular product.

Yes I am a employee of WxC (My Profile) ... but I do have my own opinions as well

https://www.facebook.com/wxccommunications

Fraktul

836 posts

Ultimate Geek

Trusted

#52358 14-Nov-2006 23:14

One possible solution with the existing Telecom infrastructure would be for separate VC's for a VoIP path and RSVP or some such on the VoIP VC. Most CPE is limited to 1 ppp dialer however....also the ATM scheduler on the DSLAM would need to dynamically adjust to the current trained line rate for the ADSL egress.

ATM is annoying.