Incoming calls when the provider's IP addresses are unknown

Status
Not open for further replies.
D

Daniel

New Member
Oct 30, 2018
12
1
3
49
Dear all,

I have a question about the logic of gateway registrations and incoming calls. For me and probably many others too, the FusionPBX is connected to the LAN and through a NAT device makes a SIP registration with a user name and password with a SIP provider. This connection is maintained by the FusionPBX and re-established if necessary.
An incoming call is signaled backwards via this connection.
Nevertheless, the FusionPBX apparently expects the IP addresses of the SIP provider to be specified under "Access Control - providers" so that the incoming connections are also accepted.
At least Deutsche Telekom does not commit itself to the IP addresses of their SIP servers and would like to remain flexible here. My first approach was to make an allow entry for 0.0.0.0/0 under "providers". However, this means that outgoing calls are seen as incoming, because the internal telephones fall into this address range. Apparently there is no order for the access control entries?
I found a note for the following settings in the external SIP profile:
apply-inbound-acl: Enabled=False
auth-calls: Value=False
So it worked first, then only after restarting the SIP profile and now not at all.
Before I post specific log files, please tell me how I should theoretically configure it "correctly" if the provider does not specify IP addresses and incoming calls are only signaled backwards via the SIP registration.
Best regards
Daniel
 
DigitalDaz

DigitalDaz

Administrator
Staff member
Sep 29, 2016
3,044
565
113
If you are using registration to the provider there should be no reason to mess with any of this.

What could be happening is NAT timeouts on your router. Try setting the expire timeout on the gateway to something like 120, that will keep the registration to the provider fresh.

Don't forget to stop and start the gateway after the change.

Do not mess with the ACLs, it is asking for trouble.
 
D

Daniel

New Member
Oct 30, 2018
12
1
3
49
DigitalDaz said:
If you are using registration to the provider there should be no reason to mess with any of this.

What could be happening is NAT timeouts on your router. Try setting the expire timeout on the gateway to something like 120, that will keep the registration to the provider fresh.

Don't forget to stop and start the gateway after the change.

Do not mess with the ACLs, it is asking for trouble.
Click to expand...
Thanks a lot for your quick help. I tried back and forth again. Now I can say that it definitely doesn't work for me with the default settings. According to the log file, a missing matching of the IP address leads to a 407 Proxy Authentication Required:

2023-06-25 18:45:15.819481 95.53% [DEBUG] sofia.c:10547 verifying acl "providers" for ip/port 217.0.130.69:0.
nua.c:878 nua_respond() nua: nua_respond: entering
nua_stack.c:601 nua_stack_signal() nua(0x55f8eb672530): recv signal r_respond 407 Proxy Authentication Required

It only works with
apply-inbound-acl: enabled=false
auth-calls: value=false

I hope that with these settings behind a NAT firewall there is no risk ;-)
 
DigitalDaz

DigitalDaz

Administrator
Staff member
Sep 29, 2016
3,044
565
113
If register is being used and the traffic is coming back to port 5080 then the implication is that port address translation is not being used, either that or some sort of ALG is in play though I doubt it because of the port 5080.

Are you able to switch the transport to TCP? That would almost certainly switch the source port from 5080.
 
Status
Not open for further replies.
Top Bottom