Is there any way to keep my log from being filled with PUBLISH requests?

In this case the phones ARE sending garbage. I stated at the beginning of this thread that the phones are sending PUBLISH requests at certain times for what appear to be no reason. I’ve also found other bad behavior with these phones - during registration they always trigger fail2ban. Other models of Cisco phones such as the CP-8845 and CP-7841, even running Cisco’s proprietary Enterprise firmware, do not cause fail2ban to spazz out. As david55 said these are failed authentications which is probably the root trigger for fail2ban. I have to keep fail2ban turned off and it seems the only way to do that is run the firewall module and whitelist the subnets the phones are on, so that if a reboot happens fail2ban won’t resurrect itself.

I understand the principle of the pool. It’s like this is why you water your lawn with a garden hose on low for a long time instead of a firehose on full blast for a short time. Same water both times - same work both times - just being forced to be spread out over time longer by the limited hose.

After raising the limit I still do get the threadpool messages - just not thousands of them when the system is doing nothing and processing no calls. Now I get them when the system is busy, which is as it should be, considering your explanation. Denying a process resources and telling it to wait is a legitimate, if hacky, sort of way of leveling out system load. It is no wonder you rewrote the entire threadpool system.

Also I didn’t just completely guess at raising the max to 150. I started lower, observed the threadpool messages, then retried with a higher limit. And observed less of the debug messages. I kept rising the max a little bit at a time and each time got fewer of these debug messages

The Cisco firmware for those phones use PUBLISH for a variety of things. Those include BLF, PRESENCE, feature states (DND, CF, etc) and for keep-alives. Since we haven’t seen a full debug/trace we can’t say which of these things is sending the PUBLISH or if more than one of this things are doing it.

Since these phones are meant to work with the UCM, which does accept PUBLISH messages for those things above, it’s working as it should with it’s default configuration. Until you configure the phones to not use PUBLISH for these things (or don’t use those features on the phone) they are going to send a PUBLISH for them.

So I guess the default settings you should be messing with should be the phones to stop them from doing what they are doing.

Agreed. And, the by-the-book way of doing this with the Cisco model 8845,s and 7841’s and those variations is by purchasing license updates for each phone to run the 3PCC/Multiprotocol firmware on these phones.

However the older model phones, the 8941s, the 6921s, 7940s, and other various x9xx phones, do not have 3PCC/Multiprotocol firmware available for them. And there is no configuration directive you can put in their XML files that makes them work “normally” As a matter of fact, chan_pjsip was modified a while ago to allow these phones to register without having to put the

[extension#](+)
force_rport=no

into pjsip.endpoint_custom_post.conf for every single one of these phones, as you used to have to do with older versions of Asterisk. If there was a way to change THAT in the phone’s config file, then the Asterisk project would have been telling people to do that, instead of modding chan_pjsip. So it’s not like Asterisk hasn’t tried to meet these annoying endpoints halfway.

Ultimately that is where I’m headed. There are other reasons not to continue to use the CP-8941’s forever. Such as they aren’t HD videophones, and they show a Foward soft button but don’t support extension forwarding in a normal industry-standard way and they don’t support paging in a normal industry-standard way. But I have a lot of them sitting unused and when I decided to use them with this project I didn’t know about the PUBLISH nonsense or the fail2ban nonsense or the extension forwarding nonsense.

The other non-by-the-book way to do this is to run the USECALLMANAGER patch, in which it’s current iteration, inserts a modified chan_sip driver into Asterisk. Which of course then requires you to compile Asterisk from scratch, and install FreePBX with the option to not use the Sangoma repositories for Asterisk. However the downside of doing that is - you now are working with your own Asterisk, thus getting support from the forums, or from Sangoma, or from a 3rd party, is not going to be that fruitful because there’s no way they have of knowing if you compiled it properly. Also, there is not any kind of baseline available to compare against.

If you look over this thread for example it’s been enormously helpful. You, and the other respondents to it, have worked with the Sangoma binaries and you know how they react from experience. So you can recognize when something is not right and explain why. As long as I stick close to what you all are doing - that is, use the same binaries and so on - then you can help me. If I go off the rails with the USECALLMANAGER patch - then I’m on my own.

The installation I’m working with is a Cisco-to-FreePBX conversion. Our existing UCM has 300 extensions on it and it’s out of licenses. It’s an older non-supported version of Cisco UCM. We need another 80 extensions for a new building. I went the by-the-book way and got Cisco to quote. But their quote is to replace the UCM with a new one and the cost is astronomical. It is roughly $150 per phone. And that’s just the capital cost. There’s an ongoing cost on top of that. It’s quite a racket.

It is clear that Cisco has priced their product out of the market and it’s clear my employer (a non-profit, BTW) cannot afford to go down the new yellow-gold-brick-road future Cisco has sketched out. So the question is, how do we extricate ourselves from the UCM and get into something else that is much less than $150 per extension?

We could go greenfield with new everything. That won’t be $150 per phone but even if it’s a 10th of a cost, I’m then stuck pitching it to the exec staff (of which I happen to be a member of) And it’s very hard to pitch a large expensive project to replace an existing project that’s working. I would vote against it if someone else in the execs had a similar approach, unless there was no alternative. I would say “before I support you spending oodles of money are you sure there are absolutely no alternative?”

So the alternative with THIS project is to do a gradual transition and keep the existing UCM for it’s 300 extensions and use FreePBX for the new building and then tie the 2 PBXes together with interPBX trunks. Which we’ve done. Using the CP-8941’s and dealing with their baloney is gaining institutional knowledge that will be enormously valuable in a year or two when I start gradually migrating. I don’t HAVE to greenfield this. I can do it a bit at a time. Ultimately the CP-8941’s will go away and be replaced with 3PCC phones, or something else.

But, going off the rails into USECALLMANAGER or spending a pile of money on phones or something else is just going to add more risk to this project.

I suspect most people posting here have not used much Cisco nor do you all understand how Cisco does business. They make their stuff “mostly interoperable” but they always find some way to add a little hook to screw over the unwary. With routers it was EIGRP. Cisco fully supports OSPF but they “encourage” you to use EIGRP. So orgs end up building out a large WAN using EIGRP and one day someone says “ya know, we could save a TON of money switching our routers to a competitor” and then when they try to do it - they discover “oh crap. We don’t have the institutional experience with OSPF in our environment” and then they are stuck. With phone systems, its this “enterprise SIP” protocol of Cisco’s which mixes regular endpoint SIP with oddball stuff like PUBLISH that has no business in extension SIP. So when someone says “ya know, we could save a TON of money switching our phones to a competitor” they are in the oh crap situation I’m in.

Discussions like this are building institutional knowledge on a Cisco-to-Asterisk conversion. I’m not the only one here who is involved in such a conversion - for example:

Use Call Manager as FreePBX Trunk - FreePBX / Endpoints - FreePBX Community Forums

I’m just the only one regularly posting about it. One of these days it would be nice to take all of this and put it into a massive whitepaper or something that Sangoma could hand out to other customers interested in doing the same thing - scraping their Ci$co UCM off their shoes and replacing it with FreePBX - and how to avoid all of the pitfalls Cisco has installed to make this very difficult for their customers to do.

Ultimately, I do think the decision NOT to use the USECALLMANAGER patch was the right decision and instead to use chan_pjsip. It’s easy to become very invested and start championing something you have spent a huge amount of time figuring out. But ultimately the only reason anyone uses the USECALLMANAGER patch is because of the phones - and, specifically, older Cisco enterprise phones. I’m always watching what the secondary market is doing with phones - and lately I’ve seen a new trend - the prices are falling on used 3PCC phones. Deskphones are manufactured in very high volumes and used 3PCC phones simply are not worth that much anymore because they are starting to flood out into the secondary market. At the same time, so many of the older 79xx phones have been pitched into the dumpster (and the 8941s 6921s and other enterprise-only phones are headed that way) that prices are starting to rise on those since they are falling into the “collectible” category. USECALLMANAER will always be around since there’s always going to be someone who wants to run an antique deskphone, but I don’t see it as an aid to a UCM-to-FreePBX conversion

For the record, that is the wrong way to do this. That will push force_rport=no into the aors, identity and other sections that have that name. To keep it specific to the endpoint section you need to do:

[extension#](+type=endpoint)
force_rport=no

Thanks, I will update my notes. Fortunately it’s no longer required for modern Asterisk/FreePBX versions, but I definitely had to define force_rport=no in FreePBX 13 to get 79xx phones to register into chan_pjsip. Something for the whitepaper, I guess.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.