Logicwrath Posted August 2, 2017 Report Posted August 2, 2017 It would be nice if the Advanced Provisioner said something like "Current (v80.0.1337)" instead of "Current". Current will change and I might not know what it is currently. It would also be nice if you could give us an option to download the device CFG file in case we want to review it for troubleshooting or hosting elsewhere. You could add a download option to the settings cog.
Rick Guyton Posted August 3, 2017 Report Posted August 3, 2017 Yea, I agree. Though I think they'll probably announce it when they do it. I'm a little concerned for the first big update. Hopefully they will do something like a staged roll out. All MACs ending with a 1 on day one, all MACs starting with a 2 on day 2, etc
Logicwrath Posted August 3, 2017 Author Report Posted August 3, 2017 15 minutes ago, Rick Guyton said: Yea, I agree. Though I think they'll probably announce it when they do it. I'm a little concerned for the first big update. Hopefully they will do something like a staged roll out. All MACs ending with a 1 on day one, all MACs starting with a 2 on day 2, etc I agree that doing the changes in stages would be best case. I worry that something will get over looked and a setting might get missed or the inherit might be broken etc for a critical item. Part of the problem is even if they announce the change, the Current is different between models in some cases and I may forget which model is current on which version. The BLF issues were so bad with that one v73 that I would never want to use that. I need to know if I should still be manually setting it on new deployments.
Administrators Darren Schreiber Posted August 3, 2017 Administrators Report Posted August 3, 2017 As noted via emails and forum announcements we are now trying to post with a few days notice prior to updates. That will include firmware updates.
Logicwrath Posted August 3, 2017 Author Report Posted August 3, 2017 In Advanced Provision for T46S for example current is: v81.0.90. However, the only other selectable option is: v81.0.110. If you notify us of a Current change, we don't have the ability to select the existing current firmware manually to avoid the change if we actually wanted to avoid the change. I think one thing we could do is start testing the v81.0.110 to try and find problems ahead of the change. However, announcing the change does not improve the safety if we can't avoid it. I had to check my phone status to find out what firmware was Current for that model. I would still like Current to be specified. 1. Show it like Current (v81.0.90) 2. Allow v81.0.90 to be selectable outside of current. 3. Make sure we have enough time to provision and test out phones on the newer firmware. I suspect it will be available to be selected ahead of the change.
Administrators Darren Schreiber Posted August 3, 2017 Administrators Report Posted August 3, 2017 Perhaps then we simply add an "Beta (vXXX)" category. Then you can set some phones to Beta, watch for the announcements, and test. We'll leave a week in between before we promote a firmware after announcing it (minimum).
Administrators Darren Schreiber Posted August 3, 2017 Administrators Report Posted August 3, 2017 Also, yes, the current firmware should be listed in addition to the "Current" option, I'll note that with @Peter Lau
Rick Guyton Posted August 3, 2017 Report Posted August 3, 2017 Perhaps the solution to all of this might be the white label URL for firmware. For those that want a different default firmware than what's offered: If you are hosing your own files, who says T27-45.80.0.95.rom has to actually contain 45.80.0.95? Rename T27-45.80.0.130.rom to T27-45.80.0.95.rom and boom! Now your "default" is .130 not .95. For those that are concerned about new firmware: So... don't put up the new T27-45.999.999.999 firmware up. Provisioner can reference it all it wants. If it's not there, it's not upgrading. Thoughts?
Administrators Darren Schreiber Posted August 3, 2017 Administrators Report Posted August 3, 2017 I don't think we'll do that, that's kind of "black magic" that gets us in trouble. Though creative :-) I can imagine our poor support staff trying to tell some super picky client to point their firmware server to their own server (they'll freak) and then tell them to manage and host their own firmware files and if they don't like a firmware to just not host it. They will not like it.
esoare Posted August 3, 2017 Report Posted August 3, 2017 After the minimum week (perhaps more) and the new "current" firmware is rolled out. What if a huge bug gets identified? i/e: the Yealink BLF fun we had a few firmware's back. Can you make a mechanism that would be able to allow us (or you the provider) to roll back easily? I would recommend that. Just in Case. esoare
Administrators Darren Schreiber Posted August 4, 2017 Administrators Report Posted August 4, 2017 Well the beta strategy I listed above would likely give enough time to find any huge bugs. To roll-back I suspect we could just remove the bad firmware which would change the default/Current one. However frankly the problems have been amplified not by a need to roll back (the manufacturers have been pretty good with fixing actual bugs quickly) but more with an inability to quickly release & move forward without being disruptive. So I feel a bit of this nervousness is from being burned in the past in ways that may not happen in the future.
esoare Posted August 4, 2017 Report Posted August 4, 2017 14 minutes ago, Darren Schreiber said: Well the beta strategy I listed above would likely give enough time to find any huge bugs. To roll-back I suspect we could just remove the bad firmware which would change the default/Current one. However frankly the problems have been amplified not by a need to roll back (the manufacturers have been pretty good with fixing actual bugs quickly) but more with an inability to quickly release & move forward without being disruptive. So I feel a bit of this nervousness is from being burned in the past in ways that may not happen in the future. I would agree with your statement of nervouseness being do to past burns and scarring. I guess something that wasn't mentioned, and I just thought of since you posted your reply Darren, is the following: There would be an announcement of the new firmware available in advanced provissioner. Reseller's would have an opportunity to select a few customers with various needs to upgrade their phones. If there are reports with said customer's we open service tickets that could be tracked to the new firmware. The Current wouldn't be forced without those being closed. (I'm not making a rule here, just a suggestion.) Obviously a "bad firmware" wouldn't be forced as current. If no reports, then the Firmware Current change is announced. And we move on with life.
Administrators Darren Schreiber Posted August 6, 2017 Administrators Report Posted August 6, 2017 I agree with that completely. We'd LOVE to have the public feedback. Frankly we've also been struggling with how to get people to actually test. I know ya'all are busy, but honestly we can't think of everything to test and it drives the costs way up if 100% of the testing is on us. I am debating whether people get "bug hunter" credits that they can cash in as incentives or something for participating in the testing. We've been pretty religious at this point about pushing ALL updates to sandbox WEEKS before pushing to production, and that includes provisioner. But we're only seeing two or three people actually use sandbox to pre-test regularly.
Rick Guyton Posted August 6, 2017 Report Posted August 6, 2017 1 hour ago, Darren Schreiber said: I agree with that completely. We'd LOVE to have the public feedback. Frankly we've also been struggling with how to get people to actually test. I know ya'all are busy, but honestly we can't think of everything to test and it drives the costs way up if 100% of the testing is on us. Ok two thoughts here. First, I'm not sure FW issues specifically needs to be handled in the sandbox. We can just upgrade our phones and report back like I did on the 80.130 yealink f/w. Second, while I think bug hunter credits would be awesome, I think the bigger issue is more that we don't know what awesomeness is available in sandbox because you only announce changes when they get to production. Right now for instance my Monday is clear. If I knew what new hotness was available in sandbox right now, I might spend a good part of the day whacking at it. And if I knew when that multi location feature was dropping, I'd block off a week to turn it inside out and back again. But I really don't want to slog through every app in sandbox trying to find new buttons to hit every week.
Administrators Darren Schreiber Posted August 6, 2017 Administrators Report Posted August 6, 2017 That makes sense. What if we add a special newsletter you can sign up for that is solely for sandbox updates?
esoare Posted August 6, 2017 Report Posted August 6, 2017 13 hours ago, Darren Schreiber said: I agree with that completely. We'd LOVE to have the public feedback. Frankly we've also been struggling with how to get people to actually test. I know ya'all are busy, but honestly we can't think of everything to test and it drives the costs way up if 100% of the testing is on us. I am debating whether people get "bug hunter" credits that they can cash in as incentives or something for participating in the testing. We've been pretty religious at this point about pushing ALL updates to sandbox WEEKS before pushing to production, and that includes provisioner. But we're only seeing two or three people actually use sandbox to pre-test regularly. I wouldn't mind having my company "in" the sandbox... Maybe I would if it went down. Lol. But it sure would get me testing new stuff. OR I was playing around with existing phones between production and sandbox. I basically would use Yealink RPS and Grandstream Gaps to change which provisioner to point to, sandbox or production, therefore it just required a "reset to manufacturers settings" the phone would reset and go to RPS or Gaps to get additional provisioner server settings. (question, are the two provisioned totally separate? So I can leave the phones built with the same Mac addresses and it won't cause issues, is my question) If the above answer is, it's OK, then I don't see a need to put my company in sandbox. ***************************************** 12 hours ago, Darren Schreiber said: That makes sense. What if we add a special newsletter you can sign up for that is solely for sandbox updates? Please make the newsletter part of the forum also!! That way all the info is in one place. I already asked a programming/api question, which would have been tougher if the smart people where on the Google groups. Being able to see what was released in the sandbox, would be easier to play with, if it was in the forum, versus in an email based newsletter, that we would have to hunt down. There may be a need to lock that topic down since some features won't make it to production or be delayed. But I would suggest the more eyes that are on it the better. Perhaps some of the people running their own cluster want to test out the latest stuff also. Hope that helps. esoare
esoare Posted August 8, 2017 Report Posted August 8, 2017 (edited) I just had a mind blowing idea! What if you could select any of the firmware's available for the phone? This would be helpful for us to "test" things out, more easily For instance. Right now the Yealink T42S has 4 firmwares on the Yealink website. Yealink T42s Downloads . What if for testing purposes, I want to have 4-6 phones that I can Beta Test stuff with. In advanced porvisioner, I can select the different firmwares, and see if there is a difference, say with "BLF", or the "Call Park" feature!! For instance. In 81.0.70 firmware, Yealink did some Optimization to the "Call Park" function. Well. I am using 81.0.110 and noticed that the Red Light gets stuck on...but I don't have a way to 1: Go back to pre 81.0.70, OR 2: Even better, have 4 phones with various firmware 81.0.110, 81.0.70, 81.0.60, 81.0.25 and because they respond differently, I know that Yealink screwed things up again on firmware 81.0.70 upwards, which killed Call Park/BLF on Production. (This isn't an official report, but I suspect that Call Park is messed up again, it seems to work with BLF and *32, but I got a Stuck "Red light Flashing" with Call Park and *32) Why is Option 2 relevant. Because there wouldn't have to be any booting/rebooting as firmware's are installed. There would be a valid testing of a features, across multiple firmware's in real time! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Yealink firmware Optimization from the PDF "Yealink_SIP_Phones_Release_Note_Of_Version_V81.pdf " "4. Optimized the feature of Call Park. Description: You can enable or disable the IP phone to dial out the call park code/park retrieve code directly when pressing the Park/Retrieve soft key. And you can press the BLF/BLF List key to park the call to the monitored user or retrieve the call parked from the monitored user." Edited August 8, 2017 by esoare Typo's and clarification (see edit history)
Administrators Darren Schreiber Posted August 8, 2017 Administrators Report Posted August 8, 2017 I'm confused, you can already select the firmwares. Are you saying when a new one becomes available, you want to manually set it beforehand?
esoare Posted August 9, 2017 Report Posted August 9, 2017 (edited) no. it's going backwards. So, from what is visible in advanced provisioner. The Yealink T42S for example. There is only 2 options. "Current" (which by the way, Should the firmware version be placed beside "Current" so it's known which Version "Current" is?) and V81.0.110. While Yealink has had 4 total firmware's for the T42s on Yealink's website. I am suggesting have all the variants available. i/e .25, .60, .70, as well as .110.... It may be to arduous to accomplish, but it would certainly tell us if something broke between firmware's. Perhaps going forward, as new firmware's become available, 2600hz plans on adding all of them to the Advanced Provisioner, and the, "going backwards" won't be of consequence? I just looked at the Yealink T42G and there are 20-24 firmware variants. Obviously some are pretty old....I wouldn't want to pick between all those. I guess it's a matter of policy, and how much Firmware variants to offer... Sorry to bring complication to this. Perhaps I'm overthinking things.... Edited August 9, 2017 by esoare added clarity (see edit history)
Guest CBV David Posted August 10, 2017 Report Posted August 10, 2017 On 8/5/2017 at 10:07 PM, Darren Schreiber said: That makes sense. What if we add a special newsletter you can sign up for that is solely for sandbox updates? On 8/5/2017 at 10:10 PM, Rick Guyton said: That would be awesome!!! ^ What he said!
Guest CBV David Posted September 6, 2017 Report Posted September 6, 2017 Sorry if I missed it - just checking to see if anything ever came of the idea for a sandbox update newsletter?
Administrators Patrick Posted September 6, 2017 Administrators Report Posted September 6, 2017 Will talk to the marketing team about the "Sandbox Update Newsletter"? I think it is a good idea, but I don't want them to spend all their days sending out different newsletters. Will see what we can do. @Miriam Libonati
esoare Posted November 1, 2017 Report Posted November 1, 2017 On 9/6/2017 at 3:05 PM, Patrick said: Will talk to the marketing team about the "Sandbox Update Newsletter"? I think it is a good idea, but I don't want them to spend all their days sending out different newsletters. Will see what we can do. @Miriam Libonati @Patrick Agreed... Rather. When is the advance provisioner going to get the New Yealink firmware? 66.82.0.20 for the T4xS series, the T29G series is 69.82.0.20.
Recommended Posts