Rick Guyton Posted August 6, 2019 Report Share Posted August 6, 2019 (edited) I'm creating a series of end user training videos right now. And I've run into an interesting issue on Polycom phones. Whenever I park a call, then go to retrieve it, the phone dials a 10 instead of *. Video attached (sorry for the quality, I had to compress it a lot) Any thoughts on what would cause this? How to fix it? https://photos.app.goo.gl/CbrryvqgiwWnXtqi9 Every time I do a park by transferring this happens... Edited August 6, 2019 by Rick Guyton Web link for video 'cause I'm not cool enough to get the formatting right (see edit history) Quote Link to comment Share on other sites More sharing options...
Baze Posted August 6, 2019 Report Share Posted August 6, 2019 Is this a phone provisioned using the 2600 server, or one you've manually setup? If memory serves there are a few ways to park, so it may be using the alternate method which prepends it this way? Here are the important bits: <!-- attendant console and blf --> <attendant.behaviors.display.spontaneousCallAppearances.normal="0" ##SO THAT YOU DON'T HAVE ANNOYING POPUP THINGS attendant.behaviors.display.spontaneousCallAppearances.automata="0" ##DITTO ABOVE attendant.behaviors.display.remoteCallerID.normal="1" attendant.behaviors.display.remoteCallerID.automata="1" attendant.resourceList.1.address="*31" ##YOUR ACTUAL PARK LINE, SO THIS PARKS TO SLOT ONE ON KAZOO attendant.resourceList.1.label="Park 1" /> <!-- allow lineKey customization --> <lineKey lineKey.reassignment.enabled="1" lineKey.1.category="line" lineKey.1.index="1" linekey.2.category="BLF" linekey.2.index="0" /> ##SETTING LINEKEY TO BE THE BLF TYPE <!-- user preferences --> <up up.softkey.transferTypeOption.enabled="1" ##SETS THE WARM/COLD TRANSFER DEFAULT TYPE up.BLFDefaultLineView="0"/> <!-- call options --> <call call.defaultTransferType="Consultative" ##SETS TO WARM TRANSFER BY DEFAULT call.directedCallPickupMethod="native" ##IMPORTANT TO MAKE SURE ONE TOUCH PICKUP OF A RINGING LINE WORKS (USING REPLACES HEADERS) call.directedCallPickupString="" ##THIS MAY BE WHERE YOUR 10 IS COMING FROM. YOU CAN LEAVE BLANK FOR KAZOO call.parkedCallRetrieveMethod="native" ##MAKES SURE THE ONE TOUCH PICKUP WORKS call.hold.localReminder.enabled="1"/> ##GIVES A NICE REMINDER TONE WHEN SOMEONE IS ON HOLD. Quote Link to comment Share on other sites More sharing options...
Karl Stallknecht Posted August 6, 2019 Report Share Posted August 6, 2019 I don't see the video anywhere? @Rick Guyton Quote Link to comment Share on other sites More sharing options...
Rick Guyton Posted August 6, 2019 Author Report Share Posted August 6, 2019 @Baze: I think that only applies if you are using keys to parking. I'm just using a transfer to *3 in this part. Thanks for the heads up, I'll be doing it based on keys next... Probably saved me another post. @Karl Stallknecht: I'm seeing why youtube is such a thing. I'm trying to get it into a format that plays on Firefox and under the max attachment size.... Got video working, just no audio Quote Link to comment Share on other sites More sharing options...
Baze Posted August 6, 2019 Report Share Posted August 6, 2019 Oh i see - should have watched video first. can you paste your dial plan? Quote Link to comment Share on other sites More sharing options...
Karl Stallknecht Posted August 6, 2019 Report Share Posted August 6, 2019 @Rick Guyton I'm having a little bit of trouble seeing the video now, but I think I may see the problem. You need to enter *3 and then the parking spot number, not just *3. I think Polycoms don't like the short transfer code and want a longer one. Also, I would highly recommend doing this with the BLF keys. Setup a BLF key via advanced provisioner like *31 and *32 (Park 1 and Park 2 respectively) and be sure to set them as automata. Then all the user has to do is press the park key rather than press transfer and remember a feature code. Also this way they'll be able to see who is parked. Quote Link to comment Share on other sites More sharing options...
Rick Guyton Posted August 6, 2019 Author Report Share Posted August 6, 2019 Just now, Baze said: Oh i see - should have watched video first. can you paste your dial plan? Heh, to be fair I've been fighting with the video, probably wasn't there when you looked. It's the provisioner defaults for this phone Quote *xxT|xxxxT|[2-9]11|0T|011xxx.T|[1][2-9]xxxxxxxxx|[2-9]xxxxxxxxx|[2-9]xxxT|x.T|*xx.T|**xx.T Quote Link to comment Share on other sites More sharing options...
Rick Guyton Posted August 6, 2019 Author Report Share Posted August 6, 2019 Ok, more, it doesn't appear to have anything to do with parking itself. It happens on the first call after ANY transfer. Video attached below (this time as a web link). I get a call from 1002, transfer to 1003. Then, press * and instead of dialing *, it dials 10. So strange... https://photos.app.goo.gl/jw1RWktcNAwkiSWS7 Quote Link to comment Share on other sites More sharing options...
Baze Posted August 6, 2019 Report Share Posted August 6, 2019 Turns out we can recreate also. Must be a bug! Quote Link to comment Share on other sites More sharing options...
Rick Guyton Posted August 6, 2019 Author Report Share Posted August 6, 2019 Hey @Plau Any thoughts on this? Quote Link to comment Share on other sites More sharing options...
2600Hz Employees Plau Posted August 6, 2019 2600Hz Employees Report Share Posted August 6, 2019 I just tested it on my end on a VVX601 and I do see it happening. I never noticed before because I would only dial off hook or pushed the speaker button. I was able to avoid the 10 popping up when pushing * by setting the transfer type to Blind (both through the phone and provisioning the Polycom with the default transfer type as Blind) Did this use to work before? Or is this something recent? Quote Link to comment Share on other sites More sharing options...
Rick Guyton Posted August 6, 2019 Author Report Share Posted August 6, 2019 Just now, Plau said: I just tested it on my end on a VVX601 and I do see it happening. I never noticed before because I would only dial off hook or pushed the speaker button. I was able to avoid the 10 popping up when pushing * by setting the transfer type to Blind (both through the phone and provisioning the Polycom with the default transfer type as Blind) Did this use to work before? Or is this something recent? Thanks for looking Plau! I couldn't tell you honestly, I have been pretty hard core Yealink for quite some time. It's only recently that I've dipped a toe into Polycom again. Do you think you guys could use your contacts at Poly to get more info? Obviously, switching the default transfer type to blind isn't going to be a good fix. Quote Link to comment Share on other sites More sharing options...
2600Hz Employees Plau Posted August 6, 2019 2600Hz Employees Report Share Posted August 6, 2019 We default transfer to blind for all the brands except Polycom. I discovered that you could switch the default transfer type to Blind way too late, so I left it as Attended to preserve the expected behavior. I'll reach out to Poly to see if they can shed some light on this issue. Quote Link to comment Share on other sites More sharing options...
Rick Guyton Posted August 6, 2019 Author Report Share Posted August 6, 2019 1 minute ago, Plau said: I'll reach out to Poly to see if they can shed some light on this issue. Thanks Plau! Quote Link to comment Share on other sites More sharing options...
esoare Posted August 7, 2019 Report Share Posted August 7, 2019 (edited) Moved this post to Edited August 7, 2019 by esoare Moved post (see edit history) Quote Link to comment Share on other sites More sharing options...
Rally IP Admin Posted August 7, 2019 Report Share Posted August 7, 2019 Try factory reset and wipe off all call histories. What's the firmware version? Quote Link to comment Share on other sites More sharing options...
Rick Guyton Posted August 7, 2019 Author Report Share Posted August 7, 2019 (edited) 2 hours ago, Rally IP Admin said: Try factory reset and wipe off all call histories. What's the firmware version? f/w is the provisioner default of 5.4.6 This phone was very recently wiped clean and provisioned from provisioner. Plau and Baze have both replicated it, so I don't think it's the phone's config. More info, I did change the default transfer type to blind. And at first I did think this fixed it. BUT, then I did an attended transfer and it happened again. So, apparently, pressing the star button after doing any attended transfer causes "10" to be dialed instead of *. Very strange stuff... BTW, @esoare the embedded video works, thanks!! Edited August 7, 2019 by Rick Guyton (see edit history) Quote Link to comment Share on other sites More sharing options...
Rally IP Admin Posted August 7, 2019 Report Share Posted August 7, 2019 Must some sort of speed dial. Quote Link to comment Share on other sites More sharing options...
2600Hz Employees Plau Posted August 8, 2019 2600Hz Employees Report Share Posted August 8, 2019 On 8/7/2019 at 1:40 PM, Rick Guyton said: More info, I did change the default transfer type to blind. And at first I did think this fixed it. BUT, then I did an attended transfer and it happened again. So, apparently, pressing the star button after doing any attended transfer causes "10" to be dialed instead of *. Very strange stuff... I guess I wasn't that clear when I wrote my post earlier. It doesn't happen on Blind Transfers, but will always happen on Attended Transfers. It only happens when a Transfer button is pressed before the phone is no longer on an active call. That's why it doesn't happen the second time you press *. You can't recreate it when the phone boots up and press * for this same reason. Blind Transfers doesn't actually fix the issue, it's more of you won't run into it because it's a problem that only occurs with Attended Transfers. Quote Link to comment Share on other sites More sharing options...
Rick Guyton Posted August 8, 2019 Author Report Share Posted August 8, 2019 1 hour ago, Plau said: I guess I wasn't that clear when I wrote my post earlier. It doesn't happen on Blind Transfers, but will always happen on Attended Transfers. It only happens when a Transfer button is pressed before the phone is no longer on an active call. That's why it doesn't happen the second time you press *. You can't recreate it when the phone boots up and press * for this same reason. Blind Transfers doesn't actually fix the issue, it's more of you won't run into it because it's a problem that only occurs with Attended Transfers. Oh, thanks Plau, I misunderstood what you were saying. Thanks for the clarification! Quote Link to comment Share on other sites More sharing options...
Rally IP Admin Posted August 9, 2019 Report Share Posted August 9, 2019 There must be something with the code.. If you press "#" instead "*", you get 11. 🙂 Quote Link to comment Share on other sites More sharing options...
2600Hz Employees Plau Posted August 9, 2019 2600Hz Employees Report Share Posted August 9, 2019 Looks like it's an issue with the older firmwares. It's resolved in 5.9.2. https://support.polycom.com/content/dam/polycom-support/products/voice/business-media-phones/release-notes/en/uc-software-release-notes-5-9-3.pdf Quote General EN-122406 After you complete a consultative transfer, VVX phones display the number “10” when you press the star (*) key when the phone is in an idle state. Quote Link to comment Share on other sites More sharing options...
Rick Guyton Posted August 9, 2019 Author Report Share Posted August 9, 2019 7 minutes ago, Plau said: Looks like it's an issue with the older firmwares. It's resolved in 5.9.2. https://support.polycom.com/content/dam/polycom-support/products/voice/business-media-phones/release-notes/en/uc-software-release-notes-5-9-3.pdf Awesome research Plau, thanks! I've upgraded to 5.9.2 and confirmed it's fixed. Any idea when that beta tag will be removed from it? I really hate running beta anything Quote Link to comment Share on other sites More sharing options...
2600Hz Employees Plau Posted August 9, 2019 2600Hz Employees Report Share Posted August 9, 2019 So there's a security flaw with a number of the older firmwares, so I'm working on updating all the Polycoms to newer versions of the firmwares that doesn't have the security flaw. I was originally going to update to 5.8.4, but it looks like I'll have to go to 5.9.3 because of this issue. Once we have it QAed, then we'll announce the release to Production. Quote Link to comment Share on other sites More sharing options...
Rick Guyton Posted August 9, 2019 Author Report Share Posted August 9, 2019 14 minutes ago, Plau said: So there's a security flaw with a number of the older firmwares, so I'm working on updating all the Polycoms to newer versions of the firmwares that doesn't have the security flaw. I was originally going to update to 5.8.4, but it looks like I'll have to go to 5.9.3 because of this issue. Once we have it QAed, then we'll announce the release to Production. To be clear, I updated to 5.9.2 and it works. 5.9.3 wouldn't be necessary unless there are other needs. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.