We have several Polycom 301s in the office along with 501s, 601s and SoundStation 4001s. Recently several of the 301s and a 4001 have stopped being able to register against Trixbox/Asterisk server and additional phones are starting to exhibit this behavior. They are able to contact the server to obtain an IP address, contact the TFTP server to provision and even upload debug logs but the registration appears to timeout. Log excepts are below. Any ideas?

Asterisk 1.4.22 Trixbox 2.8.0 Polycom 3.0.1

0724113935|sip |3|03|Retry send 281
0724113939|sip |3|03|SendMessageFail
0724113939|sip |3|03|CUser::NewWorkingServer 1 to 279772128
0724113939|sip |3|03|SipOnEvNewWorkingServer User 0, old 0, new 0, expire 0
0724113939|sip |3|03|SipOnEvRegistrarUpdate User 0, index 0, state 0, expire 0, working 1
0724113939|sip |1|03|Client State finished REGISTER
0724113939|sip |3|03|SipStartFailOver 0
0724114008|sip |1|03|CreateFailOverProxyList : Reg to Domain '' nPort 5060
0724114008|sip |1|03|CreateFailOverProxyList : For REGISTER Request nPort 5060
0724114008|sip |1|03|doDnsListLookup(udp): doDnsSrvLookupForARecordList for '' port 5060 returned 1 results
0724114008|sip |1|03|doDnsListLookup(udp): result 0 '' port 5060
0724114008|sip |1|03|CreateFailOverProxyList : Not NAPTR for '' port 5060 IP 0 is '' on udp port 5060
0724114008|sip |2|03|CreateFailOverProxyList : Exit with 1 IP Addresses
0724114008|sip |2|03|CreateFailOverProxyList : IP 1 is '' on udp port 5060
0724114008|sip |0|03|>>> Data Send to
0724114008|sip |0|03| REGISTER sip: SIP/2.0
0724114008|sip |0|03| Via: SIP/2.0/UDP;branch=z9hG4bKdc51d87E89D17EA
0724114008|sip |0|03| From: "Joe Blow" ;tag=2FC4C6AD-D293EB4E
0724114008|sip |0|03| To:
0724114008|sip |0|03| CSeq: 1 REGISTER
0724114008|sip |0|03| Call-ID: 309e7d39-a17d681b-95fecaa4@
0724114008|sip |0|03| , REFER"
0724114008|sip |0|03| User-Agent: PolycomSoundPointIP-SPIP_301-UA/
0724114008|sip |0|03| Max-Forwards: 70
0724114008|sip |0|03| Expires: 3600
0724114008|sip |0|03| Content-Length: 0
0724114008|sip |0|03|
0724114009|sip |0|03|>>> Data Send to
0724114009|sip |0|03| REGISTER sip: SIP/2.0
0724114009|sip |0|03| Via: SIP/2.0/UDP;branch=z9hG4bKdc51d87E89D17EA
0724114009|sip |0|03| From: "Joe Blow" ;tag=2FC4C6AD-D293EB4E
0724114009|sip |0|03| To:
0724114009|sip |0|03| CSeq: 1 REGISTER
0724114009|sip |0|03| Call-ID: 309e7d39-a17d681b-95fecaa4@
0724114009|sip |0|03| , REFER"
0724114009|sip |0|03| User-Agent: PolycomSoundPointIP-SPIP_301-UA/
0724114009|sip |0|03| Max-Forwards: 70
0724114009|sip |0|03| Expires: 3600
0724114009|sip |0|03| Content-Length: 0
  • Running phones against test server resulted in the same problem. Running phones against test server with new SIP firmware solved problem. Running phones against production server with new SIP firmware resulted in the same problem. I'm going to have to try something else or re-install PBX software perhaps. – Michael Glenn Jul 24 '09 at 22:15

Open an Asterisk console (asterisk -r), enable SIP debugging (sip set debug ip yourphonesip) and have the phone register. Check if you see the REGISTER packets and if there are any replies and/or error messages.

Is this just a switched network or are there any other devices between Asterisk and the phones?

Edit after your comments: At this point, I would want to make sure the phones' traffic actually reaches the Asterisk server - run tcpdump on the server and maybe also somewhere near the phones. If the REGISTER packets get to the server but do not show up in Asterisk's log (plus the phones are working with another Asterisk, as you tested), then something's wrong on the Asterisk side.

If, on the other hand, you cannot see the phones' REGISTER requests even with tcpdump, then you have to find where they get lost - more sniffing at different points in the network.

Also, here's a discussion about Polycom's not registering, the last post has the instructions for a "local config reset" - maybe that's the magic you need.

  • Turning on debugging showed no register packets or error messages. A test on a new Asterisk server reproduced the problem. Manually updating to the latest firmware from Polycom as opposed to the Asterisk packages seems to solve it. Will try to reproduce on the production machine after business hours. – Michael Glenn Jul 24 '09 at 20:20

After several weeks of having phones slowly dying off one we hired a consulting firm who determined that the firewall configuration was not allowing port 5060 UDP on the LAN. Port 5060 is default port used by the VoIP’s SIP protocol and therefore it was preventing some phones from connecting to the server. For some reasons, the phones that were working already passed through the firewall and therefore were able to connect to the Trixbox application.

They added a rule to allow port 5060 UDP but only on eth0 (which is the LAN interface). We saved the iptables rules and it will remain even if the server is rebooted. Here’s the command for that rule that was added:

iptables -I INPUT 27 -p udp -m udp --dport 5060 -i eth0 -j ACCEPT

For those interested, we enlisted the services of Teliphone Orion to solve this. They identified and solved the problem in a very short time.


We had the same issue at some point, but it turned out to be our Cisco ASA firewall thinking that the trixbox server was an attacker. adding the local LAN to the whitelist fixed that quickly.

  • In my situation this was the case. I figured it out after I replaced the phone with another one and gave the new one the same ip address and it didn't work either. So I changed the ip address and voila! – bgmCoder Aug 19 '14 at 18:14

What do you see on Asterisk's console? Try to enable verbose (set verbose 3) and search for sip errors for those peers on Asterisk´s side.

Does the Asterisk box even receive SIP messages from these phones? If the phone is able to get DHCP and TFTP communication, I guess we can rule out networking issues.

  • No communication was recorded from the affected phones after setting verbosity to 3. – Michael Glenn Jul 24 '09 at 20:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.