[VoiceOps] Is call forwarding in Polycom phones fundamentally broken?
jdupuy-list at socket.net
Tue Dec 21 17:50:13 EST 2010
I've encountered this problem in the past, many years ago, when
working with Asterisk farms. I'm encountering it again now working with
the Broadsoft platform:
Polycom Soundpoint IP phones can do call forwarding in two ways:
client-side and server-side.
In client-side mode, the phone itself does the forwarding. If the phone
is unreachable for any reason, the call forwarding never actually
happens. That is because the call server doesn't know to forward the
call and the phone isn't reachable to do the forwarding. By default, the
call usually goes to VM, which is not what the user wanted. So, it works
most of the time, but not predictably. So, it is broken by design.
(Plus with the half-broken NAT support on the Polycoms, any forwarded
calls needlessly burn two audio streams because the call is not likely
to transfer off the handset. But, I'll refrain on Polycom NAT commentary
for the moment...)
So, we go with server-side...
In server-side mode, the phone refuses to show that the phone is
forwarded anywhere on the screen. It is not uncommon for the user to
"wonder why they aren't getting calls" if they forget to cancel the
forwarding. So, it is also broken by design. (Albeit, not as badly as
client-side, since at least it will always function.)
This does not appear to be a bug, since it is well documented by Polycom.
The only work-around I've come up with is writing a customized hack that
modifies the idle screen, but that is far less than ideal. :)
In general, I really like Polycom phones, but may have no choice but to
switch to cisco/aastra/etc.
But, before I do, has anyone come up with a better work-around?
More information about the VoiceOps