RuhNet
-
Posts
140 -
Joined
-
Last visited
-
Days Won
1
Content Type
Profiles
Forums
Resource Library: Monster UI Apps for KAZOO
Events
Downloads
Posts posted by RuhNet
-
-
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.
-
20 minutes ago, Chris Labonne said:
@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.
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.
-
2 hours ago, Chris Labonne said:
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.
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.comand 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.
-
Whether you use 7777 or 5443 or 12345 as the listening port doesn't matter---it's your choice, but you must make sure the socket in config.js matches. It looks like you left out the slashes in config.js. So if your listen port is 7777 like me, your config.js should have
socket: 'wss://yourdomain.com:7777',If you want to use 5443 then put that in your bind listen in HAProxy, and also in your config.js.
Port 5555 is the port that the actual Kazoo app uses, so your server line in HAProxy must have port 5555.
The socket line in config.js tells your users' browser where it should connect to for websocket events---this is the protocol and port that you are exposing to the outside, the TLS proxied websocket port (5443 or 7777 or whatever you pick---any port as long as it isn't already in use).
The listen section in HAProxy is what config.js is referring to, it's what HAProxy is listening on from the outside (with TLS).
The backend section tells HAProxy which server[s] to send those requests to that it gets on the public (TLS proxied) side. This will always be to port 5555 on your Kazoo apps, since that is where the Blackhole Kazoo app is listening, and there is no option (nor need) to change that port.
If after correcting your config.js with the slashes, and making sure your ports are right it still doesn't work, post your whole haproxy.cfg file (you can sanitize the IPs if you like) and let me take a look.
-
Also, just to make sure, you did update your config.js with the TLS websocket port, correct?
-
Hmm yes that is strange. Attached is my whole config (sanitized) that I'm using in production. Maybe I made a change or two in the defaults section from the original and that's where the discrepancy is?
-
Hehe I forgot the default earlier in the config is set to http so you'll need to put mode tcp on the listen section as well. Also comment out the options. Here's what I tested just now on one of my machines and it's working as expected:
listen kazoo-websockets mode tcp bind *:7777 ssl crt /etc/ssl/myserver/fullpem.pem default_backend kapps-blackhole backend kapps-blackhole balance source mode tcp #option forwardfor #option http-server-close #option forceclose #no option httpclose server yourserver-blackhole 1.2.3.4:5555 check -
The backend section. Alternately you can try just removing the word “check” and it should work, but without monitoring the connection.
-
Sorry for the delay—it looks like your cert is ok (otherwise the error would be different) but it’s the health check that’s failing. You might try adding “mode tcp” in the websockets backend section and see if that makes it happy. Or you can just remove the word “check” and that should take care of it.
Reviewing your MOS Score.
in Tips and Feedback
Posted
Bump