SNOM in STUN Can't call Outside anymore..?

[WellBeIn]

Hello,
big problem since 1 week with 3 customers.
I've been hosting 3CX std's for several years for my customers (about 15)

Monday evening I do a maintenance of the cluster that hosts the VMs (switch from one node to another, etc. classic)

I check that everything is ok, the 3CX are full up to date.

The next day, for 3 customers out of the 15 or so, it was impossible to make calls to the outside world...

by digging I realize that they have the same type of configuration:
- SNOM phone in STUN so no SBC.
- If I install an SBC problem solved .....
- The port openings are ok for the tels
- the FW is ok on the standards, there was no conf change.

In the tel log, it talks about the PBX ip as Dirty host....?? (Nov 29 15:41:23.653 [NOTICE] SIP: Add dirty host: Udp:xxx.xxx.xxx.xxx:5060 (0 sec)

reboot Tel and/or standard, idem, Reset tel without effect, it connects, it provisions, but it does not call.

you can also make calls with the Apps or Browser, only SNOM blocks.

i m loosing my mind.

I forgot, the 3CX are under Debian installed with the official Iso 3CX update in V18 U5, the problem seems to impact only the SNOM without SBC ... (I already had provisioning problems in the past related to LLDP, but now the tels don't connect at all) SNOM are all D715

 

[JohnS_3CX]

- If I install an SBC problem solved .....

Hello,

This is our recommended solution. We created the SBC to solve cases exactly like the one you're facing now because STUN is unreliable if the network conditions get in the way. It's job is to replace STUN with something better, and provide encryption, and better audio management.

If you prefer to use STUN:
You should have unique ports per phone (don't let them all use the same SIP or RTP ports) and forward them on your firewall. Also make sure to disable SIP-ALG which exists on the firewall and modem. If you have already done this and you still have trouble, follow our recommendation and install an SBC to regain reliability and peace of mind.

I would also suggest you read the multiple threads we have on our forum regarding STUN (in Fanvil/Snom/Yealink/Other sections too). This has been discussed a lot of times, and you might find some more useful information there.

 

[WellBeIn]

Thank you for your answer John
Sorry but obviously you didn't read my message carefully.
I specified that the installations concerned have been in service for a long time, and that they respect the 3CX recommendations (firewall, firmware, template...) and the worst thing is that the Yealinks do not pose a problem, on the same site and connected to the same standard.
It is clearly a bug, these installations have worked like this for several years for some.
I can understand that 3CX doesn't want us to do STUN anymore, but in this case it should be clearly stated in all transparency.

yes I prefer the STUN when my customer has only one or two phones, let's be serious, we talk about switchboard on the cloud to limit the constraints and number of equipment on site, this kind of small customer can not understand that we install his switchboard on the cloud, but that he needs a 'box' on site.

finally, I provisioned a brand new SNOM on another site where there is no other phone or SIP-ALG... and the problem is exactly the same.

 

[JohnS_3CX]

Hi @WellBeIn

Sorry but obviously you didn't read my message carefully.

I've read it a couple of times to be honest, I don't think I missed anything obvious

It is clearly a bug, these installations have worked like this for several years for some.

You could be right, but it doesn't explain why mine works or why the Yealinks work:

Conditions tested today

• Snom D715
• Latest 3CX Supported firmware 10.1.84.15
• Provisioning mode: STUN
• PBX Hosted in cloud - V18.0.5.418 Debian
• Using default templates provided by 3CX

Results

• The phone registered successfully
• BLFs lit up, and update correctly as expected during calls
• Audio works fine
• Calls can be made and received
• Rebooted phone, it registered again and works correctly

I can understand that 3CX doesn't want us to do STUN anymore, but in this case it should be clearly stated in all transparency.

We still support STUN, but it's very nature makes it unreliable
So we are always recommending SBC where possible, and brought in a new innovation for Update 6.
Where not possible, you can run STUN but unfortunately you will be subjected to its unreliable nature.
It's not really the fault of STUN, usually it's the firewall and ISP that cause the issues - there are 1000s of ISP/modem/firewall/firmware combos out there, enough to cause chaos for STUN.
We have been hearing the "it worked fine for a long time and suddenly stopped working" complaint for years due to this and are trying to bring you a better solution.

the installations concerned have been in service for a long time, and that they respect the 3CX recommendations (firewall, firmware, template...) and the worst thing is that the Yealinks do not pose a problem, on the same site and connected to the same standard.

You have all the evidence you need that this is not a bug, and no evidence (so far) to support that it is:
- Yealinks work
- SBC worked
- My STUN test worked with an identical phone and PBX


Possible solutions:
1 . You could run captures on the phones and on 3CX to see if the can communicate with each other. Then when you find the first point of failure, correct it and re-iterate.

2.May I also offer an alternative solution? (at least for future installs)
From update 6 onwards, we will have some models that are capable of having a built-in SBC bridge.
This enables you to sell a phone to the customer, not have an extra box at their site, and still enjoy the benefits of SBC.
https://www.3cx.com/blog/releases/v18-update-6-alpha/
I think this will greatly simplify installations where there are only a few phones per site, and should help Partners sell devices that that make their and their customer's life much easier!


Hope this helps!

 

[WellBeIn]

You could be right, but it doesn't explain why mine works or why the Yealinks work:

hum it s exactly what i m asking i have more than 10 identical installation : Same server then datacenter, same version, same network equipements and configuration on customer site, same Internet operator...

I work this way since more than 5 years, can you explain why sudenly i'm wrong without changing nothing ..? no, you don t even try.

Sorry to bother you, I hope someone else will have the curiosity to try to understand.
I've been doing assistance for more than 25 years, I think I know how to direct my research, collect information and make the necessary groupings, you haven't shown me that you do, unfortunately you seem to be more interested in closing tickets than solving them, it's a pity, when I started working with 3CX there was really a great dynamic, constructive. We can only deplore that all this is disappearing

 

[JohnS_3CX]

I work this way since more than 5 years, can you explain why sudenly i'm wrong without changing nothing ..? no, you don t even try.

- We STUN tested a D715
- We provided the suggestions to run captures, and see what happens, if the two sides communicate properly (best test there is)
- We suggested to look at the other threads regarding STUN (because they contain valuable information and troubleshooting techniques you can use if you want to troubleshoot it)

If you prefer someone checks it for you, may I suggest opening a ticket with 3CX Support?
We will be happy to look into it further if you provide some captures and logs to 3CX Support.

 

[JosIPVG]

As far as i can tell from googling around a bit is that the Dirty Host means that the phone cant connect to the Host, who the host is in this case i cant really tell.

this means that, when a phone was unable to reach a host, the phone will not try to reach this host again until the time specified in this field has elapsed.
If this setting is 0 or empty, it has no effect (the host is set as "dirty" but only for 0 seconds, which means it will have no effect on future requests)
See also: sip_request_timeout, sip_retry_t1, sip_health_check

 

[WellBeIn]

As far as i can tell from googling around a bit is that the Dirty Host means that the phone cant connect to the Host, who the host is in this case i cant really tell.

this means that, when a phone was unable to reach a host, the phone will not try to reach this host again until the time specified in this field has elapsed.
If this setting is 0 or empty, it has no effect (the host is set as "dirty" but only for 0 seconds, which means it will have no effect on future requests)
See also: sip_request_timeout, sip_retry_t1, sip_health_check

thank you trying to help !!!
i've found this too (i understood that 0 mean for ever, i was wrong i think)

What concerns me is this notion of unreachable host.
I studied the SNOM log (syslog) and the connection is clearly established, the phone correctly provisioned.

As a proof: we can receive calls and we can call another extension...

worse, on the same installation, in the same office; one user has the problem and the other does not...

For another customer I had on the phone yesterday, SNOMs can't call, but a silly Yealink DECT doesn't have the problem.

there may be a clue that I forgot to mention.

When I reset the phones and reprovision them, at the first reboot, they mention an SSL problem or certificate I don't remember.

I remember that in the past there was a problem with this 'security' aspect, a box to check or uncheck for some phones, but I think that's ancient history?

 

[JosIPVG]

When I reset the phones and reprovision them, at the first reboot, they mention an SSL problem or certificate I don't remember.

I know for yealink there is a security option to turn off "only use trusted certificates" i dont know if thats the same for Snom since we dont use them.

Worth investigating.

 

[WellBeIn]

From update 6 onwards, we will have some models that are capable of having a built-in SBC bridge.

Ok,
i have to admit this is the most important progress I've been waiting for ! very great.
it change nothing for my existing customers and you will not prevent me from thinking that the probleme is caused by recent developements, but for new installations / small customers, it's great.