I have been reading the Allstarlink manual and ran across the subject of The Linkbox. tlb.conf - AllStarLink Manual In reading this, I see where it says you need to define an rxchannel for tlb in /etc/asterisk/rpt.conf I've been running the tlb module for years and have never done this, so I thought I would try it, when I tried it, asterisk would not run so I just went back to my dahdi/psuedo for the rxchannel in rpt.conf and everything works as it should. I think if someone were following those instructions, it would render their node inoperable. I just wanted to put this out here so someone doesn't break their node tryign to use the tlb module.
1 Like
Fred,
I don't run TLB nor have I ever, but,
It seems to reason if you set-up a communication driver which has no communication end,
it's going to stall/lock-up. Any failed communication can be a problem. So, even improper setup can cause such effects.
If you write a program looking for input on a serial port and it's not there, it will lock unless you handle that absence in the code.
But you didn't indicate in your test if you actually had TLB device installed to communicate with.
So perhaps you can say more with some clarity to actually give others better guidance, since that seems to be your goal.
Edit:
I might also add that if you did not enable the tlb.so module in modules.conf, it would also create such a problem.
Mike, my tlb works fine. When I setup my tlb, I enabled the tlb channel driver in /etc/asterisk/modules.conf. I set created my tlb.conf file and put it in the /etc/asterisk directory. I did not make any changes in the /etc/asterisk/rpt.conf file for tlb. With my Allstar being on a VM, of course the rx channel is dahdi/psuedo. The way I read it, they are saying you need to have an rx channel defined for tlb. I don't find that you need a rx channel defined for tlb in /etc/asterisk/rpt.conf.
I agree that the tlb.conf page needs some work.
For outgoing TLB connections, it does appear that you don't need (or want) to create a node in the rpt.conf file with a rxchannel = tlb/tlb#.
What I don't know is what's needed to support incoming TLB connections.
It's also very easy to get confused about node numbers (ASL, TLB, ...).
Any help with the docs would be appreciated.
Allan, I haven't messed with incoming connections from tlb. All I have ever cared about is being able to connect my Allstar node to my tlb server so that echolink and speak freely connections are able to be bridged in.
I hear you. While it would be nice to know that we can support TLB connections in both directions we may not figure out the incoming path for a while (or ever). In the meantime, it would be a good idea to update the docs for what we know works.
I haven't done tlb on ASL 3, but I have used tlb connections under 1.x. As others have said, no channel driver is needed. For inbound connections, you need to define the node number for inbound connections is defined in the relevant stanza in tlb.conf with:
astnode=nnnnnn
where nnnnnn is the node on your server that inbound tlb connections are routed to.
I don't know if this has changed in ASL 3. I don't have an ASL 3 server to play with. Also, I hope the chan_tlb driver is more stable in ASL 3, as I had issues with the older version losing connectivity and being unable to reconnect until I restart asterisk.
I'd like to upgrade to ASL 3, but it's a massive job, bnecause it has to run on the host, where there's 40+ Docker containers running on top, and an OS upgrade will be needed. Either that, or I'll have to run a dedicated VPS for ASL 3, to decouple this dependency in the future. Would be nice if there was an easy way to containerise ASL installations that don't need hardware access.
As long as your underlying system is also Debian 12. Once DAHDI dependency is removed, the underlying OS won't matter.
Tony, the issue i have with tlb on the allstar side is that after some period of time and it's random, Allstar will quit passing voice packets and receiving voice packets from my tlb server on another VM. My fix for this was to write a script to disconnect 1001 and reconnect 1001 and I have a cron job run every 6 hours to execute it. Whole process takes about 3 seconds when it runs and that's my fix until something better comes along.
Missed this one, but it sounds like chan_tlb hasn’t been fixed. And that’s just one of the issues I’ve had with this channel driver. It gets even more complicated when using multiple tlb connections, because the remote end must use a different UDP port pair (to be expected) AND IP. The latter is an issue if the remote instances of tlb are part of an IRLP reflector running different channels on the same IP, and the tlb end uses the SF_Bind2IP address for RTP/chan_tlb.
As a result, I have to setup extra instances of tlb on different IPs to terminate the chan_tlb connections on, then use a Speak Freely connection from there to the IRLP reflector itself. It’s a bit messy, but I can at least make that part fairly reliable.
I was hoping for something better than the cron hack, given that the time to dropout can be highly variable. Also, for ASL 1.x, you actually have to restart asterisk itself. Sounds like ASL3 at least only has to disconnect/reconnect the tlb connection, from what you’re saying.
Tony, after some updates to ASL3, I’ve had to wind up making a private node using USRP to make things work. Example, my public node is 45523, USRP node 1001, connection to TLB server 1085. I connect 1001 to 1085. I also connect 1001 to 45523. I put the cron in to disconnect and reconnect 1001 to 1085 every 12 hours and everything seems to stay communicating properly. I do think it’s a problem in the chan_tlb driver on ASL. It’s way above my paygrade.