RuhNet

The main problem I have encountered with Cisco phones of this vintage are that they absolutely refuse to register to a realm---they will resolve hostnames, but will always put the resolved IP address as the realm in the SIP messages. So to work with Kazoo, it requires either a local Kamailio (or similar) to do some SIP message manipulation, or to modify your Kazoo Kamailio config to detect phones from a particular IP address and make the realm changes, to allow Kazoo to identify the device as belonging to a particular account.

I also use and recommend them. I've never had an issue.

That’s what I’m hoping as well!

Yes, HAProxy only supports a combined certificate/key file in one. I normally use the bash script GetSSL to do cert renewals, and it will output a single file which removes the need to cat them together.

Hehe I didn’t really mean to target you with that lol—it was only the handiest example (of many out there) to illustrate my point. 😁 And like I said, I’m just as frustrated and anxious as everyone else but at the same time I do feel respect for 2600Hz’s position. (Except for on Konami/Konami Pro and kazoo_db which I can’t make sense of why those are closed source. 😆)

Umm 2600Hz has been clear that they do intend to release v5 open source. They have never said anything to the contrary. Now technically they could change their mind or have been lying about it, but I don’t see any indication of either of those. The time delay factor is of course frustrating, but that in itself I don’t believe is a solid sign of them backing out, and they have continued to maintain that v5 will indeed be released.

To be honest I think these nitpicky complaints are exactly [part of] the reason v5 has been delayed --- it's impossible to please everyone, and all these statements like "YOU (2600Hz) should have latest Freeswitch", "YOU should fix this XYZ bug...", "YOU should support ABC, XYZ because I want it to make money for myself...", "YOU should have released v5 two years ago when it wasn't ready so you could put up with me complaining about it for the past two years" probably don't really give 2600Hz a warm feeling about the OSS community. So why should 2600Hz release something when they know it's not ready, and it will only unleash a barrage of [free] help requests, criticism, and general bad feelings toward 2600Hz? Especially when the amount of help given back to 2600Hz by the community is somewhat limited. To be clear---I use Open Source Kazoo, I want new features, I want fixes, I want all of it to be open source (Konami hehe). I've been chomping at the bit to have v5 as long as anyone else. But at the same time, I do understand their position, and I understand why the app store has been delayed so long---it's hard to make software not pirate-able, but at the same time not a nightmare to install and use and maintain. I do wish they would go ahead and release everything else, so we could begin to work with it, but I don't know all the ins and outs of v5 to know if that's doable without a great deal of effort. So, everybody, just relax. :) Unless of course you are willing to put your money where your mouth is and actually offer to pay for certain things to be fixed, or offer to fix (and contribute) certain things yourself. :-D I don't think a fork is warranted at this time---forks are sometimes good things, but most people grossly underestimate the amount of work involved in maintaining a medium-large codebase. And unless something changes I really don't think our OS Kazoo community has enough high power developer talent to make a fork a real success, so any benefits I think would be minimal. I'm hoping we'll hear good news concerning OS v5 around Kazoocon this year. If not, then I may begin to reconsider my position. But until then I'm just going to be patient and do the best I can with what we have now.

You can manually install the latest Freeswitch can't you? Keeping latest FS in sync with Kazoo repo adds another layer of management complexity, so to be honest I'd rather have the default repo be the older (it's not all that old) version of Freeswitch that is guaranteed to work fine with the other Kazoo RPMs, rather than having breakages happen every so often and then having to wait on a fix or revert or whatever. in the mean time there's nothing stopping anyone from using the official Freeswitch repo. It's just a matter of setting your yum config for it. 🤷‍♂️

Ok yes that's very interesting. I'll have to add this to my notes.

And both Freeswitch servers were already previously added to both ecallmgr nodes? (Just trying to be clear on the scenario so I can avoid issues.) :-)

@tomas_ Was one of the FS IP addresses already there and not the other, or just the default 127.0.0.0/24 entry only?

Bump. I'd like to see this feature in some form or another, as I think it would be of benefit. Could someone from 2600Hz give a status update on it, or let us know if it has been canned/superseded/implemented some other way possibly?

I did quite a bit of experimentation with similar Cisco phones in the past. After much work, I was never able to get them to send the domain, rather than the IP in requests. This is of course generally fine with single-tenant PBX systems, but doesn't work with Kazoo. Modifying the headers with Kamailio/OpenSIPS is of course an option as you mention. However, the issue is that unless your system only has a single account, or at least only a single account is using Cisco phones, you'd have to have some sort of dynamic way to figure out which account/realm to associate the incoming Cisco phone with. You could write a little external API service that handled this, and have Kamailio use HTTP (or AMQP if you wanted) to lookup the proper realm from the API by either using the incoming IP, or from a code of some sort included in the username, or possibly from the MAC address on the request (I don't remember if Cisco phones send MAC along with all requests or not.) I'm not aware of any way to be able to lookup a realm/account for a particular device from the Kazoo API, since most things require the account or realm as the starting point for Kazoo to know which DB to search for the device in to begin with. So it's likely that a fully integrated solution isn't possible, without some custom code somewhere that keeps track of which devices belong where. Actually, now that I think about it, you could maybe encode the realm in the username, and have Kamailio strip it off and rewrite the domain using it. So for example, you could set your username to: cisco101_customer.sip.domain.com and have Kamailio treat anything past the underscore as the realm when useragent is Cisco, extract it, and rewrite. I don't know if the periods would give a problem with SIP user but if so you could always substitute them for two underscores or something like that and have Kamailio do a regex substitution on it before using as the realm. This should be reasonably easy to implement in the native Kazoo Kamilio config script.

@Jay WhiteThanks for taking the time to add that very useful info. Good to know!

I'm in Eastern time but will give Pacific, since many are in that zone. Any Tuesday through Friday, after 9AM PDT is mostly good for me. Best 2 times for me: Tuesday 11AM PDT, and Wednesday anytime between 10AM-3PM PDT.

I voted yes. I didn’t really have a problem with the old organization but the new does look a bit more organized.

Hi all! I have released another Monster UI app that I think will be of use to some people. It is called Switchboard and is a real-time device/call monitoring app. You can view registered devices on the system, along with their owners, current extension, temporary hotdesk extensions. Call status of devices is updated in real time via websockets, along with an activity log, which can be collapsed if you don't need it. When the Switchboard app is first loaded, Crossbar APIs are queried to see which devices are currently registered, and then the channels API is used to set the current state of the devices. After that, websocket events via Blackhole update the devices visually as calls come in/out. You can see when a device rings, is idle, is answered, or is on hold., along with caller/callee name and number, call direction, and an in-call timer. https://ruhnet.co/blog/switchboard-kazoo-app-monster-ui Part of the reason I developed this app was for a client that uses a combination of hotdesking and normal extensions. Users and management were often confused about who was logged in where, and why they were getting calls for someone else (their device was hotdesked to another user and they forgot to logout). So, in addition to the real time call monitoring, this app gives a very clear visual indication of which devices are hotdesked, and which extension[s] are currently active on any particular device. Try it out and let me know what you think! Also, give me a GitHub star if you find it useful, and feel free to send pull requests if you make useful changes to the source code. I intend to continue development and add features over time.

This is what I would do---Polycom is extremely flexible with macros for things like this. You could program a button with a macro that answers the call with phone on mute and immediately blind transfers the caller to your voicemail. Alternately, you could use the Channels API to get the incoming channel and reroute the call to VM when you dialed a star code. Might need Pivot or a web UI for this to work fancily but you maybe could do it simply with webhooks and the Channels API and a simple external PHP/Python script or small node app. But I would recommend just creating a macro on your phones.

Metaflows and Konami allow some control, along with the channels API. Look at the Channels API documentation link I posted as it gives some examples of call control.

For real time events, Blackhole which uses websockets is best. It is the similar to ESL in FS. You also have webhooks as @fmateo05 said, and the channels API is useful also. Here is some info about the channels API: https://docs.2600hz.com/supported/applications/crossbar/doc/channels/

Yes, the UAC module would need to be loaded, but also some additional config. You add the registration details to the database. Check out the "Nick vs Networking" blog for more info on this--he has a very good UAC explanation and example that you can work from. Not for Kazoo specifically but vanilla Kamailio, but as far as the UAC config it should be the same. As for method 2, (using external Asterisk as "carrier" for Kazoo) yes you are correct.

@Mehedi Hasan Tanim Although outbound registration is not supported with Kazoo, you can make it work by modifying the Kamailio config to use the UAC module. Alternately, (and this is probably the easiest way) you could place an external Kamailio/Asterisk/Freeswitch server outside of Kazoo and use it for the "carrier" for Kazoo; have the external server do your registrations and pass calls along to your Kazoo Kamailio server like normal carrier calls.

No problem, glad to help. :-)

Great stuff, @Mehedi Hasan Tanim When I asked you to document this so that other people could benefit, I did not expect you to start from the beginning with auth and the Flowroute setup, I just meant the part we covered about the click2call, but this is fantastic. Bravo for your contribution to the community; I'm sure others will benefit now. Good job!

This is why registration is not part of default Kazoo---it breaks the scalability and redundancy. Although some providers do require registration before allowing outbound calls, registration is generally a thing for incoming calls, which come in to Kamailio, not Freeswitch, so registering from Freeswitch will likely break incoming calls for you. A better solution is to register with Kamailio. You can do this with the UAC Kamailio module (not enabled by default). Then Kamailio will register to your provider for incoming calls, and outbound calls will just use the user/password auth from all Freeswitch servers you have. But IF your provider requires registration before allowing outbound calls, as well as inbound, then you can still make it work. What you'll need to do is in addition to using UAC, append ;fs_path=sip:KAMAILIO_IP_ADDR to your gateway server in your Kazoo carrier resource (whether offnet or account level). Example: sip.ruhnet.co;fs_path=sip:111.222.123.123 where sip.ruhnet.co is your carrier sip server and 111.222.123.123 is the IP of your Kamailio server. This will force Freeswitch to send outbound calls to that carrier through your Kamailio server. If you have more than one Kamailio server, you'll have to pick which one you want to use for this carrier. In theory, it's possible to still have redundancy for this situation, but it would require two additional external Kamailio servers sharing a floating IP (your own intermediate "carrier" just to connect to this one limited registration-only carrier.) But if you must do something like that then it's probably a lot smarter just to change carriers to one that supports IP auth. 😀