Is call forwarding in Polycom phones fundamentally broken?
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? John
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
The one case where the Polycom might act funny is with shared lines. SCA will definitely remove the call forwarding option from the phone completely.
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. This is 100 % correct - the phone simply does a redirect. Looking for the redirection in an XSLog trace is usually how I find out that someone has call forwarding enabled when they swear they don't.
double check that 'voIpProt.SIP.serverFeatureControl.dnd' and 'voIpProt.SIP.serverFeatureControl.cf' This stuff is pretty well documented in the Polycom SIP Admin Guide but not really touched on in the Broadsoft partner guide for Polycom.
In general, I really like Polycom phones, but may have no choice but to switch to cisco/aastra/etc To be honest I have not found an endpoint that works better with the Broadworks platform than Polycom. Cisco endpoints running SIP are a total joke and the only time we use them is when customers want the Cisco name on display. I do have to say that the 7945/65 using the XML based configs are much better than the 7940/60 and the color displays are really impressive looking - 100% better than the color Polycoms. Of course there has been no interop done for them with Broadsoft and Cisco only officially supports SIP on the CCM platform for them. I managed to find a particular firmware version that actually has working NTP support while not breaking other features and cobbled together the config to get them working pretty well.
-----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Michael Bain Sent: Tuesday, December 21, 2010 7:10 PM To: JD Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] Is call forwarding in Polycom phones fundamentally broken? 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 _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
I agree with all the previous comments and want to add one more thing. If you don't set 'voIpProt.SIP.serverFeatureControl.dnd' and 'voIpProt.SIP.serverFeatureControl.cf' to synchronize the cf and dnd functions between the phone and the server AND are using the server side CF and/or DND (therefore no visual indication on the phone that it is forwarded) at least enable "Play Ring Reminder when a call is blocked" on the BroadWorks CF and DND configuration screens. This will play a brief ring splash on the user's phone when a call comes in. It is a reminder that calls are not actually terminating at the phone. -----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Dawson, Robert Sent: Wednesday, December 22, 2010 12:46 PM To: voiceops at voiceops.org Subject: Re: [VoiceOps] Is call forwarding in Polycom phones fundamentally broken?
The one case where the Polycom might act funny is with shared lines. SCA will definitely remove the call forwarding option from the phone completely.
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. This is 100 % correct - the phone simply does a redirect. Looking for the redirection in an XSLog trace is usually how I find out that someone has call forwarding enabled when they swear they don't.
double check that 'voIpProt.SIP.serverFeatureControl.dnd' and 'voIpProt.SIP.serverFeatureControl.cf' This stuff is pretty well documented in the Polycom SIP Admin Guide but not really touched on in the Broadsoft partner guide for Polycom.
In general, I really like Polycom phones, but may have no choice but to switch to cisco/aastra/etc To be honest I have not found an endpoint that works better with the Broadworks platform than Polycom. Cisco endpoints running SIP are a total joke and the only time we use them is when customers want the Cisco name on display. I do have to say that the 7945/65 using the XML based configs are much better than the 7940/60 and the color displays are really impressive looking - 100% better than the color Polycoms. Of course there has been no interop done for them with Broadsoft and Cisco only officially supports SIP on the CCM platform for them. I managed to find a particular firmware version that actually has working NTP support while not breaking other features and cobbled together the config to get them working pretty well.
-----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Michael Bain Sent: Tuesday, December 21, 2010 7:10 PM To: JD Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] Is call forwarding in Polycom phones fundamentally broken? 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 _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
Thanks everyone for helping with this. We have server-based CF mostly working in lab. Changing some stuff in the SBCs to complete. Short answer for us: Despite what the documentation says, the Polycom phones _do_ display whether they are being forwarded or not in server-based CF mode. At least with the firmware version we are testing with. Or I'm misreading page 4-20 of the Admin 3.1 guide :). @David: great idea about ring reminder. Might use that in other scenarios. John On 12/23/2010 12:10 PM, Zilk, David wrote:
I agree with all the previous comments and want to add one more thing.
If you don't set 'voIpProt.SIP.serverFeatureControl.dnd' and 'voIpProt.SIP.serverFeatureControl.cf' to synchronize the cf and dnd functions between the phone and the server AND are using the server side CF and/or DND (therefore no visual indication on the phone that it is forwarded) at least enable "Play Ring Reminder when a call is blocked" on the BroadWorks CF and DND configuration screens.
This will play a brief ring splash on the user's phone when a call comes in. It is a reminder that calls are not actually terminating at the phone.
-----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Dawson, Robert Sent: Wednesday, December 22, 2010 12:46 PM To: voiceops at voiceops.org Subject: Re: [VoiceOps] Is call forwarding in Polycom phones fundamentally broken?
The one case where the Polycom might act funny is with shared lines. SCA will definitely remove the call forwarding option from the phone completely.
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. This is 100 % correct - the phone simply does a redirect. Looking for the redirection in an XSLog trace is usually how I find out that someone has call forwarding enabled when they swear they don't.
double check that 'voIpProt.SIP.serverFeatureControl.dnd' and 'voIpProt.SIP.serverFeatureControl.cf' This stuff is pretty well documented in the Polycom SIP Admin Guide but not really touched on in the Broadsoft partner guide for Polycom.
In general, I really like Polycom phones, but may have no choice but to switch to cisco/aastra/etc To be honest I have not found an endpoint that works better with the Broadworks platform than Polycom. Cisco endpoints running SIP are a total joke and the only time we use them is when customers want the Cisco name on display. I do have to say that the 7945/65 using the XML based configs are much better than the 7940/60 and the color displays are really impressive looking - 100% better than the color Polycoms. Of course there has been no interop done for them with Broadsoft and Cisco only officially supports SIP on the CCM platform for them. I managed to find a particular firmware version that actually has working NTP support while not breaking other features and cobbled together the config to get them working pretty well.
-----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Michael Bain Sent: Tuesday, December 21, 2010 7:10 PM To: JD Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] Is call forwarding in Polycom phones fundamentally broken?
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 _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
participants (4)
-
David_Zilk＠adp.com -
jdupuy-list＠socket.net -
mike＠mostly-harmless.ca -
robert.dawson＠mindshift.com