We recently created a private node to prevent SMS messages when connecting to our hub with a voip phone (over HH or HOIP). Since then the node will not allow incoming connections from other nodes. We’ve checked the obvious like port forwarding, but cannot figure out why incoming connections are denied. Any suggestions to fix this would be appreciated.
73, Bryan K6RBJ
Bryan, there is no ‘SMS’ messaging through asterisk by default.
That is somewhat a add on and if you are not loading
noload => app_sms.so ; SMS/PSTN handler
in modules.conf, you certainly are not using it.
I’m going to guess that you were seeing inter-iax messaging (kinda iax telemetry) which is required for things to work as expected. If you somehow killed it, things will not work as expected.
If you are just seeing the iax messages on your sip phone, you need to disable that in the phone if it bothers you. But they are not SMS, but iax status messages sent to all connections.
But I will add that a private node is just that, not public or ready for registered public connections.
So, you must have a path in extensions.conf to handle the routing for private connections.
And that only allows for intentional private connections.
Did you leave that out ?
Perhaps better explain the original problem with sms and/or your private node connections because the way you have said this leaves a lot to the imagination…
Thanks for the response Mike. To clarify, I used these directions https://wiki.hamshackhotline.com/doku.php?id=kb:sms.asl to add a private node to my public hub 61679 in order to stop the constant connection status tone and pop up.
The private node is connected to the hub node, and my sip phone connects to the private node whether using Hamshack Hotline or HamsOverIP.
Doing this got rid of the annoying status feedback on my phone, but somehow now prevents incoming connections to my hub 61679 from any other nodes. Outgoing connection works fine.
Hopefully this better explains my situation.
73, Bryan K6RBJ
So, what context have you assigned the private node ?
context= (rpt.conf)
Those instruction are suggesting they are in [radio-secure] which is not as intended.
[radio-secure]
exten => 1995,1,rpt,1995
Should be for Public Nodes.
Whereas the default asl3 shows
context = radio ( [radio] in extensions.conf )
You may have other customization’s not stated but [radio-secure] is intended for network connects which private nodes are not part of.
So, you evaluate what you need to do, but on the surface, that entry of private node needs to move to the proper context listed in whatever you have the node set for.
Perhaps you do.
But also note there can only be one [radio-secure] stanza
and asterisk uses a ‘first match’ process. If you have listed 2 now, one is going to fail.
Could it be that you inserted a new stanza of the same name for that private node ?
Outgoing connections do not use that routing in extensions.conf,
just data from /var/lib/asterisk/rpt_extnodes so it would not bother outgoing connects.
So, yes I am guessing. You will have to look at your own files and see what is true.
right and when sip phones receive this message and do not respond the allstar node will hang up on them. Hence do not use the callerID lines in the extensions.conf files. this will prevent it from happening as a lot of sip phones can not shut off incoming messages. this has been asked of you Guys at allstarlink to Fix it so when a private node with dahdi/psuedo is setup and running the callerid lines that we can see the users as they are logged onto the system without a message going out over the network, I know this can be done as it has been done on Hamvoip. Please be a part of the solution and not keep the problem going.
You “knowing” something was done at one point in HamVOIP to fix something with HH is fine, but as HamVOIP does not publish their source it’s unclear what the core issue is nor can such a fix be magically imported into ASL. No bug has been ever filed on whatever this supposed issue is based on a search of the ASL3 open issue list. There are many uses of SIP-attached devices with ASL that do not exhibit this problem. Claiming that ASL is “keeping the problem going” is disingenuous at best.
That HH post is for HamVOIP or maybe old ASL1/2, not modern ASL3. I would not expect it to work with ASL3 at all. So I’m not surprised that the OP is having problems after following the directions.
Feel free clearly state the details of the problem in a GitHub Issue so it can be reviewed and triaged.
I think that’s a bit unfair.
HamVoIP did some voodoo (not open source, so no idea what) to suppress telemetry and text messages in a non-standard way. This caused an awful lot of controversy when the change was made, as it fundamentally changed some behavior in their version of app_rpt from what people were expecting.
Since the ASL dev team has no way of knowing what was implemented, there isn’t a lot they can do.
Also, those instructions are for old ASL, not ASL3, so it’s unsurprising, at least to me, that following those instructions to the letter doesn’t work, as they were never updated for the new structure ASL3 uses.
I see you wrote those instructions.
Have you tried/verified them with ASL3 ? Do your instructions need updated ?
15 years I have been using sip phones on my app_rpt boxes with no hangup issues.
4 manufactures and 7+ different models over the years. More than a dozen current active phones in all.
If you have specific data that it is in the app_rpt code, then present it in a bug report.
Personally, I would say it is more likely a issue with the phone firmware for phones that were intended to be reprogrammed via the hosting server as a enterprise solution.
And many of those phones can have that function disabled in it’s firmware.
But that is a guess. I have not had a working example of the problem.
There are many anomalies with particular sip models in asterisk.
And they have nothing to do with ASL/app_rpt.
So, it appears you are blaming the car for a rough road.
Blocking iax data only seems like a workaround. Not a fix for a core issue.
But I do wonder if telemdefault=0 would also be a workaround ?
If you have more to say on this, make it relate to helping the user fix his issue, not some underlying agenda. The thread belongs to the initial poster, not you. He is asking for help…
Got any ?
Bryan,
If you are still having issues, give us some more background.
including
What version of software are you using ?
Sorry, but I’ve been both super busy at work AND under the weather all week so this has been on the back burner.
I’m running asl2 on a cloud hub. I didn’t build it, so don’t know much else about it. I do have someone helping me with this one on one, and will report back if the issue isn’t resolved.
Would it help if I posted my rpt.conf and extensions.conf files?
73, Bryan K6RBJ
Bryan, it never hurts to have a second set of eyes at least look at it.
Speaking only for myself, I am not familiar with HH or HOIP, but I’m pretty good with the asterisk dialplan LOL
But many eyes will look at it if you post it.
Here they are. Hopefully someone can point out where I went wrong. I did copy and paste the previously mentioned private node directions, which caused other problems because I inserted them in the wrong spot in rpt.conf. So the node quit sending status updates to the Allstar Node server. That issue was corrected, but then I noticed the incoming connection issue.
Thanks for having a look.
Bryan K6RBJ
extensions.pdf (50.4 KB)
rpt.pdf (72.9 KB)
Well, this you have
[radio-secure]
;exten => ${NODE},1,rpt,${NODE}
[radio-secure]
exten => 1995,1,rpt,1995
Needs to look like this
[radio-secure]
exten => ${NODE},1,rpt,${NODE}
Delete the second entry remove the comment on the line ( ; ) and I assume you only have the one public node.
You did have two [radio-secure] entries and the first one was actually empty because of the line being commented out. That is why you lost network connections. The second
[radio-secure] entry was ignored.(asterisk first match)
and the private node, which should be in [radio]
like this
[radio]
exten => 1995,1,rpt,1995
Add that bold line to the existing context [radio], do not create a second [radio] context
And in rpt.conf …this
1995 = radio@149.28.73.32:4569/1995,NONE ;private for voip phones
61679 = radio@149.28.73.32:4569/61679,NONE ;LA-HUB
should better resemble this
1995 = radio@127.0.0.1:4569/1995,NONE ;private for voip phones
61679 = radio@127.0.0.1:4569/61679,NONE ;LA-HUB
You seem to be using a public IP for a internal node. 127.0.0.1 is internal
Also in the rpt.conf file,
place a line in the private node stanza for the private 1995 node
context = radio
(I think with asl2 it defaults to radio anyway?)
You made this difficult sending pdf’s
But it got it done. Give that a shot and tell us where you are.
I did not go over this well, but on quick time. Going to bed.
Thanks Mike,
That got incoming connections working again, but now the private node 1995 won’t connect to the public node 61679. I am now able to connect my repeater node 54464 as incoming to hub 61679, so at least that is a step in the right direction.
73, Bryan
It seems as though I did make a mistake.
I keep getting confused by versions I use and my own custom programming.
Your extensions entry for [radio-secure] should look like this
[radio-secure]
exten => ${NODE},1,rpt,${NODE}
exten => ${NODE1},1,rpt,${NODE1}
Now at the top of that file under [globals]
should have at least this
[globals]
HOMENPA = 999 ; change this to your Area Code
NODE = 61679 ; change this to your node number
NODE1 = 1995
Remove the entry I has you make in [radio]
After restarting, you should be able to bi-directionally connect that private to public or visaversa
If not check your [nodes] section of rpt.conf for typo or post that section here for more eyes.
But that is the default contextual method for v2.0b6
Yep, that did the trick Mike. Thank you for your help! You mentioned PDF’s are a pain, but the file attachment types are limited. So for future reference, should I copy and paste file contents within the post itself?
Thanks again,
Bryan K6RBJ
Well, I understand.
But yes, for me, a copy paste text type works better.
Do what you gotta do.
It’s better than screeshots … LOL
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.