glennmitel
IS-IT--Management
has anyone had any problems with running the new 3300 software 6.0.5.7
if so please let me know
thanks
if so please let me know
thanks
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Problems with 6.0.5.7
- Thread starter glennmitel
- Start date
- Status
MitelInMyBlood
Technical User
Running fine here. Have it on 3 machines. Currently investigating a report of no call logs on a 5240 IPA set that was involved in a set swap (device type change). You might want to have a look at the latest KPI. Theres several mostly obscure things mentioned but nothing affecting any of our sites that I know of. Some dont agree w/me but my theory is its better to always have the latest release of s/w running so if I ever do need to call tech support abt something they dont tell me to load the latest s/w then call back. I don't enjoy sitting in a long queue listening to Zam Fir play the pan flute ;-)
YUP. OK here so far.
Ive got some Call ID issues but I think thats down to a DASS to PRI conversion that the Telco did.
Although I have chatted to the UK support and a guy there is having the same issue with the same type of line conversion.
The IP5550 console is still giving me problems. It is still inisting on writing back to the config file ever time I exit the system and putting back 192.168.1.2 as the ICP address, meaning the next time I run it, it looses it.
I have had to make the cfg file read only to everyone and its working. But I think thats just an issue with the machine its running on not version 6.x.x.x
Ive got some Call ID issues but I think thats down to a DASS to PRI conversion that the Telco did.
Although I have chatted to the UK support and a guy there is having the same issue with the same type of line conversion.
The IP5550 console is still giving me problems. It is still inisting on writing back to the config file ever time I exit the system and putting back 192.168.1.2 as the ICP address, meaning the next time I run it, it looses it.
I have had to make the cfg file read only to everyone and its working. But I think thats just an issue with the machine its running on not version 6.x.x.x
MitelInMyBlood
Technical User
We've found a problem and can dupe it. The 5240IP call logs problem I referred to above.
1. Start w/a working 5240 that has a number of accumulated call logs. Cust is fat dumb and happy ;-) but saw the 5235 someone else got and wants one. His mgr okayed it.
2. Change the set type to 5235 and give the cust. the new set. (help him get going with it, of course)
3. A week later the cust says he wants his 5240 back. You change the set type back to 5240 and give him his old 5240 again.
4. All of his old speedcall nbrs are there and work and everything about the 5240 works fine except it no longer shows any call logs (none, no incmg, outgg, missed, internal, external, etc. No logs at all)
Could this be being caused by the way we performed the set type change, in the multiline set assignmemnt form, but if not there, where else would you do it? (No Opsmn on this controller).
I thought Monday we'll maybe go back and program up another 5240 and do a move-swap then kill the other one completely and trade instruments with him to get the MAC address off the system. Then we can take his 5240 back to the shop and put it on our demo system and see how it behaves there. Not sure what else to do.
1. Start w/a working 5240 that has a number of accumulated call logs. Cust is fat dumb and happy ;-) but saw the 5235 someone else got and wants one. His mgr okayed it.
2. Change the set type to 5235 and give the cust. the new set. (help him get going with it, of course)
3. A week later the cust says he wants his 5240 back. You change the set type back to 5240 and give him his old 5240 again.
4. All of his old speedcall nbrs are there and work and everything about the 5240 works fine except it no longer shows any call logs (none, no incmg, outgg, missed, internal, external, etc. No logs at all)
Could this be being caused by the way we performed the set type change, in the multiline set assignmemnt form, but if not there, where else would you do it? (No Opsmn on this controller).
I thought Monday we'll maybe go back and program up another 5240 and do a move-swap then kill the other one completely and trade instruments with him to get the MAC address off the system. Then we can take his 5240 back to the shop and put it on our demo system and see how it behaves there. Not sure what else to do.
MitelInMyBlood
Technical User
To followup;
You can't do "mov swap" with IP sets. Doh.
We tried a couple of things today including replacing the 5240 with another brand new out of the box set, same problem; no call logs on the new 5240 either
We tried changing the set type back to a 5235 (same 5235 as original) but still no call logs. This 5235 worked perfectly the first time around (going from 5240 to 5235)
Finally created a totally new set (5240) then completely deleted the troubled set, then renumbered the new set back to the original number. Voila! success! Of course the user config, speedials, etc is totally blown away.
Moral: Changing the set type of a working set in the multiline set config screen may have unpredictable results. Professional driver on a closed course; don't try this at home ;-)
You can't do "mov swap" with IP sets. Doh.
We tried a couple of things today including replacing the 5240 with another brand new out of the box set, same problem; no call logs on the new 5240 either
We tried changing the set type back to a 5235 (same 5235 as original) but still no call logs. This 5235 worked perfectly the first time around (going from 5240 to 5235)
Finally created a totally new set (5240) then completely deleted the troubled set, then renumbered the new set back to the original number. Voila! success! Of course the user config, speedials, etc is totally blown away.
Moral: Changing the set type of a working set in the multiline set config screen may have unpredictable results. Professional driver on a closed course; don't try this at home ;-)
- Thread starter
- #7
glennmitel
IS-IT--Management
when you say call logs do you mean the ones on the 5235 it self
MitelInMyBlood
Technical User
Call History Logs... Incoming, outgoing, missed, all, etc.
Initially the 5240 call history was fine. We did a set type change (ML Set Assignment form) to make it a 5235 and then swapped out the 5240 set for a 5235.
Initially the 5235 call history logs were fine, although seems we did notice it needing to be "refreshed" in order to display most recent history logs. That seemed quite odd. Shouldn't call history accumulate dynamically and display as soon as you call up the history screen without having to be manually polled with the refresh softkey? Alas new calls were not displaying in history until pressing the refresh softkey.
Long story short, the cust ended up not liking the 5235 (complained about screen glare and touchscreen functions too small) so we swapped him back, changing the 5235 set type back to 5240 and giving the cust his original 5240 back. Now the call history logs in the 5240 were completely dead. No call history at all. Next trip we swapped this 5240 with another (brand new) one, same symptoms. No history.
Next we changed the 5240 set type back to 5235 and reconnected the 5235. However this time the 5235 call history logs were dead too. The 5235 worked ok just no call history logs, at all, period.
To fix, we finally ended up completely deleting the user (totally). Then we programmed up a new 5240 on a different unused number and tried that. This worked and we had call history logs working again. Finally we renumbered the newly programmed set back to the original user's number and this too worked. The user is completely back in business tho he lost all his personal speed dial nbrs, personal directory info, etc. All that he had to reenter from scratch.
No other users call history was affected. Only the set we tried to swap back & forth from 5240 to 5235 then back to 5240.
Initially the 5240 call history was fine. We did a set type change (ML Set Assignment form) to make it a 5235 and then swapped out the 5240 set for a 5235.
Initially the 5235 call history logs were fine, although seems we did notice it needing to be "refreshed" in order to display most recent history logs. That seemed quite odd. Shouldn't call history accumulate dynamically and display as soon as you call up the history screen without having to be manually polled with the refresh softkey? Alas new calls were not displaying in history until pressing the refresh softkey.
Long story short, the cust ended up not liking the 5235 (complained about screen glare and touchscreen functions too small) so we swapped him back, changing the 5235 set type back to 5240 and giving the cust his original 5240 back. Now the call history logs in the 5240 were completely dead. No call history at all. Next trip we swapped this 5240 with another (brand new) one, same symptoms. No history.
Next we changed the 5240 set type back to 5235 and reconnected the 5235. However this time the 5235 call history logs were dead too. The 5235 worked ok just no call history logs, at all, period.
To fix, we finally ended up completely deleting the user (totally). Then we programmed up a new 5240 on a different unused number and tried that. This worked and we had call history logs working again. Finally we renumbered the newly programmed set back to the original user's number and this too worked. The user is completely back in business tho he lost all his personal speed dial nbrs, personal directory info, etc. All that he had to reenter from scratch.
No other users call history was affected. Only the set we tried to swap back & forth from 5240 to 5235 then back to 5240.
Mitelpassion
IS-IT--Management
Any one had any problem using IP DECT and version 6?
- Status
Similar threads
- Locked
- Question