Upgraded from V15.5 to V16 and lost audio on two DID's

[covtech]

Hello everyone,

Last night I took a snapshot of our 3cx VM and then proceeded to follow posted directions here:

1. Full Configuration Backup (selected all options including audio)
2. Uninstall V15.5
3. Reboot VM
4. Install v16 and select restore from backup
5. Followed the Web GUI wizard to match ports previously used.
6. Began testing

During 6 we tried all lines and our main two numbers that ring to an Auto Attendant would ring though, call log shows routed to the IVR correctly, but there was no audio.
I took and re-routed the DID's to another extension and they had no audio.

Checked the SIP Trunks and codecs and everything was the same as it was in v15.5 except the new web meeting trunk. Rebuilt the DID routing and inbound rules, and still had the issue.

Reverted to v15.5 snapshot and confirmed all settings, stayed on v15.5 as it was functional.

Would like to retry, but need some direction as this makes no sense to us.

 

[AWS2P]

Is your trunk provider a 3CX supported one?

Have you done a firewall checker after V16 update ? if so, passes green?
Have you tried a firewall restart?

 

[covtech]

Is your trunk provider a 3CX supported one?

Have you done a firewall checker after V16 update ? if so, passes green?
Have you tried a firewall restart?

Firewall check (Meraki Firewall) comes back with identical results "Full Cone Test Fail" everything else passes green, this is the same on V15.5 also.

Did not reboot the firewall, as nothing port wise or firewall setting changed nor MAC address or VM information, everything except V15.5 to V16 is the same.

 

[cobaltit]

You didn't mention whether its a supported provider, although the same issue can happen with them. Check you port forwards (the RTP range was expanded during v15.5 lifetime) and make sure they include the current range (9000-10999): https://www.3cx.com/docs/manual/firewall-router-configuration/

 

[covtech]

You didn't mention whether its a supported provider, although the same issue can happen with them. Check you port forwards (the RTP range was expanded during v15.5 lifetime) and make sure they include the current range (9000-10999): https://www.3cx.com/docs/manual/firewall-router-configuration/

Excellent callout, We use NexVortex which is not an official supported trunk, but has worked since before V15.5.

Here is the ports we have open:

 

[cobaltit]

Not a NexVortex fan but it's definitely been used with 3CX so we'll ignore that for a sec. Ports look good. I'd check the trunk settings because in v16 they tried to make the trunks 'smarter' with auto discovery. There's a checkbox at the end of the registrar/outbound proxy fields (I'd turn them off if they are on) and then confirm the transport protocol on the 'Options' tab is set to UDP. I'd also check with Nexvortex to see if they have an updated configuration guide for 3CX and then compare your trunk settings.

 

[covtech]

Not a NexVortex fan but it's definitely been used with 3CX so we'll ignore that for a sec. Ports look good. I'd check the trunk settings because in v16 they tried to make the trunks 'smarter' with auto discovery. There's a checkbox at the end of the registrar/outbound proxy fields (I'd turn them off if they are on) and then confirm the transport protocol on the 'Options' tab is set to UDP. I'd also check with Nexvortex to see if they have an updated configuration guide for 3CX and then compare your trunk settings.

I will check with NexVortex, I did confirm Auto-Discovery was off and correct port was used. I also confirmed the Options was UDP not Auto, and IPv6 was disabled.

What bothers me is several DID's work fine with the auto-attendant IVR, just those two DID's do not.

 

[cobaltit]

Hmm.. I'd definitely ping NexVortex then. Different DIDs could have different ULCs or underlying carriers meaning it enters their network differently. You could have a stale registration or something that is routing those calls slightly differently. It's possible their media termination is getting eaten by the Meraki. I'd try to wireshark calls (working and not working) and see what the difference is. If you are not a Wireshark expert then try explaining to them first and see if they can fix it and if not, then wireshark to show them the proof.

 

[covtech]

Hmm.. I'd definitely ping NexVortex then. Different DIDs could have different ULCs or underlying carriers meaning it enters their network differently. You could have a stale registration or something that is routing those calls slightly differently. It's possible their media termination is getting eaten by the Meraki. I'd try to wireshark calls (working and not working) and see what the difference is. If you are not a Wireshark expert then try explaining to them first and see if they can fix it and if not, then wireshark to show them the proof.

Good call, I did wireshark and pcap's showed the call connecting without being eaten. The Call log shows it route to the correct queue and it answers with dead air. No audio is the only symptom.

I will ping NexVortex now.

 

[covtech]

NexVortex guide is based off V15 and they have suggested no changes in their config.

This evening, I will begin at square one, with the restored snapshot that has been in production all day of the 15.5 and go from there.

Once fully installed v16 and restored from config, I plan on taking the v15 guide and checking every setting in it.

If anyone has 3CX v16 and NexVortex or has information they can share on their upgrade process if different than listed in my original post, please chime in. I will reboot the firewall after the server is rebooted for the v16 install as precaution, but without something different being found after the upgrade, I am hesitant to believe it will be successful.

 

[AWS2P]

Do a complete power off /on on firewall if you reboot it to be sure everything start properly

 

[covtech]

Sorry for the delay. We ended up following the guide from NexVortex and had to update the FQDN from IP To Hostname, then had to switch from IP Based to Authenticaion. After these changes the audio began working.

The upgrade of the local instance was pre-emptive on moving the server to AWS. Which is our next move.