Newbie - Yealink Phones Unable to call

[leroy_hack]

Brand new install. I am evaluating the switch.
I've setup one user 000.
Windows Server running on a hosted VPS with a public IP address. Dhasboard has all green lights

I am having trouble getting yealink phones to make calls.

I have the iphone app client connected and working - make and receive external calls and can call vm.
I have the desktop app client connected and working - make and receive external calls and can call vm.

On the same LAN, I have 2 different Yealnk phones, T42G and T46G,. Each are behaving in the same way.
The phones provision ok - buttons etc. Phone calls ring into the phones - on a bit of delay but they ring.
No audio when I answer AND outgoing calling doesn't connect at all.
Calling external numbers or VM (999) time out. Calls never get to the no-audio stage because the call times-out with a message of "Invite Request No Response":
There are no errors in the dashboard.
I've had several other external voip cloud systems working on this LAN so I am inclined to believe it is not the fortigate firewall that the phones sit behind.
Phones are configured for Direct SIP remote (STUN). Tried PBX delivers audio. No difference.

Maybe I am missing a small step that makes the phones different from the apps?
Any ideas? Thank you.

 

[Evolute IT]

Brand new install. I am evaluating the switch.
I've setup one user 000.
Windows Server running on a hosted VPS with a public IP address. Dhasboard has all green lights

I am having trouble getting yealink phones to make calls.

I have the iphone app client connected and working - make and receive external calls and can call vm.
I have the desktop app client connected and working - make and receive external calls and can call vm.

On the same LAN, I have 2 different Yealnk phones, T42G and T46G,. Each are behaving in the same way.
The phones provision ok - buttons etc. Phone calls ring into the phones - on a bit of delay but they ring.
No audio when I answer AND outgoing calling doesn't connect at all.
Calling external numbers or VM (999) time out. Calls never get to the no-audio stage because the call times-out with a message of "Invite Request No Response":
There are no errors in the dashboard.
I've had several other external voip cloud systems working on this LAN so I am inclined to believe it is not the fortigate firewall that the phones sit behind.
Phones are configured for Direct SIP remote (STUN). Tried PBX delivers audio. No difference.

Maybe I am missing a small step that makes the phones different from the apps?
Any ideas? Thank you.

1. Make sure you set different SIP Port and RTP range for each phone since they are in the same network.
2. Also, set port forwarding of those ports to the IP addresses of the respective phones.
3. PBX Delivers Audio enabled.
4. SIP ALG must be disabled in the Fortigate.
5. For the last one, check your outbound rules.

For #1 to #4, use the SBC. So much easier.

 

[leroy_hack]

If I am reading your suggestions correctly, in a real deployment, it is necessary to have static LAN IP addresses for each phone (or reserved DHCP) and configure the firewall to route the traffic individually for each phone. OR add a SBC server unit to each remote site.

 

[Evolute IT]

If I am reading your suggestions correctly, in a real deployment, it is necessary to have static LAN IP addresses for each phone (or reserved DHCP) and configure the firewall to route the traffic individually for each phone. OR add a SBC server unit to each remote site.

Yes, because you want to prevent audio issues and NAT in firewalls is a issue-creator.

OR use an SBC which doesn't require any of this and can be managed from the 3CX Console.

STUN deployment is good for 1-3 phones maximum, but no one will really recommend unless it's for 1 remote worker phone.

 

[leroy_hack]

If you don't mind a related question - how do cloud UCaaS providers do remote phones without a SBC and how does it differ from what the 3CX switch is doing? Almost all of the hosted pbx I have ever worked with didn't need SBC/static routing.

 

[Evolute IT]

If you don't mind a related question - how do cloud UCaaS providers do remote phones without a SBC and how does it differ from what the 3CX switch is doing? Almost all of the hosted pbx I have ever worked with didn't need SBC/static routing.

Because some of them either use a Cloud SBC or a proxy. Some also uses rport instead of STUN. However, this is how 3CX works.

 

[leejor]

I do recall seeing posts regarding the installation of an SBC (not the 3CX SBC) , at the server end. Many cloud providers are probably not going to divulge how their offering actually functions.

 

[leroy_hack]

That's interesting. I will have to do some research. Thanks for the answers

 

[AWS2P]

in a real deployment,

even a pbx test is real case of use , so if you want it to work fine you need to set 3CX as it should to avoid problems.

 

[leejor]

Here is a discussion regarding SBCs NOT located at the remote site. There should be several more on the 3CX forum as it has come up a few times.

https://www.3cx.com/community/threa...to-allow-provisioning-of-legacy-phones.48018/

 

[JohnS_3CX]

Hi Leroy

The reason the phones did not work was because the traffic could not go through. If it went through, you would have audio. The delay in ringing is also telling.

Remote STUN phones need to fend for themselves and try to reach the registrar and media server as best as they can given the conditions they come across. Most implementations will not have things like uPnP to open ports, or tunnelling software to reach their private net. Some have onboard VPN capabilities to avoid these problems but its a hit and miss in general if you rely on STUN. Not because it's bad, but because there are factors that the phone (and often the admin) cannot control.

The 3CX SBC was designed to take care of that, but acting as a proxy and multicast forwarder to the phones, enabling you to speak locally, but reach the PBX remotely via our proprietary encrypted tunnel.

Another option is to setup a VPN between the PBX and the phones site, so that they can appear as local phones and have the VPN take care of traffic for you without messing with the firewall.

The question is, what are your specific needs? The solution depends what you need.