UC540 remote SPA525G2 audio issues

[JOHN THIEN]

My test install of the Cisco UC540 w/ SPA525G2 phones (some running remotely over built-in VPN) works pretty well, but...

The heaviest user of a remote phone, on occasion, has audio drop-out mostly on the way to him.  So the other party is talking, but he can't hear them.  This can last 10-20 seconds.

Not sure where to look.  Both locations are using Time Warner Road Runner (very few hops between locations, low pings from home to office).  The UC540 is using a Broadvox SIP trunk.  The remote location is using a Buffalo router w/ DD-WRT firmeware (I'm going to upgrade that to Tomato because the remote management works better).

The DD-WRT has IPSec passthrough turned on, but of course the phones are using SSL VPN.  The DD-WRT also has SPI (Stateful Packet Inspection) enabled.

Any ideas?  Does anyone else use the built-in VPN in the SPA525G2 and have any experience to share?

NOT blaming this on the UC540.  He has had connectivity problems at home, but I though that was behind us.  AND, when this happens, he says his RDP session (which he isn't hammering) is working fine.

[JOHN THIEN]

Is there a way to accomplish the same thing using the UC540 as the primary router (as I am doing)?

And what kind of Internet connection did this location where you were experiencing the issue have?

My work system is an Asterisk box, with Aastra 9143i handsets, behind a Tomato-based router connected to a Time Warner 12 x 1.5 connection.

I have found I don't really need to use the QoS on the downstream for my system.  I used to have it enabled but find even with it disabled, I can call my test # (888-247-2425, the CallMe service, this is a great testing #) and get outstanding call quality even when I'm hammering my Internet connection (doing speed tests, for example).

I duplicated this test w/ the UC540 and the local phones seem to work fine when I was doing a speed test (at speedtest.net).

But I've previously worked on ESI systems connected to T1's, for example, where I only had 1.5 of bandwidth in each direction.  In those cases, it was pretty easy to overwhelm the connection if someone wanted to watch Youtube, for example.  A speedtest also would easily cause drop-out.  All this even with QoS enabled on the downstream.

I think it has a lot to do with elbow room.  There is a huge difference between 1.5 and 12-mbps of download speed.

Anyway, if you (or anyone else) have tips for setting download speed limits on the UC540, they would be helpful to know about if, for nothing else, diagnostic purposes.

Thanks for all the feedback!

[Brian Rapier]

The QOS policy was put on the far end.  Where the user that is experiencing the issue was.

The location I put the policy on is using a 10mb/2mb service.  So I limited the incoming http to 8mb and so far after 6 months the issue has not popped back up.

I did a quick search and it looks like the Buffalo you are using on the far end can do the QOS.  I do not use my UC as a router so I could not begin to help you set that up!

Our issue did not happen all the time and thats where I was getting hung up, it would work fine for days, then I would get a couple calls saying they could not hear the person on the far end. 

If your far end service is 12/1.5 and you only have one user, I would try 11mb on the d/l side and see how that works.

Originally I tried the same things posted here, changed the codec, enabled mtp etc. 

After the policy I changed the codec back to 711 as the quality of 729 was not the best.

[JOHN THIEN]

Oh okay I get it.

In this particular case, his home connection is also Time Warner, and is the 30 x 5 (I think) speed.  His Buffalo router running there is actually running DD-WRT, an older version.  I need to upgrade that to Tomato.

There are only six hops between his home Time Warner circuit and the office Time Warner circuit.  And at the times when he has had problems, there hasn't been a lot going on at either office (network-wise).

I think things have probably improved since making the earlier changes suggested in this thread.

Further complicating things, BTW, is the fact that I'm also on a VOIP system and the other day he called me and said I was choppy to him.  The funny thing is, I've had other customers tell me at about that time of day that I can sound a bit choppy.  It doesn't happen much, probably has something to do with TW and stuff happening at that time of day.

But it sure doesn't help when trying to debug things.

So I think with DTLS and teleworker enabled I'll just wait a while and see how things are for him.

He did tell me, BTW, that he has some choppyness this morning on an ad-hoc conference call.  Not sure if it is the same old issues or something unique to conference calls.  I did some googling and there are some people that have experienced drop-out on ad-hoc conference calls only.

So we just need some more run-time to get some more feedback.

[Brian Rapier]

Goodluck!

Not sure what all is running at your office, but things like, automatic updates, av updates, file sync's.  They all played havoc on me when trying to track down issues.

I would get hit when our AV server was set to push out updates at 9am, it would bury the 10mb upload pushing all the updates out at once, that was also fixed with QOS.  So you may want to look at those things as well.

It took a huge amount of tweaking and fighting to get ours up to standard, but since we got the bugs sorted out its been pretty good.

[JOHN THIEN]

This is a SMALL office w/ basically one person (a receptionist) there about 90% of the time.  I have one remote phone (for testing) and the client has one other remote phone (more to be ordered once the issues calm down).

I have enabled traffic shaping on the WAN port, and have those #'s set pretty conservatively.

This last weekend he took his one remote phone to his cottage and he called me Friday night when he got there.  It sounded clear as a bell, just great call quality.  His cottage gets Internet via a wireless service that covers Door County, WI.

He made/took a bunch of calls on Saturday, no problems.

Sunday it wasn't so good.  I switched his from from G711 to G729, no real improvement.  Then I was on his notebook w/ a remote support tool and the Internet started dropping out, like crazy.  Then he told me the ISP wanted to upgrade the wireless hardware for better performance.  And I'm not sure if his old Belkin Pre-N router isn't iffy, too.

There are just so many variables in this stuff, it can get kinda maddening.

At least this client is a reasonable guy and really sees the value of the technology.  He is sold on the cost savings and the extra utility.  For example, his receptionist took last week off.  With the remote phone he didn't have to run into the office to cover her.  Being able to see who was calling, at home, and make/take calls as if he were at the office, is valuable to the guy.

We just need to work some of the kinks out, and I'm pretty confident we will.