3CX session boarder control

[JohnMitchell]

Hi All,

I have looked on the forums and have found the answer I need.
I am trying to remotely provision a Snom 320 VoIP phone so it can be used from outside the office.

The phone works well in the office and to be honest I thought once it was provisioned and unticked the disallow use of extension outside of the LAN it would still work but Alas it does not. Block remote tunnel connections is also unblocked.
3CX V14

I have read the instructions and come a blank.
I have the phone at home and I can ping our FQDN 3cx.mycoip.co.nz from home for I know the DNS is correct.
I have installed the 3CX session boarder control software on my home computer.
I have also changed the provisioning code from http to https

When I reboot the phone it trys to provision but I get the following error.

ERR | 20150918-110547.978 | 3CXTunnel | TUNL | 5484 | TunnelTcp.cpp:102 | Failed to resolved DNS SRV record for tunnel connection to 3cx.mycoip.co.nz
ERR | 20150918-110558.060 | 3CXTunnel | TUNL | 5484 | TunnelTcp.cpp:159 | Bridge [3CX SBC] failure 'Too long inactivity' on TCP connection: while processing tunnel connection

I belive this is the key.
Failed to resolved DNS SRV record

I do not have a SRV record. I have hunted high and low and I can not see the settings for me to add them into our external DNS.

I have also tried doing a SRV lookup on the local supplier who uses the A record of 3cx.sofsol.co.nz but have had no luck.

If someone could point me in the right direction that would be amazing.

I have spent too many hours going around in circles.

I dont know if it related but I can not get 3cx phone on my iphone to work outside the office wifi.

Regards
John Mitchell

 

[lneblett]

Perhaps the easiest way for the moment is this:

You did not indicate all the needed info such as how you resolve to the internal 3CX IP. I will assume, for the moment, that when it was provisioned inside the office that it used the internal private IP and not a FQDN.

Now that you are external to the office the phone needs to resolve to the Public IP. Hopefully, you have a static Public IP and can use this in the SIP server field. For a single phone, the SBC is most likely not really needed.

You of course, will need to have the router ports handled at the 3CX side and at the remote site, you will likely want the phone to use keep alives and set the SIP registration to something sooner rather than later.

Also, if you do have a static IP, turn off STUN at 3CX and at the remote Phone. In essence, you are making the 3CX system nothing more than looking like your SIP provider.

Make certain that any SIP ALG settings in any router is disabled.

 

[JohnMitchell]

Thanks for your reply.

Our 3cx pbx was initially a V12.5 and a few days later upgraded to V14.
I then virtulized the PC and have it as a VM on our hyperserver
V14 uses FQDN for internal and external connections
I have the FQDN on our external DNS pointing to our static IP address and I also have a DNS sentry in our server point to our C3x VM

The phone was provisioned by using the internal ( http ) FQDN, I have not tried to provision internally using the https FQDN
you have a static Public IP and can use this in the SIP server field - I had not thought of that, i have changed the internal ip to the FQDN so if the phone comes back in the office it can be used and it still does not connect, says that it needs proxy registration.

The required forward ports are open and I pass the firewall test.
We are using a cyberoam UTM so there may be a formof SIP ALG but we have no issues between the server and our sip provider so I doubt this is the issue but I will look further into this.

I will log in later and have a look at the STUN

I was wanting the BLF to work and looks like we may not be able to doing what you are talking about, I wonder if the SNOM 320 has VPN capability then at least it will appear to be on the local network and BLF will work.

Regards

John

 

[JohnMitchell]

I think I might have sorted it, When i changed the Ip address from local to FQDN I left the :5060.
I have now removed that and I can make a call.

Now to test the BLF

Regards
John

 

[thames]

Hi John

You didn't complete this thread by saying whether the BLF issue was resolved or not.. I have an almost identical situation where I am using SBC on the network in the internal office but I keep on getting the "cannot resolve" in the SBC logs. Phone system is working fine except for the fact that the BLFs are not working at all for the remote extensions.

I know this is an old thread but any help would be super.

Cheers
Chris

 

[ian.watts]

My Cisco BLFs keep having issues keeping subscribed.

The SRV records and the subsequent warnings are not "issues" per se.. looks like it is first trying to use those resource locator records to discover the SIP host. Indeed I added the _3cxtunnel._tcp.<yourdomain> record with 1 1 5090 <your3CXexternalFQDN> and the logs quieted down.

Still haven't had time to trace SIP traffic between SBC and handset to identify where the breakdown might be. I know I can lower the retry and expire values to make the problem "happen faster" at least.

 

[thames]

Hi Ian

I've done that too. Added both _3cxtunnel and _sip SRV records to the domain zone file and now no more errors about not being able to resolve.

Still absolutely nothing from the phones from a BLF point of view - extremely frustrating. However, another thought from me - I'm using two Grandstream GXP2100 phones which are no longer supported according to 3CX. This could well be my problem so I'm going to get out and buy a supported phone over this weekend if I can.

Any ideas about which phone would be the most recommended? I see the Fanvil X5 appears to be a good, low-priced phone but a little wary about quality considering the price.

All the best
Chris

 

[IT Hamster]

Hey John,

The DNS SRV records failing on your SBC is exactly what you think it is. Unfortunately, from what I can tell it would appear that the SBC only looks for SRV records to find your FQDN- it won't attempt to resolve your FQDN using conventional DNS.

To get around this, navigate to your 3CX.config file on your SBC (C:/ProgramData/3CX) and edit the file.

THe line that has your FQDN, put the Public IP of your PBX there instead.

This will allow your SBC to resolve your PBX address without issue.