"@Star_Communication" is appended to the phone number on outgoing calls, causing calls to fail (INVALIDNMBR). The default trunk for testing using the Star Communications (generous and wonderful) 800 test services have been deleted. New inbound/outbound routes and trunks have been set up, mirroring a working system on another platform.
All references to the Star Communications test setup, I believe, have been removed. A grep of the /etc/asterisk/.conf files show no reference to "Star_Communication". A grep of the entire system only finds it in log files and the cdr database.
Asterisk version 13.17.1, modules updated. FreePBX 14.0.1.20
in var/log/full, "@Star_Communication" first appears in macro-dialout-trunk: (phone number replaced with xxxxxxx)
[2017-11-20 10:47:05] VERBOSE[8990][C-00000015] pbx.c: Executing [s@macro-dialout-trunk:24] Dial("SIP/32-00000029", "SIP/pbx_out/1727xxxxxxx@Star_Communication,300,Tt") in new stack [2017-11-20 10:47:05] VERBOSE[8990][C-00000015] netsock2.c: Using SIP RTP TOS bits 184 [2017-11-20 10:47:05] VERBOSE[8990][C-00000015] netsock2.c: Using SIP RTP CoS mark 5 [2017-11-20 10:47:05] VERBOSE[8990][C-00000015] app_dial.c: Called SIP/pbx_out/1727xxxxxxx@Star_Communication [2017-11-20 10:47:05] VERBOSE[8990][C-00000015] app_dial.c: Everyone is busy/congested at this time (1:0/0/1) [2017-11-20 10:47:05] VERBOSE[8990][C-00000015] pbx.c: Executing [s@macro-dialout-trunk:25] NoOp("SIP/32-00000029", "Dial failed for some reason with DIALSTATUS = CHANUNAVAIL and HANGUPCAUSE = 1") in new stack [2017-11-20 10:47:05] VERBOSE[8990][C-00000015] pbx.c: Executing [s@macro-dialout-trunk:26] GotoIf("SIP/32-00000029", "0?continue,1:s-CHANUNAVAIL,1") in new stack [2017-11-20 10:47:05] VERBOSE[8990][C-00000015] pbx_builtins.c: Goto (macro-dialout-trunk,s-CHANUNAVAIL,1) [2017-11-20 10:47:05] VERBOSE[8990][C-00000015] pbx.c: Executing [s-CHANUNAVAIL@macro-dialout-trunk:1] Set("SIP/32-00000029", "RC=1") in new stack [2017-11-20 10:47:05] VERBOSE[8990][C-00000015] pbx.c: Executing [s-CHANUNAVAIL@macro-dialout-trunk:2] Goto("SIP/32-00000029", "1,1") in new stack [2017-11-20 10:47:05] VERBOSE[8990][C-00000015] pbx_builtins.c: Goto (macro-dialout-trunk,1,1) [2017-11-20 10:47:05] VERBOSE[8990][C-00000015] pbx.c: Executing [1@macro-dialout-trunk:1] Goto("SIP/32-00000029", "s-INVALIDNMBR,1") in new stack [2017-11-20 10:47:05] VERBOSE[8990][C-00000015] pbx_builtins.c: Goto (macro-dialout-trunk,s-INVALIDNMBR,1)
on the working platform, the first line appears as: (note the lack of "@Star_Communication"
[2017-11-20 11:26:20] VERBOSE[1714][C-00000185] pbx.c: -- Executing [s@macro-dialout-trunk:23] Dial("SIP/35-00000466", "SIP/pbx_out/1727xxxxxxx,300,Tt") in new stack
Any bread crumbs would be appreciated.
Last edit: paul sip 2017-11-20
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Did you try to call a number 1727xxxxxxx, starting with 1727? This is not a toll-free number and is rejected by the star communication sip proxy. Could this be the reason for your problem?
I have tested the trunk setup several times and it worked fine for me. However, I had to complete the basic Asterisk SIP setup first, configuring the public IP of my router there.
If this is not the reson for your issues please explain in more details, I'm not sure if I understood exactly what changes you made.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for your reply!
The test (Star Communications) inbound/outbound routes and trunks have been removed and new routes/trunks set up, mirroring a working system on another platform. The 1727xxxxxxx works on the other platform. The Star Communications test routes are not being used.
The main difference between the working and non-working system is the "@Star_Communication" appended to the phone number. I cannot find this reference in the GUI, command line or .conf parameters.
Please tell me where this appendage is defined so I can remove it.
Thank you so much for your help!
Paul
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've checked this, but the only explanation I have is you did not configure the outbound routes correctly. You have to configure at least one additional outbound route, e.g. with the "." as match pattern, and configure an additional trunk and use this as the destination trunk in your new route. The call to 1727xxxxxxx then uses your new route and trunk. In your case it looks like the call to 1727xxxxxxx tries the Star Communication testing trunk and then fails, because the outbound route was not properly set.
I've tested this again, and for me it works fine when the routes are properly set.
Last edit: Gernot 2017-12-02
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've deleted the Star Communication outbound route from my test setup and it worked perfectly fine as expected, all calls were successfully routed through the other trunks after this. Maybe you did not click the red "Apply Config" button after deleting the outbound route? So far I cannot see any issue in the base image, it works fine when configured properly.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'll reload the image and start from scratch. In the setup I have now, I started out by deleting the Star Communications routes and trunk, then adding the new ones. This time I will start by adding the new routes and trunk, then deleting the Star Communications routes/trunk (like what you did). will post results. It is odd that the string "Star_Communcation" can't be found in any conf file, yet it appears in the dial string. Thank you!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I got to thinking, what if it's just stuck in a string buffer. So I power cycled (literally unplugged for a few seconds) and then powered back on. Now it works.
Still a bug of SOME sort, but not quite as bad.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"@Star_Communication" is appended to the phone number on outgoing calls, causing calls to fail (INVALIDNMBR). The default trunk for testing using the Star Communications (generous and wonderful) 800 test services have been deleted. New inbound/outbound routes and trunks have been set up, mirroring a working system on another platform.
All references to the Star Communications test setup, I believe, have been removed. A grep of the /etc/asterisk/.conf files show no reference to "Star_Communication". A grep of the entire system only finds it in log files and the cdr database.
Asterisk version 13.17.1, modules updated. FreePBX 14.0.1.20
in var/log/full, "@Star_Communication" first appears in macro-dialout-trunk: (phone number replaced with xxxxxxx)
[2017-11-20 10:47:05] VERBOSE[8990][C-00000015] pbx.c: Executing [s@macro-dialout-trunk:24] Dial("SIP/32-00000029", "SIP/pbx_out/1727xxxxxxx@Star_Communication,300,Tt") in new stack
[2017-11-20 10:47:05] VERBOSE[8990][C-00000015] netsock2.c: Using SIP RTP TOS bits 184
[2017-11-20 10:47:05] VERBOSE[8990][C-00000015] netsock2.c: Using SIP RTP CoS mark 5
[2017-11-20 10:47:05] VERBOSE[8990][C-00000015] app_dial.c: Called SIP/pbx_out/1727xxxxxxx@Star_Communication
[2017-11-20 10:47:05] VERBOSE[8990][C-00000015] app_dial.c: Everyone is busy/congested at this time (1:0/0/1)
[2017-11-20 10:47:05] VERBOSE[8990][C-00000015] pbx.c: Executing [s@macro-dialout-trunk:25] NoOp("SIP/32-00000029", "Dial failed for some reason with DIALSTATUS = CHANUNAVAIL and HANGUPCAUSE = 1") in new stack
[2017-11-20 10:47:05] VERBOSE[8990][C-00000015] pbx.c: Executing [s@macro-dialout-trunk:26] GotoIf("SIP/32-00000029", "0?continue,1:s-CHANUNAVAIL,1") in new stack
[2017-11-20 10:47:05] VERBOSE[8990][C-00000015] pbx_builtins.c: Goto (macro-dialout-trunk,s-CHANUNAVAIL,1)
[2017-11-20 10:47:05] VERBOSE[8990][C-00000015] pbx.c: Executing [s-CHANUNAVAIL@macro-dialout-trunk:1] Set("SIP/32-00000029", "RC=1") in new stack
[2017-11-20 10:47:05] VERBOSE[8990][C-00000015] pbx.c: Executing [s-CHANUNAVAIL@macro-dialout-trunk:2] Goto("SIP/32-00000029", "1,1") in new stack
[2017-11-20 10:47:05] VERBOSE[8990][C-00000015] pbx_builtins.c: Goto (macro-dialout-trunk,1,1)
[2017-11-20 10:47:05] VERBOSE[8990][C-00000015] pbx.c: Executing [1@macro-dialout-trunk:1] Goto("SIP/32-00000029", "s-INVALIDNMBR,1") in new stack
[2017-11-20 10:47:05] VERBOSE[8990][C-00000015] pbx_builtins.c: Goto (macro-dialout-trunk,s-INVALIDNMBR,1)
on the working platform, the first line appears as: (note the lack of "@Star_Communication"
[2017-11-20 11:26:20] VERBOSE[1714][C-00000185] pbx.c: -- Executing [s@macro-dialout-trunk:23] Dial("SIP/35-00000466", "SIP/pbx_out/1727xxxxxxx,300,Tt") in new stack
Any bread crumbs would be appreciated.
Last edit: paul sip 2017-11-20
Did you try to call a number 1727xxxxxxx, starting with 1727? This is not a toll-free number and is rejected by the star communication sip proxy. Could this be the reason for your problem?
I have tested the trunk setup several times and it worked fine for me. However, I had to complete the basic Asterisk SIP setup first, configuring the public IP of my router there.
If this is not the reson for your issues please explain in more details, I'm not sure if I understood exactly what changes you made.
Thank you for your reply!
The test (Star Communications) inbound/outbound routes and trunks have been removed and new routes/trunks set up, mirroring a working system on another platform. The 1727xxxxxxx works on the other platform. The Star Communications test routes are not being used.
The main difference between the working and non-working system is the "@Star_Communication" appended to the phone number. I cannot find this reference in the GUI, command line or .conf parameters.
Please tell me where this appendage is defined so I can remove it.
Thank you so much for your help!
Paul
I've checked this, but the only explanation I have is you did not configure the outbound routes correctly. You have to configure at least one additional outbound route, e.g. with the "." as match pattern, and configure an additional trunk and use this as the destination trunk in your new route. The call to 1727xxxxxxx then uses your new route and trunk. In your case it looks like the call to 1727xxxxxxx tries the Star Communication testing trunk and then fails, because the outbound route was not properly set.
I've tested this again, and for me it works fine when the routes are properly set.
Last edit: Gernot 2017-12-02
The Star Communication testing trunk, outbound and inbound routes were deleted. Please delete them from your test setup and give it another try.
Even though the trunk and routes of been deleted, dial.c still references Star Communications:
app_dial.c: Called SIP/pbx_out/1727xxxxxxx@Star_Communication
I even tried deleting the new trunk and re-creating it. the reference remains. Perhaps it's in the source of app_dial.c?
I've deleted the Star Communication outbound route from my test setup and it worked perfectly fine as expected, all calls were successfully routed through the other trunks after this. Maybe you did not click the red "Apply Config" button after deleting the outbound route? So far I cannot see any issue in the base image, it works fine when configured properly.
I'll reload the image and start from scratch. In the setup I have now, I started out by deleting the Star Communications routes and trunk, then adding the new ones. This time I will start by adding the new routes and trunk, then deleting the Star Communications routes/trunk (like what you did). will post results. It is odd that the string "Star_Communcation" can't be found in any conf file, yet it appears in the dial string. Thank you!
I'm having the same problem. deleted the Star_Communications trunks and routes, still @Star_Communications is appended.
Last edit: Doug Walker 2017-12-11
I got to thinking, what if it's just stuck in a string buffer. So I power cycled (literally unplugged for a few seconds) and then powered back on. Now it works.
Still a bug of SOME sort, but not quite as bad.
I just did a fresh install and experienced the exact same issue.
I'm having this issue on a new install. I can't connect to my provider. has anyone found a solution?