Incorrect Number Detected

[joebocop]

I realize that subject line is poor, but appreciate your help in spite of that!

A 3CX system I have just deployed uses a Patton SN4316 to connect to, and receive inbound calls from, our PSTN provider.

I am getting sporadic reports (and have been able to, sporadically, reproduce the issue myself) of inbound callers reaching the incorrect extension on our system. I have verified the reports, and have seen some instances where an inbound caller dials, for example, extension 115 on our system, and 3CX is sent a different extension, say 110 for example.

I know this is not a Patton forum, but I also know that many of you have expertise with both 3CX and Patton equipment.

Have any of you ever seen this behaviour? It is really making the system as a whole (and myself, of course) look bad, as the "old" system (Nortel antique) did not suffer this same behaviour.

Any troubleshooting help, or further advice is very much appreciated.

 

[NickD_3CX]

Hi there!

There is usually a very good explanation for this behavior, however we don't have enough information about how you have setup the system. I believe you have the 16-port FXO Gateway, that means that under Gateway node in the Management Console you see 16 port numbers.

How have you setup the Inbound Rules?
Do they go directly to extensions or are they forwarded to Queues?
Do extensions have Forwarding Rules set (e.g. when Out Of Office status is set) sending calls to other extensions?

If you are accustomed to how Wireshark works, you could run it, replicate the issue, wait until it occurs and see what the Gateway is sending and which extensions the PBX is calling and why.

 

[joebocop]

Thank you very much for weighing-in...

I believe you have the 16-port FXO Gateway

Yes, we have the SN4316/JO/UI, exposing all 16 FXO ports to 3CX, each enumerated under the device's entry within the "VOIP/PSTN Gateways" node.

How have you setup the Inbound Rules?

Any inbound call coming into a port on the SN4316/JO/UI is connected to a digital receptionist object. From that digital receptionist, callers can either select from the listed options, or dial their party's extension.

Do they go directly to extensions or are they forwarded to Queues?

No queues are used in the system yet, so any extension dialled results in the caller (ideally!) being transferred to that actual extension.

Do extensions have Forwarding Rules set (e.g. when Out Of Office status is set) sending calls to other extensions?

Yes, some extensions in the system are set to have calls forwarded to cell phones, other extensions, etc. None of the instances of incorrect destination routing have been on extensions where a forwarding rule would have accounted for the routing decision. I wish!

If you are accustomed to how Wireshark works, you could run it, replicate the issue, wait until it occurs and see what the Gateway is sending and which extensions the PBX is calling and why.

I will do this and report any findings.

My concern is that the problem lies with the Patton device incorrectly "hearing" the correct dialled extension. Have you seen this before? Logs from 3CX suggest the inbound caller (myself, for testing purposes) dialled , for example, 110, when I know for a fact that I dialled 107 at the digital receptionist. Again, I can call inbound 20 times and the error occurs perhaps once or twice out of those 20 attempts. This does not seem to be to be a problem with my routing logic or forwarding rules, but rather an issue with our hardware, or perhaps the quality of the hardware.

In any case, my thanks for any insight you can provide. The expertise is very much appreciated.

 

[leejor]

Usually, when DTMF issues crop up, it is due to digits not being detected at all, not, as in your case, where incorrect digits are interpreted. Low level, and/or short duration tones are usually responsible for this. For the wrong tones to be detected would suggest that somehow the frequency(s) for some tones is somehow being changed to a new frequency, which seems unlikely.

I would check the gateways adjustments to see if incoming levels can be increased (slightly) without causing echo issues. Have you had any noticeable speech distortion while on calls?

 

[joebocop]

First, thank you for your suggestions.

We do not experience call quality problems (such as echo or speech distortion) over the SN4316, to my knowledge.

I have a support ticket open with Patton (free support in the year 2014? Are you kidding me?), and began to worry when they asked "who is the PSTN provider?", for fear that the result of this ticket would be "Your provider is providing sub-standard service. Switch providers.". Of course, there is only one provider in this geographic area.

I will ask of them (Patton support) if your suggestion of increasing levels on the gateway device may prove a useful option.

Again, my thanks for the expertise.

 

[joebocop]

Hello again,

Would it make a difference if the inbound caller was calling from a cell phone, or from something like google voice? Are we more likely to misinterpret dialled tones from those sources than from a PSTN line, perhaps? Trying to nail down this insidious affliction...

 

[lneblett]

There are a number of issues that come into play -

1. What country is the system located? Was this correctly specified during the system installation.
2. Has the 3CX system ever incorrectly transferred calls when using DTMF on internal only calls?
3. Has the 3CX system ever incorrectly dialed to an external location? (may be hard to tell as most would likely think a simple miss-dial).
4. What process was used to provision the Patton?
5. Is the Patton firmware/software version correct?
If the country was set and the system used to generate a provisioning file, then hopefully the file was generated with the attributes that would have been optimized for the region.

In answer to your question, about cell phones and other alternatives to traditional PSTN lines, sure something could be off, but if so, it would be unlikely that they ever would have reached the Patton in the first place. However, once connected, then the tones go thru another DTMF relay process and this is where you need to look at the Patton. Keep in mind that the prior system was likely all analog at the front-end. In this process, you are taking an analog signal and converting into something else (IP). In the case of a cell and GV, Skype, it also started as digital or IP and converted before getting to the Patton and then again to 3CX.

It sounds like the setting, if you will, is on the fringe for some calls. If not mistaken, 3CX will accommodate various signaling types, but prefers the RFC. Get a hold of the Patton software release manual and look in the section for DTMF relay. Even Patton indicates:
Configuring DTMF Relay
Dual tone multi-frequency (DTMF) tones are usually transported accurately in band when using high bit-rate
voice codecs such as G.711. Low bit-rate codecs such as G.729 and G.723.1 are highly optimized for voice patterns
and tend to distort DTMF tones. The dtmf relay command solves the problem of DTMF distortion by
transporting DTMF tones out-of-band or separate from the encoded voice stream as shown in Figure 2. H.323
signals the DTMF tones as H.245 user input indications, SIP uses a mechanism of RTP to reliably transport tones
(according to RFC2833).

There are settings within the Patton that you can change to alter the DTMF handling - type, duration, payload, etc. You should read the section and see if one of the major elements is off. If all seems to be correct, then you might try some of the more subtle changes (small in increment), but be prepared for experimentation and frustration as your only guide to success will be the absence of complaints over the long-haul and there will likely be some miss-dials to consider as well. Oh, and be sure to keep a record of what you change so that you can revert back if need be.

If at all possible, you should try and characterize the problem to the extent that perhaps you can identify trends when the issue occurs. Certain calls, calls to a given extension, certain numbers (0-9) that are more prone to the issue,, anything that gives you a clue such that you can more closely mimic the issue on demand. If you can replicate, then you will know when a solution is at hand. As it stands today.,......a guessing game.