Hi guy,
I want to make a outbound call from 2000@Test (SIP domain on Fusionpbx) → Astpp → ITSP but failed (403 forbiden). I ve set sip_h_X-accountcode=1256093879, it is parameter correct?
Can you guy have a correct setting for outbound call from any SIP domain on my multitenant FusionPBX?
If you use trusted IP of the FusionPBX, will you still be able to use the Account Code SIP Header to map to the correct User billing account in ASTPP?
what do you see in fs_cli when you make the test call?
it might give you some more insight as to why the call is failing.
Can you give me a correct setting? I had set sip device of ASTPP in FBX by using two field as shown in the picture I have attached. But when making a call, it ignores the fields I have declared and runs straight to the gateway to ASTPP and only runs the default account that was available when I installed astpp, if I create a new customer and disable the default customer then it doesn’t run
He asked to see the output of FreeSwitch. I suggest you post both from FusionPBX and ASTPP sides.
@tai36 i have just checked the astpp.dialplan.lua, the code snippet:
if (accountcode == nil or accountcode == “”) then
accountcode = params:getHeader(“variable_sip_h_P-Accountcode”)
end
so you need to change the setting on FusionPBX from sip_h_accountcode to:
sip_h_P-Accountcode=4727985745
@NormanMichaelis, It does indeed appear in the SIP report, but it’s not functioning as expected. I need Astpp to verify the username and password of the SIP device associated with the customer’s account configured on the PBX. Afterward, it should use the phone number declared in the SIP devices’ Caller Number field to make calls to the ISP.
As for Astpp’s current operation, it doesn’t pay attention to which account code I use on the PBX. It only requires that the PBX’s IP address be allowed in ASTPP’s white IP list, and it will pass calls through directly to the end IP. One important note is that outbound numbers must be configured within the PBX; if I configure them in the SIP device, ASTPP doesn’t recognize them.
@tai36 - can you remove the Trusted IP Mapping in the ASTPP, and run fs_cli on the ASTPP, then do your test call… you can upload the screen debug and we can have a look to see what is happening in the ASTPP, the sngrep is only showing the final output of what is happening, and not the full story.
Here is full story of ASTPP by using command fs_cli and turn of the whitelist ip
2023-09-21 16:48:42.396534 100.00% [NOTICE] switch_channel.c:1142 New Channel sofia/default/842488899207@68.183.184.86 [7662bc11-8855-45fa-b9db-2a9862f5c302]
2023-09-21 16:48:42.396534 100.00% [DEBUG] switch_core_state_machine.c:581 (sofia/default/842488899207@68.183.184.86) Running State Change CS_NEW (Cur 1 Tot 4828)
2023-09-21 16:48:42.396534 100.00% [INFO] sofia.c:10459 sofia/default/842488899207@68.183.184.86 receiving invite from 68.183.184.86:5080 version: 1.10.10 -release-24-4cb05e7f4a 64bit call-id: e3d3545e-d306-123c-4894-32140a4dcc2d
2023-09-21 16:48:42.396534 100.00% [DEBUG] sofia.c:10553 verifying acl “default” for ip/port 68.183.184.86:0.
2023-09-21 16:48:42.396534 100.00% [WARNING] sofia_reg.c:1842 SIP auth challenge (INVITE) on sofia profile ‘default’ for [84964348489@210.211.108.10] from ip 68.183.184.86
2023-09-21 16:48:42.396534 100.00% [DEBUG] switch_core_state_machine.c:600 (sofia/default/842488899207@68.183.184.86) State NEW
2023-09-21 16:48:42.396534 100.00% [DEBUG] sofia.c:2419 detaching session 7662bc11-8855-45fa-b9db-2a9862f5c302
2023-09-21 16:48:42.436536 100.00% [DEBUG] sofia.c:2532 Re-attaching to session 7662bc11-8855-45fa-b9db-2a9862f5c302
2023-09-21 16:48:42.456535 100.00% [INFO] sofia.c:10459 sofia/default/842488899207@68.183.184.86 receiving invite from 68.183.184.86:5080 version: 1.10.10 -release-24-4cb05e7f4a 64bit call-id: e3d3545e-d306-123c-4894-32140a4dcc2d
2023-09-21 16:48:42.456535 100.00% [DEBUG] sofia.c:10553 verifying acl “default” for ip/port 68.183.184.86:0.
2023-09-21 16:48:42.476516 100.00% [WARNING] sofia_reg.c:3210 Can’t find user [admin@210.211.108.10] from 68.183.184.86
You must define a domain called ‘210.211.108.10’ in your directory and add a user with the id=“admin” attribute
and you must configure your device to use the proper domain in its authentication credentials.
2023-09-21 16:48:42.476516 100.00% [WARNING] sofia_reg.c:1787 SIP auth failure (INVITE) on sofia profile ‘default’ for [84964348489@210.211.108.10] from ip 68.183.184.86
2023-09-21 16:48:42.476516 100.00% [NOTICE] sofia.c:2417 Hangup sofia/default/842488899207@68.183.184.86 [CS_NEW] [CALL_REJECTED]
2023-09-21 16:48:42.496536 100.00% [DEBUG] sofia.c:1527 Channel is already hungup.
2023-09-21 16:48:42.496536 100.00% [DEBUG] switch_core_state_machine.c:581 (sofia/default/842488899207@68.183.184.86) Running State Change CS_HANGUP (Cur 1 Tot 4828)
2023-09-21 16:48:42.496536 100.00% [DEBUG] switch_core_state_machine.c:844 (sofia/default/842488899207@68.183.184.86) Callstate Change DOWN → HANGUP
2023-09-21 16:48:42.496536 100.00% [DEBUG] switch_core_state_machine.c:846 (sofia/default/842488899207@68.183.184.86) State HANGUP
2023-09-21 16:48:42.496536 100.00% [DEBUG] mod_sofia.c:469 Channel sofia/default/842488899207@68.183.184.86 hanging up, cause: CALL_REJECTED
2023-09-21 16:48:42.496536 100.00% [DEBUG] switch_core_state_machine.c:59 sofia/default/842488899207@68.183.184.86 Standard HANGUP, cause: CALL_REJECTED
2023-09-21 16:48:42.496536 100.00% [DEBUG] switch_core_state_machine.c:846 (sofia/default/842488899207@68.183.184.86) State HANGUP going to sleep
2023-09-21 16:48:42.496536 100.00% [DEBUG] switch_core_state_machine.c:616 (sofia/default/842488899207@68.183.184.86) State Change CS_HANGUP → CS_REPORTING
2023-09-21 16:48:42.496536 100.00% [DEBUG] switch_core_state_machine.c:581 (sofia/default/842488899207@68.183.184.86) Running State Change CS_REPORTING (Cur 1 Tot 4828)
2023-09-21 16:48:42.496536 100.00% [DEBUG] switch_core_state_machine.c:932 (sofia/default/842488899207@68.183.184.86) State REPORTING
2023-09-21 16:48:42.496536 100.00% [DEBUG] switch_core_state_machine.c:168 sofia/default/842488899207@68.183.184.86 Standard REPORTING, cause: CALL_REJECTED
2023-09-21 16:48:42.496536 100.00% [DEBUG] switch_core_state_machine.c:932 (sofia/default/842488899207@68.183.184.86) State REPORTING going to sleep
2023-09-21 16:48:42.496536 100.00% [DEBUG] switch_core_state_machine.c:607 (sofia/default/842488899207@68.183.184.86) State Change CS_REPORTING → CS_DESTROY
2023-09-21 16:48:42.496536 100.00% [DEBUG] switch_core_session.c:1744 Session 4828 (sofia/default/842488899207@68.183.184.86) Locked, Waiting on external entities
2023-09-21 16:48:42.496536 100.00% [NOTICE] switch_core_session.c:1762 Session 4828 (sofia/default/842488899207@68.183.184.86) Ended
2023-09-21 16:48:42.496536 100.00% [NOTICE] switch_core_session.c:1766 Close Channel sofia/default/842488899207@68.183.184.86 [CS_DESTROY]
2023-09-21 16:48:42.496536 100.00% [DEBUG] switch_core_state_machine.c:735 (sofia/default/842488899207@68.183.184.86) Running State Change CS_DESTROY (Cur 0 Tot 4828)
2023-09-21 16:48:42.496536 100.00% [DEBUG] switch_core_state_machine.c:745 (sofia/default/842488899207@68.183.184.86) State DESTROY
2023-09-21 16:48:42.496536 100.00% [DEBUG] mod_sofia.c:380 sofia/default/842488899207@68.183.184.86 SOFIA DESTROY
2023-09-21 16:48:42.496536 100.00% [DEBUG] switch_core_state_machine.c:175 sofia/default/842488899207@68.183.184.86 Standard DESTROY
2023-09-21 16:48:42.496536 100.00% [DEBUG] switch_core_state_machine.c:745 (sofia/default/842488899207@68.183.184.86) State DESTROY going to sleep
@tai36 - thanks for the log.
does the client/tenant have there own registered Trunk (username/password) with ASTPP?
if so, then in each tenant on FusionPBX, you need to add a gateway with there own username and password, and use that trunk in the outbound routes.
Below is one of my clients profiles on FusionPBX…
And on the our bound route:
i have, from that server 30 trunks to the same ASTPP…
on the ASTPP, i have setup each client a SIP Device, and not a Trusted IP or using the AccountCode Method.
*Note, i am aware i have left the password etc in the images, but all info/IP are not accessible from the internet, only internally, we use internal DNS servers… for a .local FQDNs
These actions must be removed:
they are not used in the way you think… They are ‘informational’ and not ‘operational’
Everything is fine when I create a trunk and test calling using the first sip device of the account code, but starting from the second trunk, it reports an error and cannot connect. I have tried creating a main trunk on the main domain and separate trunks for the subdomains, but it still gives me a gateway failure error. How can you create up to 30 trunks without encountering gateway failure? I have 1 main domain and two subdomain
It will report an error if I create a second trunk pointing to the same IP.
@tai36 if the second trunk is also using Username/Password for the Gateway (on FusionPBX), it should not give that error, it could be becasue the second trunk looks like its using trusted IP.
Try delete the second trunk, and recreate it from scratch, i have had an issue before where i copied one to another.
below is one of my tenants, that has 11 gateways to the same ASTPP.
There could be two ways of authenticating and connecting pbx with ASTPP.
IP based:
Here, you can add IP of pbx in IP-Setting of ASTPP and bind with one of the account of ASTPP. Now if you want another account of ASTPP to be bound with different customer/tenant’s calls from the same PBX then you will add all the IP-settings entries of that PBX IP with prefix and configure the dialplan in PBX such that when calls routing from PBX to ASTPP then it will be that prefix only which you are configured in IP-settings of ASTPP. So different prefix for different customer/tenant of PBX.
This way customer/tenant can be one-2-one bound with ASTPP customer account.
Device/extension based:
You can use as many sip device as trunk/gateway on pbx side of ASTPP, use the different customer’s sip device as trunk/gateway in PBX for different customer/tenant.
