IVR missing digit, TCP endpoint issues

FreePBX Endpoints
1

Hi,
I set up a new FreePBX about two months ago. I initially had issues with PJSIP extensions, and since the PBX needed to be up fast, I originally set up all the extensions as chan_sip and now that we’re up and running, I’m trying to transfer them to PJSIP.

While working on that, a few problems appeared. I don’t think they’re related to the chan_sip/PJSIP point, but I’m just mentioning that in case, well, they are.

Issue number one was an IVR missing a digit.
When a caller calls in, they can press # to enter a direct extension. A few extensions, however, would give “We have not received a valid response …”.
After turning on DTMF debug, I noticed that the PBX kept missing a digit - always the same digit for each extension.
It seems that FreePBX always misses the fourth digit of any extension ending in 1 (all extension are four digits). If the digit is dialled again, there is no issue.
There is also no issue when I try dialling into the IVR from a local extension - the issue is only on inbound calls.

Issue number two turned up this morning. All our softphones use TCP. This has been working fine, but now TCP softphones have 1) one way audio issues, and 2) hang up after approximately ten seconds, with

WARNING[15965]: chan_sip.c:4126 retrans_pkt: Retransmission timeout reached on transmission 914B3FBCFE27695518137FDCBDF88B25F4C465B5 for seqno 2 (Critical Response) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
WARNING[15965]: chan_sip.c:4150 retrans_pkt: Hanging up call 914B3FBCFE27695518137FDCBDF88B25F4C465B5 - no reply to our critical packet (see https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions).

And then send a BYE with:

X-Asterisk-HangupCause: No user responding
X-Asterisk-HangupCauseCode: 18

When I switch the softphones to UDP, we have no issues.
The problem is the same with both chan_sip and PJSIP extensions.
I get the same issues whether the phones are on the local network or remote.

We’re running 15.0.16.75 with all modules up to date.

Could anyone help me with this?

Thank you in advance!

2

It seems there is something in your network for TCP traffic.

Also about the DTMF issue, what is your interconnection type? it’s PSTN or SIP trunk?

3

What do you mean by this?

It’s a SIP trunk.

Thank you!

4

from the logs that you sent, it seems your SIP/TCP messages dont reach to the destination.
You can enable pjsip logger and see what exactly is happening.

what is dtmf value in your trunk setting?

5

Hi,
Thank you for your reply.

The trunk is currently using chan_sip.

Thank you.

6

This is almost always a problem with your NAT setup on the network.

This sounds like you are bumping into a Feature Code - for it to be this specific, it has to be something in the way the DTMF stream is being interpretted.

There are two SIP Channel Drivers, PJ-SIP (which defaults to port 5060 for inbound traffic) and Chan-SIP (which defaults to port 5160). The ports are configurable, so which one is which is not that big an error.

Each of the Channel Drivers works with DTMF a little differently, but both rely on a setting for which DTMF handler you are using, which is what the question

was asking about. There are (like) four different ways to handle DTMF, each with its own advantages and disadvantages. Regardless of which choice you make, though, missing a single digit in a dial stream is not a symptom of DTMF Handler issues.

So, since DTMF seems to be working for everything but this one edge case, I recommend looking at the Feature Code table and seeing if there’s anything in there that looks like “#” followed by your extensions that might be getting “in the way”.

You can also turn on DTMF Debugging from the Asterisk CLI, which might help you narrow down your issues.

One place where these come together is in the RTP handling. In SIP, the ‘setup’ part of the conversation is done on port 5060 or 5160 (Chan-SIP or PJ-SIP, depending on your config choices), but the “sound” part of the conversation is always handled of UDP ports 10000-20000. If your firewall/router is not forwarding these ports to your PBX, you could miss the first packet of a transmission stream, while the router and the PBX negotiate how to get the sound from the outside network into the PBX.

1 Like
7

The issue appears whether the on the same network connecting directly to the PBX and when going through NAT.

I’ve checked, the only feature code with a # is “##” - In-Call Asterisk Blind Transfer.

Dialing # transfers to a different IVR which prompts to enter the extension the caller wants to call. The prompt does get played.

With DTMF debugging in the console I get the following:

-- Executing [s@ivr-2:10] ExecIf("SIP/sipgate-0000011e", "1?Background(enter-ext-of-person)") in new stack
    -- <SIP/sipgate-0000011e> Playing 'enter-ext-of-person.slin' (language 'en_GB')
[2020-10-29 20:00:14] DTMF[31565][C-00000041]: channel.c:3987 __ast_read: DTMF begin '3' received on SIP/sipgate-0000011e
[2020-10-29 20:00:14] DTMF[31565][C-00000041]: channel.c:3991 __ast_read: DTMF begin ignored '3' on SIP/sipgate-0000011e
[2020-10-29 20:00:14] DTMF[31565][C-00000041]: channel.c:3873 __ast_read: DTMF end '3' received on SIP/sipgate-0000011e, duration 160 ms
[2020-10-29 20:00:14] DTMF[31565][C-00000041]: channel.c:3962 __ast_read: DTMF end passthrough '3' on SIP/sipgate-0000011e
[2020-10-29 20:00:15] DTMF[31565][C-00000041]: channel.c:3987 __ast_read: DTMF begin '0' received on SIP/sipgate-0000011e
[2020-10-29 20:00:15] DTMF[31565][C-00000041]: channel.c:3991 __ast_read: DTMF begin ignored '0' on SIP/sipgate-0000011e
[2020-10-29 20:00:15] DTMF[31565][C-00000041]: channel.c:3873 __ast_read: DTMF end '0' received on SIP/sipgate-0000011e, duration 110 ms
[2020-10-29 20:00:15] DTMF[31565][C-00000041]: channel.c:3962 __ast_read: DTMF end passthrough '0' on SIP/sipgate-0000011e
[2020-10-29 20:00:15] DTMF[31565][C-00000041]: channel.c:3987 __ast_read: DTMF begin '0' received on SIP/sipgate-0000011e
[2020-10-29 20:00:15] DTMF[31565][C-00000041]: channel.c:3991 __ast_read: DTMF begin ignored '0' on SIP/sipgate-0000011e
[2020-10-29 20:00:15] DTMF[31565][C-00000041]: channel.c:3873 __ast_read: DTMF end '0' received on SIP/sipgate-0000011e, duration 104 ms
[2020-10-29 20:00:15] DTMF[31565][C-00000041]: channel.c:3962 __ast_read: DTMF end passthrough '0' on SIP/sipgate-0000011e
    -- Executing [300@ivr-2:1] GotoIf("SIP/sipgate-0000011e", "1?i,1") in new stack
    -- Goto (ivr-2,i,1)
    -- Executing [i@ivr-2:1] Set("SIP/sipgate-0000011e", "INVALID_LOOPCOUNT=1") in new stack
    -- Executing [i@ivr-2:2] GotoIf("SIP/sipgate-0000011e", "0?final") in new stack
    -- Executing [i@ivr-2:3] Set("SIP/sipgate-0000011e", "IVR_MSG=no-valid-responce-pls-try-again&enter-ext-of-person

In the above log, I dialed “3001”, and as you can see, the PBX saw it as just “300”.

The same happens when I vary the time between dialing the digits.

However, I just noticed that if there is a lot of noise in the background while dialling, the PBX does hear the last digit and everything works as expected. I only get this issue if there is very little background noise. I’ve done multiple tests with loud noise, shouting, music, and quiet, and the above holds. Any idea?

Ports 10000-20000 are forwarded to the PBX.

Thank you!

8

It may not be you system that gives you the problems, I ran into a similar issue , It was phones or phone-systems on the other end. For example they wanted to dial 22345 .What my system got was 2222222345.as you can see the call went to extension 22222, If you have such an extension

Its called key-bouncing. To correct the problem, I used a more random numbering in the ivr.

9

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.