Phone or License?

[cavagnaro]

This capture was done from where??
Ipset itself or OXE or switch?

[murraya]

DHCP offers are coming from the procurve switch from looks of it (172.16.152.190) so guess the trace is near the phone.
the next server is 172.16.248.10 so that should be the main CPU.
I see the TFTP request to that address for files but not a lot of responses. I don't have a good trace to compare with but maybe someone else has.
I assume LANPBX file is good.

[tgn]

how is your phone connected? is there a vpn something other limitation of MTU between the phone and the callserver. Sometimes the packet fragmentation doesnt work correctly for tftp transfer. can you download the lanpbx.cfg and the binary files from callserver with a tftp client from your pc?

regards...

[jbower]

After further tracing and working with or Network Manager we were able to trace the issue to an ACL. So the ACL was created just over 11 months ago and has never been modified. We tend to lock down our network since students have been know to try and probe where ever they can. Prior to this we could take phones in and out of service with absolutely no issue. This all started after loading new OPS files. So I am lead to believe that the new files changed the UDP ports being used in IP communication. We made the following changes to our ACL:
;permit all IP phones RTP/RTCP access to switch
permit udp any range 1001 1099 172.16.248.0 0.0.0.255
permit udp any range 2222 2270 172.16.248.0 0.0.0.255
permit udp any range 32500 33000 172.16.248.0 0.0.0.255

After making these permission the problem was resolved. So a valuable lesson is first disable ACL on a vlan when there is an issue with IP devices. Since we haven't made any changes to the ACL it was the last thing we tried. So thanks to everyone for your suggestions and if anyone locks down there voice vlan as we do please take note of these new permission.