RuhNet

Bump

Ok thanks for the clarification @mc_ I will make sure to install the open source white label app instead on clusters I build.

I don't know where it was obtained from---the last one I looked at did not have any git files, so it didn't show a git remote entry. There is a community app called "Whitelabel" that offers similar functionality. But the Branding app looks a bit more polished as far as the UI, so if it's OK to use it I would prefer to install and use it. But I don't want to use it if it's not open source or free/legal to use and was obtained through unapproved means. I know there was a company a while back selling bootlegged copies of some MonsterUI apps and there are probably some of those floating around still, so I just didn't want to inadvertently use something that wasn't allowed.

No, I'm talking about the Branding MonsterUI app that has the fingerprint icon:

Recently, I've seen the Branding app installed on some open source clusters that I have worked on for various clients, but I do not see it on GitHub. What is the licensing status of the Branding app? Is it open source, or available for purchase, or ??

Yum supports using a SOCKS5 proxy, so what I've done in cases like this is to SSH to another machine (that isn't blocked) and add the -D5000 option to SSH, which will give a SOCKS5 proxy on port 5000 that yum can connect to. Then you can use an environment variable to tell yum to use the proxy on socks5://localhost:5000. You could also use some publicly available HTTP proxy.

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.