DTMF Codes Not Recognized When Toll Free Used

[ArcLord]

Good Morning,

We have a strange issue.

On inbound calls, if we take a call directly to our DID the IVR and DTMF queue selection (press 1 for X and 2 for Y…) work fine. If someone calls the toll free number above, the call is forwarded to the same DID, but when they press 1 or 2, nothing happens and they remain in the IVR. To me it looks like the DTMF is not recognized over the toll free, but I cannot fathom why.

Tested this multiple times. If they use the toll free, there is no recognition of the key press. This line has been in operation for almost a year without issues and developed this issue in the last day or so. No changes on our side.

Anyone seen this before?

Cheers.

 

[Guillaume Bourgeois]

Hi,
The « symptoms » you write are quite vague and can represent different problems.

My first (5) questions, to better help you, would be;

#1
Your toll-free number with the same provider as your local number?

#2
The call forwarding is made from the provider of the toll-free number or is made from another destination ? (ex. another telephone system)

#3
If you configure your IVR to repeat after a period (timeout) does the call automatically drop off after 32 seconds or do you continue to hear your IVR on repeat?

#4
Have you checked in the configuration of the # tolls-free if it has a parameter that mentions "Type of DTMF" ?
Examples ;
- In-BAND ,
- SIP Info (RFC2976) ,
- RFC4733/RFC2833,
- « Automatic »

#5
Why not configure your toll-free number « directly » in 3CX in SIP method , instead of call forwarding?


Please answer the 5 questions to allow me to help you.

 

[leejor]

You may want to speak to your provider. It may have something to do with the type of trunks coming in to them, carrying the toll free calls. As it has recently changed, perhaps someone, along the line is using a new provider/transport path, or someone has made a change that was not expected to affect calls.
I have seen some providers (trying to save $) using low bit rate trunks (non-SIP), that have issues when transporting audio DTMF. If it is SIP, incoming to, it may have something to do with the incoming DTMF Method. Your provider should be able to compare DTMF type being sent on calls from other destinations, and those from the toll free numbers, that are failing. I would get them involved.

 

[ArcLord]

@G.BOURGEOIS

The Toll Free number is managed by another company and I have no access to the back-end settings. I'm talking to the other company IT Dept, but communications with them are brief and curt. All of my Toll Free's work fine. The problem toll free line seems to have an issue with DTMF pass through.

When I made them aware of the issue we were told that the "double-announcement" had been fixed, but my test calls still fail most (60% ish) of the time.

 

[Guillaume Bourgeois]

I'm talking to the other company IT Dept, but communications with them are brief and curt.

If you answer their questions like you answer mine, I understand their reactions… You haven't answered my 5 questions... I don't want your diagnosis.
It is my pleasure to give you my time for free but .. you have to collaborate.
If you want me to help you, you have to give me all the details (Answers to my questions).. otherwise, I can only make assumptions..

For now, I have 2 answers of 5 questions ..

#1
Your toll-free number with the same provider as your local number?

Your Answer : No

#2
The call forwarding is made from the provider of the toll-free number or is made from another destination ? (ex. another telephone system)

Call your « Another Company » and ask them if they are resellers or if they are recognized as being RESPORG .. (North American)

#3
If you configure your IVR to repeat after a period (timeout) does the call automatically drop off after 32 seconds or do you continue to hear your IVR on repeat?

Why didn't I get an answer to this question?

#4
Have you checked in the configuration of the # tolls-free if it has a parameter that mentions "Type of DTMF" ?
Examples ;
- In-BAND ,
- SIP Info (RFC2976) ,
- RFC4733/RFC2833,
- « Automatic »

You don't have access to their configurations but you can ask them... Make an effort, help me help you..

#5
Why not configure your toll-free number « directly » in 3CX in SIP method , instead of call forwarding?

Ask the « Another » company, why they don't config to you in SIP without Call Forward.. But above all…. be sure to answer their questions.

Anyway, you seem to insist on "All of my Toll Free's work fine"…
I can help guide you to the source of the problem, which is necessarily on the « call redistribution » side (Call Forward) .. So, I support what @leejor writes.

If you don't get the help they need… change provider..
I know of excellent ones preferred by 3CX

If your provider is a reseller, they probably mismanage setting outbound call / DTMF method (call forwarding).

@leejor is right, require them to provide you with the traces that support their verifications…. PCAP and I VERBOSE Logs ect…

At the risk of giving the illusion of being arrogant, It is not the goal ; A little advice in parallel, if a doctor asks you where your headache is located.. (forward, backward, sideways).. answer him... he may be able to "save your life" !

 

[ArcLord]

Here you go. Please be aware this is on an Enterprise 3CX system.

#1
Your toll-free number with the same provider as your local number?

No, it is hosted through another provider other five Toll Frees, I don't know who. They forward their calls to my DID. Key-presses on calls direct to the DID work as advertised. Calls forwarded from the toll free line to the DID do not.


#2
The call forwarding is made from the provider of the toll-free number or is made from another destination ? (ex. another telephone system)

Another company sends calls to our DID through the toll free number they manage.

#3
If you configure your IVR to repeat after a period (timeout) does the call automatically drop off after 32 seconds or do you continue to hear your IVR on repeat?

It is set to repeat the prompt if there is no entry, or illegal entry. It repeats continuously even if there is a valid key press made. We set the queue to go straight to one of the queues until a solution is found.

#4
Have you checked in the configuration of the # tolls-free if it has a parameter that mentions "Type of DTMF" ?
Examples ;
- In-BAND ,
- SIP Info (RFC2976) ,
- RFC4733/RFC2833,
- « Automatic »

I asked for this (and other info) from the other IT Dept and got no response. I have no insight into how this line is managed. The sum total of communication from them is a one line email that says "It is working now:" It isn't.

#5
Why not configure your toll-free number « directly » in 3CX in SIP method , instead of call forwarding?

Because we do not manage this number. Of the toll free numbers I do manage, they work correctly on our server.

>@leejor is right, require them to provide you with the traces that support their verifications…. PCAP and I VERBOSE Logs ect…

Hard to get info from someone who does not want to admit the line does not work in the first place. Among other things, I asked them to do a Wireshark and send me the results. Nada.

\

 

[Evolute IT]

Here you go. Please be aware this is on an Enterprise 3CX system.

#1
Your toll-free number with the same provider as your local number?

No, it is hosted through another provider other five Toll Frees, I don't know who. They forward their calls to my DID. Key-presses on calls direct to the DID work as advertised. Calls forwarded from the toll free line to the DID do not.


#2
The call forwarding is made from the provider of the toll-free number or is made from another destination ? (ex. another telephone system)

Another company sends calls to our DID through the toll free number they manage.

#3
If you configure your IVR to repeat after a period (timeout) does the call automatically drop off after 32 seconds or do you continue to hear your IVR on repeat?

It is set to repeat the prompt if there is no entry, or illegal entry. It repeats continuously even if there is a valid key press made. We set the queue to go straight to one of the queues until a solution is found.

#4
Have you checked in the configuration of the # tolls-free if it has a parameter that mentions "Type of DTMF" ?
Examples ;
- In-BAND ,
- SIP Info (RFC2976) ,
- RFC4733/RFC2833,
- « Automatic »

I asked for this (and other info) from the other IT Dept and got no response. I have no insight into how this line is managed. The sum total of communication from them is a one line email that says "It is working now:" It isn't.

#5
Why not configure your toll-free number « directly » in 3CX in SIP method , instead of call forwarding?

Because we do not manage this number. Of the toll free numbers I do manage, they work correctly on our server.

>@leejor is right, require them to provide you with the traces that support their verifications…. PCAP and I VERBOSE Logs ect…

Hard to get info from someone who does not want to admit the line does not work in the first place. Among other things, I asked them to do a Wireshark and send me the results. Nada.

\

Why not port the numbers to a supported friendly provider that will actually help you? Sounds like this company should go f*** themselves.

 

[Guillaume Bourgeois]

Here you go. Please be aware this is on an Enterprise 3CX system.

#1
Your toll-free number with the same provider as your local number?

No, it is hosted through another provider other five Toll Frees, I don't know who. They forward their calls to my DID. Key-presses on calls direct to the DID work as advertised. Calls forwarded from the toll free line to the DID do not.


#2
The call forwarding is made from the provider of the toll-free number or is made from another destination ? (ex. another telephone system)

Another company sends calls to our DID through the toll free number they manage.

#3
If you configure your IVR to repeat after a period (timeout) does the call automatically drop off after 32 seconds or do you continue to hear your IVR on repeat?

It is set to repeat the prompt if there is no entry, or illegal entry. It repeats continuously even if there is a valid key press made. We set the queue to go straight to one of the queues until a solution is found.

#4
Have you checked in the configuration of the # tolls-free if it has a parameter that mentions "Type of DTMF" ?
Examples ;
- In-BAND ,
- SIP Info (RFC2976) ,
- RFC4733/RFC2833,
- « Automatic »

I asked for this (and other info) from the other IT Dept and got no response. I have no insight into how this line is managed. The sum total of communication from them is a one line email that says "It is working now:" It isn't.

#5
Why not configure your toll-free number « directly » in 3CX in SIP method , instead of call forwarding?

Because we do not manage this number. Of the toll free numbers I do manage, they work correctly on our server.

>@leejor is right, require them to provide you with the traces that support their verifications…. PCAP and I VERBOSE Logs ect…

Hard to get info from someone who does not want to admit the line does not work in the first place. Among other things, I asked them to do a Wireshark and send me the results. Nada.

\

So what I understand is that the tolls free number does not belong to you.

Your scenario resembles scenarios that I manage with several of our clients.

An Inssurer that publishes a toll-free number and calls dispatcher in round-robin strategy to different « brokers » .
Do I understand your situation correctly?

In our case, the Calls dispatcher is not retransmitting the DTMFs intentionally because it is trying to avoid the calls being sent to IVRs. They also ask not to send to Queues. They ask to use RingGroups.
Without voicemail destination in case of no response.
Their objective is to be able to redirect the caller to another broker if no one answers the call at the first broker.
Obviously, if an IVR or Queue answers the call, in the « eyes » of the Calls dispatcher, the caller is answered.. it's not what they want.
Are you sure the behavior is unintentional from your « Calls dispatcher » ?

Alternatively, ask your local number provider to do a PCAP (Wireshark) at the source (A-Leg Part)..
and reproduce the problem..
Not the « part » that send you (Not B-Leg) .

Send me a private message, I will analyze the PCAP.
With this, we will see the SIP method used (may be) by the provider of your "Call Dispatcher" .

I eagerly await PCAP