VoIP provider can not register when STUN is removed

[terrylai]

Hi all,

This might be a very staight forward question to many, but I have spent some time trying to revole it, without success.

The issue I'm trying to resolve is illustrated below in 2 step:

1. When STUN is set in General Settings as stun.3cx.com. etc, etc, by default.
= Firewall test shows error (4) on all open ports
= Voip register with provider with no problem
= Call quality is very poor, can not hear a single word (using a 1500k/256k DSL line), I thought this might be a firewall problem.

2. When STUN is removed by only removing stun.3cx.com/stun2.3cx.com from the boxes, the ports number I still left there (port 3471???).
= Firewall test passed with no problems......only info (9) message saying ports are open and can make calls.
= PROBLEM is voip lines can nolonger register with provider.

Has anyone come across this problem, you help is much appreciated.

Thanks, Terry

 

[asfuture]

= Call quality is very poor, can not hear a single word (using a 1500k/256k DSL line), I thought this might be a firewall problem.

he Terry
i think that the quality is not depended from stun.
i thought that the STUN is using to enables a device to find out its public IP address and the type of NAT service its sitting behind

 

[N_G]

STUN has no bearing at all on VOIP quality. To improve quality you can remove the option 'PBX delivers audio'

WIthout stun registering wont work at all. Thats to be expected

 

[Andy Schmidt]

STUN removal prevent Trunk Provider Registration

Hi,

my 3CX server is on a public IP and does NOT use NAT. Consequently, I had "disabled" STUN in the "General Settings" (trying to keep it simple and eliminate unneeded services).

Apparently, that "General Setting" option should really be removed until someone tests 3CX and fixes the various problems that occur when you DO turn STUN off.

I have the SAME problem as the person who started the thread:

I had ONE VOIP trunk provider who didn't require registration (IP address based authentication) and they worked fine.

I configured a second VOIP trunk provider and couldn't get the to work for days. They DO require inbound/outbound registration. There was NOTHING in the logs even when you press "Register this line". Only after I read this thread, went back into General settings and put stun.3cx.com back in - did the line suddenly register!

So - my conclusion: General Settings - Remove STUN - is REALLY not a functional! SOME STUN server appears to be required by 3cx!

 

[asfuture]

all right. now we are wiser.... maybe in v6 is this problem fixed. i did also a test with a sip trunk from RPiority Telecom (NL) and we had the same problem.

 

[Andy Schmidt]

Through trial and error I found that you CAN specify the PROVIDER's IP address in the "Specify IP" option if you don't use STUN.

Of course THAT is outright rediculous.

a) you don't want to hard code any IPs - it should be DNS resolved.

b) I ALREADY specified the provider's registration server a little further up on the SAME configuration screen - so why would I need to manually resolve that to an IP and then type it again into the "specify IP field".

The entire "NO STUN" function clearly has never undergone any kind of testing because I uncover new things in various parts of the system.

 

[archie]

Actually, if you're sepcifying IP in registration settings of VoIP provider - you should specify YOUR IP, not provider's one.

 

[Andy Schmidt]

Nick:

WIthout stun registering wont work at all. Thats to be expected

WHY is that to be expected? My provider doesn't need STUN and my 3CX is on a public IP, no NAT. There is absolutely NOTHING for "STUN" to discover. Both sides (mine and provider) have fully resolvable FQDNs that point to public IPs - can't get any easier than that.

Why would I need to introduce a THIRD party to the equation (stun.3cx.com) which now has the power/ability to BRING DOWN my ability to place/receive phone calls if some construction worker with a backhoe digs up the phone line or fibre cable somewhere in the street whereever you host stun.3cx.com!?

This is a HUGE unwanted point of failure over which I have no control and that I do NOT want!

 

[Andy Schmidt]

Actually, if you're sepcifying IP in registration settings of VoIP provider - you should specify YOUR IP, not provider's one.

Maybe I should, but THAT doesn't WORK.

I just WENT through all 4 options:

a) leave as "external IP" -> no registraton is attempted in the logs.
b) set to "internal IP" -> no regstiration is attempted in the logs.
c) specify MY IP -> your input screen displays a garbled error screen (it closes the registration section, opens the "CODEC" section) and then displays some cryptic sentence in a pop-up (screen shot attached)
d) specify the PROVIDER's IP -> THAT is the ONLY combination that actually DOES work and register the line (whether you feel that it should or not!)

I very much appreciate the interest you are taking in this. As your answer shows, it's time for someone at 3CX to really test this entire subject - clearly nothing works as intended...

 

[archie]

Yes, I've tried to enter IP in that field and it really looks weird in web interface, but IP (I suppose your IP is 63.xx.xx.130) is saved OK.
I've just written bug report in this regards.
Thanks for cooperation.

 

[Andy Schmidt]

Hi Archie,

sorry - but NO. 63.107.174.130 is NOT saved. After the POPUP I have to click OK for it to go away. If I check the registration settings it now shows my input in RED (see screen shot). If I click OK to get out of that screen, the whole popup window comes back and it all starts over.

If I click CANCEL to exit the screen (my only other choice), then it will NOT save the input.

You may have to write up more bugs on that screen :cry:

 

[archie]

You're looking at web interface and we definitely have a problem with it. But I checked database. And in database it is saved correctly.

 

[Andy Schmidt]

Archie:

I certainly do NOT want to annoy you - but allow me point out one detail that might change your opinion:

- I had defined the IP address: 209.40.241.3 (the providers' IP) in that field.
- I then ran the tests for which you see the screen shots - where I tried to change that (as per your instructions) to 63.107.174.130, MY IP. I then got the various error screens that I documented.
- I then exited 3CX and if I go back into that SAME configuration screen it shows: 209.40.241.3

So, if it shows the orginal value, it CLEARLY has READ them from SOMEWHERE in your database - and it clearly is NOT reading the new value from that column/row.

 

[archie]

I would recommend you to upgrade to V6. I have repeated your actions in V6 and (beside some bugs in web interface) it works corretly.

 

[Andy Schmidt]

Uh, well that at least explains why you can't possibly reproduce my problems. You are testing in a different version than the customer 8) .

I'm very tempted to install V6 (for the Intercom feature) - but how risky is that for me to do? Usually I wait a week or two to see if the early adopters run into any unexpected snags that are fixed by a few subsequent beta builds... (I'm a coward by nature... )