Yes, but we don’t use TCP transport.
In one site we have about 40 GXP2000/GXP2010’s and I’ve seen this alot.
Rebooting the phone fixes the issue for about a while – well a few minutes,
then the old BLF subscription expires on the server with a high ‘version’
number, the BLF’s stop working at this stage.
A 2nd reboot of the phone is then required.
One of our senarios was that phones are randomly rebooted at night from
power glitch, etc.
The result is phone resubscribes within a few minutes, but before the
previous BLF subscription on the server has expired.
After a while the previous subscription expires on the server, sending
out a final ‘timed out’ NOTIFY, which the phone happily accepts, with a the
high ‘version’ number of the last subscription.
Now the phone is expecting the next NOTIFY to have a higher ‘version’
number but it won’t come until the server has sent enough updates to be
greater then the previous version number, as new subcriptions start the
‘version’ number at ‘0’.
Enabling ‘syslog on error’ on the phone helped me track this down. Didn’t
fix anything, just helped me understand.
I did write a patch for our system, that doesn’t send the timeout NOTIFY,
which is inline with MWI and CALL_COMPLETION
If the patch below helps, let me know and I’ll get a bug report raised.