Calls not coming through on first or second try

Hi. I am trying to set up a freePBX server and I am able to send and receive calls. However, I noticed something peculiar. When I try to call the system from my cell phone, I often just hear 2 short beeps on the first try (sometimes also when I try the call again). The third try then usually goes through (without any changes to the system). I have also tried to place an outgoing call after I heard the beeps, and then I am typically also able to place an inbound call afterwards and it goes through. I am talking to Flowroute in parallel to see if that has anything to do with the trunk settings (maybe a timeout that is too short?). I am wondering if anybody here has seen this and has some pointers to what I can try to resolve that issue.

I am not sure if that also happens when I call from a landline.

Thanks.

You need to obtain logs and see whether the request is arriving, and if so how it is handled.

Thanks. I talked to flowroute, and they said that their system tries to connect to me, but cannot, and ends up with a 408 error. So, not much help there, other than maybe some issues with connectivity or modem, etc.

So, in order to test this a bit further, I thought that maybe the signaling goes wrong because I have currently a Vonage phone (VoIP) connected as well. So I decided to disconnect the Vonage router and forward the calls to that number to my system, meaning Vonage does not try to connect to their router but instead forwards the call to Flowroute. When I tried to call the vonage number, my system rang, but when I picked it up, the sound was pretty garbled. So, I decided to reboot the asterisk server and the modem. I waited for a minute, then tried to call the vonage number again. This time I got only silence. Looking at the asterisk log, I found this new line I had not seen before:

WARNING[1883][C-00000001] channel.c: Unable to find a codec translation path: (slin) → (g729)

Checking my trunk, I see that I had g729 enabled, but not slin. g729 was the top codec on my list.

I added the slin to the list, but that did not help.

I then looked at the IVR recording that was supposed to be played (it plays fine in FreePBX) and added a bunch of other formats other than wav. I also re-ordered the codecs and they now are listed in the following order (in the trunk settings): alaw, ulaw, gsm, g726, g722, h264, slin

So, now when I call the vonage number, the warning is gone, and instead I see (after a bunch of normal asterisk log entries):

file.c: <PJSIP/flowroute-00000005> Playing ‘custom/ivr1.alaw’ (language ‘en’)

But I don’t hear anything. If I don’t respond by pressing a number, the IVR eventually hangs up.

I can also connect the inbound route directly to an extension, which then rings, but there is no sound in either direction.

Now, this is what happens when I call the Vonage number that routes to my system. When I call the system directly from my cellphone, I do NOT see a response in the logs. I just hear a couple of short beeps and get disconnected.

So, I thought I had this all set up, but now it is all weird again, and I am back to square one …

Ok, figured out the sound issue. I had hardwired my IP address into the Asterisk SIP settings, but since I am using DDNS, the actual IP address to connect my system had changed. Using the FQDN in the Asterisk SIP settings fixed the sound issue.

The connection issue persists, though… Need to dig a bit deeper.

Do you have sufficient G.729 licences? Do you really need to enable G.729, given that there are better open source codecs, and bandwidth is no longer at such a premium in most of the world.

1 Like

Thanks, David.

I think the G729 was a distraction. I realized that I had hardwired an IP address in the Asterisk SIP settings, and then my DDNS changed. I put the FQDN (from the DDNS) in, and that seems to have taken care of the sound issue. However, the issue with failing connections still exist, but I think I have a clue for that.

I installed sngrep on the Freepbx server and started it and then placed 6 calls into the system. the first and last went through, the other 4 failed. The only difference in the report I see is that all the calls that succeeded were initiated from 34.210.91.112, while calls that failed were initiated from 34.210.91.114. So, it seems my installation rejects calls that are not coming from the 112 IP.

The trunk has an IP permission set to 34.210.91.112/28, as specified by the provider (Flowroute), which should allow any IP with 34.210.91.xxx, but that does not seem to work. I am not seeing that I can set that anywhere else. Am I missing something?

This was the first time that “report” appeared in the thread. Is this a report from Flowroute (with nothing in the Asterisk log)? If so, then the incoming INVITE was blocked by your either your router or FreePBX Firewall.

Run sngrep and see whether the failing calls appear. If yes, set FreePBX Firewall to pass the traffic:

fwconsole firewall trust 34.210.91.112/28

If no, make sure that your router forwards UDP port 5060 (or whatever Port to Listen ON is set to) to the LAN address of FreePBX.

This is a report (or what it shows on the screen) from sngrep, with nothing in the Asterisk logs for the calls that didn’t go through. I was looking for the Freepbx firewall, which I think should appear under “Connections”, but it is not there. Issuing the “fwconsole” command I get a response “Command “firewall” is not defined” from the linux prompt, and “no such command” from the CLI prompt.

Ports are forwarded to the local IP. I think the 112 IP would also not work if that was not the case.

Since the 112 address goes through fine, I don’t think it is a router problem, and since I don’t seem to have a FreePBX firewall, it seems to me a configuration issue, but I don’t know where to look. I’ll try to permit the 114 IP specifically in the trunk settings to see if that changes anything.

Indeed, that shows that the Firewall module is not installed. But if the INVITE shows in sngrep and not in the log, there must be some other software firewall running on the system that is blocking the request.

From a root shell prompt, what does

iptables -vL

show?

That sows a whole lot of stuff…not sure where that all comes from. This is the “INPUT” part there is a similar OUTPUT part as well.
What am I looking for?

Chain INPUT (policy DROP 2503 packets, 644K bytes)
 pkts bytes target     prot opt in     out     source               destination
 143K   19M ACCEPT     all  --  lo     any     anywhere             anywhere
 400K   22M ACCEPT     tcp  --  any    any     anywhere             anywhere             tcp flags:ACK/ACK
72878   17M ACCEPT     all  --  any    any     anywhere             anywhere             state ESTABLISHED
   29 14471 ACCEPT     all  --  any    any     anywhere             anywhere             state RELATED
    0     0 ACCEPT     udp  --  any    any     anywhere             anywhere             udp spt:domain dpts:1024:65535
    0     0 ACCEPT     icmp --  any    any     anywhere             anywhere             icmp echo-reply
    0     0 ACCEPT     icmp --  any    any     anywhere             anywhere             icmp destination-unreachable
    0     0 ACCEPT     icmp --  any    any     anywhere             anywhere             icmp source-quench
    0     0 ACCEPT     icmp --  any    any     anywhere             anywhere             icmp time-exceeded
    0     0 ACCEPT     icmp --  any    any     anywhere             anywhere             icmp parameter-problem
    0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere             tcp dpt:auth
    0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere             tcp dpt:1723
    0     0 ACCEPT     udp  --  any    any     anywhere             anywhere             udp dpt:iax
    0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere             tcp dpt:32976
    0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere             tcp dpt:4445
    0     0 ACCEPT     udp  --  any    any     anywhere             anywhere             udp dpt:ntp
    0     0 ACCEPT     udp  --  any    any     anywhere             anywhere             udp dpt:tftp
    0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere             tcp dpt:9022
12217 1184K ACCEPT     udp  --  any    any     anywhere             anywhere             udp dpt:mdns
    0     0 ACCEPT     udp  --  any    any     64.2.142.215         anywhere             multiport dports sip:5069,iax
    0     0 ACCEPT     udp  --  any    any     64.2.142.216         anywhere             multiport dports sip:5069,iax
    0     0 ACCEPT     udp  --  any    any     64.2.142.9           anywhere             multiport dports sip:5069,iax
    0     0 ACCEPT     udp  --  any    any     64.2.142.17          anywhere             multiport dports sip:5069,iax
    0     0 ACCEPT     udp  --  any    any     64.2.142.18          anywhere             multiport dports sip:5069,iax
    0     0 ACCEPT     udp  --  any    any     64.2.142.29          anywhere             multiport dports sip:5069,iax
    0     0 ACCEPT     udp  --  any    any     64.2.142.87          anywhere             multiport dports sip:5069,iax
    0     0 ACCEPT     udp  --  any    any     64.2.142.106         anywhere             multiport dports sip:5069,iax
    0     0 ACCEPT     udp  --  any    any     64.2.142.107         anywhere             multiport dports sip:5069,iax
    0     0 ACCEPT     udp  --  any    any     64.2.142.109         anywhere             multiport dports sip:5069,iax
    0     0 ACCEPT     udp  --  any    any     64.2.142.111         anywhere             multiport dports sip:5069,iax
    0     0 ACCEPT     udp  --  any    any     64.2.142.187         anywhere             multiport dports sip:5069,iax
    0     0 ACCEPT     udp  --  any    any     64.2.142.188         anywhere             multiport dports sip:5069,iax
    0     0 ACCEPT     udp  --  any    any     64.2.142.189         anywhere             multiport dports sip:5069,iax
    0     0 ACCEPT     udp  --  any    any     64.2.142.190         anywhere             multiport dports sip:5069,iax
    0     0 ACCEPT     udp  --  any    any     64.2.142.214         anywhere             multiport dports sip:5069,iax
    0     0 ACCEPT     udp  --  any    any     64.2.142.26          anywhere             multiport dports sip:5069,iax
    0     0 ACCEPT     udp  --  any    any     199.101.184.146      anywhere             multiport dports sip:5069,iax
    0     0 ACCEPT     udp  --  any    any     174.34.146.162       anywhere             multiport dports sip:5069,iax
    0     0 ACCEPT     udp  --  any    any     cpshared02-chi.ubiquityclients.com  anywhere             multiport dports sip:5069,iax
    0     0 ACCEPT     udp  --  any    any     b2.36.364a.static.theplanet.com  anywhere             multiport dports sip:5069,iax
    0     0 ACCEPT     udp  --  any    any     ev1s-209-62-1-2.theplanet.com  anywhere             multiport dports sip:5069,iax
    0     0 ACCEPT     udp  --  any    any     67.215.241.250       anywhere             multiport dports sip:5069,iax
    0     0 ACCEPT     udp  --  any    any     74.63.41.218         anywhere             multiport dports sip:5069,iax
    0     0 ACCEPT     udp  --  any    any     69.147.236.82        anywhere             multiport dports sip:5069,iax
    0     0 ACCEPT     udp  --  any    any     68-233-226-97.static.hvvc.us  anywhere             multiport dports sip:5069,iax
    0     0 ACCEPT     udp  --  any    any     67.205.74.184        anywhere             multiport dports sip:5069,iax
    0     0 ACCEPT     udp  --  any    any     67.205.74.187        anywhere             multiport dports sip:5069,iax
    0     0 ACCEPT     udp  --  any    any     174.137.63.206.16clouds.com  anywhere             multiport dports sip:5069,iax
    0     0 ACCEPT     udp  --  any    any     174.137.63.202.16clouds.com  anywhere             multiport dports sip:5069,iax
    0     0 ACCEPT     udp  --  any    any     server.zimbabwewebdesign.com  anywhere             multiport dports sip:5069,iax
    0     0 ACCEPT     udp  --  any    any     199.87.144.0/21      anywhere             multiport dports sip:5080,iax
    0     0 ACCEPT     udp  --  any    any     204.11.192.0/22      anywhere             multiport dports sip:5080,iax
    0     0 ACCEPT     udp  --  any    any     scottshelton.clientshostname.com  anywhere             multiport dports sip:5069,iax
    0     0 ACCEPT     udp  --  any    any     node24.174.136.64.voipinnovations.com  anywhere             multiport dports sip:5069,iax
    0     0 ACCEPT     udp  --  any    any     node24.174.136.64.voipinnovations.com  anywhere             multiport dports sip:5069,iax
    0     0 ACCEPT     udp  --  any    any     did.voip.les.net     anywhere             multiport dports sip:5069,iax
    0     0 ACCEPT     udp  --  any    any     magnum.axvoice.com   anywhere             multiport dports sip:5069,iax
    0     0 ACCEPT     udp  --  any    any     future-nine.com      anywhere             multiport dports sip:5069,iax
    0     0 ACCEPT     udp  --  any    any     85.17.148.32         anywhere             multiport dports sip:5069,iax
    0     0 ACCEPT     udp  --  any    any     63-211-239-14.teliax.com  anywhere             multiport dports sip:5069,iax
    0     0 ACCEPT     udp  --  any    any     atlantanew1.voip.ms  anywhere             multiport dports sip:5069,iax
    0     0 ACCEPT     udp  --  any    any     lax.teliax.net       anywhere             multiport dports sip:5069,iax
    0     0 ACCEPT     udp  --  any    any     8-14-120-23.leap.tel  anywhere             multiport dports sip:5069,iax
    0     0 ACCEPT     udp  --  any    any     8-17-37-23.teliax.net  anywhere             multiport dports sip:5069,iax
    0     0 ACCEPT     udp  --  any    any     66.54.140.46         anywhere             multiport dports sip:5069,iax
    0     0 ACCEPT     udp  --  any    any     66.54.140.47         anywhere             multiport dports sip:5069,iax
    0     0 ACCEPT     udp  --  any    any     85.17.186.7          anywhere             multiport dports sip:5069
    0     0 ACCEPT     udp  --  any    any     node11.dns-hosting.info  anywhere             multiport dports sip:5069
    0     0 ACCEPT     udp  --  any    any     2.b6.e443.ip4.static.sl-reverse.com  anywhere             multiport dports sip:5069
    0     0 ACCEPT     udp  --  any    any     www.freenum.org      anywhere             multiport dports sip:5069
    0     0 ACCEPT     udp  --  any    any     syn-024-211-064-206.res.spectrum.com  anywhere             multiport dports sip:5069
    0     0 ACCEPT     udp  --  any    any     199.30.56.194        anywhere             multiport dports sip:5069
    0     0 ACCEPT     udp  --  any    any     209.216.15.70        anywhere             multiport dports sip:5069
    0     0 ACCEPT     udp  --  any    any     bser1.bingotelecom.com  anywhere             multiport dports sip:5069
    0     0 ACCEPT     udp  --  any    any     11.97.154.184.unassigned.ord.singlehop.net  anywhere             multiport dports sip:5069
    0     0 ACCEPT     udp  --  any    any     gw1.sip.us           anywhere             multiport dports sip:5069
    0     0 ACCEPT     udp  --  any    any     gw2.sip.us           anywhere             multiport dports sip:5069
    0     0 ACCEPT     udp  --  any    any     e.65.1632.ip4.static.sl-reverse.com  anywhere             multiport dports sip:5069
    0     0 ACCEPT     udp  --  any    any     67.212.84.21         anywhere             multiport dports sip:5069
    0     0 ACCEPT     udp  --  any    any     static.206.39.9.176.clients.your-server.de  anywhere             multiport dports sip:5069
    0     0 ACCEPT     udp  --  any    any     25.prd1.tms.anveo.com  anywhere             multiport dports sip:5069
    0     0 ACCEPT     udp  --  any    any     f2.66.1632.ip4.static.sl-reverse.com  anywhere             multiport dports sip:5069
    0     0 ACCEPT     udp  --  any    any     c-98-254-157-185.hsd1.fl.comcast.net  anywhere             multiport dports sip:5069
    0     0 ACCEPT     udp  --  any    any     sip.didlogic.net     anywhere             multiport dports sip:5069
    0     0 ACCEPT     udp  --  any    any     c-98-254-157-185.hsd1.fl.comcast.net  anywhere             multiport dports sip:5069
    0     0 ACCEPT     udp  --  any    any     64.2.142.26          anywhere             multiport dports sip:5069
    0     0 ACCEPT     udp  --  any    any     node04.dns-hosting.info  anywhere             multiport dports sip:5069
    0     0 ACCEPT     tcp  --  any    any     node04.dns-hosting.info  anywhere             tcp dpts:sip:5069
    0     0 ACCEPT     all  --  any    any     10.0.0.0/8           anywhere
    0     0 ACCEPT     all  --  any    any     127.0.0.0/8          anywhere
    0     0 ACCEPT     all  --  any    any     172.16.0.0/12        anywhere
 307K   48M ACCEPT     all  --  any    any     192.168.0.0/16       anywhere

quick update. I added the 114 IP to the iptables with this command:

iptables -I INPUT -p udp -s 34.210.91.114 -j ACCEPT

and I believe that fixed the problem. At least it connected the first time with that IP as the source. Fingers crossed.

Wow, there are entries for many VoIP providers, but not the one you need! Is this Incredible PBX or some other specialized distribution? If so, there may be documentation on how to add an entry for Flowroute. If you just add an iptables entry, it will likely be overwritten on restart.

You could disable iptables altogether, if you believe that your hardware router/firewall offers sufficient protection, but I don’t know enough about your environment to recommend that.

Googling “incredible pbx add firewall rule for flowroute” shows an AI generated solution, but I don’t know whether it’s correct.

I am not sure with Incredible PBX. This is FreePBX, but I am running it on a Raspberry PI (with the code from Github. It seems to work with the (temporary) rule addition. I’ll check out your suggestion. I also found iptables-persistent which seems to fix that problem.
Thanks for your help.

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