[BUG]

[WEBudoGT]

Describe the bug When making a call it fails with 480 Temporarily Unavailable

To Reproduce After creating a scenario with 2 SIP profiles (1 internal and 1 public), a gateway on the internal, inbound interconnection, routes and other stuff referred on this page: https://github.com/hnimminh/libresbc/discussions/39 Sending a call from the public profile for it to be routed to the only gateway defined, the call fails.

Actual behavior On fs_cli it shows the call being routed through the "access" context and then executing calling/main.lua After that, apparently the last thing it does ok is setting the variable X-LIBRE-INTCONNAME to the correct IN Interconnect. Then the channel gets destroyed. The libresbc log shows an error when running some redis stuff: redis error: ERR wrong number of arguments for 'scard' command

Expected behavior main.lua should process some other rules before failing

Log & Screenshots Freeswitch logs:

2022-01-20 05:17:12.050277 [DEBUG] mod_sofia.c:154 sofia/Public5060/webudo-laptop@X.X.X.X SOFIA ROUTING 2022-01-20 05:17:12.050277 [DEBUG] switch_core_state_machine.c:236 sofia/Public5060/webudo-laptop@X.X.X.X Standard ROUTING 2022-01-20 05:17:12.050277 [INFO] mod_dialplan_xml.c:637 Processing webudo-laptop ->XXXXXXXXXX in context access Dialplan: sofia/Public5060/webudo-laptop@X.X.X.X parsing [access->access_to_any] continue=false Dialplan: sofia/Public5060/webudo-laptop@X.X.X.X Action lua(callng/main.lua) 2022-01-20 05:17:12.050277 [DEBUG] switch_core_state_machine.c:287 (sofia/Public5060/webudo-laptop@X.X.X.X) State Change CS_ROUTING -> CS_EXECUTE 2022-01-20 05:17:12.050277 [DEBUG] switch_core_state_machine.c:644 (sofia/Public5060/webudo-laptop@X.X.X.X) State ROUTING going to sleep 2022-01-20 05:17:12.050277 [DEBUG] switch_core_state_machine.c:585 (sofia/Public5060/webudo-laptop@X.X.X.X) Running State Change CS_EXECUTE (Cur 1 Tot 5) 2022-01-20 05:17:12.050277 [DEBUG] switch_core_state_machine.c:651 (sofia/Public5060/webudo-laptop@X.X.X.X) State EXECUTE 2022-01-20 05:17:12.050277 [DEBUG] mod_sofia.c:209 sofia/Public5060/webudo-laptop@X.X.X.X SOFIA EXECUTE 2022-01-20 05:17:12.050277 [DEBUG] switch_core_state_machine.c:329 sofia/Public5060/webudo-laptop@X.X.X.X Standard EXECUTE EXECUTE [depth=0] sofia/Public5060/webudo-laptop@X.X.X.X lua(callng/main.lua) EXECUTE [depth=0] sofia/Public5060/webudo-laptop@X.X.X.X export(X-LIBRE-SESHID=ebfe80e5-ca13-4ab2-8ef9-34d5049621da) 2022-01-20 05:17:12.050277 [DEBUG] switch_channel.c:1310 EXPORT (export_vars) [X-LIBRE-SESHID]=[ebfe80e5-ca13-4ab2-8ef9-34d5049621da] 2022-01-20 05:17:12.050277 [DEBUG] switch_cpp.cpp:773 CoreSession::setVariable('X-LIBRE-INTCONNAME', 'fromOldSIP') 2022-01-20 05:17:12.050277 [DEBUG] switch_cpp.cpp:1209 sofia/Public5060/webudo-laptop@X.X.X.X destroy/unlink session from object 2022-01-20 05:17:12.050277 [NOTICE] switch_core_state_machine.c:386 sofia/Public5060/webudo-laptop@X.X.X.X has executed the last dialplan instruction, hanging up.

LibreSBC logs: 2022-01-20T05:45:07.860541+00:00 ny-sbc program=libresbc, pid=815, module=callng, space=main, action=inbound_call, seshid=6ed2679b-8464-4e54-93f5-c943b542a097, uuid=5974bbbe-504b-4f7b-ba2d-2e72b2672fd0, context=access, sipprofile=Public5060, network_ip=X.X.X.X, realm=Public5060.libresbc, intconname=fromOldSIP, call_id=0481d9b038282fd32289178631c627e5@X.X.X.X:5060, transport=udp, caller_name=webudo-laptop, caller_number=webudo-laptop, destination_number=XXXXXXXXXXX 2022-01-20T05:45:07.860689+00:00 ny-sbc program=libresbc, pid=815, module=callng, space=main, action=exception, error=/usr/local/share/lua/5.2/redis.lua:703: /usr/local/share/lua/5.2/redis.lua:426: redis error: ERR wrong number of arguments for 'scard' command

[hnimminh]

Hi @WEBudoGT , did you run cluster with multiple node? can you share me output of fscli -x "global_getvar CLUSTERMEMBERS" ?

[WEBudoGT]

Hello @hnimminh

fscli -x "global_getvar CLUSTERMEMBERS" nysbc,ny-sbc

The reason there are 2 "nodes" is because the hostname is ny-sbc, and during the whole installation it went as ny-sbc, but I got issues when trying to make initial configuration, because the regex of one API call didn't allow me to use the dash (-) on the name, so I tried to figure out how to change the existing references to nysbc and never got a chance to remove the ny-sbc (don't know how using the API).

If this is causing the issue, please point me in the right direction to remove that ny-sbc reference.

I tried executing the update cluster, removing the bad referencie with this: { "name": "defaultname", "members": [ "nysbc" ], "rtp_start_port": 10000, "rtp_end_port": 60000, "max_concurrent_calls": 6000, "max_calls_per_second": 200 }

But I get: { "error": "engaged node" }

Thanks again

[WEBudoGT]

I tried running as many API endpoints as I touched when trying to configure it for the first time, and didn't found any relationship between "ny-sbc" and other stuff. Also, the nodeid when getting the predefine endpoint shows this: { "application": "LIBRESBC", "swversion": "0.5.7", "description": "Open Source Session Border Controller for Large-Scale Voice Infrastructures", "nodeid": "nysbc", "candidates": [ "nysbc", "ny-sbc" ], "codecs": [ "ALAW", "ULAW", "OPUS", "G729", "AMR", "AMR-WB" ] }

How do I remove the candidate?

[hnimminh]

Hi @WEBudoGT ,

{
"error": "engaged node"
}

mean that the name ny-sbc is used and associated with other setting like inbound/outbound interconnection.

By right, The node name will not effect by API restrict on naming convention, the node with name ny-sbc should work well.

so if there is other setting that already associated with ny-sbc, you can keep it and remove nysbc.

[WEBudoGT]

Thanks @hnimminh ! I found the reference to ny-sbc on the "nodes" for an interconnect. After removing it, I was able to delete from cluster definition. I was able to dial a call. Now I have audio issues, but I'm guessing it's an ACL or Firewall issue because SDP is well defined on call setup. Thanks again for your help!