Why is the SIP phone not registered on Cisco cme?

Question

SIP

I have a Cisco 1760, I can't connect third-party SIP phones to it via the SIP protocol, the status on the phone is "Time Out". But if, for example, you use a software SIP client, for example, on Android, then registration is successful and the voice works in both directions. The problem is only with hardware phones.

spoiler

!
aaa new-model
!
!
aaa authentication login default local
!
aaa session-id common
!
resource policy
!
clock timezone AEST 10
clock summer-time AEST recurring last Sun Oct 2:00 last Sun Mar 3:00
voice-card 3
!
ip cef
!
!
!
!
ip name-server 192.168.90.1
!
!
!
voice service voip
allow-connections sip to sip
sip
bind control source-interface FastEthernet0/0
bind media source-interface FastEthernet0/0
registrar server expires max 3600 min 3600
!
!
!
voice class codec 1
codec preference 1 g711ulaw
codec preference 2 g711alaw
!
!
!
!
!
!
!
voice register global
mode cme
source-address 192.168.1.245 port 5060
max-dn 10
max-pool 4
!
voice register dn 1
number 400
!
voice register pool 1
id mac 1111.2222.3333
number 1 dn 1
voice-class codec 1
username 400 password 12345
!
voice hunt-group 1 parallel
!
!
!
!
!
!
username admin privilege 15 secret 5 $1$YZNq$OPoLOzzgWOquTukQu9SfM.
!
!
!
!
!
interface FastEthernet0/0
ip address 192.168.1.245 255.255.255.0
speed auto
!
ip default-gateway 192.168.1.100
ip route 0.0.0.0 0.0.0.0 192.168.1.100
!
ip http server
no ip http secure-server
!
!
control-plane
!
!
!
voice-port 3/0
signal groundStart
no non-linear
no vad
no comfort-noise
cptone RU
connection plar 400
station-id name 125
station-id number 125
caller-id enable
!
voice-port 3/1
!
voice-port 3/2
!
voice-port 3/3
!
!
!
!
!
!
dial-peer voice 1 pots
destination-pattern 1..
port 3/0
forward-digits all
!
dial-peer voice 2 pots
destination-pattern 0...........
port 3/0
forward-digits all
!
!
telephony-service
max-ephones 1
max-dn 1
ip source-address 192.168.1.245 port 5060
auto assign 1 to 1
user-locale RU
network-locale RU
max-conferences 4 gain -6
transfer-system full-consult
create cnf-files version-stamp Jan 01 2002 00:00:00
!
!
ephone-dn 1 dual-line
number 1
!
!
ephone 1
!
!
!
line con 0
line aux 0
line vty 0 4
privilege level 15
transport input telnet
!
end

Answer 1

I would start by debugging the phone boot:
debug tftp events
debug ccsip error
debug ccsip messages
Another point - who issues DHCP - have you forgotten about option 150?

Answer 2

As it turned out, the problem was in the D-Link devices. Some, after updating their firmware, did work, and some did not. Tired of experimenting with firmware, plus some phones that we managed to start started hanging tightly, users are nervous ... In general, they returned these d-links, bought SNR and the problem disappeared by itself.