CyCoreSystems
Getting started, need help!
Hey I watched your presentation live last year, and rewatched online yesterday. I'm trying to get your stuff up and running in GKE, and even locally. What order do the images need created from your demo files? I've created a kamailio image from the kamailio directory. Also did the same for the asterisk one, but neither can run on their own.
Can you nudge me in the right direction to get something up and running? Thanks!
You shouldn't need to "build" anything unless you want to do so. The YAML files in the k8s directory can be used to deploy the pre-built images to a kubernetes cluster.
That said, I definitely need to clean this up a bit. It's gotten a bit messy with a few years' worth of tweaks and talks.
It is true that kamailio and asterisk are dependent each other, but kubernetes should just restart each until they are both up.
The main thing which is usually missing is the asterisk configuration. You can use the provided template in the asteriskconfig directory, but you will likely need to customize the inbound numbers for matching. I need up upgrade this to use the new auto-context feature of ARI so no dialplan is needed at all.
Ok so I got most of it up and running. The asterisk instance has an issue with the config container on GKE. It keeps crashlooping etc. I know this is more of a k8s question, but how can I figure out why it's crashing? I didn't make any specific changes in configuration in any of the items, but I did make the zip file and got it set as a secret. Thanks!
Can you see what component is crash-looping? kubectl -n voip describe pod/asterisk-??? should show you.
If it is the config container, pull the last logs of it with something like:
kubectl -n voip logs -c config -p asterisk-xasd98
ok thanks! Here is what I see many times... 2019/08/09 03:12:28 service exited: failed to reload asterisk modules: module res_pjsip.so failed to reload due bad authentication 2019/08/09 03:12:28 asterisk-config exiting
Also in this setup, where do I configure my trunk? Is that in Kamailio somewhere. Seems like that would be my connection to the outside world.
I also get the following errors from the dispatchers containers on all three pods of kamailio...
2019/08/09 01:51:52 run died: failed to run initial dispatcher set update: failed to list endpoints: performing request: Get https://10.55.240.1:443/api/v1/namespaces/voip/endpoints/asterisk: dial tcp 10.55.240.1:443: connect: connection refused 2019/08/09 01:51:52 run died: failed to run initial dispatcher set update: failed to list endpoints: performing request: Get https://10.55.240.1:443/api/v1/namespaces/voip/endpoints/asterisk: dial tcp 10.55.240.1:443: connect: connection refused 2019/08/09 01:51:52 run died: failed to run initial dispatcher set update: failed to list endpoints: performing request: Get https://10.55.240.1:443/api/v1/namespaces/voip/endpoints/asterisk: dial tcp 10.55.240.1:443: connect: connection refused 2019/08/09 01:51:52 too many short-term deaths
Any ideas on my config container issue? Also, I have a situation I want to use it without any sip peers. I basically will be bridging incoming calls with an outgoing call. I'll be a middle man. So do I still make the external registration with Asterisk, or I'd expect Kamailio does that somehow for me in this situation? If so, would that be what I put in the dispatchers.list?
The auth problem with the reload should have been fixed some time ago. I'll have to look and make sure everything is up to date in the demo.
The connection refused is probably because your API server is running on port 6443, not 443. That is the new normal, but that really should be being auto-discovered.
There is no outbound configuration in the demo. Inbound is wide open, since it is simpler and there are no outbound paths available. Firewall rules are the best place to restrict traffic there.
If you ran this in production, would you use Kamailio with Mysql, or stick with flat files? Which would be better for speed, ease of use, etc? I'm guessing Mysql would complicate things with running a cluster that has nodes coming and going, etc. and persistent storage would be another issue to worry about.