Because as a Interconnected VoIP Provider in the US (and to some extent now Canada) you have to follow regulations. So as a SIP Provider in the US you must be registered at the Federal and State levels but outside of all that as the SIP Provider you must do:
Robocall Mitigation for both the inbound and outbound traffic and act accordingly. I.e if you see your customer sending 10 calls per second they are robo/automated calling. You need to be able to detect that and act on it. Same for incoming calls.
STIR/SHAKEN compliance. All SIP providers need to participate in STIR/SHAKEN. So they need to deal with the STIR part on incoming calls. Now most upstreams can do parsing of the Identity header to get the Attestation and Orig Id (related to the org that signed the call). Otherwise the provider using your solution will need to do that. At the same time any call leaving the system will need to have the SHAKEN part done. That’s going to require the Attestation to be assigned by the provider (ones using your module), their Orig Id and other information about the call to be encoded and attached as the Identity header for the call.
Kari’s Law/Ray Baum’s Act compliance for 911. As a provider there was a bit of different rules for this. We really don’t need to alert those with PBX systems because the PBX system should be doing the alerts (required by law) when a 911 call is made, however, we do have to make sure that every single location for our end users is registered properly. We also have what is called Dynamic Location Records (DLR). So you can do the traditional DID+Location 1:1 relationship or you can with DLR do a 1:many relationship (1 DID, multiple locations) where basically the device/endpoint is what determines the 911 details being sent. It also allows for the changing of locations very easily for non-fixed devices.
Then there are other things like the TRACED Act, which ties into STIR/SHAKEN and it all about the trustworthiness of the CallerID being presented in the call. Which is why you will see many people saying that their provider doesn’t allow them to send a DID as the CallerID they don’t own or have verified ownership of the DID. As well the TRACED Act requires any provider to respond to FTC/FCC for a Call Traceback within 24 hours of a notice with some sort of action such as terminating the user that triggered the traceback. No response/no action will now result is said provider being blocked.
No but at the same time there’s an entire sector that would be unable to use something that doesn’t meet these requirements (even PBX systems have to comply to Kari’s Law/Ray Baum’s or can’t be sold in the US). Since the US/Canada both share the North American Number Plan and have a bunch of overlap in our Telecom networks Canada has also introduced STIR/SHAKEN on their networks and they have their own NG911 regulations.
My example here. (In France) you can be a SIP provider (local, regional, national).
In our case, we had 3 upstream SIP providers (main SIP providers), and we can sell trunks to our customers all over France.
3 upstream SIP providers: So, 1 main, and 2 backup. If the first was not available, then the second became available. …Etc. (we’ve got OVH, Orange, SFR, …Etc)
The laws in France allow this kind of thing.
So our service was a kind of SIP sub-provider.
In France, from 2025, ISDN will be finished and removed. This means no more T0 or T2. There are many customers who will not change their system because it is too expensive and some are not ready to change their system on SIP technologies. And those are working well for now.
In this case, we provided a SIP ↔ ISDN gateway. (T0 or T2)
You can imagine that your main office uses a SIP trunk and many secondary offices use ISDN. You can then add a gateway and replace the ISDN trunk with a gateway connected to your main office using a SIP trunk. This should be allowed in this case in the US. You are not really a SIP provider.
This kind of part is the SIP provider that is concerned.
There is a kind of hub where calls are made in France, next to it there are national telecom operators: Orange, SFR, Bouygues, OVH…etc that are concerned by this kind of thing.
Then, you can buy a trunk from OVH, and provide DIDs to your customers. So, a trunk and maybe 100 DIDs. Whatever the use, you can resell a DID to a customer. No problem.
No because anyone down to the network admin can just throw a SIP<>PRI gateway in front of their PBX and convert SIP to PRI or PRI to SIP. That has nothing to do with being a provider. However, if you were providing them the SIP trunk you are the provider.
You can be that here in the US, I am. I also have multiple providers to the PSTN.
Let me explain how it would work for you over here doing your “sub-provider” setup. In the US if you are the one selling and providing the VoIP service to the customer you are an Interconnected VoIP Provider in the FCC’s (our regulating body) eyes.
This would require you to register with the FCC, register to receive an OCN (Operating Carrier Number), the OCN would allow for you to get your STIR/SHAKEN tokens so you can participate in STIR/SHAKEN. You would need to register in each state you want to sell your service in. You would need to register to the Robocalling Mitigation Database (RMD) that contains your robocalling mitigation plans and shows your STIR/SHAKEN status.
If you are not in the RMD even being fully STIR/SHAKEN compliant it means the other other carriers/providers cannot accept your calls because you do not exist in the RMD which is a requirement. What you are describing is how it used to be in the US until all the new rules and regulations started rolling out 5 years ago.
Just like how you used to be able to do SMS/MMS over VoIP numbers freely but now you have to conform to 10DLC in the US for messaging if you are using VoIP numbers for messaging. It also means unless a VoIP carrier has gotten special exemptions, SMS/MMS cannot happen on VoIP numbers for non-business customers. It is now limited to businesses and if that business doesn’t have proper 10DLC registration no other carrier will accept SMS/MMS from those unregistered numbers as of Feb 1st 2025 (some have already cut it off).
I get that, which is why I’m asking what your module for these “services” covers. What does it do? Will it conform to the requirements needed in North America, especially in the US? Does it conform to non-French or non-EU requirements other countries in the world may or may not have?
The point we are trying to make here is, because you would be charging the end user for the service and have the direct relationship with them it makes you a provider in the US. In the US a VoIP Provider must be registered with the FCC. There’s no coding that will do these parts of the requirements. You can write code on your system all day long, if you’re not registered properly carriers will not allow/accept your traffic.
How will your code put you in the Robocalling Mitigation Database? How will your code have you listed in the STIR/SHAKEN database in which we can verify your STIR/SHAKEN certificates? There are non-technical requirements that must be met on top of all the technical requirements.
We also, as ruled in 2024, have to abide by Know Your Customer (KYC) requirements. This requires a verification process, including document requirements to be collected. If you are requested to provide these details for any reason, you need to provide it.
I mean even right now we have rules waiting that could require us, as the provider, to contact the PSAPs (emergency call centers where 911 is routed) when there is an outage on our networks that impact 911 calls. It will require all involved and Bandwidth is like your SFR. If Bandwidth had an outage that impacted 911 calls, not only would Bandwidth have to alert the PSAPs…all the providers using Bandwidth will have to notify the PSAPs. This includes when the outage happens and is resolved.
You said : coding has nothing to do with it…
I can say yes. I can imagine someone needs to code a billing report for the customers or using a CRM to do that. Whatever.
How you do your billing doesn’t matter. It’s the fact you are billing the customer that matters in the US. If you bill your customers for DIDs and usage…you are a provider in the US.
How many active calls can be made on a system. But your LLM answer is incorrect because it pulls from information that is years upon years old and really doesn’t apply.
I’ve had over 800+ simultaneous outbound calls on a system with just 4 CPUs/8GB RAM. That includes some of those calls be recorded. Then there were inbound calls being handled by queues, ring groups calling multiple extensions at once. Both directions firing off AGI and System calls during the calls.
The reality of having 800+ calls active at once means there was a higher number being handled as there’s never 100% answer rate on calls. So the system was probably handled upward of 900 calls being setup but 800 being answered.
