@JaredBusch We are intentionally being vague on this because the technical stuff on the backend isn't solid yet. We may be able to attest those calls depending on the circumstances. So the vagueness is simply because the product is still in motion.
Still using swap file? Memory is cheap. I don't recall a server where I created swap partition or swap file.
Memory is NOT cheap, not at all.
It is if you own it. If you rent your hardware, yeah, it adds up.
Even if I own it, throwing away 2-3GB of RAM makes no sense. Now, if I own it, I can easily assign 4GB of RAM then remove it once installed, by why? That's harder to script and still no benefit.
It's a bad habit to see resources as cheap and so waste them just because you can. Extra memory doesn't improve performance, it hurts it (just the tiniest bit). And it's not free, if you always apply twice as much RAM as you use (or four times, here), that gets costly one way or another. Either you wasted money overspeccing in the beginning, or you are stuck buying more now.
I believe ./run.sh restarts all services, and I suspect that includes Nginx.
Yes, Nginx is inside a Docker container. But there are three.
All you need is...
systemctl start docker
systemctl enable docker
And you are good to go. It's just a process that needs to be started like any other. There's nothing to know about Docker in this instance. Think of it as the server itself, it just needs to be turned on.
We've been using Skyetel as our primary trunks for some time now, and most of our customers are either using them now or porting over to them in the near term. Service has been great, and very easy to use.
Go into your @Skyetel endpoint setting and make sure it is talking to your PBX on port 5160 also.
This seems likely to be my issue then. I had left it at 5060 in the skyetel portal as you showed above and initially had it port forwarded to 5060 on the FreePBX. When I realized that I had set port 5060 up as the chan_sip port instead of the pjsip I changed the firewall to forward 5060 to 5160 on the FreePBX. I'll try making the change in the Skyetel portal directly to 5160 and just direct port forward 5160 in the morning.
As @JaredBusch figured, this fixed my issue. Once I made this change I had two way audio and no call's being taken down prematurely.
Audio issues are always port related. Though mostly because firewalls are fucking things up.
FFS I cannot do a damned thing in their system without issues with fucking 11 digit numbers..
Today it was opening a support ticket.
Yes, I intentionally did not put the 1 in there. I knew that it would probably bitch.
Point 1 is not important though, as I do not have a DID that comes to me. That DID goes to an IVR. So I have to put an extension in there. But no, you can only ever use an 11 digit number on anything you ever do in the Skyetel portal.
Aside form the extension issue, like my point about the tenant contact info, the contact info for the person they need to call need not be a US based person. Just because I am working with a US based carrier on a US based number does not mean that I have to buy a US based number for you to call me when I am in Tokyo or London or WTF ever.
@Skyetel Have you all never thought about anything like this at all? Seriously?
Okay. You're right. We're over it.
Now you can use 10 digits so long as the first digit does not start with 1 <3
... and you can add extensions into the support ticket request form :D
Signups will do the same tomorrow.
Might want to look at Tenant contact info also. But I do note the new error "only 10 or 11 are supported"!! Awesome.
Ha - yea, tell me about it. You should see what we have to deal with behind the curtain. :P
You could streamline things if there was a way to see the requested port in information after submitted, but prior to your entering the DID into the system.
I had a lot of duplicated typing that would have been awesome to have a copy previous request button or something. Mostly because everything was 1 req for the normal DID and 1 req for the toll free DID.
First, the number port completed perfectly. All things working.
But my concern about the number being entered and routable was 100% valid.
I received an email about 6pm that the number for port A had a FOC and was now entered into my Skyetel dashboard.
I then dialed said number from my personal Skyetel account and it was terminated to my client's PBX.
From any other service the number still terminated at the losing carrier.
The next day was a repeat of an email near 6pm for port B.
I did not specify an endpoint as @Skyetel describes in post 4 because I didn't know I needed to. But as this was a new turn up to Skyetel I only had one endpoint and it was pointed there by default I assume.
The ports completed as scheduled and calls flowed in as they should.
But during that couple of days it was 100% possible that calls could have went the wrong place if I had multiple endpoint groups setup and such as I wold on a bigger design.
A revamp of this process to include the ability to specify the endpoint group or documentation at the least to instruct users to note an endpoint group on the port request will definitely smooth this bump out.