Allstar Support

[jimrochny]

Hello,

Most of our ham repeaters are connected via Allstarlink, particularly the ones we use for Public Service events. We have to use a separate IAXRPT app on a Win PC to connect in, with a USB foot switch for transmit keying which IAXRPT supports.

Are there any plans to implement web support for Allstar using the IAX protocol? We would like to migrate to Linux workstations for events if that were to occur. The connection could also be to a 3rd party service like Hams over IP. We also use Zello, thanks for the new integration!

We also utilize a VoIP service for event participant call-ins. Any plans on building in a SIP client?

Jim - NY2US

P.S. As an original TicketsCAD user from a very long time ago, we are so so glad to see the new platform development and support.

[ejosterberg]

Audio routing, WebRTC, codec support, transcoding, various browser incompatibility issues, buffering, jitter, playback for instant recall, and hundreds of additional ideas...
I'd say someday.
It was being worked on, and I've been putting in 40 hour weeks for 2 months... It was tabled for 'later'.
I was working on building my own hardware for analog radio support and I instead moved towards using already existing AllStar radio interfaces. But as for IAX protocol, not sure about that one. Jim Dixon, and SteveR were good friends of mine back in 2002. I've been an early AllStar user, essentially from the start. So maybe someday.
Anyone else willing to build it and contribute, or would anyone support the development financially?

[ejosterberg]

Jim — a technical note to go alongside Eric's answer, since you asked about two specific protocols and the codebase already has something concrete to say about both. Timeline and the funding/contributor question are Eric's, not mine; this is just what exists today.

The Phase 114 work replaced the old one-off-per-integration approach with a unified channel registry (inc/channel_registry.php). Every communications channel — Zello, DMR, Meshtastic, chat, SMS, email — is now a catalog entry declaring its capabilities and its regulatory class, and the Communications Console builds its strips from that catalog rather than from hard-coded panels.

Both things you asked about are already in that catalog as reserved entries:

'allstar' => [
    'label' => 'AllStarLink',
    'regulatory_class' => 'amateur',
    'capabilities' => [
        'voice_rx' => true, 'voice_tx' => true, 'ptt_floor' => true,
        'tts_out' => true, 'record' => true,
    ],
],
'sip' => [
    'label' => 'SIP Telephone',
    'regulatory_class' => 'pstn',
    'capabilities' => [
        'voice_rx' => true, 'voice_tx' => true, 'full_duplex' => true,
        'tts_out' => true, 'record' => true,
    ],
],

To be clear about what that is and isn't: these are catalog entries with no adapter behind them. Nothing connects to AllStar or SIP today. What it does mean is that the shape of the work is decided — an adapter registers against an existing interface rather than requiring the console, the audio matrix, or the permission model to be redesigned around it. The full_duplex flag on SIP is deliberate, because a phone call is not push-to-talk and the console has to know that.

Two details relevant to how you actually operate:

• PTT floor arbitration (ptt_floor) is already a modelled capability, which is the piece that matters for your foot switch — the console needs to know who holds the channel before it keys anything.
• The Zello path you're already using went through a server-side proxy rather than browser-direct, precisely because of the audio problems Eric listed. Whatever lands for AllStar would almost certainly follow that shape: a small service holding the protocol connection, with the browser talking to it over WebSocket. The hard-won lessons from the Zello and DMR work are written up in docs/ZELLO-PROXY-LESSONS.md and docs/DMR-CODEC-LESSONS.md in the dev repo — worth reading first if you or anyone in your group ever wants to take a run at the IAX adapter, because a good chunk of the pain is already documented there.

Leaving this open as the tracking issue for AllStar/IAX and SIP support.