Inbound Calls Not Working / Rejected

[DavidShaw]

Hi Huys,

1. I have setup a SIP Trunk which works for outbound, however inbound is being rejected.
2. I have added the providers IPs in the ACL. (see attached image) note I do not have a section called Nodes under ACL
3. The username for the SIP trunk is alphanumeric.
4. I tried changing the Domain Details (under default settings) "Type" from "boolean" to "sip_to_user" found in successful outbound calls.
5. 
   
6. 
7. This is my event log.

3-19 14:35:49.730119 [DEBUG] switch_core_state_machine.c:585 (sofia/internal/90009000@18.135.164.97) Running State Change CS_REPORTING (Cur 1 Tot 167501)
63d52002-cf16-4e49-a9ea-c004ce115143 2021-03-19 14:35:49.730119 [DEBUG] switch_core_state_machine.c:936 (sofia/internal/90009000@18.135.164.97) State REPORTING
63d52002-cf16-4e49-a9ea-c004ce115143 2021-03-19 14:35:49.730119 [DEBUG] switch_core_state_machine.c:174 sofia/internal/90009000@18.135.164.97 Standard REPORTING, cause: WRONG_CALL_STATE
63d52002-cf16-4e49-a9ea-c004ce115143 2021-03-19 14:35:49.730119 [DEBUG] switch_core_state_machine.c:936 (sofia/internal/90009000@18.135.164.97) State REPORTING going to sleep
63d52002-cf16-4e49-a9ea-c004ce115143 2021-03-19 14:35:49.730119 [DEBUG] switch_core_state_machine.c:611 (sofia/internal/90009000@18.135.164.97) State Change CS_REPORTING -> CS_DESTROY
63d52002-cf16-4e49-a9ea-c004ce115143 2021-03-19 14:35:49.730119 [DEBUG] switch_core_session.c:1726 Session 167500 (sofia/internal/90009000@18.135.164.97) Locked, Waiting on external entities
63d52002-cf16-4e49-a9ea-c004ce115143 2021-03-19 14:35:49.730119 [NOTICE] switch_core_session.c:1744 Session 167500 (sofia/internal/90009000@18.135.164.97) Ended
63d52002-cf16-4e49-a9ea-c004ce115143 2021-03-19 14:35:49.730119 [NOTICE] switch_core_session.c:1748 Close Channel sofia/internal/90009000@18.135.164.97 [CS_DESTROY]
63d52002-cf16-4e49-a9ea-c004ce115143 2021-03-19 14:35:49.730119 [DEBUG] switch_core_state_machine.c:739 (sofia/internal/90009000@18.135.164.97) Running State Change CS_DESTROY (Cur 0 Tot 167501)
63d52002-cf16-4e49-a9ea-c004ce115143 2021-03-19 14:35:49.730119 [DEBUG] switch_core_state_machine.c:749 (sofia/internal/90009000@18.135.164.97) State DESTROY
63d52002-cf16-4e49-a9ea-c004ce115143 2021-03-19 14:35:49.730119 [DEBUG] mod_sofia.c:364 sofia/internal/90009000@18.135.164.97 SOFIA DESTROY
63d52002-cf16-4e49-a9ea-c004ce115143 2021-03-19 14:35:49.730119 [DEBUG] switch_core_state_machine.c:181 sofia/internal/90009000@18.135.164.97 Standard DESTROY
63d52002-cf16-4e49-a9ea-c004ce115143 2021-03-19 14:35:49.730119 [DEBUG] switch_core_state_machine.c:749 (sofia/internal/90009000@18.135.164.97) State DESTROY going to sleep
2021-03-19 14:35:53.810139 [DEBUG] sofia_reg.c:2458 Changing expire time to 799 by request of proxy sip:st.voicehost.co.uk
2021-03-19 14:35:57.430095 [WARNING] sofia_reg.c:1794 SIP auth challenge (REGISTER) on sofia profile 'internal' for [248@18.135.164.97] from ip 143.244.57.72
2021-03-19 14:35:57.470096 [WARNING] sofia_reg.c:2930 Can't find user [248@18.135.164.97] from 143.244.57.72
You must define a domain called '18.135.164.97' in your directory and add a user with the id="248" attribute
and you must configure your device to use the proper domain in its authentication credentials.
2021-03-19 14:35:57.470096 [WARNING] sofia_reg.c:1739 SIP auth failure (REGISTER) on sofia profile 'internal' for [248@18.135.164.97] from ip 143.244.57.72
15a1c666-e495-4b53-a6f4-10b6b45a6cb2 2021-03-19 14:35:58.470091 [NOTICE] switch_channel.c:1118 New Channel sofia/external/53301@18.135.164.97 [15a1c666-e495-4b53-a6f4-10b6b45a6cb2]
15a1c666-e495-4b53-a6f4-10b6b45a6cb2 2021-03-19 14:35:58.470091 [DEBUG] switch_core_state_machine.c:585 (sofia/external/53301@18.135.164.97) Running State Change CS_NEW (Cur 1 Tot 167502)
15a1c666-e495-4b53-a6f4-10b6b45a6cb2 2021-03-19 14:35:58.470091 [DEBUG] sofia.c:10280 sofia/external/53301@18.135.164.97 receiving invite from 89.190.156.71:52180 version: 1.10.5 -release-17-25569c1631 64bit
2021-03-19 14:35:58.470091 [DEBUG] sofia.c:10374 verifying acl "domains" for ip/port 89.190.156.71:0.
2021-03-19 14:35:58.470091 [DEBUG] sofia.c:2434 detaching session 15a1c666-e495-4b53-a6f4-10b6b45a6cb2
15a1c666-e495-4b53-a6f4-10b6b45a6cb2 2021-03-19 14:35:58.470091 [DEBUG] switch_core_state_machine.c:604 (sofia/external/53301@18.135.164.97) State NEW
2021-03-19 14:35:58.470091 [DEBUG] sofia.c:2544 Re-attaching to session 15a1c666-e495-4b53-a6f4-10b6b45a6cb2
15a1c666-e495-4b53-a6f4-10b6b45a6cb2 2021-03-19 14:35:58.490128 [DEBUG] sofia.c:10280 sofia/external/53301@18.135.164.97 receiving invite from 89.190.156.71:52180 version: 1.10.5 -release-17-25569c1631 64bit
2021-03-19 14:35:58.490128 [DEBUG] sofia.c:10374 verifying acl "domains" for ip/port 89.190.156.71:0.
2021-03-19 14:35:58.490128 [WARNING] sofia_reg.c:2930 Can't find user [53301@18.135.164.97] from 89.190.156.71


My external SIP Profile port is 5080, this is the provider log, their port is 5060, will this effect things baring in mind i can dial out, further I tried changing to port 5060 and the profile would not start. I would like to add that my provider says they are receiving a Proxy Authentication Required rejection from the PBX, I see the field Proxy mandatory when setting up the gateway?

 

[KitchM]

One of the problems that people forget (although I do not know if this is yours), is that there are four areas of possible communications blockages. These include, in order; router firewall, Netfilter iptables, Fail2Ban and ACL.

Make sure to port-forward any provider's IP addresses with their protocols and necessary port(s), only. Do this in your router. Then go to the iptables and just block everything coming in except for your necessary items again, but allow all outgoing. You probably do not need to do anything with Fail2Ban. Finally add the same items in your ACL you had in your port-forwarding.

This process will eliminate any issues with the communication channel(s).

 

[DavidShaw]

This is my settings for IPTABLES which I have never changed, It seems the IPTABLE accepting all traffic? It is an AWS Debian instance which sits behind the AWS firewall which I have already configured the correct ports etc.

Chain INPUT (policy DROP)
target prot opt source destination
f2b-nginx-dos all -- anywhere anywhere
f2b-nginx-404 all -- anywhere anywhere
f2b-fusionpbx-mac all -- anywhere anywhere
f2b-fusionpbx all -- anywhere anywhere
f2b-sip-auth-failure all -- anywhere anywhere
f2b-sshd all -- anywhere anywhere
f2b-freeswitch all -- anywhere anywhere
f2b-sshd tcp -- anywhere anywhere multiport dports ssh
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
DROP udp -- anywhere anywhere udp dpts:sip:5091 STRING match "friendly-scanner" ALGO name bm TO 65535 I
CASE
DROP tcp -- anywhere anywhere tcp dpts:sip:5091 STRING match "friendly-scanner" ALGO name bm TO 65535 I
CASE
DROP udp -- anywhere anywhere udp dpts:sip:5091 STRING match "sipcli/" ALGO name bm TO 65535 ICASE
DROP tcp -- anywhere anywhere tcp dpts:sip:5091 STRING match "sipcli/" ALGO name bm TO 65535 ICASE
DROP udp -- anywhere anywhere udp dpts:sip:5091 STRING match "VaxSIPUserAgent/" ALGO name bm TO 65535 I
CASE
DROP tcp -- anywhere anywhere tcp dpts:sip:5091 STRING match "VaxSIPUserAgent/" ALGO name bm TO 65535 I
CASE
DROP udp -- anywhere anywhere udp dpts:sip:5091 STRING match "pplsip" ALGO name bm TO 65535 ICASE
DROP tcp -- anywhere anywhere tcp dpts:sip:5091 STRING match "pplsip" ALGO name bm TO 65535 ICASE
DROP udp -- anywhere anywhere udp dpts:sip:5091 STRING match "system " ALGO name bm TO 65535 ICASE
DROP tcp -- anywhere anywhere tcp dpts:sip:5091 STRING match "system " ALGO name bm TO 65535 ICASE
DROP udp -- anywhere anywhere udp dpts:sip:5091 STRING match "exec." ALGO name bm TO 65535 ICASE
DROP tcp -- anywhere anywhere tcp dpts:sip:5091 STRING match "exec." ALGO name bm TO 65535 ICASE
DROP udp -- anywhere anywhere udp dpts:sip:5091 STRING match "multipart/mixed;boundary" ALGO name bm TO
65535 ICASE
DROP tcp -- anywhere anywhere tcp dpts:sip:5091 STRING match "multipart/mixed;boundary" ALGO name bm TO
65535 ICASE
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
ACCEPT tcp -- anywhere anywhere tcp dpt:http
ACCEPT tcp -- anywhere anywhere tcp dpt:https
ACCEPT tcp -- anywhere anywhere tcp dpt:7443
ACCEPT tcp -- anywhere anywhere tcp dpts:sip:5091
ACCEPT udp -- anywhere anywhere udp dpts:sip:5091
ACCEPT udp -- anywhere anywhere udp dpts:16384:32768
ACCEPT icmp -- anywhere anywhere icmp echo-request
ACCEPT udp -- anywhere anywhere udp dptpenvpn

 

[KitchM]

AWS? Apache Web Server? What are you doing with that on you telephony server?

 

[DavidShaw]

Amazon Web Services, like Azure... Haha

 

[KitchM]

Ah, I get it. Thanks David.

None of my business, but I wonder why not host it internally. Are you creating a PBX for your own business or for others?

The way I see it is that I would want my telephones as closely connected to my PBX as possible. No need to increase latency.

 

[DavidShaw]

Ah, I get it. Thanks David.

None of my business, but I wonder why not host it internally. Are you creating a PBX for your own business or for others?

The way I see it is that I would want my telephones as closely connected to my PBX as possible. No need to increase latency.

Don't want to drift off topic, but in short geo redundancy amongst other things.

 

[DigitalDaz]

That ACL is completely wrong, firstly, I see domain names in the same rows as IP, this should never be the case, there should be one entry and in that case nothing in the ip field. Secondly, I see IPs in there that are not CIDRs. Every entry should be a CIDR so /32 for a single host.

 

[DavidShaw]

That ACL is completely wrong, firstly, I see domain names in the same rows as IP, this should never be the case, there should be one entry and in that case nothing in the ip field. Secondly, I see IPs in there that are not CIDRs. Every entry should be a CIDR so /32 for a single hos

 

[KitchM]

I believe he means that there appears to be both in the table in your first comment. My instructions are as follows:
"Basically, Fusion needs to have the SIP provider’s IP address(es) included. Select Add. On the next screen put in the name, the default to “allow”, the type of “allow” and the CIDR notation which is the address followed by /32 as required by the software. This notation will look something like 192.168.1.1/32. Give it a description if you want and then click Save."
These are the basic steps, which will work. Note that the domain field is not necessary.

 

[DavidShaw]

Thanks for the reply Daz! I see it clearly states this in the Docs my bad...

1) Would this be valid for DOMAINS with different providers under the same AC (Node) see below, for some reason my version has does not call them Nodes...

2) If we add the Domains do we still need the CIDRs for the provider in a separate AC/NODE?
3) Do the CIDRs always have to end in /32 and not a number less than 32? My SIP provider gives me the following when asking for their CIDRs (see below),

4) If 3the above is incorrect do I just need to add/32 to their IP addresses for their Trunk/SBC

 

[DavidShaw]

Ok I have answered question 3 and that provider is working with the above CIDRs ending in /25 and /28.

 

[DavidShaw]

I got both working by just adding /32 to the other provider's "POP" IP. If im not mistaken I think CIDRs need to be added to the AC/Node called Domains under the CIDR field of course as you explain. I was also creating a AC per provider, but haven't replicated it... I just deleted everything under the Domain AC/Node and just added CIDRs and done, life is good now Thanks for the help friends.