Cover Story
From Box to First Call
Configure the endpoint, verify registration, place a test call, and understand what each milestone proves.
By WH6AV — Gescio “Jesse” Alpuro
For many operators, a SIP phone is their first direct interaction with Hams Over IP. You receive an extension and credentials, enter a handful of settings, and wait for the reassuring Registered status.
When everything works, the process can seem effortless. When it does not, terms such as authentication, transport, NAT, codecs, SIP ALG and registration expiry can quickly make a simple phone feel much more complicated.
SIP PhoneYour desk phone, ATA or compatible softphone
→ PJSIP Registration →Authentication and signaling to the PBX
Hams Over IPYour extension becomes reachable on the network
What you need before you begin
A typical endpoint configuration requires a SIP/PJSIP server, extension number, authentication username, password, SIP port and transport. Manufacturers use different labels: Registrar, SIP Server or Domain may describe the same basic destination; Auth ID, Authentication Name or User ID may describe the authentication identity.
Registration is the first milestone
Your phone sends a SIP registration request to the Hams Over IP PBX. The server challenges the device for authentication, the phone responds using its configured credentials, and—if the information is correct—the PBX records the device as a contact for your extension.
Seeing REGISTERED tells us signaling and authentication have succeeded. It does not prove that every part of a call will work.
Make the first test call
After registration, place a test call and verify audio in both directions. A successful conversation confirms much more than registration alone: call signaling, routing, codec negotiation and the RTP media path are all participating.
Change one thing at a time
Good VoIP troubleshooting is methodical. Determine whether the failure is at registration, call establishment or audio, then investigate that layer. Changing several unrelated settings at once often hides the original problem.
Registration → signaling → call establishment → two-way audio. Following that order turns a vague “my phone doesn't work” report into a much smaller technical problem.
Technical Corner
What “Registered” Actually Means
Understanding registration makes troubleshooting much faster.
By Hams Over IP Editorial
SIP registration is the endpoint telling the PBX where it can currently be reached. The registration is not permanent; the phone periodically refreshes it so the PBX knows the contact is still available.
Registered does not mean the whole call path is healthy
A phone can be registered while outbound routing is incorrect, an inbound destination is unavailable, or RTP media is being blocked. That distinction is extremely useful when diagnosing problems.
- Registration failure: investigate credentials, server address, port, transport, DNS and network connectivity.
- Call does not establish: investigate dialing, routing, destination availability and signaling.
- Call connects but audio fails: investigate RTP/media, NAT, firewall behavior and codec negotiation.
The status display on the telephone is evidence about one layer of the system—not a verdict on every layer.
Audio & Codecs
When Signaling Works but Voice Does Not
Codec negotiation is important, but NAT and the RTP media path matter just as much.
By Hams Over IP Editorial
Once a call is established, both endpoints need to agree on how voice will be encoded. That is the job of the codec.
Rather than enabling every codec a phone happens to offer, configure the codecs appropriate for the Hams Over IP connection and place preferred choices in a sensible order.
When the call connects but you cannot talk
No audio and one-way audio are not automatically codec problems. If SIP signaling successfully established the call, inspect the media path as well. RTP may be affected by NAT, firewall rules or incorrect addressing.
Separate signaling from media: SIP establishes and manages the call; RTP normally carries the voice. Knowing which side is failing prevents unnecessary configuration changes.
NAT & Home Networks
Routers, Firewalls and SIP ALG
Home networks add another layer to SIP and RTP troubleshooting.
By Hams Over IP Editorial
Most home operators place their SIP phone behind a router using a private IP address. Network Address Translation is therefore part of the normal path between the endpoint and the PBX.
Watch for SIP ALG
Some routers include a SIP Application Layer Gateway intended to help VoIP traverse NAT. Implementations vary, and an ALG that rewrites SIP traffic incorrectly can create registration, inbound-call or audio problems.
Symptoms that deserve a network/NAT investigation include a phone that registers but cannot receive calls, one-way audio, registrations that periodically disappear, unexpected call drops, or a phone that works on one network but not another.
Do not disable security features or expose the phone directly to the Internet as a first troubleshooting step. Confirm the failure layer and make targeted changes.
Troubleshooting
A Practical SIP Phone Checklist
Work from network connectivity to registration, call setup and finally two-way audio.
By Hams Over IP Editorial
- Confirm the phone has network connectivity. Verify it received an IP address and can reach the network.
- Verify the SIP server. A typo in the registrar/server field sends registration to the wrong place.
- Verify the extension and authentication ID. Do not assume the phone uses the same label as another manufacturer.
- Re-enter the password carefully. SIP credentials are case-sensitive; copied spaces can cause authentication failures.
- Check port and transport. Use the values assigned for the connection rather than guessing.
- Look at registration status. If registered, move the investigation toward routing, call setup or media.
- Place a controlled test call. Note whether it rings, connects, and has audio in each direction.
Record what changed and test one variable at a time. A short troubleshooting log is often more valuable than repeatedly resetting the phone.
Premium Update
Change Your Voicemail Password from Your Phone
A new self-service option is available directly through the voicemail system.
By Hams Over IP Editorial
Hams Over IP Premium users can now change their voicemail password directly from their telephone.
Change your voicemail password
Dial *97, choose 0 — Mailbox Options, then choose 5 — Change Password. Enter the new password twice when prompted.
This adds another self-service capability for Premium operators without requiring an administrator to manually change voicemail credentials.
Network Update
Around the Hams Over IP Network
Premium self-service, knowledge resources, call forwarding and inter-PBX development continue to expand.
By Hams Over IP Editorial
Development across Hams Over IP continues rapidly. Recent work includes improvements to Hams Over IP Premium, expanded PBX Resource Manager capabilities, a user-facing Knowledge Base, targeted Notices & Updates, improved call-forwarding visibility and continued work on inter-PBX architecture.
We have also been working with Asterisk DUNDi as a method of discovering destinations between participating PBX systems. DUNDi is a large enough subject to deserve its own issue rather than a few paragraphs here.
Gear Desk
Choosing an IP Phone for Hams Over IP
Prioritize interoperability, configuration, documentation and the features you will actually use.
By Hams Over IP Editorial
For a Hams Over IP endpoint, the best phone is not necessarily the model with the longest feature list. Start with the features that make an IP phone practical to configure, operate and support.
- SIP/PJSIP compatibility and clear account configuration.
- Multiple accounts if your operating setup needs them.
- Programmable keys and BLF for operators who monitor network resources.
- Ethernet and PoE where a single-cable installation is useful.
- Appropriate codec support and reliable audio.
- A usable web interface for configuration and troubleshooting.
- Firmware and documentation that remain available from the manufacturer.
Hams Over IP operators use equipment from many vendors, including Cisco, Grandstream, Yealink, Fanvil and software endpoints. The configuration labels may differ, but the SIP concepts in this issue remain the same.
Editorial disclosure: This section is general editorial guidance and is not a paid endorsement of a particular manufacturer.
Sustaining the Network
Keeping Hams Over IP Available
Participation, experimentation and optional financial support all help sustain the community.
By Hams Over IP Editorial
Hams Over IP remains a community-focused service, while servers, connectivity, monitoring, storage and continued development carry real operating costs. Contributions are optional, but they help offset the infrastructure that keeps the network available.
Just as valuable is participation: use the network, test new capabilities, document what you learn and help another operator get connected.
Support Hams Over IP
Next Issue
Coming in Issue No. 4: DUNDi
Distributed destination discovery and the future of interconnected amateur-radio VoIP networks.
By Hams Over IP Editorial
For Issue No. 4, we plan to zoom back out from the endpoint and examine Asterisk DUNDi and interconnected amateur-radio VoIP networks.
How can independent PBXs discover destinations without maintaining an enormous collection of static routes? We will look at distributed number discovery, how DUNDi differs from an ordinary SIP or IAX2 trunk, and what it can mean for cooperating amateur-radio IP networks.
