[cisco-voip] Reset on 7945 series phones

[Wes Sisk]

[crickets..]

a couple things come to mind:
if you push out the message you could send "init:services" or similar to 
clear the message without resetting the phones. that would keep the 
message and corrective action on the same administrative interface with 
similar impact.

As far as only impacting 7945 model phones - offhand there is nothing 
unique to those phones.  reset does depend on database replication. if 
you have those model phones registered to a different CM node with 
broken replication then they would not reset. 

beyond that it would be good to know the CM version, phone load, 
architecture that is specific to your deployment.

/wes

On Saturday, August 21, 2010 11:32:50 AM, Terry Oakley 
<Terry.Oakley at rdc.ab.ca> wrote:
>
> I have a job scheduled in Job Scheduler that resets phones in our 
> College classrooms.   The reason behind this was to clear the display 
> for each day as we send out a message at 10 PM each night to say that 
> the College is now closed.   That job has stopped doing the reset or 
> better does the reset but does not actually reset the phones.   This 
> appears to be only happening on phones that are the 7945 series 
> phones.   Does anyone know why this would happen or better where I 
> would look to resolve it?
>
>  
>
> Thanks
>
>  
>
> Terry
>
> Terry Oakley
>
> Telecommunication Coordinator,
>
> Information Technology Services
>
> 100 College Blvd,  Red Deer, AB T4N 5H5
>
> *Red Deer College <http://www.rdc.ab.ca/>*
>
> Tel (403) 342-3521
>
> Terry.Oakley at rdc.ab.ca <mailto:Terry.Oakley at rdc.ab.ca>
>
> *When you get here you understand*
>
>  
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20100823/50c81149/attachment.html>