Backup restore on V20 trial from V18 - No FQDN/License Key - User's mobile apps are still "registered".

[GeekSqueak]

I have been testing the V20 upgrade from V18. I took a recent V18 backup, 1 or 2 days prior, and restored it to a V20 trial instance ( I did not include the FQDN or License key in the V18 backup). The trial V20 instance has a different FQDN and license key from our V18 instance. The V20 instance is on a completely different network with a different internet provider. I noticed a peculiar behavior when I started testing functions. I sent a test chat message to a user. Some how the user received the message on their mobile app that was currently registered with the V18 instance. I was also able to place a call to the same user and they received the call through their mobile app(currently registered with the V18 instance). When they picked it up it just disconnected the call. It seems the restored user still had a one way "session" open to the mobile app. The chat showed up in the notifications on the phone but was missing from the chat window in the 3cx mobile app. It seems kind of like a ghost message/call. I restarted all the services along with the OS. This did not kill the one way "session". I had to reset the password on the user to kill the "session". I'm sure this is a special circumstance but it was a bit alarming when I accidentally messaged a user that was in our production environment. I'm also worried that this may be exploitable on some level.

 

[GeekSqueak]

I believe I used an older backup of V18 and these "Seesions" were closed. I don't have the specific timeline on how old the backup was.

 

[GeekSqueak]

The users tested had a mix of Iphone and Android mobile apps. The chats did not show up in any of the other applications, Web client, Windows app, PWA, or Windows Desktop app.

 

[SweetAction]

It sounds like a push "issue"

The v20 PBX has the "push" info (subscription/keys) from v18 PBX in it and it's valid. So push message show up, but nothing in the app because it can't actually register against the v18 PBX (due to FQDN having a different IP that it resolves to)

I'd say this is not a bug exactly, but it certainly should be noted somewhere.