Dropped calls after upgrade or migration

[seantp]

I'm not sure which happened first. I migrated my system to a new server, but at some point it also upgraded to the latest version.

In any event, calls are ringing the lines once then hanging up. It's happening on direct lines and call queues.

For the extensions I'm seeing ... has failed; Cause: 487 Request Cancelled

and

x-call-control DROP: call is not found: ...

 

[NickD_3CX]

Hi, when you say you migrated the system, from where to where did this migration happen? If public IP of the new system is different than that of the previous, make sure you have set the new Public IP correctly everywhere, including in the SIP Trunk settings where it may be set.

Also, if you have local LAN phones, does it happen also there, or only e.g. for Remote STUN phones and/or incoming calls via your SIP Trunk?

A bit more info may be needed to better understand the circumstances.
Also please state PBX version you are currently running on and if its Windows or Linux.

 

[seantp]

It was from one ubuntu server to a fresh install. No local lan, all remote stun phones.
Pro 16.0.7.1078

The migration was as simple as exporting and reimporting, like I've done each time over the years.

I was a little surprised to see the upgrade to 16, since it had been in beta for so long, but I assume it's out of beta except for messaging.

Firewall checker passed, no issues

 

[NickD_3CX]

I hope you mean Debian and not Ubuntu, because 3CX is only tested and supported on Debian...

Also, V16 has been out of Beta for at least a year and a half:
https://www.3cx.com/blog/change-log/phone-system-change-log/

But the questions still remain:
- From what version did you migrate to what version?
- Did you do so by taking a backup and restoring (that is what I understand)? What versions of 3CX was the backup taken from (including service pack)?
- On what calls does this happen? Extension to Extension? Incoming via SIP Trunk, outgoing, both?

 

[seantp]

Sorry, yes Debian. I used the 3CX iso. I use a lot of ubuntu so that just came out.

I don't remember the exact last version, but it was the latest version of 15x.

That's weird because in the update manager it always showed 16 as an upgrade option but was noted as beta, so I never bothered to pick that upgrade.

So it would have been (I assume) the latest version of 15x backed up and then migrated. Since I used the 3CX CD I guess it had the latest 16x version on it because I don't remember seeing updates available. I only figured it out when I saw the new Messaging feature in the menu.

It happens on all calls, ext to ext and incoming via the trunk. Outgoing calls work just fine.

 

[NickD_3CX]

Ok, first thing I'd suggest running the Firewall Checker again to make sure everything is good there.
Then, as your server is obviously remote as all phones are remote STUN, configure a mobile app against an extension, to isolate possible STUN issues, then make and receive calls via your SIP Trunk using the Mobile App.

If that is also OK then, at least you will have narrowed down the issue to something regarding the STUN IP Phones.
By the way, what make/models are the phones?

 

[seantp]

OK, I'll try testing that.
They are Yealink SIP-T58's

 

[seantp]

Would it have made a difference if the original server was running behind a firewall and the new server is not?

 

[NickD_3CX]

Possibly, yes. So has the public IP changed? Because if so check that the FQDN is also resolving to the new IP.
Also, edit one of your extension, go to the Phone Provisioning tab, and in the drop-down ensure the right IP is being used, then press OK (press OK anyway to re-write the phone config file).

Then make sure you reprovision the phone(s). To ensure that they do actually pull the new settings, I usually make a small change ot the name of one extension and nsure I see the change on the display.

Btw, what happened with the test with the Mobile App?

 

[seantp]

Same behavior with the mobile app. It rings then drops.

The new IP is set in the server correctly and in the extensions is show the correct URL.
The URL is pointing to the correct IP address

I took re-wrote the config file, also regenerated all the options. reconfigured the phone (reset to factory and autoconfigure) and mobile app.

Call in and it's the same thing. On my direct line it will ring twice then go straight to voicemail.

On the queue, it bounces back and forth between members, hardly getting a single ring in so no one has any time to pick up. The only difference in the log now is the domain is present in both, were the loop back was shown before.

12/30/2020 11:58:42 AM - [CM503003]: Call(C:9): Call to <sip:[email protected]:0> has failed; Cause: 487 Request Terminated/INVITE from 127.0.0.1:5080

12/30/2020 11:58:42 AM - [CM503003]: Call(C:9): Call to <sip:[email protected]:0> has failed; Cause: 487 Request Cancelled/INVITE from 47.33.9.198:5065

12/30/2020 11:58:38 AM - x-call-control DROP: call is not found: gRGrireQvu5u6qZG6F4DmA..;from-tag=dc4b5b06;to-tag=7f86c246

12/30/2020 11:58:37 AM - [CM503003]: Call(C:9): Call to <sip:[email protected]:0> has failed; Cause: 487 Request Terminated/INVITE from 127.0.0.1:5483

12/30/2020 11:35:21 AM - x-call-control DROP: call is not found: udaRFQLj5Y_K5Dkkqhbf8Q..;from-tag=155ccf30;to-tag=32c88e41

12/30/2020 11:35:20 AM - [CM503003]: Call(C:5): Call to <sip:[email protected]:0> has failed; Cause: 487 Request Terminated/INVITE from 127.0.0.1:5080

12/30/2020 11:35:38 AM - [CM503003]: Call(C:5): Call to <sip:[email protected]:0> has failed; Cause: 487 Request Terminated/INVITE from 127.0.0.1:5483

12/30/2020 11:13:31 AM - [EC100009]: External application [ucc:0/PbxConfigTool] is disconnected:

12/30/2020 10:51:21 AM - x-call-control DROP: call is not found: DKCi8zXOEPreYe41xlUo7w..;from-tag=f28f7920;to-tag=40ae4951

 

[NickD_3CX]

Ok, so whenever you call your direct line (DID), rings twice and goes straight to VMail. If you do leave a VMail, is it left on your system?
Could it be that you have left your SIP Trunk registered on your "old" PBX as well, and calls are still being sent there?

An easy way to see this is to log into your "new" PBX and go to Dashboard and press on "Number of calls in use". This shows in live what calls are happening on the system and where they are connected.
While here, call your DID again, and once it goes to VMail, check to see if you indeed see the incoming call connected to your VMail.

If that still bears no results, I would start off by starting by making a capture and checking if the call is indeed established between your provider and the "new" PBX.
If it is, then I would move onto enabling Verbose logging, and after the call going to the Activity Log and checking where the call was routed on the "new" PBX, and possibly why, the logs should give you some clue to this.

 

[ivan.antic]

seantp,

What are the results when you resolve domain "mydomain.biz" ?.
It needs to be same IP as you 3CX Server.

Call from provider goes to [email protected]

Try with /etc/hosts

127.0.0.1 mydomain.biz
3CX-SERVER-IP mydomain.biz

 

[seantp]

Yes, DNS A record is correctly pointing to the right server
when I ping the url from terminal it comes back with 127.0.0.1
in the host file it only has the internal loopback ip it does not have the public ip

 

[seantp]

Ok, so whenever you call your direct line (DID), rings twice and goes straight to VMail. If you do leave a VMail, is it left on your system?
Could it be that you have left your SIP Trunk registered on your "old" PBX as well, and calls are still being sent there?

An easy way to see this is to log into your "new" PBX and go to Dashboard and press on "Number of calls in use". This shows in live what calls are happening on the system and where they are connected.
While here, call your DID again, and once it goes to VMail, check to see if you indeed see the incoming call connected to your VMail.

If that still bears no results, I would start off by starting by making a capture and checking if the call is indeed established between your provider and the "new" PBX.
If it is, then I would move onto enabling Verbose logging, and after the call going to the Activity Log and checking where the call was routed on the "new" PBX, and possibly why, the logs should give you some clue to this.

Well its all very weird. I went to test with verbose enabled and its working like normal today. I have no clue, I didn't' touch it.