[VoiceOps] Is call forwarding in Polycom phones fundamentally broken?

[Michael Bain]

On 21 December 2010 14:50, JD <jdupuy-list at socket.net> wrote:
> 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.

This sounds like you want BroadWorks' "Call Forwarding Not Reachable"
service to cover this case.

> (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...)

This doesn't make sense... When using the client side CF, the Polycoms
send a 3xx message in response to the INVITE. There is no dialog
set-up, and no media exchanged. BW will just resend the INVITE to the
address in the Contact: header from the 3xx response. There is no
further interaction with the forwarding phone.

> 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 expected behavior of the feature is the behavior you want. The one
case where the Polycom might act funny is with shared lines. With
private lines, I'd double check that
'voIpProt.SIP.serverFeatureControl.dnd' and
'voIpProt.SIP.serverFeatureControl.cf' are enabled (and I'd recommend
disabling 'voIpProt.SIP.serverFeatureControl.localProcessing.cf' and
'voIpProt.SIP.serverFeatureControl.localProcessing.dnd' as well. This
way the phones will respect any override cases to the DND & CF
features)

Enabling the serverFeatureControl features will cause the phones to
start SUBSCRIBEing to the featureSync event package, so you can check
your AS logs or a packet capture to confirm that it's being set up
correctly.

If you've done all that, and you're still not seeing the behavior
expected then I'd suggest opening a ticket with Polycom Support.

(I've not tested any of the above, and it's all off the top of my head
so I may have missed something, but the essentials should be
correct...)

Mike