Just Say the Callsign

Voice dialing hides complexity on purpose. The operator should not need to understand every step that takes place after dialing 4010.

For the experimenter, however, those steps are where things become interesting.

Step 1: Start the voice directory

The call enters the Voice Callsign Directory through extension 4010. Instead of immediately routing to another telephone, the service interacts with the caller and listens for a callsign.

Step 2: Turn speech into something searchable

The spoken response has to become text that can be compared with callsign information known to Hams Over IP.

Recognition alone is not enough. The result also has to be normalized into a form the routing system can reliably search.

Step 3: Resolve the callsign

Once HOIP has a callsign, the system needs to determine whether that callsign has a reachable destination.

This is where voice dialing connects with the callsign directory and the routing information already maintained across Hams Over IP.

Step 4: Route the call

Finding an extension is only part of the problem. That extension may not belong to the PBX where the caller originated.

The routing layer therefore has to determine how to reach the destination and hand the call to the appropriate path.

Simple outside, complicated inside

That contrast is intentional.

The caller should experience:

4010 → say callsign → call.

The network can worry about everything in between.

A callsign directory is useful on one PBX. It becomes considerably more interesting when the same idea operates across a multi-PBX network.

Hams Over IP has expanded voice callsign dialing across the HOIP PBX network so that an operator does not need to know where another user is hosted before attempting the call.

Ask for the operator, not the server

When you dial 4010 and speak a callsign, the important information is the identity of the amateur radio operator you are trying to reach.

Whether that destination belongs to the same PBX or another HOIP system should be a routing decision rather than something the caller has to determine first.

Local information comes first

If the requested callsign can be resolved locally, the PBX can use that information immediately.

If the callsign is associated with another part of the Hams Over IP network, the routing process can continue toward the system that knows how to reach that destination.

From directory lookup to call routing

This changes the traditional role of a telephone directory.

A normal phonebook tells a person which number to dial. A network-aware callsign directory can provide destination information directly to the communications system.

The operator asks for a callsign. HOIP determines where that callsign belongs and how the call should get there.

One feature across the HOIP network

The goal is consistency. An operator should be able to use the same familiar 4010 voice-dialing feature without first thinking about the underlying PBX infrastructure.

As more services become network-aware, the physical location of an extension can increasingly become an implementation detail.

Know the callsign. Let Hams Over IP determine the route.

The Hams Over IP Live Phonebook began with a straightforward purpose: help operators find people, extensions and resources on the network.

As HOIP has grown, that directory information has become useful for much more than displaying a searchable list in a browser.

Callsign plus destination

When a callsign can be associated with an extension or other communications resource, the same information that helps a person find somebody can also help network services determine where a call should go.

That makes directory accuracy increasingly important.

An outdated entry is no longer merely something that looks wrong on a webpage. Stale, duplicate or incorrect information can affect applications that depend on the directory to understand what resources exist.

A phonebook that reflects the network

The Live Phonebook brings together resources from different parts of Hams Over IP so operators do not have to search several independent lists.

That includes the extensions and services people use every day as well as specialized resources that make up the wider network.

More than names and numbers

Recent development has also moved the Live Phonebook toward showing information about the current state of network resources.

When directory information is combined with registration, availability and other live state, the phonebook becomes more than a static list. It becomes another window into what is happening across Hams Over IP.

Useful to people and useful to systems

The browser-based directory remains important, but there is a larger idea behind this work:

maintain accurate information once and make it useful throughout the network.

Voice callsign dialing is one example of what becomes possible when communications tools can make use of the same identity and destination information that operators already use.

A SIP desk phone and a browser-based video conference may seem like two completely different communications systems.

Hams Over IP has been working to make those systems communicate with one another.

The HOIP Jitsi Meet environment provides browser-based audio and video conferencing, while PBX integration provides a path for telephone users to participate through the Hams Over IP voice network.

Not everybody needs a browser

There are times when joining from a computer or mobile browser makes sense. There are other times when the telephone already sitting in the shack is the better communications device.

A telephone participant does not need a camera, a web browser or an entirely separate communications setup simply to participate by voice.

Connecting two communications worlds

Behind the integration are two different environments.

On one side is the familiar PBX and SIP telephone network. On the other is Jitsi Meet, where participants may be using computers, tablets or mobile devices for audio and video conferencing.

Bridging those environments lets a traditional telephone call become part of a modern online conference.

Use the device that makes sense

This is an important principle for Hams Over IP. Interoperability should give operators more choices rather than forcing everybody onto identical equipment.

A desk telephone, softphone, browser, RF-connected resource or other communications endpoint may each be appropriate in different situations.

The interesting engineering begins when we make those different technologies work together.

A net-control application is relatively straightforward when everyone belongs to the same organization and follows the same workflow.

The challenge changes when several groups need to use the same platform while keeping their operations separate.

Recent development of the HMASN Net Control environment addresses that challenge with multi-group support.

Separate groups on a shared platform

Each group can maintain its own operating environment instead of placing every member and every net into one common workspace.

Group membership can also carry different responsibilities, including roles for viewers, controllers and administrators.

That allows somebody who manages one group to have the appropriate access there without automatically receiving the same authority over every other group using the platform.

Reports go where they belong

Different organizations may also need completed net information delivered to different people.

Report recipients can therefore be associated with the individual group, allowing each organization to maintain its own distribution requirements.

Multiple nets can operate independently

The larger goal is to support separate operating groups even when more than one net is taking place around the same time.

Each group can work with its own members, controllers and reporting configuration while sharing the underlying Net Control platform.

Common infrastructure without identical operations

This follows a familiar Hams Over IP design principle.

Sharing infrastructure does not mean every organization has to operate the same way.

The platform provides common tools while allowing individual groups to maintain their own people, responsibilities and workflows.

Hams Over IP Premium continues to evolve as both a communications service and an experiment in how much useful PBX management can be placed directly in the hands of amateur radio operators.

Recent development has touched extension management, IAX2 resources, RF-Links, voicemail, call forwarding, registration visibility and the administrative tools behind those services.

Call forwarding from the telephone

Some features do not need another dashboard.

Premium users can use familiar telephone feature codes to control call forwarding. Dial *72 to enable call forwarding and *73 to disable it.

This gives operators a quick way to redirect calls when moving between devices or locations without requiring an administrator to make the change.

Better visibility when something does not register

Registration problems can have many causes. A wrong password, NAT behavior, firewall rules, an incorrect server address or endpoint configuration can all produce symptoms that initially look similar.

Improved registration monitoring gives administrators more useful information when investigating those problems, including registered resources and failed registration activity.

RF-Links and IAX2 resources

Premium also continues to provide tools for operators experimenting beyond ordinary SIP extensions.

RF-Link and IAX2 resources allow compatible systems, gateways and Asterisk installations to become part of the wider communications environment.

Administrative tooling around those resources continues to improve as real-world use reveals where additional management and troubleshooting capabilities are needed.

Self-service needs boundaries

Giving users more control also means paying careful attention to permissions.

An operator should be able to manage and generate configuration for resources belonging to that operator without gaining access to another user's passwords or private configuration.

That balance — more control without giving away somebody else's control — is an important part of building useful self-service communications infrastructure.

Not every Hams Over IP project results in a new button, webpage or feature that can be demonstrated in a screenshot.

A considerable amount of development happens in the parts of the network that operators should eventually not have to think about.

Routing should just route

If a call belongs on another Hams Over IP system, the network should have a dependable way to get it there.

The person placing the call should not have to understand the internal route merely to have a conversation.

Presence should represent reality

A BLF lamp or phonebook indicator is useful only when its state can be trusted.

Work continues on exchanging and synchronizing device state between HOIP systems so remote resources can increasingly behave like familiar local resources from the operator's point of view.

Directories should stay accurate

Removing stale resources and keeping extension information synchronized may sound like routine housekeeping, but services increasingly depend on that information.

As directories become inputs to features such as callsign lookup and routing, data accuracy becomes part of communications reliability.

Administration should scale

A manual repair that takes only a minute can become a serious operational burden when it has to be repeated across hundreds or thousands of resources.

Monitoring, synchronization and administrative automation help turn recurring repairs into repeatable processes.

The invisible infrastructure matters

The Voice Callsign Directory demonstrates the result particularly well.

From the telephone, the feature is easy to explain:

Dial 4010. Say a callsign. Place the call.

Behind those few seconds are directories, databases, voice processing, PBX dialplans and routing decisions.

When all of those pieces cooperate correctly, the operator does not need to think about any of them.

That is exactly what good infrastructure should accomplish.

One of my goals with Hams Over IP has always been to keep experimenting with what an amateur communications network can become.

We started with extensions and PBXs. As the network grew, we added more systems, more regions, RF resources, directories, conferencing, dashboards and tools for managing everything behind them.

But growth creates another challenge: complexity.

We should not solve that problem by asking every operator to memorize more information.

We already have an identity

Amateur radio operators have been identifying one another by callsign for generations.

If I want to call another amateur and I already know that person's callsign, why should I necessarily need to remember another number first?

That question is what makes the Voice Callsign Directory interesting to me.

Dial 4010. Say the callsign. Let the network figure out the rest.

Simple features can require complicated systems

Of course, making something look simple does not mean the technology behind it is simple.

There are directories to maintain, voice recognition to process, destinations to resolve, PBXs to communicate with and routes to select.

Those are exactly the kinds of engineering problems that make Hams Over IP enjoyable to build.

Keep experimenting

I do not want Hams Over IP to become just another telephone service.

I want it to remain a place where amateur radio operators can experiment with SIP, Asterisk, IAX2, RF linking, conferencing, networking, automation and whatever communications technology we decide to connect next.

Some experiments will become permanent features. Some will change considerably along the way. Others will teach us something useful and lead to a completely different idea.

That is part of amateur radio.

Thank you to everyone who continues to use the network, test new features, report problems, suggest improvements and help other operators get connected.

And the next time you want to call somebody on HOIP, try something different:

Dial 4010 and just say the callsign.

73,
WH6AV — Jesse
Founder, Hams Over IP

Hams Over IP continues to evolve quickly, and several projects are currently moving through development and testing.

In Issue No. 7, we will return with another detailed look at the technology, experiments and communications infrastructure being built across the network.

That may include new approaches to registration and routing, additional interoperability work, improvements to network visibility, and some of the projects currently being tested behind the scenes.

As always, we would rather show you a working system than announce something before it is ready.

Until then, keep experimenting, keep building and keep telling us what you would like to see Hams Over IP try next.