Open adrianhumphrey111 opened 6 years ago
Update.
If I ssh into the container itself and run "core reload now" in the asterisk CLI, I get all of the applications.
Also, when I hang the phone up I get these errors from the asterisk-config container:
2018/11/26 20:30:57 service exited: failed to reload asterisk modules: failed to contact ARI to reload module res_pjsip.so: Put http://127.0.0.1:8088/ari/asterisk/modules/res_pjsip.so: dial tcp 127.0.0.1:8088: connect: connection refused
2018/11/26 20:30:57 running service
2018/11/26 20:30:57 engine failure encountered: http2: response body closed
2018/11/26 20:30:57 change detected
2018/11/26 20:30:57 service exited: failed to reload asterisk modules: failed to contact ARI to reload module res_pjsip.so: Put http://127.0.0.1:8088/ari/asterisk/modules/res_pjsip.so: dial tcp 127.0.0.1:8088: connect: connection refused
2018/11/26 20:30:57 running service
2018/11/26 20:30:57 change detected
2018/11/26 20:30:57 service exited: failed to reload asterisk modules: failed to contact ARI to reload module res_pjsip.so: Put http://127.0.0.1:8088/ari/asterisk/modules/res_pjsip.so: dial tcp 127.0.0.1:8088: connect: connection refused
2018/11/26 20:30:57 running service
2018/11/26 20:30:57 change detected
2018/11/26 20:30:57 service exited: failed to reload asterisk modules: failed to contact ARI to reload module res_pjsip.so: Put http://127.0.0.1:8088/ari/asterisk/modules/res_pjsip.so: dial tcp 127.0.0.1:8088: connect: connection refused
2018/11/26 20:30:57 running service
2018/11/26 20:30:58 change detected
2018/11/26 20:30:58 service exited: failed to reload asterisk modules: failed to contact ARI to reload module res_pjsip.so: Put http://127.0.0.1:8088/ari/asterisk/modules/res_pjsip.so: dial tcp 127.0.0.1:8088: connect: connection refused
2018/11/26 20:30:58 running service
2018/11/26 20:30:58 change detected
2018/11/26 20:30:58 service exited: failed to reload asterisk modules: failed to contact ARI to reload module res_pjsip.so: Put http://127.0.0.1:8088/ari/asterisk/modules/res_pjsip.so: dial tcp 127.0.0.1:8088: connect: connection refused
2018/11/26 20:30:58 running service
2018/11/26 20:30:58 change detected
2018/11/26 20:30:58 service exited: failed to reload asterisk modules: failed to contact ARI to reload module res_pjsip.so: Put http://127.0.0.1:8088/ari/asterisk/modules/res_pjsip.so: dial tcp 127.0.0.1:8088: connect: connection refused
2018/11/26 20:30:58 running service
2018/11/26 20:30:58 change detected
2018/11/26 20:30:58 service exited: failed to reload asterisk modules: failed to contact ARI to reload module res_pjsip.so: Put http://127.0.0.1:8088/ari/asterisk/modules/res_pjsip.so: dial tcp 127.0.0.1:8088: connect: connection refused
2018/11/26 20:30:58 running service
2018/11/26 20:30:58 change detected
2018/11/26 20:30:59 service exited: failed to reload asterisk modules: failed to contact ARI to reload module res_pjsip.so: Put http://127.0.0.1:8088/ari/asterisk/modules/res_pjsip.so: dial tcp 127.0.0.1:8088: connect: connection refused
2018/11/26 20:30:59 running service
2018/11/26 20:30:59 change detected
2018/11/26 20:30:59 service exited: failed to reload asterisk modules: failed to contact ARI to reload module res_pjsip.so: Put http://127.0.0.1:8088/ari/asterisk/modules/res_pjsip.so: dial tcp 127.0.0.1:8088: connect: connection refused
2018/11/26 20:30:59 running service
2018/11/26 20:30:59 change detected
2018/11/26 20:30:59 service exited: failed to reload asterisk modules: failed to contact ARI to reload module res_pjsip.so: Put http://127.0.0.1:8088/ari/asterisk/modules/res_pjsip.so: dial tcp 127.0.0.1:8088: connect: connection refused
2018/11/26 20:30:59 asterisk-config exiting
This certainly sounds like an order-of-operations problem. What Asterisk container are you using? Are you using any mitigation for staying its start on the completion of asterisk-config's first run? I usually have the entrypoint script check for the existence of one of the generated config files for this purpose.
See #1 for information about the order-of-operations issue.
You are correct. It was an order of operations issue. I am using the Asterisk cycoresystems/asterisk image for the asterisk container. The "Network" config did not work for me. It was putting the wrong privateIPV4 address into the asterisk config file. The way I fixed this problem was create an entrypoint script to the asterisk-config dockerfile that would download netdiscover, get correct privateIPV4 and export it to an enviroment variable, then use "Env" in the template config file Works perfectly!
That works, but it really should work the same way with no cloud provider set, since the configuration is generated by netdiscover in the same manner.
Hey, Yeah I thought so too. But for some odd reason it does not grab the right address if I specify "aws" as the cloud. A Little Background, I am testing it in AWS EKS and each node has primary and secondary privateIPv4 address. What happens is it is grabbing the correct privateIPV4 address of the node that the pod is on, however, when I ssh into the asterisk-config or asterisk containers and run netdiscover, the privateIPV4 address is different than the one that is returned by the asterisk-config template using the "Network" privateIPV4. And that address returned from netdiscover on the container always seems to be a secondary privateIPV4 address. Weird.
Oh, yes you are also right, if I do not provide a cloud provider, the privateIPV4 address is correct, however, none of the Applications show up in Asterisk, causing asterisk not able to find the AudioSocket and disconnecting the call, however, it works if I ssh into the asterisk container and reload asterisk. Even with the check in the asterisk entrypoint. Maybe I can try I different way to have that asterisk container exit until the config is finished?
It sounds like I must have a bug somewhere, then. Let me take a look.
Do you happen to get any error messages when running with no cloud provider set? (other than the warning about not having one set)
I'm not finding anything which would fail with no Cloud set; in fact, I have a system in production on Azure which has to run with no cloud provider set (because their AKS networking is kind of broken), which definitely works with AudioSocket.
I am unsure of exactly what is causing this for me, I think it is simply and order of operations. Not setting the cloud provider, asterisk-config container sets the correct IP address, and the asterisk container loads with the correct IP addresses, I simply need to restart asterisk. My work around was setting the cloud to AWS and simply using Environment Variables in tmpl file instead of the the Network Variables. Still unsure what would cause this. However, I really appreciate the help and the fast responses!
Hello,
I am currently trying to get this up and running on Amazon EKS and it is working for the most part. The only problem is if I do not specify a cloud, and run "core show applications" inside of the asterisk cli, these are the applications that I get:
All of the Applications including the AudioSocket Application shows up. The problem is when the Audiosocket application is not registered when I do not specify the cloud, the call ends because Asterisk can not find the AudioSocket Application.
However, if I specify "aws" as the cloud, the asterisk-config container finds the wrong privateIPv4 address and puts it in the pjsip.d/k8s-asterisk-config.conf.tmpl file. So when the ACK comes from my provider, kamailio is unable to send the ACK back to the right nated ip address and the call hangs up after 32 seconds by asterisk because it never received the ACK.
I have solved this by 1) not providing it a cloud parameter. and 2) ssh into the asterisk container, running netdiscover or "hostname -I" to get the containers privateIPv4 and setting it in the pjsip.d/k8s-asterisk-config.conf.tmpl.
I would like to know, what is the best solution to get both the right ip address and to get the asterisk Audiosocket application to register?