Post
When phone firmware causes no audio
Firmware belongs on the suspect list when a phone registers, rings and establishes a call but audio fails on that model alone. It should not be the first explanation for every silent call. The useful clue is a boundary: older phones work on the same extension, network and PBX while a particular model or firmware build does not.
That pattern is easy to miss during a rollout. Registration looks healthy, the firewall test passes, and the failure resembles a familiar RTP problem. Teams can spend hours changing NAT and codec settings around a fault introduced at the endpoint.
A quick isolation matrix
| Test | Result | What moves up the list |
|---|---|---|
| New phone to new phone, same LAN | No audio | Phone configuration, firmware, codec or local switching |
| Known-good phone to known-good phone | Two-way audio | Not a site-wide PBX or carrier outage |
| New phone replaced by known-good phone on the same cable and extension | Audio returns | Endpoint model, provisioning or firmware |
| New phone on a known-good firmware build | Audio returns | The changed firmware becomes the leading variable |
The third test is especially valuable because it holds the switch port, VLAN, extension, route and call destination steady.
Prove where RTP stops
Run one internal call before involving the carrier. Capture at the PBX or SBC and, if possible, mirror the phone’s switch port. Compare the negotiated SDP with the actual RTP streams.
- If the phone sends RTP but cannot receive it, follow the return address, port and switch path.
- If RTP reaches the phone but the handset produces silence, the endpoint deserves closer attention.
- If the phone sends no RTP after answering, compare its SDP, codec choice and behaviour with a working model.
- If internal audio works but external audio fails, put the trunk and carrier leg back into scope.
Do not infer a firmware defect merely because the version is new. A provisioning template may expose a setting that the previous build ignored, or the PBX may support only a tested firmware branch.
Record versions before changing them
For each affected phone, record the exact model and hardware revision, current firmware, bootloader where available, provisioning method, PBX version and assigned template. “Latest firmware” is not a reproducible version.
Check the PBX platform’s supported-phone list as well as the manufacturer release notes. 3CX, for example, manages supported phone firmware through its administration workflow and publishes platform-specific firmware guidance. A manufacturer’s newest release and a PBX vendor’s tested release may not be the same build.
Use a controlled rollback
A rollback is a test, not a permanent strategy by default.
- Select one affected phone outside a critical position.
- Save its current configuration and document how it can be recovered.
- Install a known-supported build using the approved method.
- Reprovision, then repeat the same internal and external calls.
- Confirm audio in both directions, hold, transfer, DTMF and headset operation.
- Decide whether to pause the rollout, remain on the tested build or escalate with captures.
If a known-good build restores audio on the same phone, cable, extension and call path, stop changing the firewall. Preserve both captures and send the vendor a narrow reproduction case.
What to include in the vendor case
Provide the affected and working firmware versions, hardware revision, a sanitised configuration, one successful and one failed Call-ID, packet captures from the same point, and the smallest repeatable call sequence. State whether the fault affects the handset, speaker, headset or every audio device.
For related checks, see phone provisioning, VoIP packet captures and voice codecs.
Technical references
Scheduled for 18 August 2026. Firmware procedures and supported builds vary by phone model, hardware revision and PBX release.