Can't get client configured...

[rshores]

I've got a new install that we're working on implementing for a client, and we got two Windows clients connected, but now we're getting errors.

We stood the system up in our office (not the client's) and got the phones (GXP-2160's) provisioned with no major issues. Had to dig up templates from GS, but no biggie.

Moved the server and phones to the client's office, and had to change lots and lots of IP addresses all over the server, then reprogram and reprovision each phone. Lesson learned.

Our first soft user worked out fine - sent him welcome email, he opened the provisioning file, he's up and running.

Another user tried the same steps, and it connects for a second, then disconnects. Looking at the "3CXforWindows.log" file, it appears that there's a quick hit (registration?) on the internal IP address, followed by trying to hit external names for the 3CX server. If it's able to register, why is it rolling to the external address - and then eventually failing out?

I've got over 61000 lines of log files, just figured I'd throw this out and see if anybody can help - let me know if I need to post some more of it.

Thx!

[27.10.2014 15:41:02.906][18] 15:41:02.906    pjsua_acc.c  ...."First Last"<sip:120@##.###.###.##:5060>: registration success, status=200 (OK), will re-register in 120 seconds

[27.10.2014 15:41:02.906][18] 15:41:02.906    pjsua_acc.c  ....Keep-alive timer started for acc 0, destination:192.168.0.16:5060, interval:15s

[27.10.2014 15:41:02.906][18] 15:41:02.906 PjsuaCallbacks  ....******* ON_REG_STATE2 ********* acc_id 0, status 0, code 200, expiration 120

[27.10.2014 15:41:02.906][18] 15:41:02.906 PjsuaCallbacks  ....******* ON_REG_STATE2  10

[27.10.2014 15:41:04.498][1] Connection failed. Endpoint changed to: https://voip.domainname.com:5001/MyPhone/MPWebService.asmx
[27.10.2014 15:41:04.498][1] LoginToMyPhone() started
[27.10.2014 15:41:04.498][1] Server URI: 'https://voip.domainname.com:5001/MyPhone/MPWebService.asmx'
[27.10.2014 15:41:04.499][1] Created tmp channel = 55899007
[27.10.2014 15:41:04.501][1] LoginToMyPhone() ended
[27.10.2014 15:41:04.505][1] Error event caught, message: Cannot send request: Login
[27.10.2014 15:41:04.505][1] There was no endpoint listening at https://voip.domainname.com:5001/MyPhone/MPWebService.asmx that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.
[27.10.2014 15:41:04.505][1] Myphone server got disconnected, IsExplicitLogoutRequest = False
[27.10.2014 15:41:04.505][1] channel_Disconnected 2
[27.10.2014 15:41:04.505][1] Setting app channel to null, was null
[27.10.2014 15:41:04.505][1] UnsubscribeEventsFromMyPhoneAndCTI()
[27.10.2014 15:41:04.505][1] Setting tmp channel to null, was 55899007
[27.10.2014 15:41:04.505][1] UnsubscribeEventsFromMyPhoneAndCTI() finished
[27.10.2014 15:41:04.505][1] channel_Disconnected 3
[27.10.2014 15:41:04.506][1] IsExplicitLogoutRequest = False
[27.10.2014 15:41:04.517][1] LoginCallback() starts
[27.10.2014 15:41:04.517][1] LoginCallback() channel mismatch: current tmp channel = null, app channel = null, got channel 55899007
[27.10.2014 15:41:06.518][1] Connection failed. Endpoint changed to: http://##.###.###.##:5000/MyPhone/MPWebService.asmx

 

[leejor]

it appears that there's a quick hit (registration?) on the internal IP address, followed by trying to hit external names for the 3CX server. If it's able to register, why is it rolling to the external address - and then eventually failing out?

Where is it getting the Domain Name? Was that used in the previous test set-up? I assume that these sets are local to the 3CX server? Some sets do have a provision for a second (fallover) server address, I'm not certain if that includes the GPX-2160s.

You might want to search for, and purge the Domain Name, from the 3Cx server, if it is not needed, then put it back later on in the one place reserved for it. You might also scan though the config file generated for the set to see where (under what parameter) this name is introduced.

 

[rshores]

Thanks so much for your reply!

I've looked on all of the tabs of all of the sections on the server, but the only places I've found references to the domain name are in the user's email address in individual extensions, and under Settings -> General -> Mail Server, which uses [email protected].

I found the external IP under Settings -> Phone Provisioning -> External & Public IP and Provisioning URL - and it's correct that it's there, right?

Additionally, I backed up the system (using the 3CX backup tool), then searched through the files looking for the domain name, and was only able to find it only in the email addresses registered to the extensions.

I combed through the logs (both Server Activity Log and Server Event Log), and wasn't able to find any entries that matched the time/date stamp on the log I put in above; the only odd entries that jumped out at me were:

[size=85]28-Oct-2014 22:27:14.126	[CM506001]: STUN request to resolve SIP external IP:port mapping is sent to STUN server 198.50.247.220:3478 over Transport 192.168.0.16:5060
28-Oct-2014 22:13:32.234	PBX has dropped a message with 'User-Agent: friendly-scanner' from IP 195.154.222.54 because it is on blocked UAs list
28-Oct-2014 22:07:26.383	[CM506004]: STUN request to STUN server 192.95.0.175:3478 has timed out; used Transport: 192.168.0.16:5060
28-Oct-2014 22:07:23.331	[CM506004]: STUN request to STUN server 192.95.0.175:3478 has timed out; used Transport: 192.168.0.16:5060
28-Oct-2014 22:07:20.308	[CM506004]: STUN request to STUN server 192.95.0.175:3478 has timed out; used Transport: 192.168.0.16:5060
28-Oct-2014 22:07:17.266	[CM506004]: STUN request to STUN server 192.95.0.175:3478 has timed out; used Transport: 192.168.0.16:5060
28-Oct-2014 22:07:14.024	[CM506001]: STUN request to resolve SIP external IP:port mapping is sent to STUN server 198.50.247.220:3478 over Transport 192.168.0.16:5060
28-Oct-2014 21:47:26.327	[CM506004]: STUN request to STUN server 192.95.0.175:3478 has timed out; used Transport: 192.168.0.16:5060[/size]

But... the IP resolution I'm getting from pinging the STUN server (stun.3cx.com) is 198.50.247.220 (seen in top entry). Where's the 192.95.x.x address coming from that STUN is trying to access STUN from? That 192.x.x.x certainly isn't our external IP - is that indicating that there's some issue with the 3CX STUN server trying unsuccessfully to look up our external address? That's really confusing me.

Thoughts?

 

[leejor]

Doing a DNS search on that IP doesn't bring up anything, so I'm not certain where it came from. More than one STUN server can be put into the 3CX PBX, as alternatives, so you might want to check in there. I may be wrong, but seem to recall that STUN servers make use of two IPs, so that may be the second one.

Without actually being there to look over everything, it's difficult to see the overall picture of what is going on. The changes you made since the first set-up are not going to help. That said, you sate that one extension provisioned, and worked just fine. What about the remaining, other than this one you are having issues with? Have you tried deleting, then re-creating the "failing" extension. I'm just thinking that if at least one set, functions properly, then what is different, when it comes to the ones failing. If it were a critical "common" mis-configuration, then one would expect the same "faulty" behaviour from every extension that was provisioned.

 

[cooki3monst3r77]

The STUN server is located under \Settings\Network on the STUN Server tab. The little info bubble says to get this information from your VOIP provider.....I'm still trying to figure out this issue, as mine is doing the same thing.

 

[leejor]

You can use any STUN server, one given to you by your provider, and/or one you find while doing a search on the net. As long as it works, they all do the same job. Some do, however, seem to go down from time to time which is probably the reason for providing space for more than one.

 

[rshores]

We finally got this working by deleting and recreating the extension, reprovisioning his handset, and reprovisioning the softset as well.

Additionally, we completely disabled STUN, as all of our users have desktops and only want the soft clients for presence information.

 

[leejor]

Additionally, we completely disabled STUN, as all of our users have desktops and only want the soft clients for presence information.

If all of the devices were being used on the local LAN (same LAN as the 3CX server) then STUN should not have been enabled, that is probably where the public IP was being "picked up". The devices have no need to "know" what sort of NAT they are behind, and that is what a STUN test tells them.