@BraswellJay said in FreePBX : Skyetel inbound call "Rejecting unknown SIP connection ...":

Go into your @Skyetel endpoint setting and make sure it is talking to your PBX on port 5160 also.

9e3c2ef7-462b-49f6-ae9f-036c302f4b68-image.png

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.

Super helpful, Thanks!

For those who are curious, our international rates and their corresponding tiers are here:
https://files.skyetel.com/SkyetelHighCostPrices.xlsx

@Skyetel Do you have a blog somewhere that you do rant on STIR/SHAKEN? Even better, post it in a new thread here!

@cdbrush said in Setting up FreePBX to send a X-Tenant SIP header for Skyetel Tenant tracking:

This is great. Thanks.

What is this significance to the numbers within the "{OUTBOUND_ROUTE_NAME:0:4}" preceding the route name?

That’s a substring. Look at the route name, starting at character zero and going for 4 characters.

@Skyetel said in Skyetel needs to get over 11 digit numbers:

@Skyetel said in Skyetel needs to get over 11 digit numbers:

@JaredBusch said in Skyetel needs to get over 11 digit numbers:

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?

11e5f493-56c3-4a2a-ab4b-3e9b57ed2a4d-image.png

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 ❤

... and you can add extensions into the support ticket request form 😄

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.

bdc2cc1c-fb25-439e-9132-082fff8e7fc3-image.png

@Skyetel said in Skyetel port in promo code:

@JaredBusch said in Skyetel port in promo code:

@Skyetel submitting port requests!

gods the paperwork...

Ha - yea, tell me about it. You should see what we have to deal with behind the curtain. 😛

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.

So, to circle back on this.

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.

@JaredBusch said in Skyetel tenant functionality:

Well, the month rolled, and so I now have a report.

The tenant report is awesomely detailed for those that actually care about sending something on to a client.

In my use case, the client just needed location specific break out, so I only care about the totals. But OMFG the awesomeness of the numbers....

Great work on this part @Skyetel

Thanks @JaredBusch We're really proud of this!

@JaredBusch said in I guess Skyetel doesn't want business:

@Dashrender said in I guess Skyetel doesn't want business:

And cell phones have allowed pure 10 digit dialing for at least 10, though likely more like 15 years (when the plan simply included what used to be called long distance)

Since my very first one in 1996

My first was 1992, because of the reasons I mentioned above with the land lines and everything being long distance. Long distance on the cell in 1992 was so much cheaper than the land line cost per minute, that it paid for the cost of the cell phone!

The benefit (to me) of setting this up like this means that your inbound routing is all just 10 digit numbers.
80b943b7-bc27-4b89-82a3-498dec52b007-image.png

@Dashrender said in Relationship Pricing:

@JaredBusch said in Relationship Pricing:

But with the second one there, I only perform a lookup once every 30 days for numbers that call me.

Is this because FreePBX caches the info?

Yes, but any system can be setup that way.

@scottalanmiller said in Setting up a Skyetel Trunk on FreePBX:

Don't forget to set your Codec to G722.

But always offer G711 🙂

We do our best to deliver calls over G722 and follow your preferred priority (based on what you put in your SIP), but when we can't get the call delivered over G722, we fall back to G711.

@JaredBusch said in Skyetel auto enables billable services without notice:

@Skyetel said in Skyetel auto enables billable services without notice:

@scottalanmiller said in Skyetel is a scam:

@DustinB3403 said in Skyetel is a scam:

It's not about sensitive. Accounting departments can be incredibly cranky about things being negative and not "due". Negative usually means past due, and can get people up in arms.

Normally the system is pay ahead only, that he was able to port with no money on the account is odd. It is, under normal circumstances (and this is pretty standard for trunk providers for many reasons) standard to only allow you to pay ahead and send a notice when you are getting low on funds so that you can "top up", either manually or automatically. Under normal conditions here, I wouldn't expect a possibility of being in the negative.

This is true - our LNP team should not have ported the number without first reaching out to him about having a $0 balance. We made a mistake and we're going to be making sure to clarify that with our team 🙂

I intentionally didn't add funds to a new account I setup (but it does have a valid CC linked) and inititated a port request.

New process FTW. Good work @Skyetel
3098ea3c-99af-43e0-8ff7-6e18e8ebb2d3-image.png

Thanks! We work hard to listen to everyone's feedback!

Just an FYI, I followed the guide using CentOS 7 Server and it installed no hiccups. It's up and working now, first try. Don't think that the docs have changed.

@Dashrender said in Skyetel Inbound SIP Trunk on FreePBX:

@JaredBusch said in Skyetel Inbound SIP Trunk on FreePBX:

@scottalanmiller said in Skyetel Inbound SIP Trunk on FreePBX:

@JaredBusch said in Skyetel Inbound SIP Trunk on FreePBX:

@scottalanmiller said in Skyetel Inbound SIP Trunk on FreePBX:

Locking a port to a single IP is a trivial task for any gear, even consumer.

I wouldn't go that far.

I don't know much consumer gear that doesn't make that easy.

Super easy tomport forward? Yes. Able to restrict to a specific source IP? No.

eh - if you're only open for the trunk provider, then you can likely lock to one or a few IPs.

if you need mobile support - that's another story.

How? Where? Been a while since I was in a consumer router, but port forwarding screens had nothing about source IP.

Welcome guys.

@FATeknollogee said in VOIP Provider: Skyetel:

@scottalanmiller curious question...why are you responding to a post from Dec of 2018 made by a user who only posted that one time?

Also, because @scottalanmiller .......