Outgoing cal drops as soon as its picked up

we can receive incoming calls no problem, we can use internal calls ok. Its when we make an outgoing call - the call rings and is ok until the person answers, as soon as they do it disconnects the call.

I cannot attach my log as I’m new :frowning:

Post a pastebin link

See instructions: https://wiki.freepbx.org/display/SUP/Providing+Great+Debug#ProvidingGreatDebug-AsteriskLogs-PartII

If you cannot post links, format it as preformatted text.

Thanks here is my log https://pastebin.freepbx.org/view/c8f0f995

I don’t know what’s wrong, but noticed a few strange things; perhaps one is relevant to the problem.

The log is missing most of the normal entries. The pjsip logger entries are there, but except for one error, none of the dial plan processing entries are present. There was a bug a while back that affected Asterisk logfile settings. In Settings -> Asterisk Logfile Settings ->Log Files, the defaults for both ‘console’ and ‘full’ have Debug, Error, Verbose, Notice and Warning turned on. If you paste another log, make sure these are all set.

The initial outgoing INVITE on the trunk has no SDP. While the RFCs permit that, it’s unusual behavior for pjsip. Possibly a build difference (was FreePBX installed from the Distro ISO)? Or possibly related to codec or other trunk settings (post screenshots). The closest I found was https://community.asterisk.org/t/no-sdp-sent-in-outbound-invite-from-asterisk-using-pjsip/76710 but no real resolution in that thread.

Line 157 shows
Contact: <sip:[email protected]:5060;transport=TCP>
but line 171 has
Via: SIP/2.0/TCP;rport=44311;received=;branch=z9hG4bKPjeda64edc-2876-42fe-9348-8aef709c6205;alias
So either your router/firewall rewrote the source port from 5060 to 44311 (which could cause in-dialog packets to not be received), or you are actually using 44311 as Port to Listen On. However, on line 407 the re-invite was sent to 44311. Please confirm that any SIP ALG in your router/firewall is turned off, and try to avoid the source port rewriting by forwarding TCP 5060 or by enabling ‘consistent NAT’ or whatever your firewall may call it. Post router/firewall make/model if this isn’t clear.

The 447802 number looks like a normal Telefonica mobile, but there are no 180 Ringing or 183 Progress responses in the log. That could be normal if the mobile were offline and the call went immediately to voicemail, but that is inconsistent with your ‘until the person answers’ response.

I have made another call and this time i have answered the call and it drops after about 2 seconds, I can talk and hear myself in those 2 seconds.

I’m using freepbx in a docker on unraid - I can receive calls from outside perfectly well.

I’ve turned off ALG on the router, and port forwarded TCP 5060 & UDP 10000 - 20000.

The new log still does not contain the normal Asterisk entries. Please confirm that you pasted from the Asterisk log file (/var/log/asterisk/full) or in the GUI Reports -> Asterisk Logfiles.

Also, the new log still shows the INVITE as being sent by Asterisk from port 5060, but being received by the provider as from a different port (this time it was 34053). Something in your network must have rewritten the port number. Router/firewall make/model? Does it have on its WAN interface? If not, your modem is likely configured as a gateway (also doing NAT) and could be altering the SIP traffic.

If you have a reasonably easy way to run a regular FreePBX Distro (installed from ISO), we could distinguish problems caused by the build or execution environment from any quirks of the trunking provider. Can you set up a regular virtual machine, either on a server on in the cloud? Or, install FreePBX on a no-longer-used desktop or laptop? If you can’t easily do this, take a close look at the errors written to the Asterisk log as it starts up.

I have 2 routers, a draytek 2680, this connects the Internet, it’s lan 1 port connects to a dlink DIR-X1560 WiFi 6 router. The draytek passes all traffic through to the dlink via its dmz (ip of draytek is and has alg turned off. The dlinks dhcp pool is set to 192.168.1.x, The dlink serves the dhcp and has its firewall on and all turned off. I have passed through the relevant ports (see above), I have tested to see if the ports are open and they are.

Do you think maybe my setup/dlink might be the issue?

You are probably experiencing double NAT issues if you have one router behind the other.

I have removed the other router and setup the draytek router but its still exactly the same result.
I dont have the ability to setup a freepbx server ATM. The log settings are “‘console’ and ‘full’ have Debug, Error, Verbose, Notice and Warning turned on”

I have setup freePBX in a vm, I used the ISO to install it, followed the wizard and put the vm in a DMZ and enabled the smart firewall in freepbx. I have the exact same issue as before, incoming calls work fine but outgoing calls drop after about 2 seconds. I’ve been at this all day now and am no further forward.

I’m now starting to think is my panansonic KX-TPA60 Or KX-TPX600!

IMO, unlikely but certainly possible. Can you call *43 (echo test) from the Panny? Call other extensions?

Also, if this is the only device type on your system, set up a softphone extension and test with that. I recommend Linphone, MicroSIP or PhonerLite, all of which have good logging capabilities. Of course, it’s also easy to run Wireshark on the machine with the softphone.

Good. Please confirm that you are using bridged networking for the VM and let us know what virtualization platform you are using.

Probably not good. I could not find Draytek 2680. Did you mean Draytek 2860? If so, DMZ on that simply means send everything that would otherwise be dropped to the DMZ host. That’s not what you want for VoIP, because it doesn’t help source port rewrites on outbound connections. Turn off the DMZ and instead forward TCP port 5060 and UDP ports 10000-20000 to the PBX.

Although the new PBX may not be working any better, presumably the log issue has been fixed, so you can now paste the complete Asterisk log (including SIP trace) for a failing call. With luck, it will have a clue as to what is going wrong.

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