SOLVED other PBX as Gateway - inbound route: "Cant' find user"

[Tobias.F]

Hello,

I am migrating from 3CX to FusionPBX and can't get running the connection to the gateway.

My sip account is bound the the hardware provided by the internet provider (Fritz!Box). The way I am using this in combination with my currently running 3CX ist that I have set-up a sip account on the provider box for phone number I have and on 3CX a trunk connection to each of them. The same I wanted to realize with FusionPBX but I do not get the inbound running:

Can't find user [yyyyyyyyyyy@192.168.10.40] from 192.168.178.1
You must define a domain called '192.168.10.40' in your directory and add a user with the id="yyyyyyyyyyy" attribute and you must configure your device to use the proper domain in its authentication credentials.

The call from outside is arriving on the provider box and is arriving on FusionPBX. The external phone number I am calling from and the phone numbers I am calling to are shown correctly in the FusionPBX log. But something I wrong in the inbound routing.

Explanation:
192.168.178.1 is the IP of the provider box
192.168.10.40 is the IP of FusionPBX
xxxxxxxxxxx is the external number I am calling from
yyyyyyyyyyy is the number of the sip account I am dialing

Any idea?

Log:

bf3a4d0d-760d-42e9-a0c5-f6d9f27018d2 2024-03-24 15:46:14.945076 98.27% [NOTICE] switch_channel.c:1142 New Channel sofia/external/xxxxxxxxxxx@fritz.box [bf3a4d0d-760d-42e9-a0c5-f6d9f27018d2]
bf3a4d0d-760d-42e9-a0c5-f6d9f27018d2 2024-03-24 15:46:14.965049 100.00% [DEBUG] switch_core_state_machine.c:581 (sofia/external/xxxxxxxxxxx@fritz.box) Running State Change CS_NEW (Cur 1 Tot 15)
bf3a4d0d-760d-42e9-a0c5-f6d9f27018d2 2024-03-24 15:46:14.965049 98.23% [INFO] sofia.c:10459 sofia/external/xxxxxxxxxxx@fritz.box receiving invite from 192.168.178.1:5060 version: 1.10.11 -release 64bit call-id: 7EB0F79E93F6AF8E@192.168.178.1
2024-03-24 15:46:14.965049 98.23% [DEBUG] sofia.c:10553 verifying acl "providers" for ip/port 192.168.178.1:0.
bf3a4d0d-760d-42e9-a0c5-f6d9f27018d2 2024-03-24 15:46:14.965049 98.23% [DEBUG] switch_core_state_machine.c:600 (sofia/external/xxxxxxxxxxx@fritz.box) State NEW
2024-03-24 15:46:14.965049 98.23% [DEBUG] sofia.c:2419 detaching session bf3a4d0d-760d-42e9-a0c5-f6d9f27018d2
2024-03-24 15:46:14.965049 98.23% [DEBUG] sofia.c:2532 Re-attaching to session bf3a4d0d-760d-42e9-a0c5-f6d9f27018d2
bf3a4d0d-760d-42e9-a0c5-f6d9f27018d2 2024-03-24 15:46:14.985064 98.23% [INFO] sofia.c:10459 sofia/external/xxxxxxxxxxx@fritz.box receiving invite from 192.168.178.1:5060 version: 1.10.11 -release 64bit call-id: 7EB0F79E93F6AF8E@192.168.178.1
2024-03-24 15:46:14.985064 98.23% [DEBUG] sofia.c:10553 verifying acl "providers" for ip/port 192.168.178.1:0.
2024-03-24 15:46:15.045009 98.23% [WARNING] sofia_reg.c:3210 Can't find user [yyyyyyyyyyy@192.168.10.40] from 192.168.178.1
You must define a domain called '192.168.10.40' in your directory and add a user with the id="yyyyyyyyyyy" attribute
and you must configure your device to use the proper domain in its authentication credentials.
bf3a4d0d-760d-42e9-a0c5-f6d9f27018d2 2024-03-24 15:46:15.045009 98.23% [NOTICE] sofia.c:2417 Hangup sofia/external/xxxxxxxxxxx@fritz.box [CS_NEW] [CALL_REJECTED]
bf3a4d0d-760d-42e9-a0c5-f6d9f27018d2 2024-03-24 15:46:15.065016 98.23% [DEBUG] sofia.c:1527 Channel is already hungup.
bf3a4d0d-760d-42e9-a0c5-f6d9f27018d2 2024-03-24 15:46:15.065016 98.23% [DEBUG] switch_core_state_machine.c:581 (sofia/external/xxxxxxxxxxx@fritz.box) Running State Change CS_HANGUP (Cur 1 Tot 15)
bf3a4d0d-760d-42e9-a0c5-f6d9f27018d2 2024-03-24 15:46:15.065016 98.23% [DEBUG] switch_core_state_machine.c:844 (sofia/external/xxxxxxxxxxx@fritz.box) Callstate Change DOWN -> HANGUP
bf3a4d0d-760d-42e9-a0c5-f6d9f27018d2 2024-03-24 15:46:15.065016 98.23% [DEBUG] switch_core_state_machine.c:846 (sofia/external/xxxxxxxxxxx@fritz.box) State HANGUP
bf3a4d0d-760d-42e9-a0c5-f6d9f27018d2 2024-03-24 15:46:15.065016 98.23% [DEBUG] mod_sofia.c:469 Channel sofia/external/xxxxxxxxxxx@fritz.box hanging up, cause: CALL_REJECTED
bf3a4d0d-760d-42e9-a0c5-f6d9f27018d2 2024-03-24 15:46:15.065016 98.23% [DEBUG] switch_core_state_machine.c:59 sofia/external/xxxxxxxxxxx@fritz.box Standard HANGUP, cause: CALL_REJECTED
bf3a4d0d-760d-42e9-a0c5-f6d9f27018d2 2024-03-24 15:46:15.065016 98.23% [DEBUG] switch_core_state_machine.c:846 (sofia/external/xxxxxxxxxxx@fritz.box) State HANGUP going to sleep
bf3a4d0d-760d-42e9-a0c5-f6d9f27018d2 2024-03-24 15:46:15.065016 98.23% [DEBUG] switch_core_state_machine.c:616 (sofia/external/xxxxxxxxxxx@fritz.box) State Change CS_HANGUP -> CS_REPORTING
bf3a4d0d-760d-42e9-a0c5-f6d9f27018d2 2024-03-24 15:46:15.065016 98.23% [DEBUG] switch_core_state_machine.c:581 (sofia/external/xxxxxxxxxxx@fritz.box) Running State Change CS_REPORTING (Cur 1 Tot 15)
bf3a4d0d-760d-42e9-a0c5-f6d9f27018d2 2024-03-24 15:46:15.065016 98.23% [DEBUG] switch_core_state_machine.c:932 (sofia/external/xxxxxxxxxxx@fritz.box) State REPORTING
bf3a4d0d-760d-42e9-a0c5-f6d9f27018d2 2024-03-24 15:46:15.065016 98.23% [DEBUG] switch_core_state_machine.c:168 sofia/external/xxxxxxxxxxx@fritz.box Standard REPORTING, cause: CALL_REJECTED
bf3a4d0d-760d-42e9-a0c5-f6d9f27018d2 2024-03-24 15:46:15.065016 98.23% [DEBUG] switch_core_state_machine.c:932 (sofia/external/xxxxxxxxxxx@fritz.box) State REPORTING going to sleep
bf3a4d0d-760d-42e9-a0c5-f6d9f27018d2 2024-03-24 15:46:15.065016 98.23% [DEBUG] switch_core_state_machine.c:607 (sofia/external/xxxxxxxxxxx@fritz.box) State Change CS_REPORTING -> CS_DESTROY
bf3a4d0d-760d-42e9-a0c5-f6d9f27018d2 2024-03-24 15:46:15.065016 98.23% [DEBUG] switch_core_session.c:1744 Session 15 (sofia/external/xxxxxxxxxxx@fritz.box) Locked, Waiting on external entities
bf3a4d0d-760d-42e9-a0c5-f6d9f27018d2 2024-03-24 15:46:15.065016 98.23% [NOTICE] switch_core_session.c:1762 Session 15 (sofia/external/xxxxxxxxxxx@fritz.box) Ended
bf3a4d0d-760d-42e9-a0c5-f6d9f27018d2 2024-03-24 15:46:15.065016 98.23% [NOTICE] switch_core_session.c:1766 Close Channel sofia/external/xxxxxxxxxxx@fritz.box [CS_DESTROY]
bf3a4d0d-760d-42e9-a0c5-f6d9f27018d2 2024-03-24 15:46:15.065016 98.23% [DEBUG] switch_core_state_machine.c:735 (sofia/external/xxxxxxxxxxx@fritz.box) Running State Change CS_DESTROY (Cur 0 Tot 15)
bf3a4d0d-760d-42e9-a0c5-f6d9f27018d2 2024-03-24 15:46:15.065016 98.23% [DEBUG] switch_core_state_machine.c:745 (sofia/external/xxxxxxxxxxx@fritz.box) State DESTROY
bf3a4d0d-760d-42e9-a0c5-f6d9f27018d2 2024-03-24 15:46:15.065016 98.23% [DEBUG] mod_sofia.c:380 sofia/external/xxxxxxxxxxx@fritz.box SOFIA DESTROY
bf3a4d0d-760d-42e9-a0c5-f6d9f27018d2 2024-03-24 15:46:15.065016 98.23% [DEBUG] switch_core_state_machine.c:175 sofia/external/xxxxxxxxxxx@fritz.box Standard DESTROY
bf3a4d0d-760d-42e9-a0c5-f6d9f27018d2 2024-03-24 15:46:15.065016 98.23% [DEBUG] switch_core_state_machine.c:745 (sofia/external/xxxxxxxxxxx@fritz.box) State DESTROY going to sleep

 

[cagriaksu]

You need a domain on the system as "fritz.box" with the proper gateway(your fritz device.) or if you can configure your fritz box, make it report a different domain of your choice.

Most of this firsr issues end up being about domains and the ip's not being in the acl.

 

[Tobias.F]

Most of this firsr issues end up being about domains and the ip's not being in the acl.

Thank you. You made my day!

I believed that ACL was set correctly and still do not understand what any of the error and debug information in the log could be linked to ACL.
I checked again and found a typo in the provider acl.

It still is not yet running and I need to figure out how to set the inbound routes correctly. But I am a step closer.

 

[cagriaksu]

The thing in your logs are, your fritz box is sending the comunication as "yyyyyyyyyyy@192.168.10.40" which the fusionpbx is comparing against thedomains you have setup on your system, which I assume do not have a domain called "192.168.10.40" if you have given a domain name to your default domain, just change it back to this ip and try again.

Or maybe you are missing the user as yyyyyyyyyyy@192.168.10.40?

 

[Tobias.F]

Now inbound is running as well without and change. I only rebooted the system. Any configuration was not reloaded.

That is correct. "192.168.10.40" is not set-up as a domain. For testing I have set up a local domain that can be resolved to this IP and back. After having corrected the ACL this error message "can not find user" is gone.

Looks like all is solved now.