It’s not uncommon when debugging VoIP phone systems to simplify as much as possible to eliminate possible incompatibilities, as well as to reduce TCP packet size. Especially having too many codecs can cause issues; in the U.S., the default codec that is assumed to always work is PCMU, also known as G711u.
However I’ve just run across an issue where the simplification caused very confusing issues.
The Environment
The environment was fairly simple:
- A Grandstream UCM6301 PBX running the latest firmware (version 1.0.25.9).
- A desk phone and Grandstream Wave for Windows (version 1.25.13) registered to extension 100.
- A simultaneous ring group that included x.100 and x.110, with a 20-second delay before delivering to the voicemail for x.100.
- A third extension x.105 registered on a desk phone for testing.
- x.100 and x.105 used TLS/SRTP. x.110 used UDP and unencrypted RTP. All extensions were configured to use PCMU only.
- A VoIP trunk with an inbound route pointing to the ring group.
The Symptoms
The symptoms were confusing and misleading:
- Calling in from outside: the ring group rang x.100 four times. The call rang on the desk phone but not in Wave. Wave showed a missed after 20 seconds, then the call kept ringing until it was answered.
- Calling internally from x.105 to x.100: the call rang four times on the x.100 desk phone but not in Wave, then went to a busy signal instead of to voicemail. Wave showed the missed call. The x.105 desk phone displayed code “Q.850 Cause 58” which means “Bearer capability not presently available.”
- I temporarily switched the x.105 desk phone to UDP and pulled a trace during a failed call. After ringing four times, the SIP response from the PBX was “488 Not Acceptable Here”.
- If I logged out of Wave and dialed x.100 from x.105, the desk phone rang four times, then the call when to voicemail as expected. A trace showed that the PBX accepted the INVITE with a “200 OK”.
- If I logged back in to Wave, I could dial from Wave (x.100) to x.105 with two-way audio. So the codec and SRTP are okay; it’s just that Wave isn’t getting or accepting SIP signaling for the call.
The Problem: Wave Requires H.264 for Voice Calls
When you initially configure an extension in the UCM63xx, it allows no fewer than nine codecs, in this order: G.722, PCMU, PCMA, GSM, G.726, G.729, H.264, iLBC, and OPUS. That’s a lot of overhead to carry around. But it turns out that trimming it back to PCMU only is too much. Through some trial and error, I discovered that Wave will ring if H.264 is enabled in the extension. In the UCM, here is what Extension/Trunk > Extensions > Media tab > Codec Preference looks like now:
I don’t understand why Wave requires a video codec to accept voice calls—it seems like a bug. But once I turned on H.264 in the extension configuration, Wave started working as expected—it rang when called internally, it rang when an external call triggered the ring group, and when the call was unanswered, it transferred properly to voicemail.
General Troubleshooting Tips
Troubleshooting this kind of issue is a matter of simplifying and narrowing down as much as possible. It seems no one decrypts TLS traffic for debugging, so see if you can replicate the issue with UDP or maybe TCP so you can see the error messages in the SIP traffic. And when working with a configuration that “should” work by default, go back to the default for testing. It was easy to create a test extension with all nine codecs. When that worked with Wave, I enabled SRTP. When that worked, I started removing codecs until I found that Wave wouldn’t work without H.264.