- Trixbox 2.6 PBX (Asterisk 1.4)
- Mixture of Linksys SPA 942 and Yealink SIP-T22P VOIP phones
- Phones connecting to the PBX from a remote site over WAN.
People using Yealink SIP-T22P SIP phones occasionally can't receive incoming calls. Outgoing calls working fine. Linksys phones are not affected. When the issue occurs Asterisk CLI shows phones as UNREACHABLE. Yealink web GUI displays phones as Registered. Rebooting phone resolves the issue until it happens next time.
Worst thing is that users don't have any indication when their phones are not able to receive incoming calls.
The first step was to replicate the issue. After some testing I was able to replicate the issue by cutting off Internet connection for certain period of time. If Internet was down for relatively long time (an hour or so), after connection was restored, all Yealink phones initially successfully re-registered with Asterisk PBX, but very soon PBX would report these phones as UNREACHABLE. Further testing revealed that issue was occurring if connection was down while phones were trying to re-register after SIP registration had expired. Cutting connection for an hour ensured all phones tried to re-register during downtime (default SIP registration timeout is 3600s). Shorter downtime would only affect phones trying to re-register during the downtime.
Enabling Asterisk debug logs revealed following sequence of evens:
VERBOSE logger.c: -- Registered SIP '651' at xx.xx.xx.xx port 40601 expires 3600
NOTICE chan_sip.c: Peer '651' is now Reachable. (145ms / 2000ms)
NOTICE chan_sip.c: Peer '651' is now UNREACHABLE! Last qualify: 145
Asterisk marks peers as UNREACHABLE if they fail to respond to "SIP OPTIONS" requests, which asterisk regularly sends to all peers when qualify option is set to yes
It seems that issue was caused by a bug in Yealink firmware. If Internet connection was down during re-registration attempt, when connection was restored, phones were successfully registering with PBX, but then subsequently failed to respond to SIP OPTIONS requests (until they were rebooted). All phones were running Yealink 184.108.40.206 firmware version.
Issue was resolved by updating Yealink phones to the latest firmware version, which at the time was 220.127.116.11.