STUN configuration method and two identical records in Phones

[Leo_B]

Hello everyone,

Currently experience the weird glitch in 3CX: I try to register Yealink T58A remotely (Direct SIP/STUN method), and as auto provision completes, 3CX reports the extension assigned to be online, while the SIP phone itself displays 'No Service' status and Phones section lists two totally identical records sharing the same MAC address.

To say frankly, I'm puzzled. Could someone advise me how to fix the glitch described above?

3CX Version: Enterprise Annual 16.0.1078
Server OS: Debian 9 v16.0.655
Is the 3CX Server Hosted: no
IP Phone Make/Model/Firmware: Yealink T58A v58.85.0.5
Provisioning Method: SBC
Trunk Provider: Vitelity
Has the Firewall Checker passed: YES
Are custom Phone Templates being used: NO

 

[cobaltit]

This isn't a glitch. This is what it looks like when you have a STUN phone behind a firewall that doesn't play nice. Did you setup the port forwarding on the phone side? Is SIP ALG off? Your info says provisioning method 'SBC" but you say the phone is direct SIP/STUN. A SBC would also resolve the issue.

 

[Leo_B]

This isn't a glitch. This is what it looks like when you have a STUN phone behind a firewall that doesn't play nice. Did you setup the port forwarding on the phone side? Is SIP ALG off? Your info says provisioning method 'SBC" but you say the phone is direct SIP/STUN. A SBC would also resolve the issue.

Thank you for response! Most of the phones are supposed to stay behind the SBC, but three ones should be deployed outside the office. The problem is that I've set up the first 'external' extension successfully, but failed to complete provisioning for the second one, The phone definitely pulls up configuration from the server (admin password changed, custom background etc etc), but still fails to register properly despite the following log record:

RPS request for Yealink T58 IP Phone of XXYYZZ (151) delivered successfully
3CX Phone System Management Console ID: 10018 02/17/2021 1:46:58 PM

 

[cobaltit]

Provisioning and registration are two separate things. Provisioning is simply the device pulling the config via HTTPS which pretty much any firewall can handle without issue. Registration then takes that information and the device tries to register via SIP which is less tolerant of bad firewalls. Are both of those devices behind the same firewall?

 

[Leo_B]

Provisioning and registration are two separate things. Provisioning is simply the device pulling the config via HTTPS which pretty much any firewall can handle without issue. Registration then takes that information and the device tries to register via SIP which is less tolerant of bad firewalls. Are both of those devices behind the same firewall?

Yes, they are. Oddly enough, when I put the 'problem' phone behind the SBC (i.e. different firewall), the one registered extension seamlessly with STUN method enabled. So it looks I have to figure out the 'bottleneck' in the firewall the phones were located behind originally.

 

[cobaltit]

3CX Intermediate Training: 4. Remote IP Phone Extensions (STUN & SBC)

Slide 7. You are supposed to have unique SIP and RTP port ranges per phone behind the same NAT device. They also should be port forwarding to those devices.

 

[Leo_B]

Thanks, guys! Appreciate your responses, I will definitely consider the clues you kindly provided.