Call quality appears worse after UC 560 upgrade to Software Pack 8.1.0

[lawrence.david]

To all,

After updating the SA540 to its latest firmware and installing the 8.1.0 software pack this weekend on our UC560, our call quality has gotten worse.

When talking to the Small Business Support Center I needed to pick up the phone to get them to be able to understand me.  The speaker phone was sufficient in the past before the updates.  Both outbound and inbound call quality appears to have deteriorated. In some cases the sound seems to woosh growing from not being able to hear the caller and increasing to a normal level.  There are drop outs during conversation in both directions.  Not really any static, just variations in the sound level or a distortion that sounds like a short burst of reverb.

We are using AT&T SIP Trunks.  I experienced the same difficulty with a customer that stated they were calling from a land line.  They also stated they were disconnected on their first attempt to call us after they were ringing my extension.

Is there anyone else having similar issues with a UC560 and the latest software pack?

Dave

[David Trad]

Hi Dave,

Have you tried locking the system in on a particular Codec for your SIP trunk?

Try and lock it in as G.729 first and then try G.711 and see if there is any difference in the call quality.

It is just a thought, but as part of the fault finding procedures I use this is normally the first one I try when fault finding a SIP trunk.

Cheers,

David.

[lawrence.david]

David,

I really appreciate you taking the time to respond.  During a prior session when I was on the older software packs, Cisco Support set the codec choices as follows:

voice class codec 1

  codec preference 1 g711ulaw

  codec preference 2 g729r8

(Note: I'm assuming this is the setting you were suggesting I experiment with).

I tried changing it to just one and then the phone system stopped routing inbound and outbound calls.  At first, all of them, then some would go through and other would disconnect as soon as they connected.  I tried using g729r8 first, then just g711ulaw by itself.  Then I tried reversing the order above.  All were intermittent until about 5 minutes after I returned it to the above setting.

There is a Cisco document from 2009 for AT&T IP Flex Reach Trunks that suggests the following:

voice class codec 729

  codec preference 1 g729r8

  codec preference 2 g729br8

  codec preference 3 g711ulaw

When I tried that, I got a warning message about g729br8 not support VAD negotiation, so I backed those settings out and went back to the originakl setting.

Any other thoughts?  Am I not waiting long enough for the system to stabilize?  Is there a process I should be following other than just editing the running config and then performing wr mem?

Dave

[David Trad]

Hi Dave,

You are correct about the voice-class, it was i guess a way to test or diagnose the issue, the standard config I use on all SIP trunk configs is as follows:

voice class codec 1

codec preference 1 g729br8

codec preference 2 g729r8

codec preference 3 g711ulaw

codec preference 4 g711alaw

But CCA should auto create this anyway so there is no need to CLI this

What concerns me is that AT&T did not negotiate the Codec every time, normally the SBC would see that only one Codec is being presented and then use that one unless AT&T force or prefer only one Codec unless your account has special configuration on it.

Do not worry about the VAD warning issue, that is typical and will not cause any problems many ITSP's support this particular Codec and you will see this NOTICE come up all the time, it is not an ERROR as such.

Chance the Voice Class to above and see how you go...

Cheers,

David.

[lawrence.david]

David,

I'll try the codec reconfiguration of the UC560 tomorrow.  I agree, it should get setup automatically by the SIP Trunk configuration.  I'll try to remove the SIP trunk configuration and then reconfigure it and see how CCA does the voice codec configuration from scratch.

I don't think I mentioned that this UC560 is behind an SA540.  Perhaps that is impacting the quality?

Dave

P.S.  I updated the subject in my messages in this thread to reflect this is the 8.1.0 software pack, not 8.0.1

[David Trad · Accepted solution]

Hi Dave,

I don't think I mentioned that this UC560 is behind an SA540.  Perhaps that is impacting the quality?

I don't know much about the SA540 appliances, I have only just started to look at the SRP range, there are so many appliances now to try and get my head around i am wondering if I should even bother.

I would check and make sure that the SA540 is not interfering with the Voice Traffic, it is not entirely impossible that this would be happening especially if you have any form of firewall (SPI or otherwise) enabled on it, maybe even consider port forwarding SIP-5060 and RTP 100000 onwards to the UC just as a test maybe??

Let me know how you go

Cheers,

David.

(PS) If you are using uLaw/aLaw do you have enough bandwidth for them on your link? This can cause voice issues as well so many look at G.729 and make sure the carrier can lock it in at their end to that Codec as well.

[lawrence.david]

Dave,

I worked with Cisco Support for almost 4 hours this morning.  As you and others suggested, they also recommended moving the UC to connect directly to the SIP Trunk provider’s (AT&T IP FLEX REACH) subnet.  We first moved the SA to another IP address in the WAN subnet, so we could reuse the current address for the UC.

We left the UC LAN port connected to the SA LAN via a trunk port, but we connected the WAN port directly to the SIP provider.  We configured the port for the SIP provider and enabled the firewall and NAT.  We took more time identifying cables and getting them plugged into the right ports then reprogramming the UC. 

Call quality improved after we did that, but we weren’t completely out of the woods.   As you therorized, there were still some residual issues related to codecs.  The support tech tried to adjust them via CLI, but after a few attempts that didn’t improve the situation, he agreed to let me disable the SIP trunk provider and then re-enable it through CCA.  That also required the DIDs on the inbound dial plan to be reentered.  With that done, the system stabilized within 5 minutes and calls were routing correctly.

At that point we made a few test calls and thought we were done.  We started our staff meeting late, then tried another test call after the meeting and found that random calls were not being completed.  From a land line they simply hung up.  From a wireless phone, the caller hears a “this number has been disconnected or is not in service message” about half the time.  So, we went back to Cisco support.

It took about an hour of troubleshooting until the next support person disabled the access group for incoming calls.  Then every call went through.  Somehow the UC was blocking some incoming calls.  About 20 minutes to get to an engineer at AT&T and we found two addresses missing from the SIP configuration for permitted access.  Once they were added all calls came in.

We had already noticed that our BACD was no longer working after the upgrade.  There was a fraud detection access rule blocking access to the pilot number from the AA script.  We use a custom AA script and the best guess is that the CCA developers didn’t expect the AA script to be configured from CUE.  We do that to get an optional “you’ve reached us after hours” message that works with holidays and the business hours script.  The CUE custom script also allows the dial-by-name feature to support dial by first name instead of just dial by last name.

After removing the translation rule blocking 3-digit dialing requests from the custom AA script, we were able to access the BACD using its pilot number.

The configuration change has allowed using the SA in auto rollover instead of load balancing with its protocol bindings.  This should also allow us to use the remote phone VPN setup wizard in CCA to configure an SPA525G or SPA525G2 to be used as a remote extension.  One big gain is that bringing down the SA no longer interrupts our phone calls.  So other than the time we lost getting this figured out (or having the experts figure it out), we seem to be in a better place.

Dave

[David Trad]

Hi Dave,

Firstly let me just say WOAH!!!!!

The good thing is that the issue is resolved, and that support did their job in assisting you in resolving this issue.

Now the thing that disappoints me the most is that CCA is still putting excess information in places where it may not be required, i find it disturbing that it creates ACL's based on assumptions instead of asking the question during the configuration possess (But I will stand corrected on this if indeed it does ask this information), I think this process really needs to be checked instead of relying on the end user to make the changes at the end, at which point unless a reminder is provided the user will most likely forget.

However I point out that having ACL's in place to protect the appliance from Toll Fraud is an ABSOLUTE ESSENTIAL requirement, the amount of UC-500 I have seen compromised because a SIP trunk has been configured on it, till this date amazes me, and it is good that this is thought out with CCA where as the old CLI days protection was either not right or not done.

All-in-All you are back on track, this is great news and I hope everything remains smooth for you and you get enjoy the system

***Will drink a coffee now re-reading your post over an over again working out where the process failed***

Cheers,

David.