IP Communicator over AT&T UVerse through Cisco ASA: UCCX Application Issue

[James Carlson]

Hello! We have several UCCX Agents working from home. They use the Cisco IP Communicator SoftPhone v8.6.6.1 for their phone and connect to our HQ via VPN / Cisco ASA.

There are 4 work from home employees who cannot establish a call with extensions associated with UCCX Applications. For example, if they dial the 4-digit extension of the CTI Route Point associated with the UCCX Application, the call rings and then picks up with a busy signal and drops the call.

Calling from IP Communicator Phone -to- IP Communicator Phone works fine.

Calling from IP Communicator Phone -to- 8845 Phone works fine.

Calling from IP Communicator Phone -to- an external number works fine.

Receiving calls to their IP Communicator Phone works fine.

It's only when they call an extension associated with a UCCX Application that it fails. And it fails on every UCCX Application that they call, not just one or two.

I've eliminated the phone configuration, the Call Manager config, the UCCX config and the Zoom Call Recording settings as potential causes.

We have over 50 WFH users who using IP Communicator Phone and able to call the UCCX Applications without any issues.

In working with TAC, they recommended disabling the SIP-ALG on the ASA:

Ironically, a SIP ALG can end up interfering with traffic headed for your phone. A SIP ALG can re-write SIP packet headings, which can mangle the delivery process. This can make the device you're calling believe that your phone is not behind a NAT, when in fact it is. If an ALG disrupts a call, it can lead to incoming call failure, and phones that unregister themselves.

The SIP ALG is not fatal in and of itself. There are times when SIP ALGs won't cause problems. However, in many cases, they are the cause of dropped calls. SIP ALGs are usually enabled by default.

I had our Network Admin disable the SIP-ALG on the ASA but it didn't make a difference.

The only consistent variable that I've found in the configuration of these 4 users is that they are all using AT&T for their home internet.

Has anyone experienced an issue like this before? Any input is greatly appreciated.

Thanks!

[Roger Kallberg]

Call failure at answer is for the most caused by a codec mismatch and no transcoder resource available to be invoked for the call. I would check that the codec setup between the calling device and your contact centre service is always G711, as not having that is the most common cause of this type of problem.

[james.buchanan1]

It might also be worth checking to make sure IP Communicator isn't configured to use Low Bandwidth mode. This can interfere with UCCX calls (and only UCCX calls). Since UCCX only speaks one codec (as noted above), that's why it's important to check this and to check the Region settings in CUCM.

[Nithin Eluvathingal]

Codec would be the first thing  which I check for the above issue. If your contact centre and your calling device use different codec then you need to have a transcoder to handle this call or  Use the same codec ( most preferred for UCCX is g711).