PIAF *not* loving Cisco 7961 / 7941 *at all* (detailed)

Okay, so I've spent the past several weeks trying to track this problem down, and I have no effective solution - but I think it has to do with *something* particular to PIAF.

First off, this is only affecting Cisco 7941/7961 and better - I also have a couple Cisco 7960s, and those work just fine.

Some background :
I used to run Trixbox CE (which was running Asterisk 1.4, and still is, because Fonality doesn't actually believe in updating their CE stuff). I switched to PIAF mostly because of security concerns (something Fonality also doesn't seem to understand) and upgradability (ditto about Fonality not really having a grasp on that one as well - okay, enough Fonality rants) - because with all that's wrong about Trixbox CE, it at least supported the Cisco 7941/7961 series well.

I upgraded to PIAF, initially running the Asterisk 1.6 version, as there were issues with Asterisk 1.8 - but once the 1.8 version was 'blessed', and alleged Cisco related issues were resolved, I upgraded to PIAF with Asterisk 1.8 / Purple.

It works great with my softphones, my Linksys SPA-942, as well as the Cisco 7960 phones. I love the added security model, the far better support community, and the ever helpful nerdvittles site.

Yet, my Cisco 7961s no longer worked.

Stuck at "Registering" and never getting beyond it. Unable to ever connect to Asterisk.

I did the suggested NAT=no, turned IPTABLES off, and Fail2Ban off, etc... Made no difference.

Then, this weekend, on a whim, I installed several VMs under Virtualbox, including the prior Trixbox installation - I changed the IP for the proxy to the various VM installations on a text 7961.

The moment it connected to the Trixbox CE 2.8 VM (running Asterisk 1.4) - boom, it works. Registers, etc...

PIAF w/Asterisk 1.6 - no go.

PIAF w/Asterisk 1.8 - no go.

PIAF w/Asterisk 1.4 - NO GO!

Ditto, also tried all of these with IPTABLES and Fail2Ban turned off - made no difference.

Now, I initially thought that it might have been just a case of Asterisk 1.4 being "the one that works" - nope, the case of PIAF w/Asterisk 1.4 seems to indicate otherwise.

The PIAF VMs had all been installed from the PIAF 17.5.7.1 media, so they are all running FreePBX 2.8.

Which is my next investigation - that maybe the newer version of FreePBX has some problems, so I would be interested in either removing FreePBX completely, or replacing it with an older version.

So, that's where I am now - basically, this is all about the 7961 Cisco phones (running firmware 8.54), and I suspect that whatever the culprit ends up being, it's probably responsible for other related issues (maybe even the 7970 nightmares, but not touching *that* one right now).

I'd like to appeal to the various experts and contributors to help in possibly isolating the issue, and hopefully coming up with a solution.


Any idea, thoughts, suggestions?

What kind of config files are you using? XML?

Set NAT to "never" and turn iptables and fail2ban off. (From my experience it makes a difference)

Guys, I *know* that 7960s work just fine.

This is about 7961s (or 7941s, same phone).

The 7961s only use XML based config files.

Are either of you using 7961s?

Where do I get the 2.0.6.1 media?

Do you mean PIAF 2.0?

Would you please try NAT set to "never"?

PS: They can use different types of config files.

I'm grabbing it now, albeit I tend to agree with you - I believe it won't work either.

Like I said, the points I have so far:

- Trixbox CE - works like a charm
- Asterisk @ Home (Asterisk 1.2) - works like a charm
- PIAF 1.7.5.6 Purple (Asterisk v1.8) - nothing
- PIAF 1.7.5.6 Silver (Asterisk v1.4) - nothing

What's changed?

I just did. no difference.

'Registering' sitting there forever. small 'x' next to the phone icon. Not working

- PIAF 1.7.5.6 Purple (Asterisk v1.8) - nothing
- Cisco 7961 w/SIP firmware 8.54

Then it's not a phone problem - something with Asterisk...Ross or Ward could help you with this.

Do you have your 7961 config files in the /tftpboot directory on your server? Have you looked at the system status on the 7961 to see what is failing? What is the 7961 seeing for the tftp server from your dhcp server?

Yes - the 7961 config files are in the /tftpboot/ directory and are being properly loaded from it.

Status messages on the 7961 are 'normal', as can be expected:

- Error updating locale
- No CTL installed
- File not found: CTLFile.tlv

How about the asterisk log file /var/log/full? What does it say about the 7961 registration authenticating? BTW can you ping the phone from the PiaF server?

a) yes, I can ping the phone's IP from the PIAF server.
b) /var/log/asterisk/full never even shows *any* message or any traffic having to do with the phone when it tries to register. It looks as if the phone's attempts to register never actually reach Asterisk.

This behavior is the same whether I have iptables/fail2ban on or off - thus the firewall appears to make no difference. I just turned both off, and reset the phone, and had tail -f /var/log/asterisk/full running, and it never even showed any traffic.

If I repeat the same exercise from the Trixbox server, I get the following in /var/log/asterisk/full:

[Dec 18 06:09:13] VERBOSE[2300] logger.c: == Manager 'admin' logged on from 127.0.0.1
[Dec 18 06:10:11] NOTICE[2249] chan_sip.c: Peer '561720' is now UNREACHABLE! Last qualify: 49
(7960 loads remaining config files, and the moment it displays "Registering", we get:
[Dec 18 06:11:04] NOTICE[2249] chan_sip.c: Peer '561720' is now Reachable. (1498ms / 2000ms)

If I do the same with the PIAF / Asterisk 1.8 box, I get this:

[2011-12-17 22:14:48] VERBOSE[11267] asterisk.c: Asterisk Ready.
[2011-12-17 22:14:48] VERBOSE[11267] config.c: == Parsing '/etc/asterisk/cli.conf': [2011-12-17 22:14:48] VERBOSE[11267] config.c: == Found
(in other words, nothing - at this point the phone is stuck on 'Registering' and there's nothing happening)

Have you tried wiresharking to see what is being sent out?

Nope, not yet - that's the one thing I haven't tried.

I'd want to wait for Ward or Ross to jump in and see what they have to say. I don't think the issue is specifically with Asterisk (it works fine on Trixbox) but rather something that PIAF appears to have added that makes these particular Cisco phones not enjoy themselves.

Just as an additional FYI - I've also, in the meantime, managed to flawlessly register and hook-up my Cisco 7960 (old faithful) as well as the Cisco 7970 to the same Trixbox 2.8 VM - literally, just swapped the IP to the one of the Trixbox server, after having set up a couple of extensions - Boom, it works (even the 7970 - so it could very well be that Ward's hate/hate relationship for the 7970 is related to this issue that we're trying to uncover in this thread).

The 7960 is pretty reliable, any of the 79x1s are to put it mildly a b#itch to get going. Have you tried the Endpoint Manager?

Actually, I hate to disagree about the 7961s, as *no*, they are not a b#tch to get going.

Like I said, once I pointed them to a Trixbox installation, it took me less than 10 minutes to get two 7961s *as well as* the "impossible" 7970 humming along like obedient pets. Seriously, it couldn't be easier. I've made calls on them, back and forth. It's the way this *should* have been.

The problem, or whatever is causing the issues with the 7961s and above lies squarely somewhere in the distribution or how the distribution is configured, or was built. With that in mind, I've downloaded the AsteriskNOW, and FreePBX, and Elastix distributions now, to see if they act any differently.

Regardless, I'm obviously not going to switch back to Trixbox over this - I am convinced that this is something that is fixable, if we're able to isolate the issue and initiate whatever fix is needed.

This is fixable, that's the good news, and once fixed, all of these other Cisco phones will be a easy to use.

As for your question regarding the Endpoint Manager - no, I always disable them. EPM is a horrible bit of user-hostile code. Seriously, the user interface leaves much to be desired (and I'm being kind).

That said, it's an admirable bit of work, and an honorable effort to simplify the phone configuration voodoo that most users encounter.

Either way, since the problem, as we have established, is with the distribution / configuration side, and not with the phone configurations, the EPM would have no bearing (and, FWIW, I have tried the EPM in the early phases of this investigation)