Sippeer getting Wrong password but the password is correct

[celsoannes]

I am using asterisk 16 and sip realtime with sippeer table to registry extensions and from time to time I am getting ip phones lose registry and I start do see messages such as:

[2019-10-18 08:38:07] NOTICE[21843]: chan_sip.c:28929 handle_request_register: Registration from '"7003" <sip:7003@192.168.0.100>' failed for '192.168.0.100:5062' - Wrong password

And if I just do a:

sip reload

And then the extensions register again.

Just to be clear, the problem isn’t the password.

How can I solve this problem?

[penguinpbx]

Turn up SIP debug on that endpoint IP address and watch everything that happens, including re-transmits. Sometimes a delay in processing SIP packets can lead to jumbled replies and failed registrations, but this can be ameliorated by adjusting SIP timers upward.

Also how many endpoints are you dealing with ?

[celsoannes]

I will wait to this happens again to debug it, but I don’t know where to look exactly to identify if it have delay on the packetges.

The scenery is small, 5 ip phones.

[penguinpbx]

There might be a scenario which triggers the failure, such as a manual phone reboot. You could run tcpdump on UDP port 5060, then test a phone reboot to see what the packet capture says vs. Asterisk NOTICE messages log for that same time period. (Maybe keep running captures if a phone reboot doesn’t trigger it – just watch drive space.)

Also, if you are still in a testing phase for this setup, then I would suggest trying a switch from chan_sip to newer chan_pjsip. They both implement SIP in Asterisk. And you can run them simultaneously (on separate UDP/TCP ports.) Ideally, this issue solves itself with new chan_pjsip configuration.

[celsoannes]

At moment I can change to chan_pjsip, as I am using realtime sippeers I can execute the command:

[2019-10-22 17:16:03] NOTICE[21843]: chan_sip.c:28929 handle_request_register: Registration from '<sip:7052@10.101.0.39>' failed for '10.101.54.117:5060' - Wrong password

*CLI> sip set debug peer 7052
No such peer '7052'

That occurs because the peer will only appears when it registry, I dont know if is possible to show all the peers when they have never registered before.

my sip.conf:

[general]
udpbindaddr=0.0.0.0
bindport=5060
ignoreregexpire=yes
limitonpeers=yes
subscribecontext=default
context=interno
qualify=yes
callcounter=yes
allowsubscribe=yes
rtcachefriends=yes
rtsavesysname=yes
rtupdate=yes
rtautoclear=no
language=pt_BR
nat=force_rport,comedia
insecure=invite
trustrpid=yes
sendrpid=yes
match_auth_username=yes

The peers are on the table sippeers.

I use this command to get the follow debugg:

*CLI> sip set debug ip 10.101.54.117:5060

7052-debug.txt (17.2 KB)

If I execute the command: sip reload it works again.

[penguinpbx]

@celsoannes

I dont know if is possible to show all the peers when they have never registered before.

*CLI> sip show peer 7052 load

…might do it. See this post from 2013: https://forums.asterisk.org/viewtopic.php?t=86342

Related, that Asterisk forum post is from the same year the Polycom SPIP 301 went End Of Life, so you might want to update the firmware or try a newer phone (even a soft phone on your computer would be helpful to test with.) Older phones tend to be a little slower…

I see you have NAT enabled with your SIP, but it looks like your devices can talk to each other without NAT. If this is the case, then you might try disabling NAT entirely, or, try configuring NAT with the following lines in your sip.conf, replacing your IP & subnets as appropriate:

externaddr=1.2.3.4
localnet=10.50.60.0/255.255.255.0
localnet=10.50.61.0/255.255.255.0

Generally, if you can eliminate the NAT between your PBX and phones, then there is less that can go wrong.

For example, no NAT means you won’t need to qualify peers (this is the OPTIONS message that the PBX keeps sending.) These messages are critical for NAT because they help keep the UDP connections open on your firewalls; otherwise, inactive UDP ports will (usually) be reaped by the firewall in a few minutes or so, resulting in phones being unable to receive calls until they REGISTER again (which could be a while – see line in logs for Expires: 3600 ; also, minexpiry and maxexpiry in sip.conf)

Assuming no NAT, you might try disabling the qualify setting in sip.conf globally, for all peers:

qualify=no

…or change qualify to “no” for just this peer, as a test, by modifying the qualify column value for the peer’s row in the sippeers database table.

Other options include changing realtime settings in the “rt…” lines, but I’ve not used those recently.