Ring delay and short no answer hang up with Patton SN4112/JO/EUI

[46degrees]

Hi,

I am using a Patton SN4112/JO/EUI FXO gateway and having some issues with inbound calls.

First issue, is that when a call is placed on that landline, the extension starts to ring with a delay. The caller listens to 2 tones and on the 3rd tone the call gets to the extension. It used to be delayed for 3 ringing tones, but I managed to reduce that by changing the "Ring Number -> Ring bursts:" setting to 1 in the Patton's FXO interface settings. Unfortunately there no way to set it to any less than 1 (0 will not pick up at all), and the delay is still too long.

Second issue, is that the phone rings only 6 times before it hangs up the call as no answered (the caller listens to 6 ringing tones, but the extension rings only 4 times). I have set all the ring timeout settings to 120 seconds in 3CX and it works properly on another SIP Trunk that I have. Also, if I connect an analog phone straight to the landline, here is no issue, so it's not an issue of the provider.

Below are the debug logs of the Patton and the capture log of 3CX, while I was doing a test call.

Thanks

 

[leejor]

The first issue is typical of a PSTN Gateway. It must first detect the call (a bust of ring generator), then pass it on to 3CX. If a 1 second delay is the minimum they allow, then that is what you will have accept, there is no way around this. Calls are not "instant" as on a SIP trunk.

In North America, or anywhere Bellcore type caller ID is used, we must wait until after the second ring, to pass the call to 3CX (about 3 seconds), or caller ID will not be detected, as it is sent between the first and second ring. Because some regions sent caller ID before the first ring, in some cases after a line reversal, that time can be shortened, but will still be limited buy the manufacturer, as you've discovered. Perhaps they found that setting to zero caused other issues. You could always ask them, they do have a website, and probably a forum.

As for the second issue... Check the 3CX Activity Log (Verbose) to see which end is terminating the call after 6 rings, 3CX or the gateway. If it is the gateway, then there may very well be a setting that is causing this.

 

[46degrees]

The first issue is typical of a PSTN Gateway. It must first detect the call (a bust of ring generator), then pass it on to 3CX. If a 1 second delay is the minimum they allow, then that is what you will have accept, there is no way around this. Calls are not "instant" as on a SIP trunk.

In North America, or anywhere Bellcore type caller ID is used, we must wait until after the second ring, to pass the call to 3CX (about 3 seconds), or caller ID will not be detected, as it is sent between the first and second ring. Because some regions sent caller ID before the first ring, in some cases after a line reversal, that time can be shortened, but will still be limited buy the manufacturer, as you've discovered. Perhaps they found that setting to zero caused other issues. You could always ask them, they do have a website, and probably a forum.

As for the second issue... Check the 3CX Activity Log (Verbose) to see which end is terminating the call after 6 rings, 3CX or the gateway. If it is the gateway, then there may very well be a setting that is causing this.

Thanks for your reply. Yes, I know about the two ring delay in some countries. I will probably have to live with that delay, but it's a bit annoying for the caller to wait longer for the call to be answered. The 0 ring setting on the Patton gateway is supposed to mean "not to answer the call at all" ( which I don't really understand the purpose). It would be nice to have an option to answer the call immediately, at least for the countries that send the caller id before the first ring. Maybe there is some setting there, but so far it's the only option they gave me to try from Patton support ticket.

I did look at the log (which is attached at my post above), but couldn't figure out which device terminates the call. But although I used to be a network engineer and sysadmin, I have no experience and very limited understanding of phone services. I did setup 3CX and solved some issues I had, and it's working great, but I think I reached my limit in troubleshooting this issue.

 

[leejor]

Unfortunately the pcap file , while having some text characters, primarily consists of unreadable gibberish when opened with a text viewer.

The reason for the zero option, if it does, in fact prevent the gateway from answering, may be for use on phone lines used only for outgoing calls. This would eliminate having to get 3CX (or whatever other device the gateway were connected) to ignore, or terminate that call. If you want a callers first audible ring-back to be actually ringing an extension, then you'd have to move to SIP trunks, even then, the ring and ring-back may still not be in sync.

 

[NickD_3CX]

For the Second issue you mentioned, something you can do is have the incoming call on 3CX be answered by a Digital Receptionist which will effectively answer the call, then forward the call to the extension you want.

This way you won't have to worry about the call being terminated by the Gateway or the PSTN provider after 6 rings, because as far as they will be concerned, the call has been answered.

 

[ChrisC_3CX]

@46degrees

Just want to add that I took a look at the provided .pcap file and can see that there are actually two calls in from the Gateway that only have some miliseconds difference:


They DIDs for these calls are 000000 and 000001 suggesting one came from the first physical port of the gateway and the second from the second port. However, the Caller ID for both calls is exactly the same so this does seem a bit weird.

Just mentioning this in case you made any configuration changes to the gateway that may have caused this and that you would probably want to revert. If not sure and want to confirm if this is an issue, you might want to make a few test calls while performing a packet captures to see if this happens for every call that should've been just a single call coming in through only one of the PSTN ports.