cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
820
Views
0
Helpful
26
Replies
Highlighted
Beginner

SPA525G2 Wireless Call Quality Issues

I have two SPA525G2's in my office.  One is at my desk and connected directly to my WIFI router using the LAN port, the other is at another desk using WIFI only.  The WIFI unit indicates it has a full signal, its probably 5 foot away from the wireless router if that, i can hear the callers fine but they say i sound very choppy.

On the Cisco/Linksys E6400 wifi router i have QOS turned on for both MAC ID's of both phones. I have no issues with the hard wired phone, is there some setting im missing on the phone that is wireless or any tricks anyone knows to make the call quality better?

I have a 80/5 internet connection so its not a bandwidth issue, only a couple computers doing light web browsing.

Any ideas?

Thanks

26 REPLIES 26
Highlighted

OK one more try :), new capture

tcpdump -i any host 192.168.1.143 -T rtp -vvvvv -s 0 -w /home/capture9

with looks like RTP packets included 

thx mike

Highlighted

Well,

  1. it's no complete call. Thus no final BYE, thus no phone's statistics available (assuming you configured "Stats In Bye"  to Yes)
  2. you didn't configured "RTP Packet Size" to 0.020
  3. for a some reason, every packet is captured twice (you should verify the packets are not send twice over air but it's caused by capture itself)

To compensate [3] I removed duplicates before further analysis. I removed packets unrelated to particular call as well. The resulting file is attached so you may verify my conclusions.

There's no problem with the second stream (0x1ebdedff) - no packet lost, max delta as well as jitter is good. The first stream (0xc53e3fda) is different beast. 6.8% packet lost is unacceptable. Burst of 124 packets missing (#10571-10693) mean about 2.5s of silence. Not surprisingly, the sound quality is low.

 

Highlighted

what would be a syntax for tcpdump to include "Stats In Bye"=yes and RTP Packet Size" to 0.020 ?

 

thx 

 

tcpdump -i any host 192.168.1.143 -T rtp -vvvvv -s 0 -w /home/capture9

Highlighted

It's not tcpdump's configuration but the phone's one.

Highlighted

which option is that - do you see it on my 1-5 screenshots from message above ?

Highlighted

It should not be so hard to find them for you, isn't it ? Both are on SIP tab, RTP Parameters section.

Highlighted

Dan, I appreciate your patience working with me :)

I think I got it this time , "Stats In Bye"=yes and RTP Packet Size=0.020  all set and captured 2 files:

#10 over wifi

and #11 over Cat5e

 

I'm not sure but looks like #11 has zero loss vs 10 some loss ?

Anything I can tweak  in this phone settings to optimize WiFi transmission ?

 

thx Mike

Highlighted

OK. I filtered out duplicates as well as unrelated packets. Analysis of resulting file (wireless variant) follow:

5% packet lost is still so high. And even 142ms of delay. Note that for phone call the delay of 100ms is considered maximum for standard quality calls. I mean end-device-to-end-device(!) delay. You are exceeding overall limit in first hop.

I need not to listen the stream to assume the call quality will be low.

It is clear.

What's not as clear is the cause of packet los and delay measured and it will be hard to debug.

The packets may be lost because

  1. they has not been transmitted from phone at all because of
    1. firmware bug
    2. wireless environment condition
  2. they has been transmitted, but lost later on
    1. air (so they has not been received by AP)
    2. wire (so they has been lost in wired part of transmit)

You need to capture packets from air as well as monitor wireless environment to distinguish those cases.  Unfortunately, it require special equipment to analyze thinks like it.

Some smart AP with detailed statistics may help a lot, but not those cheap one.

Well, there's something simple and cheap you can try to decide the SPA525G2 is guilty or not.

Use a wireless-to-wired bridge (please not the cheapest crap you found around) on phone's side. Connect phone using wire to it.

In such scenario phone doesn't affect wireless operations in any way. It's the bridge who is sending/receiving packets to/from air.

Repeat the test. If the results become acceptable then issue is related to phone. If there will be still packet lost and so high delay, then phone is not causing the issue.

 

Highlighted

do you see any loss in #11 over Cat5e ?

Highlighted

No loss in captured file.


 

Highlighted

Thanks Dan, for guiding me thru troubleshooting - I guess we have 2 options , those phones are not designed to be on non Cisco wifi-equipment or actual fw Bug preventing it working normal within any wifi networks. 

I bet Cisco did their homework testing it but most likely only with their own $$$ equipment, all point of wifi standard to be a standard across all platforms . 

Highlighted

It may be phone's firmware bug or other phone-related issue, it may be noisy environment causing wireless working unreliably, ...

As we discovered no issue cause yet, I'm not willing to claim who's guilty.