Forward to Cell Fails

[mantalope]

I have a Cisco 504g and an extension that has been configured for the past several years to ring for 10 seconds and then forward to a cell phone. This has worked without issue until last week. Now, the handset rings as expected, and the call is forwarded to the cell, as expected, and the cell phone rings. When the user answers the cell phone, the call is dropped immediately. This is only happening for this one extension.

Here'e the server activity for one of the failed calls:

25-Sep-2014 17:22:21.319 Leg L:938.3[Extn] is terminated: Cause: 487 Request Terminated/INVITE from 69.255.179.87:5060
25-Sep-2014 17:22:21.175 L:938.1[Line:10002<<585755XXXX] forwards call from Extn:867 to Out#:>>Rule{11 Digits}>>1703622XXXX based on rule Fwd[Available/NoAnsw]
25-Sep-2014 17:22:21.175 L:938.1[Line:10002<<585755XXXX] failed to reach Extn:867, reason No Answer
25-Sep-2014 17:22:11.154 [CM503025]: Call(C:938): Calling T:Extn:867@[Dev:sip:[email protected]:5060] for L:938.1[Line:10002<<585755XXXX]
25-Sep-2014 17:22:11.100 [CM503027]: Call(C:938): From: Line:10002<<585755XXXX ("WIRELESS CALLER" <sip:[email protected]:5060>) to T:Extn:867@[Dev:sip:[email protected]:5060]

Does anyone have any insight as to why this may be happening?

 

[leejor]

Do the extensions, where this continues to work, use the same wireless provide, outgoing trunks? Have you compared a 3CX log for a working call and this one that fails?

 

[mantalope]

In our tests, a Verizon cell phone called into the system and was forwarded to another Verizon cell phone. Originating call from from NY and the destination was in VA.

I looked at the good/bad logs, and did not notice any difference, but will review again. It appears that the problem occurs when 3CX hands off the call to the two parties (calling and receiving).

The strange thing is that the problem appeared suddenly to an extension that has been working fine for several years. Nothing has changed on our system or on the user's system (to the best ok my knowledge). I contacted our VoIP provider (Windstream) and they pushed the blame back onto our 3CX PBX.

We also have another issue where outside calls coming into 3CX and routed to an external handset are disconnected when the user picks up the handset. Voicemail to that extension works fine and internal calls work fine. This extension has just been reconnected after sitting idle for several months. I don't know that these issues are related to the same problem or not.

 

[leejor]

We also have another issue where outside calls coming into 3CX and routed to an external handset are disconnected when the user picks up the handset.

Many time, when this happens, it's after about 30 seconds, and the 3CX log for the call will show No ACK Received. Even though the call seems to connect, it is dropped after a 30 second (or so) timeout (waiting) period.

The strange thing is that the problem appeared suddenly to an extension that has been working fine for several years. Nothing has changed on our system or on the user's system (to the best ok my knowledge). I contacted our VoIP provider (Windstream) and they pushed the blame back onto our 3CX PBX.

In some cases, even though you don't think anything has changed at your end, it may have. That said, it may also be that your provider that has changed how they handle calls, and unless the person that you spoke with works on the equipment, they may not even be aware of it.

looked at the good/bad logs, and did not notice any difference, but will review again. It appears that the problem occurs when 3CX hands off the call to the two parties (calling and receiving).

The call will still pass through 3CX, so unlike two 3CX extensions "talking" (with NO PBX Delivers Audio option selected), the call is not handed off to the two parties.

You may have to incorporate on something like Wireshark to see the differences between a working and non-working call. that might give you some "ammo" when you go back to your provider.

 

[mantalope]

Thanks for your help on this. I plan to set up a test phone to see if I can duplicate these problems in a more controlled environment.

 

[mantalope]

After setting up a test phone, duplicating the problem, and troubleshooting, I found that disabling NAT and changing the SIP Transport from UDP to TCP on our Cisco SPA 504g handsets solved the problem.

Thanks again for your help.