Possible to connect 3CX extension to a router SIP client / ATA?

[PeeBeeEx]

I have an ISP provided Sagecomm gateway, which has a built-in ATA/SIP Client - i.e. You can configure a SIP account which outputs to an RJ11 port on the modem for you to connect an analogue telephone.

This is how the ISP provides the telephone service, so it's definitely working as it should with their config.

I'm wondering if it's possible to reconfigure this built-in ATA/SIP client to work with a 3CX extension so we could use an analogue DECT phone set with 3CX.

Experimenting with the settings, thus far I've found:

• Everything seems to work as it should with the ISP's configuration. Inbound and outbound calls all work fine - I try changing as few settings as possible from this configuration when making my own changes and input the same types of values (e.g Where they put an FQDN, so do I, etc.)
  
  
• No matter what configuration I try for connecting to a 3CX extension, it never connects. It perpetually displays "Registering" on the modem interface; however the Events / Activity Log on the 3CX server doesn't appear to show any connection attempts (viewing from the 3CX Web UI)
  
  
• Strangely, when I try connecting this built-in ATA/SIP Client to another VOIP provider of mine - it connects as expected and inbound calls work fine, but I cannot seem to make any outbound calls. No idea why, it seems to work fine with the ISP's SIP account - I change only the SIP Account details, SIP Registrar and remove all proxy's, nothing else.

Below are screenshots of what's hopefully all of the relevant voice config options within the router:



In an attempt to connect to a 3CX extension, from the working ISP config I've modified only the "Voice -- SIP configuration" page and essentially tried every combination I can think of that would make sense:

- Local IP address of the 3CX server - 192.168.0.30
- Public IP address of the 3CX server - 123.456.789.123
- Public FQDN of the 3CX server - example.3cx.com.au
- Extension @ Local IP - [email protected]
- Extension @ Public IP - [email protected]
- Extension @ FQDN - [email protected]

SIP Port of the server has been set to 5070, so I'm always using this in the SIP config. Have experimented with other random ports (5060, 5090, Random) with no luck.

The fact that the 3CX server doesn't appear to show anything in it's Events / Activity log, leads me to believe the SIP Client isn't even making it to the 3CX server to try and establish a connection.

Thought the issue may have been on the Global Paramters page with Bound Interface Name, changed this from ptm0.1 to LAN, thinking this might make the SIP client try searching the LAN for the SIP connection rather than internet, but this didn't seem to work either:



Any thoughts/ideas much appreciated. Will continue with my own investigation a little more, but I'm personally nearing the end of my own capabilities.

--------------------

A few side notes:

I've managed to connect Zoiper softphone to a 3CX extension using:

username: [email protected]:5070
password: <3CX-AUTH-PASS>
Hostname: 192.168.0.30:5070
OPTIONAL
AuthUsername: <3CX-AUTH-ID>

The Zoiper softphone wouldn't receive any audio though, but at least it connected.

I've also tried enabling these features on the 3CX server:

Settings > Phone / Client Options > Firmware settings > Allow alternative firmwares (i.e. localized/3rd party firmware other default 3CX supported firmware)

Settings > Network Settings > Settings for Direct SIP Calls > 3CX Phone System can make or receive Direct SIP Calls ([email protected]) as well as place Direct SIP calls to other domains. Requires DNS SRV records. Click here for more info.

No idea if they have any relevance nevertheless - made no difference.

 

[PeeBeeEx]

Update: Managed to get the built-in SIP/ATA client working as expected with my other external VOIP provider. Seemed to have been one of the two (or a combination of both):

- Needed to populate all of the proxy settings with the same details as the registrar
- Having an appropriate dial plan given to me (dial plans are beyond me right now)

I'm happy about this, because I was beginning to think that the ISP may have perhaps locked down functionality of the built-in SIP/ATA client in some way via their custom firmware.

This essentially guarantees the ISP hasn't locked down the functionality of the built-in SIP/ATA, so theoretically I should be able to use it with 3CX.

 

[PeeBeeEx]

UPDATE: IT WORKS, IT WORKS!

Could have sworn I tried this combination prior to putting up this thread, either way - hopefully putting up this working solution may help someone in the future if they're trying to configure the same thing.

Seems the major thing I had to do was chang the Global Parameters > Bound Interface Name from ptm0.1 to LAN:



My technical knowledge of things is not quite at this level, but my assumption is having this set to "ptm0.1" means it tries connecting the SIP account via my internet connection (looking at WAN info I see an interface with this name, connected and with my public IP address), so any time I put a local IP address it simply wasn't going to the correct place.

In saying this, not entirely sure why it didn't work when using the FQDN or Public IP address.

Changing this to LAN, presumably, means it now tries connecting the SIP account via my local LAN, so when I'm putting the local IP address now, it can actually get to the PBX.

It also seems like I have to populate all items:

- SIP Proxy
- SIP Outbound Proxy
- Secondary SIP Proxy
- SIP Registrar

With the 3CX local IP address and correct port number in order for everything to work as expected.

Within SIP Account most things are fairly self-explanatory:

Extension = Extension
Display Name = (Think this can be anything really)
Authenciation Name = Authentication ID
Password = Authentication Password

That's about it - apply the settings and after a few seconds the status shows as Up.

Still have some more testing to do, but it seems basic functionality is all working as expected:

- Inbound/outbound calls and audio working
- Can dial external numbers and it works
- Can dial internal extensions and it works
- Can dial 999 and get to voicemail

I'm guessing any functionality beyond this will be a bit hit and miss - it seems if I press the "Call Wait" button on the Analogue phone whilst on a call it puts the other phone on hold, which is nice.

Pressing "Call Fwrd" seems to do nothing and then results in button presses on the analogue phone doing absolutely nothing after - was hoping this would allow for transfers, but it seems this may have more to do with Call Forwarding which can potentially be setup in the advanced settings:



Will explore this stuff a bit more now that it's working and see what does/doesn't work.

 

[leejor]

You are fortunate, that, as an ISP supplied device, it is not "locked down" by them, most are, at least the VoIP portion. When that is the case, ports 5060 and 5061 are usually assigned internally to the FXS ports and cannot be changed/forwarded. Some Voice ports are also, not available for forwarding to the IP, assigned to the 3CX server.

 

[YiannisH_3CX]

Glad to see the issue has been resolved and thank you for posting your finding so far. I am sure this will help other people facing similar issues.

 

[PeeBeeEx]

You are fortunate, that, as an ISP supplied device, it is not "locked down" by them, most are, at least the VoIP portion. When that is the case, ports 5060 and 5061 are usually assigned internally to the FXS ports and cannot be changed/forwarded. Some Voice ports are also, not available for forwarding to the IP, assigned to the 3CX server.

*insert several nasty comments about ISP's here*

I have no idea how they manage to get away with this sort of thing, but this also happens here in Australia. I personally believe if you're paying for a service, you should be entitled to use it however you like.

The ISP does actually lock down the device, they also outright REFUSE to give you the admin credentials or SIP account details. Want to use another modem/router with their connection? No phone for you.

They changed the way the internet service connects recently so you no longer require login credentials, so you can at least use your internet service with a third-party modem. Somewhat useless though, as soon all ISP telephone services will be delivered using SIP.

Thankfully, some absolute champions have provided information on how to extract the necessary passwords from these particular ISP provided devices - which has allowed for slightly more control over my services. Control I really should be entitled to as a paying customer.

As far as certain ports (such as 5060) being locked down, I believe this is the case. Initially I setup 3CX with the default port 5060, only to discover the firewall test always failed and whenever I use an external port checker - 5060 never showed as being open. Changed this to port 5070 and things work fine.

Bit confused that 5060 would show as blocked though, if they were/are delivering the telephone service over it I'd imagine it would have shown as being open. (I've noticed the ISP's SIP account shows port 0 for the SIP Proxy and SIP Registrar, if that makes any difference.)

Anyway, I tend not to get this in-depth with these types of technicalities, it's generally too much effort trying to wrap my head around everything. Typically if something doesn't work I'll just try enabling/disabling port forwarding and try changing port numbers - most of the time this seems to get things working.

Regarding audio ports - 3CX firewall test passes everything. Audio in/out also seems to work fine. So at least for now, everything's looking good.

 

[leejor]

If the device has built-in FXS services, the assumption is that they will most likely be used, and that you probably won't be connecting some other sort of SIP device that needs those port(s). It's easier to just permanently forward 5060 to one, and 5061 to the other, and not allow someone to "mess things up" by changing that.

My experience with provider supplied modem/router type devices, that include ATA's, is that they are almost always "restricted", in some way. Most being provided by ISPs that also offer VoIP services. It is quite clear that they have no intention of "lending" you a device, and then have you use it to connect to a voice service, that they are not supplying, which is really not unreasonable.

 

[PeeBeeEx]

If the device has built-in FXS services, the assumption is that they will most likely be used, and that you probably won't be connecting some other sort of SIP device that needs those port(s). It's easier to just permanently forward 5060 to one, and 5061 to the other, and not allow someone to "mess things up" by changing that.

If this is the case, shouldn't I see port 5060 as open when I do an open port check? It seems the ISP may be doing some kind of sorcery, because 5060 seems to always show as being closed/blocked when using online port checker tools.

ISP SIP account to uses port 0 for SIP Proxy / SIP Registrar - so maybe the ISP redirects 5060 to 0? Could this be the reason 5060 shows as blocked?

Might reconfigure the ATA with the ISP SIP account and see if this changes things and suddenly opens up port 5060. My understanding is that unless there's something listening on 5060 as well as the port being opened, it can show up as blocked/closed.

In any case, at least for the PBX - just switching to 5070 seemed to do the trick. As long as it works, I'm a happy chappy.

My experience with provider supplied modem/router type devices, that include ATA's, is that they are almost always "restricted", in some way. Most being provided by ISPs that also offer VoIP services. It is quite clear that they have no intention of "lending" you a device, and then have you use it to connect to a voice service, that they are not supplying, which is really not unreasonable.

The thing is, they don't "lend" you these devices. They're essentially forced upon you as part of your internet/phone service and you actually do take ownership of the devices.

When you don't lock yourself into a 24 month contract, they typically charge you for these modems too.

Personally, I feel if you own the hardware, you should be entitled to use and access and it however you please. I believe there's even consumer laws that somewhat ensure this too, although I'm no solicitor.

I believe it gets so bad with some devices that you can't even use them with other providers, or even other accounts with the same provider - which is pretty ridiculous tbh.

Considering this is pretty much standard practice among ISP's, I'm sure they've probably got something in their T&C's that protects their selfish backsides and allows them to lock down their devices like this - they probably sell them to you stating that the devices have only limited access or something.

Locking their own devices however is something I can reluctantly accept.

What I don't accept, is them refusing to provide you with the credentials to the SIP/Internet services you pay for, so that you can use your own hardware.

Completely understand if they say they won't provide any support for the services whilst they on third-party hardware, but I feel you should still be entitled to use the services you pay for however you like.

 

[leejor]

What I don't accept, is them refusing to provide you with the credentials to the SIP/Internet services you pay for, so that you can use your own hardware.

In most cases, this is an attempt to limit trouble tickets/complaints. They would rather be in control of the "customer experience" from end to end. Security may also play some part.

 

[PeeBeeEx]

In most cases, this is an attempt to limit trouble tickets/complaints. They would rather be in control of the "customer experience" from end to end. Security may also play some part.

Provide a device that's locked down which you can control via TR-069 and simplify everything for most of your consumers, sure - I understand and agree with that, it's very efficient and works perfectly for the majority of consumers out there who simply want plug-n-play.

At the same time though, if the consumer pays for and owns that device, they should be entitled to the admin account and use it however they please if they request it.

And without a doubt, the customer should be entitled to request the details of the accounts/services they pay for and use them how they please - within T&C's of course.

In terms of support - "if you're not using our supplied gateway, we will not provide support".

Personally I think it's just a case of the ISP serving themselves more than their customers.

I sincerely hope something eventually happens that forces them to present their customers with the details of their accounts and devices if they request them. I'm just happy that at least for now, I can get this information myself.