Cover Story
Real-Time State: More Than a Green or Red Light
Behind every BLF lamp and presence indicator is a stream of registrations, device states, subscriptions and events.
By WH6AV — Gescio “Jesse” Alpuro
A telephone network can successfully route thousands of calls and still leave operators wondering what is actually happening.
Is an extension registered? Is somebody already on a call? Is an RF-Link active? Is a conference in use? Did a remote system disappear?
For Hams Over IP, answering those questions has become an increasingly important part of operating the network. That is where real-time state comes in.
Many operators first encounter state through the Busy Lamp Field, or BLF. Behind that seemingly simple lamp is a larger system of events, subscriptions, registrations and device-state information.
Beyond the telephone
The Live Phonebook, PBX management tools, RF-Link monitoring, conference information and operational dashboards increasingly depend on live information originating from Asterisk.
The objective is simple: when something changes on the network, the interface should know about it. Not several minutes later and not only after somebody refreshes a webpage.
Technical Corner
From Registration to BLF Lamp
Follow an endpoint through the pieces Asterisk uses to determine whether it is reachable, ringing or busy.
By Hams Over IP Editorial
A SIP endpoint first registers with the PBX, giving Asterisk a current contact for signaling. Registration alone does not mean the endpoint is idle: Asterisk also maintains device and extension state as calls ring, answer, go on hold and end.
Subscriptions make the lamp useful
A SIP telephone configured with a BLF key can subscribe to state information for another resource. Asterisk then sends notifications when that state changes.
The same underlying information can be consumed by applications through the Asterisk Manager Interface (AMI), turning state into indicators in phonebooks, RF-Link monitors, conference dashboards and administrative interfaces.
The difficult part is not drawing a green or red indicator. It is making sure the indicator accurately represents reality.
Asterisk Events
AMI: Listening to the PBX
Asterisk Manager Interface events let applications react when something changes instead of constantly requesting another snapshot.
By Hams Over IP Editorial
Asterisk knows a tremendous amount about what is happening inside the PBX. AMI provides one way for applications to receive that information as events.
Applications can listen for changes involving endpoints, contacts, channels, bridges, conferences and other resources, then associate each event with the correct resource and distribute the updated state to connected browsers.
Events plus synchronization
A restarted application cannot assume the next event tells the complete story. It needs a reliable initial view of the network and then uses live events to keep that view current. This combination of initial synchronization plus live events is central to dependable real-time monitoring.
Live Phonebook
Push Instead of Refresh
The Live Phonebook is becoming a window into the network rather than a periodically refreshed directory.
By Hams Over IP Editorial
Polling repeatedly asks whether anything changed. An event-driven system instead distributes a change when it happens.
For the Hams Over IP Live Phonebook, this lets endpoint state appear much closer to real time.
- AVAILABLE — reachable and available.
- BUSY — currently engaged.
- RINGING — an incoming call is alerting.
- HOLD — a call is on hold where that state is available.
- UNAVAILABLE — not currently reachable.
The most important word is not real-time. It is accurate. An offline extension should not appear AVAILABLE, and an extension should not remain BUSY after its call has ended.
Federation
Presence Across Network Boundaries
Hams Over IP and Amateur Wire are exploring what happens when federation includes state as well as dialing.
By Hams Over IP Editorial
Routing a call between independent networks is one challenge. Sharing useful state information between them is another.
Recent work between Hams Over IP and Amateur Wire has explored how presence and BLF information can cross independently operated systems. Hams Over IP uses the 910 dialing prefix toward Amateur Wire, while Amateur Wire uses 304 toward Hams Over IP.
Federation does not require centralization
Independent amateur communications systems can cooperate while retaining their own infrastructure, policies, numbering and communities. That gives us interoperability without requiring uniformity.
Communications
When the PBX Meets the Video Conference
Jitsi Meet and the Premium PBX demonstrate how a telephone caller can participate in a browser-based conference.
By Hams Over IP Editorial
Hams Over IP has integrated Jitsi Meet conferencing with the Premium PBX environment, providing a path for supported SIP/PJSIP callers to participate in conference rooms from the telephone network.
On one side is the traditional SIP telephone; on the other is a modern browser-based audio and video conference. A telephone participant can enter through the PBX while others use computers or mobile devices.
It is another example of a recurring Hams Over IP idea: different technologies become more interesting when we make them work together.
Premium Update
Better Visibility, Better Operations
PBX Resource Manager continues to bring account, voicemail, call, conference and network information into one operational environment.
By Hams Over IP Editorial
Hams Over IP Premium continues to evolve beyond simply providing another extension. Recent development has focused heavily on the PBX Resource Manager and its operational tools.
That work includes extension management, voicemail and MWI configuration, IAX2 resources, RF-Links, conference management, call detail information, support tickets, firewall administration and real-time phonebook information.
Automation matters as the system grows
A repair that takes thirty seconds once becomes an operational problem when repeated across many accounts. The objective is to automate predictable work, surface useful state and help administrators identify problems quickly.
Support Desk
Premium Tickets Meet Discord
Real-time support notifications help get new Premium tickets in front of the people who can act on them.
By Hams Over IP Editorial
The Premium support environment now connects web-based ticket activity with the Hams Over IP administrative Discord environment.
Tickets submitted through Premium can be surfaced to administrators in Discord, where the support team can see new activity and respond through the integrated workflow.
The objective is not to replace the ticket system with chat. The ticket remains the record. Discord provides another operational interface for the people supporting the network.
This is another form of real-time state: something happened, and the right people should know about it.
From the Founder
The Network Should Tell Us What It Is Doing
Every new layer of visibility gives us another opportunity to understand, experiment and improve.
By WH6AV — Gescio “Jesse” Alpuro
One of the things I enjoy most about building Hams Over IP is that there is always another layer to explore.
At first, the goal may seem simple: connect telephones and let amateur radio operators call one another. Then we ask more questions. Can we connect PBXs in different regions? Independent networks? RF systems? Web conferences? Can the phonebook show whether somebody is actually available? Can administrators see what is happening without searching through several servers?
Each answer creates another experiment. That is exactly what I believe Hams Over IP should encourage.
We are not simply trying to recreate a commercial telephone company using amateur infrastructure. We have an opportunity to experiment with communications technology, learn how the pieces work, break things occasionally, fix them, and share what we learn.
Thank you to everyone who continues to test, report problems, suggest improvements and help operate the network.
73,
WH6AV — Jesse
Founder, Hams Over IP
Next Issue
Coming in Issue No. 6: Beyond One Network
Interconnection, federation and the engineering behind making independent communications systems cooperate.
By Hams Over IP Editorial
For Issue No. 6, we plan to look more closely at interconnection and federation.
We will explore numbering, routing, IAX2 and SIP interconnection, federated directories, presence exchange and some of the engineering challenges that appear when independently operated networks begin communicating.
The objective is not to make every network identical. It is to understand how independent amateur communications systems can cooperate while retaining their individual identities.
