Chris Labonne

I appreciate the suggestions and the detail. I think this will be something we try out going forward. And I'm very tempted to go the Debian route.

So I want to manage my tone and encourage others to do so also (this thread has been a pretty level discussion so far). I'm frustrated with the delays, but only in so far as they are delays beyond 2600hz's own self-imposed expectations. More than I am frustrated, I'm appreciative on the immense amount of work that goes into a project like this. To open source a project like Kazoo is something few companies do. The purpose of this post is to say, if others are also willing to help out, I would be willing to work on a fork of the 4.3 branch. The first goal of this forked-project would be to just get the current release on a supported version of the OS and make new deployments easier. (Also, maybe someone already has done this fork? If so point me in that direction) TO-DO: - Build 4.3 on Alma latest and see what works and what does not - Make it easy for those who get their own PAT from SignalWire to use their FREESwitch repos (you know, because they are not public anymore) If there is a theme for a forked 4.3 project, it is "Stability on current Alma". I have some modest resources in my lab that allows me to build and test so I can provide my own feedback on how this works. But honestly, I'm probably blind to some of the challenges we will encounter (eg CouchDB 1.0 on Alma 9???). This brings me back to Ooma/2600hz - if they are close to a release, this is not worth the effort. But it seems we will just never know until it actually happens (which could be never). I manage a couple production deployments of 4.3 and they work well. But I'll soon get heat for Centos 7 and we will have to make a move. If I don't act soon, I'll likely be forced to jettison Kazoo for Asterisk. I really like the architecture of Kazoo especially for its use of FREESwitch and Kamailio. Open to feedback...

They had a conference call about this today. https://investors.ooma.com/news-events/events-presentation I would hope there is news about Kazoo 5 open source this week with KazooCon happening.

@RuhNet - coming in hot and heavy there buddy! I'm just noting that the current release won't easily update because the old FreeSwitch repos have moved to SignalWire. Seems like a good place to start if we fork.

As soon as we fork, that will be the time they go and release the v5 code to the community. But I really can't argue against @fmateo05here. I'd like to see a release based on v4 that allows admins to get a PAT from SignalWire to keep FreeSWITCH up to date. And there are some features regarding shared call appearance that might be good to develop into this stack.

@mc_ Appreciate you asking and following up persistently. We do appreciate this project and all of the work that was freely given to the community. Still can't help feeling antsy as we thought the release of 5.x would have come a lot sooner. Just as important as the actual release is setting the expectation of when it will be released. I for one don't want my superiors questioning whether we should continue with Kazoo vs FreePBX. I'm sure you understand.

https://forums.2600hz.com/forums/topic/14065-2022-q4-newsletter/

My main concern is the change of FreeSWITCH repos to SignalWire. I don't blame SignalWire for making this move, I was able to attain a Personal Access Token from them with no fuss. But the current 4.3 packages are looking for FreeSwitch repos which have moved and require this PAT to access them. So either we just migrate to 5.x open source or we fix 4.3 open source. I'm game for either and I'm volunteering to get my hands dirty to do this 4.3 fix. Has anyone come up with a sure-fire hack to get around the FreeSwitch/SignalWire repo issues on 4.3?

You are correct, in our environment, we have only one tenant using these Cisco 79x5 phones, so we just assume the domain/realm substitution for IP address is for that tenant. Your idea of encoding the realm in the username is workable. Seems like this is allowed according to the standards. RC 3261 defers to RFC 2396. Encoding dots as %2E may work eg cisco101_customer%2Esip%2Edomain%2Ecom Reading https://datatracker.ietf.org/doc/html/rfc2396#section-2.3 and section 2.4 that follows leads me to believe that this scheme would work.

Going to publish some info in stages about Cisco 7945, 7965, and 7985 phones. The company I work for uses these as our standard desk phone on campus. They are pretty old, but good phones that can take some abuse and still work reliably. Even better, there is an ample supply of these phones on eBay and elsewhere. I'm sure you can order a pallet of them when a company clears out an office building. I just browsed eBay for 7945, which is a 2-line model, and they were varied in price but many listings were there for $20 or less per device. My intent here is to publish several posts. The first will describe our current solution which uses OpenSIPS as a B2BUA to receive Cisco traffic in SIP and fix it up to work well with Kazoo and vice-versa. I could just give you my OpenSIPS script, but really the ultimate goal would be to integrate these SIP fix-ups into the Kamailio scripts provided by Kazoo, so in later posts that is what we will do. Also, really not trying to promote OpenSIPS over Kamailio. The guilt would be too heavy for my conscious. So wait for it. Our current solution for Cisco includes a means to pull device information from Kazoo, merge that information with an XML template for the Cisco devices, and stage the configuration files on a TFTP server. This is some custom code written in PHP that implements the Kazoo APIs. depending on your feedback, we will see if I should publish some or all of this solution for the community. Our network team makes it easy for the phones to boot up and find our TFTP via DHCP. I don't think there is anything we are doing that most of you have not already solution-ed on your own LAN. Step 1: Identify when a SIP message is coming from a Cisco phone We examine the user agent using this RegEx '^Cisco.*' Step 2: Filter out some of the noise I lack a lot of knowledge wrt Cisco's own solutions and these devices were built to work with Cisco CallManager or CallManager Express. For example, we see a lot of noise coming from the phones like power reports where the phone is using SIP to communicate what might be better done using SNMP. So if method is REFER or PUBLISH and it is a Cisco device, we generally ignore the messages. But here is a problem, if you don't at least acknowledge these reports, the phone will keep restarting. So send reply 200 OK, and then ignore the report. Step 3: Setup routing for fix-ups to support Cisco We will discuss in the next step how to fix up the SIP headers. But here we need to consider when to do a fix-up. There are a couple of scenarios where this is needed: 1) When the phone REGISTERs, do a fix-up 2) When a request has a TO-tag, we don't fix-up ACKs 3) When a request has TO-Tag, we don't fix-up 404 due to record-routing issues 4) Other than #2 and #3, we fix-up requests with a TO-tag 5) CANCELs are not fixed-up 6) as mentioned in Step 2, reply 200 OK and then ignore REFER and PUBLISH, no fix-ups 7) other PUBLISH and SUBSCRIBES, we just send 503 (no fix-ups) 8) all other requests are fixed-up Step 4: Fix-up operation --> Insert a proper domain in Request-URI From and To Headers These Cisco's seem to prefer IP addresses in SIP headers rather than a domain name. Could I fix this in the provisioning of the phone? Maybe, but I have not figured that out. So here is what worked for us. To fix-up the From and To headers we use the UAC Module's uac_replace_from and uac_replace_to If user agent is '^Cisco.*' then: 1) rewritehost() eg "your.businessfqdn.com" The alters the Request-URI domain name but leaves everything else unchanged. 2) build a FROM header that preserves the user part eg "sip:ChrisL_Cisco7945@" but replaces the phone's IP address with a domain name. So the FROM header will look like this "From: <sip:ChrisL_Cisco7945@your.businessfqdn.com>" 3) build a TO header in the same way we just fixed up the FROM header eg "To: <sip:ChrisL_Cisco7945@your.businessfqdn.com>"

Thanks @DanH I appreciate your response. Being "heard" is always a step towards comfort :) My solution to Cisc,o, while practical and well-tested at this point, was a little unorthodox. I basically loaded a second SIP Proxy to serve as the Cisco gateway (sort of a B2BUA) so that all of the Cisco traffic was fixed up. I'll start by posting a list of the things we had to alter to get the phones to work well. I'll try to post that really soon in the twil knowledge base. What would take longer is a more artful solution that works within the Kamailio scripts offered by Kazoo, so that a separate SIP Proxy is not needed.

My name is Chris Labonne and I work as a Telecommunications Engineer for Great Healthworks (GHW) in Hollywood FL. I've been in this industry since it was known as "Computer Telephony" and you were required to add PC hardware in order to connect to the telephone network. The internet was just starting to gain public adoption and the web was coming online. VoIP did not yet exist but was introduced a few years after I got started. My first 14 years were focused on building IVR solutions with Parity Software's Voice Operating System (VOS), CT Connect, and Dialogic. After that, I had the pleasure of working at Dialogic with the entire product line: media, signaling, voice, fax, and video. Dialogic absorbed many of its competitors during my time there so I got to work with an even larger set of products from Brooktrout, Excel, NMS, and Veraz Networks. While at Dialogic I started working more with open source telephony projects like OpenSER and some Asterisk. I've continued with open source using Kamailio, FreeSWITCH, and some OpenSIPS. Now I prefer working with open source telephony, even more so when you can compound the power of these projects with the ever-more capable cloud offerings and modern phone carriers who offer APIs. It has been a blast to see everything become more connected and more open. We use Kazoo here running several stacks; mostly AiO. But we want to make those stacks more robust. Learning Kazoo without a mentor was a steep hill to climb. But now I'm comfortable with the APIs and working in CouchDB to see what is really going on. Still lots to learn but I'd rather use Kazoo because I feel it can scale and run robustly. I also had previous training for Kamailio and am comfortable working with FreeSWITCH. I've been patiently waiting for 5.x to be released. Perhaps I'll begin posting about how we continue with 4.3 yet with the FreeSWITCH repo changes. The old repo that 4.3 is looking for is no longer available and the installation is just broke. This would not a problem if 5.x was released. But 2600hz is way beyond their self-imposed expectations. I'm tempted to start modifying the 4.3 packages so that a Kazoo administrator can add their SignalWire PAT and continue as normally as possible with installation or maintenance. If 5.x is around the corner, I can wait a little longer. But we have been waiting 2 years so .... A former engineer got GHW running on Kazoo 4.1 using Cisco phones. I picked up where he left off. Since then, I've successfully modified Kazoo 4.3 stacks to work with Cisco 79x5 phones which are the main devices we use at the office. We are also using some Poly CCX 600/700 including some simple video use cases - successful so far. The Cisco integration might be worthy of publication here. You can get these phones for near nothing on eBay. But they are so old (manufactured ~2012), I'm looking for new devices to standardize on for the future. Side note: staying away from YeaLink - great phones - but https://www.defenseone.com/technology/2022/01/common-office-desk-phone-could-be-leaking-info-chinese-government-report-alleges/360500/ . Re this forum topic: My joining this forum pre-dated this introduction requirement. But I was retroactively downgraded to a limited permission profile. Seems odd, but hopefully this post will remedy that.