Posts made by Skyetel

@dafyre said in SIP Registration:

@JaredBusch said in SIP Registration:

@Skyetel said in SIP Registration:

I'm interested in your gentle (cough Jared cough ) feedback.

@Skyetel -- you probably already know this... but...

Oh I know

@Pete-S said in SIP Registration:

@JaredBusch said in SIP Registration:

@Skyetel said in SIP Registration:

We are worried about fraud risk with SIP Registration.

A valid worry as highlighted by the "admin" that posted here

Domain/IP whitelisting?

Enter domain names/IPs that are allowed to register in your account setup.
Domain names are resolved and only IPs that are whitelisted can successfully register.

On prem PBX can even have dynamic IP then (with DDNS).

Quite a few services use this layered approach so that it requires both a valid IP and valid credentials.

Well, for customers with this config, we'd just tell them to use our existing IP Registration. We wouldn't need to offer that separately.

Hi All

We have decided to introduce SIP Registration support in a forthcoming update on Skyetel. Our goal it to roll it out in Mid-Late November, but it may come sooner or later than that depending on our testing period. I am posting this because I would like to see if anyone here is interested in acting as a beta tester for us when its further along in development.

While it is in Beta, there will be some limitations:

1. International Calling will not be supported
2. You will be limited to 30 concurrent calls on our network (15 per SIP Region - more on that later)
3. You will be limited to 1 call per second

Our SIP Registration deployment will support 2/4 regions - NW and NE. Your PBX will need to be configured to register to both regions and we will round robin from our regions to support multi-region redundancy. If we do decide to roll it out to all 4, your PBX would need to register to 4 regions in the config (which would be a pita to configure).

It is our intention to still strongly encourage the use of IP Authorization instead of SIP Registration. So we will probably have a few limitations for SIP Registration that do not exist with IP Auth. We also will not support connecting a desk phone or ATA directly to our network, even though technically it will be possible to do so.

A few things we're still thinking about:

1. We have not decided yet if we want to add registration to all 4 of our regions, or only support it in two.
2. We have not decided if we want to include SIP Registration in our SLA or leave it as a "Best effort" service. (TBH, I'm leaning toward including it in the SLA)
3. We have not decided on the Registration timeouts - some carriers enforce a full 1800 seconds and won't let you re-register faster than that. We're leaning toward a 6 minute Registration timeout, and providing guidance that you should re-register every 5 mins.
4. We are worried about fraud risk with SIP Registration. Since it is possible to get your carrier credentials compromised on an old PBX, it becomes possible for a Skyetel account to be compromised itself, rather than through a PBX. So we're thinking about having different balance requirements, or different verification methods, etc. We may also block SIP Registration on old PBXs (please people, stop using Trixbox for the love of god).

I'm interested in your gentle (cough Jared cough ) feedback. What have you guys had experience with, what suggestions or ideas do you have?

Hey Guys,

We released our Tenant Billing solution today. Check it out:
https://skyetel.com/introducing-end-user-billing/

Chime isn't really intended for MSPs, it's more of a platform to build services like Slack or Teams on top of. That's why they don't include CNAM or 911. Their support is going to be tailored for those kinds of customers, as will their integrations. So be mindful to try and not fit a square peg in a round hole.

Below is the link for Chime's pricing

DID: $1.00

Inbound Calling:
United States of America $0.002216

Outbound Calling:
United States of America $ 0.004800

https://aws.amazon.com/chime/pricing/

Friendly reminder that Chime prices do not include support, and that is an additional (high) charge, whereas our pricing includes support.

But what about the same user on multiple machines, since the system is designed 1:1, that's a show stopping oversight.

It feels like artificial limitations being put in that block user functionality, why not leave it open to being useful? Is there some simple code to be removed to fix these issues? Is it that simple?

The single login per computer is probably pretty easy to change, and I can add that to the change request. That would allow for both multiple logins on different computers, and would allow for something like "[email protected]" for the main company number.

Both of these limitations are related to security concerns our developers had. We've seen people transmit information via SMS that they really shouldn't (credit card numbers, SSNs, etc), and so they went a little heavy on the security.

The 1:1 relationship between a user and a phone number is by design. We didn't build it to allow for more than one user corresponding on a particular phone number at a time (hence the can only login in one place at a time).

The Address Book should be unique per user, but user 2 not being able to add a duplicate value sounds like a bug.

Login persistence between sessions (the F5 annoying thing) is simply incomplete. So you can classify it as a bug for now, and will be fixed in version 1.2.

@scottalanmiller said in Install Skyetel Postcards on CentOS 7:

@JasGot said in Install Skyetel Postcards on CentOS 7:

@scottalanmiller Works ok with 2GB? I remember someone saying it really needs 4gb.

Perfectly fine in 2GB. Going to test 1GB soon. Only using 480MB according to free.

It takes 2GB to build, but then its very lightweight. 4GB is recommended if you are have other things running on the server that is hosting Postcards.

It is a Cloudflare outage, and it impacts about 30% of the internet. Details here: https://www.cloudflarestatus.com/

I wanted to make sure I followed up and let you all know that we confirmed that there was no bug. There was a propagation delay that impacted @JasGot which caused it to appear that the 10 digit vs 11 digit input mattered.

@JasGot said in Wrong Caller ID:

@Skyetel said in Wrong Caller ID:

Would you please open a support ticket so we can ask for PII?

Done:
#82411

Great, thanks. We've already replied

@JasGot said in Wrong Caller ID:

@krzykat said in Wrong Caller ID:

@JasGot What are you referencing? The DIP at Skyetel or ?

For the Caller ID Editor.

Without the "1" They accept it, tell you it has processed, then do nothing with it......

With the "1", they accept it, tell you it has processed, then they actually submit it to the Caller ID database in the sky (or wherever it is)

Looks like this isn't a bug, but without more details we can't troubleshoot further.

Would you please open a support ticket so we can ask for PII?

@JasGot Ah, yea, that’s what I’m going to check out tomorrow

@JasGot said in Wrong Caller ID:

@Skyetel said in Wrong Caller ID:

@JasGot said in Wrong Caller ID:

@krzykat said in Wrong Caller ID:

@JasGot What are you referencing? The DIP at Skyetel or ?

For the Caller ID Editor.

Without the "1" They accept it, tell you it has processed, then do nothing with it......

With the "1", they accept it, tell you it has processed, then they actually submit it to the Caller ID database in the sky (or wherever it is)

This might be a bug. I’ll have it checked out.

Or, and better, do validation on the submission and require 11 digits! (Always better to validate user input....)

We cant validate a submission like we can elsewhere because the CID updated is not a real time process. That’s why (as Jared noted) it can take a couple of days for it to update. These updates sit in a queue and get updated when the CID gods are in a good mood.

We tweaked our UI to allow 10 digit entries based on feedback here and I suspect that when we did that, the thing that converts the entry into E.164 got mixed up. The CID stuff is crazy arcane...

CID entries can also get rejected If the LIDB thinks their data is more accurate than ours. We don’t get any feedback about that (the log will just show it as rejected, often without a reason, and we have to open a ticket to dispute the rejection.)

And of course, as Jared mentioned, if the party you are calling caches their records for a long time (or never updates them - something that’s super common) then there’s nothing we can do.

So yea, that tool hides a lot and generates a lot of support tickets for us. We try to make what is an absurdly complicated process easy, but by doing so we’re opening the door to bugs like this. Welcome to telecom! lol

@JasGot said in Wrong Caller ID:

@krzykat said in Wrong Caller ID:

@JasGot What are you referencing? The DIP at Skyetel or ?

For the Caller ID Editor.

Without the "1" They accept it, tell you it has processed, then do nothing with it......

With the "1", they accept it, tell you it has processed, then they actually submit it to the Caller ID database in the sky (or wherever it is)

This might be a bug. I’ll have it checked out.

@JaredBusch I think this is expected behavior and is by design.

I'll have @cody hop on now and take a look

@JaredBusch Did you give it the 2/4GB of RAM?

FWIW - We are updating the installation script to work with Centos 8.

@JaredBusch said in Introducing Postcards - Our SMS & MMS UI:

@Skyetel said in Introducing Postcards - Our SMS & MMS UI:

This page does not state that.
https://support.skyetel.com/hc/en-us/articles/360049697373

Fixed

And also. OMG 4GB ram?

Yea, docker and the like are resource heavy. Also - for large deployments the DB can start using a lot of RAM.

Exact same error.

CentOS 8 on a $10 Vultr Instance (2GB RAM) and I made a 2GB swapfile also.

Use 7. 8 needs some tweaking still.

This page does not state that.
https://support.skyetel.com/hc/en-us/articles/360049697373

Fixed

And also. OMG 4GB ram?

Yea, docker and the like are resource heavy. Also - for large deployments the DB can start using a lot of RAM.