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.

[Alexander Maroukian]

Hello John,

There are a lot of things to consider when you have such issues but you may try the following.

Change the codec on the phone to G729.

Check the uplink load on the UC and the download on the other side.

Check if under the SSL setting you have DTLS enabled (enable if it is not).

HTH,

Alex

*Please rate helful posts

[jlesa2457]

Agree with Alexander - enable DTLS this will use udp as oppose to tcp which probably explains your one way loss.

HTH

[JOHN THIEN]

Thank you for your help guys.

Please excuse my ignorance, I don't have the UC540 local and I looked in the manual and can't find it, is DTLS enabled in the SSL VPN setup via CCA?  I'm not sure where I enable the DTLS.

[jlesa2457]

Yes,

navigate to security --> SSL VPN ---> basic or advanced setting tab(can't recall which one)

you'll be able to see it from there.

HTH

[JOHN THIEN]

Okay, thank you again for the help.  I'm pretty sure I don't have that enabled now.  I didn't realize a failure to enable DTLS would result in the phones doing TCP instead of UDP.  If that is the case, all I can say is they work pretty darn well doing TCP, LOL.

[jlesa2457]

Means you have a fairly good connection remotely if it works well. I find it the biggest issue for internet voip.

cheers.

[trgood]

Apart from what has already been mentioned I would make sure you have the "Use as Teleworker Phone" Checkbox clicked in the particular ephone under users and extensions.

[JOHN THIEN]

I don't actually have that box checked.  The remote phones were setup w/ the Wizard, and that didn't check the box.  So I left it unchecked.

I will place checkmarks in that box for remote phones.  But can someone tell me what that does?

[jlesa2457]

enables MTP resources for the remote phones. It tells you right next to where you check it.

that's how I knew.

:-)

HTH

[trgood]

As Joseph said, it enables MTP.  This forces all calls to hairpin the RTP stream through the UC500 rather than directly connecting to the remote caller.  I've seen it resolve one way audio issues in the past.  Its recommended to be checked for remote phones anways. 

[JOHN THIEN]

Okay, thanks.

For the record, this isn't the classic one-way audio where only one party can hear, so the call cannot even really begin.  In this case, both parties can hear each other for most of the conversation, but there is a momentary drop-out in one direction lasting just 15 or so seconds.

Nonetheless, I'm hoping the two changes I made this morning (enabling DTLS and setting the Teleworker option on the remote phones) clears-up the problem.

[Brian Rapier]

Did you get this figured out?  I ran into the same issue you are having.  The solution for me was to put a QOS policy on the incoming side that limited http bandwidth.

What was happening to our users was when they were on a call, if anyone started browsing youtube or some other time wasting site it would bury the incoming bandwidth and knock incoming voice out.  Of course when you are talking to the user they "Are not downloading or streaming anything".  It just happened that I was over at the location one day trying to sort it out that we found the problem, as one of the users were watching a "training" video on youtube when the call started acting up.

Outgoing voice was never an issue as the QOS setup made sure the outgoing side had priority.

Since I have added the incoming policy I have not had any issues with losing incoming audio.

[JOHN THIEN]

Hi Brian.  It is better, just still not as good as I've accomplished w/ Asterisk and ESI systems.

The problem is, this particular client has had issues w/ his Internet at his remote site, making the problems a bit more complex.

May I ask, how do you set a policy for bandwidth allocation for incoming http?

[Brian Rapier]

I have cisco routers at every location, so I setup the QOS policy on the routers using the CCP.