Patton 4114 FXS not working on v15.5

[CCAdmin]

We recently upgraded from v14 to v15.5 finally.
We are now hosting from Google Cloud vs our hosted COLO facility, so the 3CX is still remote.
All needed ports/firewall/etc are verified properly open.

We were using a Patton 4114 (as FXS ports) to make outbound calls from a modem pool
via the SIP trunks. On v14 it was working just fine. However, on v15.5 I can't get the Patton
to connect to the server?

I created the config off the 3CX server, through the FXS/DECT section.
First thing I noticed is that 3CX is missing an important line in their config file.
I had to add "route 0.0.0.0 0.0.0.0 10.10.8.1" under the 'context ip router' section,
just to get the device to properly ping and see the network. That was a fun trip through
the console port to find and resolve. Pretty major flaw.

However, even after I finally got the device talking on the network (with no other manual
changes other than that "route" line - which is required), it won't properly dial out any of the ports?
I can connect an analog phone to the 4114, get a dial tone, but when I dial a number and send,
I get a busy tone.

I have double/triple checked all the settings and they properly match the extensions tied to each
port on the 4114, but none of them are connecting to the 3CX server.

 

[leejor]

I can connect an analog phone to the 4114, get a dial tone, but when I dial a number and send,
I get a busy tone.

You have dialtone, so either the ATA is registered, or it is set to provide dial tone even if not registered (which is not really a great option to have turned on, as it is misleading). Does 3CX show the extensions as registered? Check the 3CX Activity Log for a registration attempt, and , perhaps failure. You'd know then if the Patton is trying to communicate with 3CX. If it is actually registered, then the log should show the progress of a dialled call, and why it fails.

I assume you've had a read through this and tried re-provisioning.

 

[CCAdmin]

You have dialtone, so either the ATA is registered, or it is set to provide dial tone even if not registered (which is not really a great option to have turned on, as it is misleading). Does 3CX show the extensions as registered? Check the 3CX Activity Log for a registration attempt, and , perhaps failure. You'd know then if the Patton is trying to communicate with 3CX. If it is actually registered, then the log should show the progress of a dialled call, and why it fails.

I assume you've had a read through this and tried re-provisioning.

The device (four extensions) are not showing registered with the 3CX server, no.
There is also nothing in the activity log showing any attempt to register those extensions either.
I have factory-reset and reloaded a few times to no avail. Even tried searching the Patton logs,
but nothing obvious is showing on those logs either.

I can successfully reach (ping) the PBX from the patton (diags), so I know the Patton is capable
of seeing the PBX as well {after adding the "route" statement}.
This has been very frustrating. No apparent errors, yet not working.

 

[CCAdmin]

You have dialtone, so either the ATA is registered, or it is set to provide dial tone even if not registered (which is not really a great option to have turned on, as it is misleading).

I know 3CX is very strict about touching their config files, so if the dial tone option is on it's because
they do so by default. I try not to manually change anything since that is their first go-to to deny
support.

 

[leejor]

Is the IP of the Patton, in the IP Blacklist of 3CX by any chance?

 

[CCAdmin]

Is the IP of the Patton, in the IP Blacklist of 3CX by any chance?

I wish. Would've been an easy fix.
Actually both the internet IP and the internal IP of the Patton are part of "allow" rules on the PBX already.

 

[leejor]

Then i would say that either the Patton is not sending to the correct FQDN/IP/port, or it is being blocked somewhere along the way.

 

[CCAdmin]

Found two issues (but finally a resolution!):

1) I found another flaw in the "stock" 3CX FXS config file.
Not only are they missing the default GW route statement, which makes your 4114 inaccessible the moment you upload their config, they are also missing the DNS settings!
I added my DNS server and voila, the 4114 started trying to talk with the 3CX server finally.
Guess they assume that people use IP address when building the FXS config file.

2) Apparently they have locked Fax extensions from being used over the internet?!
Once I was finally able to get the 4114 to talk to the 3CX server I noticed an error saying
"SIP request (REGISTER) from {my internet IP} was rejected. Reason: Block WAN requests is ON".
I was mapping four Fax extensions to the 4114. I changed one of the extensions from a Fax to a
normal extension and unchecked the "disallow use outside of LAN" and BOOM! It finally worked!

Why on earth would they lock the FAX extensions to LAN use only and not even give you the
ability to unlock it like normal extensions? Especially since more and more people are moving
to cloud hosted PBX servers, thus nothing is LAN!

Ugh! This was a pain to figure out. Now I have to get ahold of 3CX to find out why fax
extensions aren't allowed over WAN.

 

[CCAdmin]

Thank you for your assistance Leejor!
Sometimes just having someone look along with you helps find more bugs.

 

[CCAdmin]

Well, shoot, I spoke too soon.
Now the 4114 dials finally, after a long delay, but the call never actually connects.

I'm able to call from an analog phone, through the 4114, to my cell phone.
My cell phone rings, after a long pause on the analog phone, and I answer, but the
call never connects the two devices. After a long delay, the analog phone gets a 'busy signal'
tone, like noone ever picked up the call (even though I did). {No ACK for the call}

I have tried with and without "PBX delivers audio". The same result both ways.

So the 4114 still isn't working properly.

 

[leejor]

Does the Activity Log actually show No ACK from the provider? Do any other devices work correctly (3CX Windows or Android phone?) If they don't, then it's not the 4114. Does your 3CX firewall test all pass?

As far as Fax from a "remote" ATA...https://www.3cx.com/community/threads/cannot-register-fax-extension.51691/

I assume, it is because getting fax over VoIP to work (reliably) is frustrating enough when the ATA is local to the server. As mentioned in the post, you could use VPN.

 

[CCAdmin]

All other phones, cell, softphone, etc are working fine.
The 4114 is the only item that isn't working.
Activity Log shows:
"03/15/2018 6:46:05 PM - [CM503021]: Call(C:15850): ACK is not received from sip:8881@{server}:5060"

I'll try to change the server from DNS name (that resolves to external IP) to internal IP (we do have a VPN tunnel already to Google Cloud) and see how that pans out.

 

[CCAdmin]

Ok, so more experimenting.
Changed the server to an internal IP over our VPN tunnel (like Leejor suggested) to Google Cloud.

"Fax" extensions still don't work. They dial fine now (no delays, etc), but no audio. My guess is that FAX extensions don't deliver audio via the PBX and you can't change that, so no go.

"User" extensions work however, with the 'PBX delivers audio' checked.
I was able to finally dial a number and actually speak/hear both directions.
Now to see if the 4114 works with modems using this method! Wish me luck! LOL

 

[leejor]

"User" extensions work however, with the 'PBX delivers audio' checked.

This suggests that a firewall or router, is unable to keep track of voice packets. This is quite common when attempting to use more than a couple (and sometimes just with two) ATA's behind a router, and not use an SBC. Using PBX Delivers Audio, is a work-around, but as all audio now routes back to the PBX, even for set to set calls at the same location, it will use a lot more bandwidth, if that is a concern. Making use of VPN, should work as the Patton would be seen as being on the same local network.

As far as the Fax extensions...you have to install those as actual fax extensions, so don't expect to use them for voice calls. It may still be trial and error to get them working,as you are now adding the internet (possible latency )between the fax machine and the 3CX server.