Tom
-
Posts
69 -
Joined
-
Last visited
-
Days Won
9
Content Type
Profiles
Forums
Resource Library: Monster UI Apps for KAZOO
Events
Downloads
Posts posted by Tom
-
-
With MTLS, a client certificate signed by the manufacturer with the MAC address as the subject is embedded with the phone at the factory. As long as you trust the manufacturer's guarding of their private keys and validate the MAC in the certificate, it makes bruteforcing MAC addresses quite difficult.
-
3 hours ago, VincentdeWit said:
Been working on this for a while now, and found out that the existing solutions are a bit outdated.
What we did is build a NodeJS API (based on Express) together with MongoDB where we store information such as MAC address, Account ID and Owner ID (if applicable).
Our beta solution now basically provides a few things;
- Provisioning based on MAC address
- Remote phonebook support linked to users and groups in Kazoo (CouchDB layer)
- Custom editable fields, such as IP address, DNS, Language etcThere still are some things that we're not sure of on how it would work best; such as security, scalability and overall performance.
Would be happy to share code when it's fully up and running.
I believe mTLS is the most secure solution, but it's unfortunately the most difficult to implement properly.
-
1 minute ago, tomas_ said:
Sounds great!
The monster UI part is already in place in the default SmartPBX / voip app (4.1), at least selection of device, MAC address field and feature keys.
Br - Tomas
I don't think the provisioning aspects of Monster UI should be reused for a couple reasons:
- When a device contacts the provisioning server, there needs to be a fast way to lookup the configuration based on mac address. Currently, all of the device data for an account is under an account database, so you'd have to filter by mac under ever account, which will yield low performance. I was thinking of creating a single database just for provisioning (it would store the device config options, mac address, and account owner).
- I tried examining the Monster UI source code to determine what requests/responses I needed to implement, and this proved to be a difficult endeavor. I would rather code a new app that I fully understand.
- Coding a new app provides more flexibility than being stuck with whatever UI elements made sense for the 2600hz provisioner. Even 2600hz needed to expose different functionality and created the Advanced Provisioner app, which is not open source.
-
I know there are quite a few of us running open source Kazoo who would like to auto provision phones but cannot purchase the service from 2600hz for various reasons (if you can buy from 2600hz, I think you should - their auto provisioner is really good). There is an open source solution out there, but it is not secure (Provisioner v4).
I am interested in creating an open source auto provisioner, but I need the community's help to make it a reality.
Right now I could really use help defining a secure, robust, and scalable architecture, specifically the data model, before I begin coding. Right now, I am thinking about creating a separate server that uses mTLS for authentication (I don't know Erlang so a Kazoo app isn't an option) and a Monster UI app.
If the community can help me at this early stage with the architecture and data model, I intend to deliver an MIT licensed auto provisioner on GitHub that incorporates as much of your feedback as possible (similar to what I did for my Ansible roles for those who have checked them out).
I look forward to working with you guys to make this a reality!
-Tom
-
48 minutes ago, amn said:
I would be interested in your configs that are different from bigcouch. Looks to be almost the same except for zones. There is just one comment by the developer about it with one example it but not explained in much detail.
These are the only things I changed: https://github.com/kazoo-ansible/couchdb/tree/master/templates
Note: I'm only running in one zone right now.
-
On 8/7/2017 at 4:59 PM, mc_ said:
I think this is a great suggestion! I've been using Couch 2 (well, the master branch that I update every week or so) to good effect. We'll have to wait and see how operations feels about migrating existing installations from BigCouch to Couch 2. I think that's the main holdup at this point.
Would love to hear experiences others have with migrations and with running Couch 2 vs BigCouch.
I'm running CouchDB 2 in production, and I haven't had any issues. I had the luxury of planning my first deployment around this transition, so I don't have any experience with the migration.
-
@Uzair Mahmud/@VincentdeWit, I have updated the Kamailio role to use the internal IPs, so the NAT correction should work now.
-
@Uzair Mahmud, I changed the Sip profile to auto, and that seems to have worked with my environment. I'm not sure how it will work with a Lan setup. Can you test it before I add a variable?
Edit: I tested this for LAN as well, and it worked fine as long as I used my public IP from my ISP when I registered the phones. Is this something that you can live with? If it is, the newest version of the Ansible roles should work for you.
Edit 2: Setting FreeSwitch to auto does not work now that I tested it again. Are you good with the variable disable_nat_correction to disable the SDP fix and FreeSwitch external IPs?
-
We can add something like:
enable_nat
or something similar
-
Unfortunately, getting NAT and LAN working together isn't possible from what I've gathered. The FreeSwitch external IPs will only support one of the scenarios at a time.
-
I think I got this all working with the exception of SIP devices behind the same NAT as Kamailio/FreeSwitch.
-
I've been trying to track down this NAT issue for months. I need help, but I'm not sure who to ask.
I reinstalled my VM where I had this all working, and it's not working again, despite using the same configuration.
Follow-up:
It seems that http://kamailio.org/docs/modules/stable/modules/presence.html#presence.p.server_address might have something to do with this. I added this in, and I was able to make calls again.
-
You will need to upgrade the Ansible role, remove the kazoo-configs-kamailio package, and rerun Ansible.
My home lab is NATed, and I am getting calls from my carrier, sending calls to my carrier, and making internal calls between phones.
-
I removed the SDP "fix" and added the ability to find the correct IP from Akamai's IP service.
Can you update your Ansible roles and try again?
-
At this point, I'm thinking that the SDP fix doesn't do anything anymore, which doesn't surprise me because I found it on the old forum from 2015. I'm grading programs for a class I'm teaching right now, but I'll try to experiment later today.
-
Can you get me:
- WireShark logs of the SIP packets from one of the phones
- sipinterface_1.xml
-
This is definitely an SDP issue. Do you have a static IP that differs from the public IP that ipconfig.io/ip is reporting? I've found that with cloud providers (Google and AWS), you have to use their internal APIs because any other method of getting the static IP returns some sort of gateway rather than the IP of the server.
-
It looks like your configuration file has the private IP. I have code to detect the public IP address, but it doesn't work in all situations. If your cloud provider has an API to get the public IP, I can add it. I can also find a way to set the public IP for each host, but this is less ideal.
It's not just Kamailio. There's a file in Freeswitch too. It's better if we can automate it than trying manual tweaks.
-
I would highly suggest eliminating Nat if at all possible. There's supposedly an SDP fix that I found on the old forums, but I haven't Incorporated it because I can't confirm whether or not it works.
-
Can you use Wireshark to check the IPs? It sounds like the SDP IPs are wrong. Are the phones on your local network or somewhere else?
-
On 10/9/2017 at 6:56 PM, Sean Wysor said:
What is the owner being changed to? I do not know of anything offhand that sets permissions in opt outside of /opt/kazoo.
The kazoo-applications and kazoo-ecallmgr startup scripts take recursive ownership of /opt/. I have submitted a pull request at https://github.com/2600hz/kazoo-configs-core/pull/8, and I hope someone can review it for me.
-
2 hours ago, Sean Wysor said:
What is the owner being changed to? I do not know of anything offhand that sets permissions in opt outside of /opt/kazoo.
The kazoo user takes ownership of everything under /opt:
[tnewman@kazoo opt]$ ls -la /opt total 0 drwxr-xr-x. 4 kazoo root 34 Oct 10 01:08 . dr-xr-xr-x. 17 root root 224 Oct 9 23:33 .. drwxr-xr-x. 9 kazoo couchdb 122 Oct 10 01:06 couchdb drwxr-xr-x. 8 kazoo daemon 107 Oct 10 01:11 kazoo
Here are the steps to verify this:
- sudo chown -R couchdb /opt/couchdb
-
The permissions are now correct:
[tnewman@kazoo opt]$ ls -la /opt total 0 drwxr-xr-x. 4 kazoo root 34 Oct 10 01:08 . dr-xr-xr-x. 17 root root 224 Oct 9 23:33 .. drwxr-xr-x. 9 couchdb couchdb 122 Oct 10 01:06 couchdb drwxr-xr-x. 8 kazoo daemon 107 Oct 10 01:11 kazoo
- sudo systemctl restart kazoo-applications
-
The permissions are incorrect again:
[tnewman@kazoo opt]$ ls -la /opt total 0 drwxr-xr-x. 4 kazoo root 34 Oct 10 01:08 . dr-xr-xr-x. 17 root root 224 Oct 9 23:33 .. drwxr-xr-x. 9 kazoo couchdb 122 Oct 10 01:06 couchdb drwxr-xr-x. 8 kazoo daemon 107 Oct 10 01:11 kazoo
-
We may need to ask a Kazoo developer for help with this. The Ansible roles don't go around changing these permissions. The permissions get changed once you restart kazoo-applications or kazoo-ecallmgr.
-
Subnets:
/32 is the correct ACL, since /32 is a single IP address. Since the clustering is automated, we can ensure that only the exact Kamailio IP addresses are whitelisted.
Cookie:
The Kazoo role does change the cookie. I'm really confused why it's not working. You might have to restart kazoo-applications and kazoo-ecallmgr for the cookie file used by sup to actually be written.
Open Source Auto Provisioner
in PSTN, Software, and Services
Posted
The idea behind mTLS is that knowing the MAC is useless if you don't have the correct client certificate.