Outgoing Calls Work, Incoming Calls Fail

[Reptilead]

Outgoing calls work, incoming calls fail. PBX appears to answer then hangs up.

• SIP Provider sends incoming calls to 5060
• SIP Provider (50.18.202.17) in ACL Domains

https://pastebin.com/raw/SrEbjJbv

I have been banging on this for several days and cannot figure out what is wrong. I would greatly appreciate any thoughts and I have made this post, and the log file, clean and neat out of respect for your time. Typically we use Asterisk/FreePBX but I would like to begin using FreeSwitch/FusionPBX so I'd like this machine to work well.

I would sincerely appreciation any help or thoughts. Kindest Regards.

 

[Andrew Pickett]

Few of things to check.

In ACL have you used full cidr range and reloaded your ACL - can be done in sip status.

Are you behind Nat and configured your ip properly in variables?

Have you checked fail2ban ( just in case )

You say inbound connects briefly. Please share log. you can run trace in sngrep and print results here.

 

[Andrew Pickett]

Sorry seen trace now

 

[Reptilead]

1. It's hosted on AWS Lightsail and is set to be fully exposed.
2. Behavior is unchanged when fail2ban is disabled. Will keep f2b disabled for now.
3. CIDR: 50.18.202.17/32 (correct?)
4. pcap of failed incoming call: http://files.jackalcorp.com/incoming_fail.pcap

Thank you for telling me about sngrep. I did not know about it and it's a very helpful tool. I sincerely appreciate your help, sir. It's very kind of you to take time out of your day.

 

[DigitalDaz]

Well, firstly you have compression on the headers, why is that?

 

[Reptilead]

I did not ask for header compression (am not sure what they are), and cannot find a way to disable it.

It should be close to the default setup. Did you see compressed headers in the pcap file or the pastebin? The pcap may be more reliable.

It's nice to hear from you DigitalDaz. While I was setting up my server I frequently came across this forum and threads you contributed to. I appreciate your time.

 

[brb5548]

You try routing to a simple extension to confirm that works? Quick review makes me think the dial plan needs some scrutiny.

 

[Matthew Main]

When you say inbound call are you talking about internal or external?

internal calls should be via 5060 - i.e EXT 2000 calling 2001
external calls should be hitting 5080 - i.e calling 442395 443256 being picked up by EXT 2000

it looks like you have an external calls hitting 5060 and not 5080
INVITE sip:+16664444444@34.220.78.250:5060;user=phone;transport=UDP SIP/2.0

 

[brb5548]

I think that is the preferred approach (for several reasons like sofia thread performance or if you are behind a nat and have internal phones) but depending upon the authentication requirements of your trunk provider, the internal profile needs to be used. Specifically in my experience, you have to use the internal profile for providers like Flowroute and Twilio.
Disclaimer: I am still learning so, please don't hesitate to correct me.

 

[brb5548]

@Matthew Main I stand corrected. I went back and did some further testing with using the external profile and twilio (changing port 5080) and it works just fine. I always thought digest authentication would not work (without additional configuration) using the external profile.

 

[Reptilead]

@Matthew Main I believe external calls (from PSTN via SIP Provider) are hitting 5060.

I read this was acceptable if the provider was listed in ACL Domains.

I have attempted to switch the ports so that Zoiper (Android App) and Hardware Phones hit Internal Profile on 5080 and SIP Provider hits External Profile on 5060, but after changing the 4 variables on "Advanced -> Variables" (and restarting the server) I find nothing works.

• I still cannot receive calls from the SIP Provider
• I cannot configure the phones to make successful calls to the server no matter how I set them.

If you believe it would be valuable I could switch the variables, restart the server, and post a pcap file of what happens when SIP Provider hits External Profile on 5060.

 

[markjcrane]

Switching internal from 5060 to 5080 and external 5080 to 5060 ports isn't needed and will just make things harder for you to get working.
Just use 5060 for internal as it is by default and then set the domains access control list (Menu -> Advanced -> Access Controls) to accept the CIDR range of your provider IP addresses. Often this is done by adding the IP address with xxx.xxx.xxx.xxx/32 (represents one IP address) and then reloadacl can be done from Menu -> Status -> SIP Status.

If your server is on a public IP address then the external profile is optional. It is more useful when the server is behind NAT.

 

[Matthew Main]

so I have all external calls from provider going to 2 x SRV records that are prioritised.

_sip._upd(or _tcp).inbound.domain.tld. ttl IN SRV "10" "10" "5080" pbx1.domain.tld.
_sip._udp(or _tcp).inbound.domain.tld ttl IN SRV "20" "10" "5080" pbx2.domain.tld.

so my provider points all traffic to inbound.domain.tld and all calls come in a hit on 5080, its then a simple case of adding the number in the correct format to the destinations in the domain. the job is done.

I only have Twilio running as an outbound on 1 server and have never used it for inbound. But I can guess that this way will work fine.

As Mark has already suggested keep it as simple as possible, Less to go wrong

 

[Reptilead]

Thank you gentlemen. Then I believe my server is in the ideal configuration.

The server has an external IP address, which was not recognized automatically so I have specified in "Advanced -> Variables."

It is similar to a VPS so I'm not sure if it would be accurate to say it has NAT routing.

 

[Matthew Main]

Yup its NAT, so is all working now?

 

[Reptilead]

@Matthew Main Regretfully it continues not work. I can't explain it and am very sad. It appears to answer calls PSTN calls from SIP provider and then hangs up as it attempts to connect audio.

 

[Starblazer]

On my google cloud instance I had to force the RTP audio IP address. .Advanced/Variables/IP addresses and then set both of them to 'true' with my public IP.

 

[Reptilead]

@Starblazer If you mean these two variables, I have already set them.

I am at quite a loss and am considering trying another hosting provider, or abandoning FusionPBX altogether. I would be willing to share the login credentials with someone if they would like to take a look at it.

 

[Starblazer]

I will dig more into my config tommorow. I remember having this issue but I forgot what all I did to fix it off the top of my head.

 

[Matthew Main]

@Starblazer If you mean these two variables, I have already set them.

I am at quite a loss and am considering trying another hosting provider, or abandoning FusionPBX altogether. I would be willing to share the login credentials with someone if they would like to take a look at it.

View attachment 580

Fusionpbx is extremely stable and is capable of far more than whats labled on the tin. Take a look at moving providers you will not be disapointed, if you want to try before you buy , then set up a digital ocean or vultr account, the £5 a month VPS is normally enough to get calls working and would handle an offices worth of calls