UC520 - Calls dropped when transferred using full consult method

[Derek Thom]

Hello-

This is my second time posting with this issue as it was never originally resolved and no one is answering on my original post.

I have a client with a UC520 that has the latest  software pack installed (8.0.2) and the system fully configured with CCA 2.2.2 as a key system. When they try to transfer a call that has come from an outside line to an internal user using the "full consult" method,the calls will intermittently drop. Through testing, I have gotten the calls to drop consistently by calling on the same outside line and trying to transfer two calls in a row on that same line.

The transfer goes through fine the first  time. If I call right back, go through the same process, the call is  dropped as soon as the receptionist hits transfer or hangs up. All  parties drop to dead air. I have attached a debug vpm and voice ccapi output as suggested on a previous post response.

Switching to full blind transfer method fixes this issue, but this is unaccaptable to the customer.

I really need to get this figured out, so any help would be appreciated.

Thanks!

Derek

[antyeung]

Can you increase the loggin buffer size "logging buffer 10000000" and include the current "show ver/run" output excluding the passwords?

debug voip ccapi inout

debug vpm signal

debug ephone detail mac-address

Where is the mac address of the phone doing the transfer.

Thanks,

Anthony

[Derek Thom]

OK, I have attached the debugs and show run you requested.

I went by the client today to get these debugs and the problem is actually worse now than just disconnecting. Now, when a call is transferred, it locks up the system and all of the phones reboot on their own. At one point the phone I was trying to transfer to said "UCM down features disabled" and showed that it was still on the test call that I placed from my cell phone, even 5 minutes after I disconnected.

Thanks in advance for any help!

Derek

[antyeung]

I sifted through the debugs and this is the call sequence-

1. Incoming call on FXO 0/1/1

2. Rings ephone-dn 2 on button 3 of ephone 7

3. Ephone 7 answers and presses the transfer softkey

4. Ephone 7 transfers to extension 203 and then goes onhook after it connects

Shortly after the phones unregister. Can you confirm this sequence?

For some reason the phones unregister b/c it looses keepalives-

Aug 30 21:49:27.639: %IPPHONE-6-REG_ALARM: 10: Name=SEP0021A0D97769 Load= SCCP41.8-5-3S Last=TCP-timeout

I'll see if I can reproduce this in my lab.

Thanks,

Anthony

[Derek Thom]

Hi Anthony-

Yes, that looks about right in terms of the sequence. Before it would just drop the call after I tried transferring to the extension twice in a row, now it locks up the system and forces the phone to re register on the first attempt to transfer. No changes were made to the system except for turning on the debugs.

Thanks for your help on this.

Derek

[f.giordano]

Hi Derek,

Did you resolve your issue ?

I'm having the same issue with CME 8.0.

When an ephone is connected and pressed the Transfer softkey, then the call is disconnected and the phone restart immediately.

I tried to update the IOS and change also the platform 2821 and 2851 but issue is still there...

Thanks for your feedback

Fabian

[Derek Thom]

Hi Fabian-

No, I have not reached a resolution to this issue. I haven't heard back from anyone, and I haven't tried anything new as I have exhausted everything I know to do with the system. But, this is something that really needs to be resolved soon. I hesitate to sell the product reassuring customers it will work just as their current phone system does, and have it not do something as simple as transfer a call.

I may wipe and reload the device and set it up again from scratch, but I really don't know how much that will change things as that's how I did it from the beginning.

Derek

[antyeung]

Sorry about the delay guys. Will see if I can reproduce it today. Hang tight

[f.giordano]

Ok we got it !

Issue was not related to CME or Phones firmwares.

The default gateway gateway of the Phones was the Cisco ASA.

When disconnecting the ASA of the network, all the phones were working fine.

After some research we found that the proxy-arp was enabled on the Asa voice interface.

After disabling it, everything's fine.

Don't understand why... but it works

Regards

Fabian

[Derek Thom]

Hmmm not sure if this will fix the issue on mine. I do not have an ASA in this network, just the UC500. So, is there a proxy arp setting I

can check somewhere else?

Anyone else have any further suggestions?

Thanks,

Derek