Import FreePBX distro on GCE problem


(Croket0902) #1

Recently I’ve tried to get FreeePBX on GCE from https://community.freepbx.org/t/how-to-install-freepbx-distro-with-commercial-modules-on-google-cloud-compute-engine/56529
But I have ran into some issues, I can’t get the Agent Installer of Cloudendure install, it keeps fail to install. I’ve tried to troubleshoot and found nothing wrong, my kernel-header is matched( and not a symbolic link), disk space is more than enough.


(Moussa) #2

In the network setting of VM do you have it set as Bridged Adapter?

ubuntu_-_Network

Is your VM connected to the internet?

In the VM, were you able to download the “installer_linux.py” from “wget -O ./installer_linux.py https://gcp.cloudendure.com”?


(Croket0902) #3

I’ve done all of that, I’ve already downloaded the installer and it has ran all of the setting perfectly fine but then failed at the installation


(Moussa) #4

I assume you read this article https://docs.cloudendure.com/Content/FAQ/Troubleshooting_Agent_Issues/Error_Installation_Failed.htm

Does your VM go to sleep during the process? i.e Connection times out?

I encourage you to reach to either support@cloudendure.com or Google support (if your GCP is less than a year old you can have email support for your GCP projects)


(Croket0902) #5

-No, my VM still running during the process.
-I have reached cloudendure support and still waiting for them to respond to my attachment in the mail.
-And I could use chat support on GCP to help me out with my problem on virtualbox ? I also attach the image of the chat support category, is it correct ?
image

p/s: also my gcp project is under 1 year, could I still use the chat support function for it ?


(Moussa) #6

I usually start by calling the toll free number. They will generate the ticker and I usually get an email within 24 business hours. I solved two issues like this.

When you solve it, please let us know what was the issue and how to solve it.

Best.


(Croket0902) #7

thx, i’ll do that


(Croket0902) #8

Also do you have any idea why my call on freepbx cloud drop after 6s ( extension to extension) (I managed to use the instruction from Almost PBX to install freepbx + centos 7 on gcp).
I have set the public ip static = external ip on gcp


#9

Does a call to *43 (echo test) drop? Can you hear the announcement? Does the echo test work? If any of this fails, use it as a test call to log. Otherwise, use a call between extensions and report whether callee can hear caller and whether caller can hear callee.

At the Asterisk command prompt, type
pjsip set logger on
(or sip set debug on if you’re using chan_sip), make the failing call, paste the relevant portion of the Asterisk log at pastebin.freepbx.org and post the link here.


(Croket0902) #10

yes, the *43 also fail too, and both caller and callee can’t hear each other, also here is the link to my post about the problem with log include Call drop by using extension number drop after 6 second on hosted PBX ( the external ip in the post has been changed for security)


(Moussa) #11

People in this community may able to help with this “Call (extension to extension) drops after 6s”

Are extensions up all the time? check “FreePBX Statistics” in Dashboard

I had issues in the past not hearing the other side on the call that was solved by playing with Advanced setting in the Extension.

DTMF Signaling (I have it set to Auto)
NAT Mode (I have it set to Yes)

Other places to look at is firewall rules local, FreePBX and GCP firewall.


(Croket0902) #12

I have set rule for the ports use for communication but still don’t know why, maybe I’ll try the setting in advanced


#13

I considered that log to be junk and didn’t read it. For starters, please don’t post screenshots with text. In the FreePBX GUI, go to Reports->Asterisk Logfiles. Copy the relevant section to an editor, modify any IP addresses, phone numbers, etc. that are personal, paste the result at pastebin.freepbx.org and post the link here.

Next, you posted more than 12 minutes worth. If your call takes 2 seconds to answer and drops 6 seconds later, then 10 seconds of log is all you need post, but of course it should be the correct 10 seconds.


(Croket0902) #14

thank you I’ll do that


(Croket0902) #15

Here is the link to my log: https://pastebin.freepbx.org/view/529edaf0


#16

Settings -> Asterisk SIP Settings, NAT Settings:
External Address should be your public IPv4 address. Usually clicking Detect Network Settings will set it correctly. Local Networks should be 10.0.0.0 / 8.

After changing these, Submit and Apply Config, you must also restart Asterisk

Then retest – there may be more stuff wrong, in which case post another log.

If External Address and Local Networks were already correctly set, I don’t know what’s wrong; did you mess with any chan_sip settings that you think may be relevant? Also, why are you using chan_sip (you tried it after having trouble with pjsip, known incompatibility between pjsip and some device you have, etc.)?


(Croket0902) #17

I found out that I’ve set the wrong public IP and set it back and managed to make a call , but now only the Caller could hear the Callee . Also I set the NAT on chan_sip setting to No.
I use chan_sip since I don’t really know how to use pjsip ( I’m still new to Asterisk).
Here is the log about the situation I just said: https://pastebin.freepbx.org/view/2a600803


#18

For both extensions, Advanced tab, NAT Mode should be Yes.
(It should also be Yes in chan_sip settings, but that’s only a default and changing it doesn’t affect already existing extensions).

Also, make sure that the UDP port range for RTP (default is 10000-20000) is in your Ingress rules in Google VPC network Firewall rules.

If no luck, post another log.


(Croket0902) #19

thank you, it’s work, I think setting extension NAT mode to force both causing the problem, just don’t know why.
Also should I change to using pjsip instead of chan_sip , and also the reason . Thx


#20

Well, if it ain’t broke, maybe you shouldn’t fix it, but chan_sip is deprecated for good reason; it has some architectural faults and limitations that will never be fixed.

For example, pjsip extensions don’t have any NAT settings – it looks at what comes in and does the right thing.

However, chan_sip will be around for a long time, because the authors have worked around numerous quirks presented by various devices and trunking providers. The pjsip philosophy seems to be “if it violates the RFCs, we won’t make any effort to accommodate it”.