Dropped Call

mgbolts · January 19, 2019, 7:13am

Hi,

Hope I am not posing a common question…I did have a good hunt around for a solution. I am running FreePBX 14 behind a pfsense firewall. I have a dedicated static external IP and Internal IPs which are Natted 1:1.

I have followed a couple of guides which improved the time from 15mins to 60mins but it still drops …I changed the firewall optimisation setting to conservative and also Disabled the Firewall Scrub.

I am guessing its still the firewall…keen to hear any ideas as what to try next.

Log for call drop is detailed below (note: My number has been starred out)

-- Channel SIP/Aus_Phone_Co-00000005 left 'simple_bridge' basic-bridge <f0b079b3-7c8e-4bc9-8d13-8b24f5df1300>
-- Channel SIP/210-00000004 left 'simple_bridge' basic-bridge <f0b079b3-7c8e-4bc9-8d13-8b24f5df1300>

== Spawn extension (macro-dialout-trunk, s, 32) exited non-zero on ‘SIP/210-00000004’ in macro ‘dialout-trunk’
== Spawn extension (from-internal, **********, 6) exited non-zero on ‘SIP/210-00000004’
– Executing [h@from-internal:1] Macro(“SIP/210-00000004”, “hangupcall”) in new stack
– Executing [s@macro-hangupcall:1] GotoIf(“SIP/210-00000004”, “1?theend”) in new stack
– Goto (macro-hangupcall,s,3)
– Executing [s@macro-hangupcall:3] ExecIf(“SIP/210-00000004”, “0?Set(CDR(recordingfile)=)”) in new stack
– Executing [s@macro-hangupcall:4] NoOp(“SIP/210-00000004”, "SIP/Aus_Phone_Co-00000005 monior file= ") in new stack
– Executing [s@macro-hangupcall:5] AGI(“SIP/210-00000004”, “attendedtransfer-rec-restart.php,SIP/Aus_Phone_Co-00000005,”) in new stack
– Launched AGI Script /var/lib/asterisk/agi-bin/attendedtransfer-rec-restart.php
– <SIP/210-00000004>AGI Script attendedtransfer-rec-restart.php completed, returning 0
– Executing [s@macro-hangupcall:6] Hangup(“SIP/210-00000004”, “”) in new stack
== Spawn extension (macro-hangupcall, s, 6) exited non-zero on ‘SIP/210-00000004’ in macro ‘hangupcall’
== Spawn extension (from-internal, h, 1) exited non-zero on ‘SIP/210-00000004’
– SIP/210-00000004 Internal Gosub(crm-hangup,s,1) start
– Executing [s@crm-hangup:1] NoOp(“SIP/210-00000004”, “Sending Hangup to CRM”) in new stack
– Executing [s@crm-hangup:2] NoOp(“SIP/210-00000004”, “HANGUP CAUSE: 16”) in new stack
– Executing [s@crm-hangup:3] ExecIf(“SIP/210-00000004”, “0?Set(__CRM_VOICEMAIL=)”) in new stack
– Executing [s@crm-hangup:4] NoOp(“SIP/210-00000004”, “MASTER CHANNEL: 1547877720.4 = 1547877720.4”) in new stack
– Executing [s@crm-hangup:5] GotoIf(“SIP/210-00000004”, “0?return”) in new stack
– Executing [s@crm-hangup:6] Set(“SIP/210-00000004”, “__CRM_HANGUP=1”) in new stack
– Executing [s@crm-hangup:7] AGI(“SIP/210-00000004”, “sangomacrm.agi”) in new stack
– Launched AGI Script /var/lib/asterisk/agi-bin/sangomacrm.agi
– <SIP/210-00000004>AGI Script sangomacrm.agi completed, returning 0
– Executing [s@crm-hangup:8] Return(“SIP/210-00000004”, “”) in new stack
== Spawn extension (from-internal, h, 1) exited non-zero on ‘SIP/210-00000004’
– SIP/210-00000004 Internal Gosub(crm-hangup,s,1) complete GOSUB_RETVAL=

PitzKey · January 20, 2019, 3:25pm

Have you forwarded ports 10000-20000 to the PBX?

sorvani · January 20, 2019, 4:15pm

This is not needed for SIP trunk providers that use outbound registration. Also, he already has calls working with 2-way audio. So this kind of change would do nothing.

If he “tweaked things” to get from 15 minutes to 60 minutes, then he needs to look at whatever setting he changed from 900 to 3600 and then provide more detail.

lgaetz · January 20, 2019, 4:35pm

This is not accurate. While it is true that some providers will generally work without forwarding, a lot of providers don’t proxy media thru the signalling host and will experience one-way audio without ports forwarded. Even in cases where media and signalling come from the same IP, there are certain call scenarios where audio will fail if port forwarding is not in place as I described once in this post.

sorvani · January 20, 2019, 4:38pm

For many providers, this is not a requirement.
Is that better?

But also this has nothing to do with the OP’s issue as he has 2-way audio.

PitzKey · January 20, 2019, 4:48pm

One of the things that causes phone calls to drop is “due to the lack of RTP”. IMO: RTP is very tricky, you can sometimes have full audio even tho you didn’t forward ports properly, but this will cause issues every here and there.

sorvani · January 20, 2019, 4:55pm

Things are not magic. It does not work sometimes and sometimes not.

If there is two way audio, then the port mapping is in place and working.
If it then stops, something is dropping it. In this case something in pfSense.

The OP changed some settings and things went from 15 minutes (900 seconds) to 60 minutes (3600 seconds). This clearly tells you that something in the settings is killing things.

BlazeStudios · January 20, 2019, 4:59pm

I believe there are a couple things that everyone has glanced over during all of this.

The OP is using PFSense. This is notoriously bad for handling SIP/NAT, etc. As I’ve said in other posts, in the IRC channels (#freepbx, #asterisk) when people have issues like this and they have pfsense, 99% of the time it’s pfsense. Sure they fight and say “pfsense works fine” but the moment you have them do things like bypass it or use another router, the issues go away soooo.
The issues where happening with calls dropping after 15mins and now they are about an hour or so before dropping. Welcome to re-INVITEs. The first re-INVITE generally happens around the 10-15 minute marker of the call and depending on the provider could happen every 15 or even more minutes to make sure everything is where it still is supposed to be.

So since this is happening on “long calls” and in time intervals that are standard “on-boarding” checks most Carriers do with their wholesalers/partners these tests are to rule out any networking/NAT or other issues that might happen during “long calls” like re-INVITEs and updates. AND there are two PBXes and both are sitting behind pfsense I’m going with this is a NAT/network issue and it is 100% going to be based on the pfsense config(s) (one or both routers).

Because even if RTP is flowing on the call, once the carrier doesn’t get signalling responses during those re-INVITE/UPDATEs they will drop the call as well. That’s how a SIP call works, both the signaling and the media need to be responsive to requests/updates during the call. If either of those fail to respond the call can be dropped.

Basically a dropped call doesn’t mean audio stopped.

mgbolts · January 21, 2019, 1:10am

@pitzkey - I have not port forwarded or opened these ports to the pabx server as its operating from within the trusted LAN. The server is registering outbound to the sip provider. I have not seen anything odd to suggest that the FW is blocking traffic on the basis of the ports (so far ) .

That said, there is a lot of chatter in the logs regarding RTP which I do not understand. I am guessing this could be exactly related to the point made regarding not all required ports being opened. Fortunately, this does not appear to have impacted the calls at this time. Once I have the basic server bedded down, I will shift to a VLAN with improved security rules and open some ports up… I did not want to start opening ports on the main LAN if I did not need to at this stage.

BTW, as of a couple of hours ago (Monday morning here now), the SIP provider support has responded. They had restricted calls to max of 60 minutes. Now that this is lifted, I will test again.

Thank you everyone for their assistance and sorry to waste your time…

Regards

PitzKey · January 21, 2019, 6:07am

Exactly. Asterisk can sometimes drop calls due to the lack of RTP activity.

You posted a log only from the point where the call is already getting disconnected. Can you post a full call log?

You don’t have to open these ports publicly, you can allow it from your vendor IPs only.

mgbolts · January 21, 2019, 8:20am

I will certainly post logs that I have (in a few hrs). I am not sure that I can post the full dropped call (other than above) as the issue is now resolved by my provider.

Your point on VLAN ports is well noted. I also need to monitor provider IP for a little while to make sure its not shifting over time.

PitzKey · January 21, 2019, 8:23am

Most providers can give their IP(s), it’s a very common request.

I’m not sure about the firewall you use, but some firewalls allow you to open traffic from a FQDN.

system · January 28, 2019, 8:23am

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