So you don’t have your own network? Do you even have a token? Individual PBX admins aren’t going to have to sign their own calls coming off their PBXes.
I talked to some folks at Bandwidth this morning about all this. No red flags so far for me as far as I have to sign my own calls and Bandwidth won’t anymore. Still waiting for some higher ups to get back with me on this but the general consensus was that VI is an aggregate and they aren’t a carrier. They use other carriers and resell their services so VI can’t sign calls. I mean, VI uses Bandwidth.
I think there is some confusion about things with all this. I mean TransNexus has Asterisk listed as a compatible system and they didn’t even test properly with it or they would have found it wasn’t compatible because it can’t do what they need. Why? Mainly because Asterisk isn’t a Session Border Control/Softswitch it’s a B2BUA.
Although it won’t help you in the short term, it seems to me that your provider should be signing, as your agent, as part of their virtual network provider service support. As I understand it, you are already in an agency service for signing, with ClearIP as your agent, so presumably the FCC is happy with agents signing.
I actually wonder about your legal relationship with your clients. Currently you are reselling services to them, so you are their provider, but I wonder, if instead, you acted as their agent, it would then be you clients who were the legal customers of the physical service. IANAL TINLA.
If done correctly, a redirect should not need to touch the incoming leg, so being a B2BUA isn’t relevant. By correctly, I mean by appending ? and form encoded headers, to the Contact URI in the redirect.
I wonder if this is channel driver dependent? My guess would be that chan_sip is less likely to handle headers in URIs correctly, although both have to handle them in Refer-To, although they might not have general implementations, but just recognize replaces.
Asterisk can’t pull the headers they add in the 302 Redirect, which has information needed to be added to the following INVITE being sent out. That’s a problem.
Thinking about it a bit more, chan_sip has two redirect modes. The default is effectively a back to back user agent redirect, which is the default (promiscredir=n), in which it actually redirects to a local channel, not a SIP destination. That may be the only one that FreePBX supports, but there is also promiscredir=yes, which redirects to the URI provided.
And they are requesting that the majority of their customer base, which includes a whole bunch of non-499A filers reselling services, to now sign their own calls even if it’s from individual PBX instances? That’s what is happening right now as I am understanding it, correct?
I think the issue boils down to who bills the end user. Now technically I’m VI’s only customer and I own all the DID’s so to them I’m the one generating the calls. I had thought that with a Robocall Mitigation Database entry in place and a posted Robocall Mitigation Plan that would allow them to sign my traffic with a B attestation. Apparently that’s not how they read it.
Well technically anyone who resellers VoIP has to be a 499 Filer. Even those that are under the 10K in USF still have to file a annual form and have a 499 Filer ID. This has been the case for years now. Lets just make sure we are stating the correct things here.
Correct, I am aware of that. It still doesn’t change the case there are plenty of those in this and other voip communities that don’t do this. I know, I’ve had experience with plenty over the years.
So when I state many of the users of VI aren’t 499A filers I’m not referring to what they technically should be doing. I’m referring to what they are doing, not filing. The amount of small voip providers doing things the wrong way or not knowing they should be doing this is way higher than it should be.
The SHAKEN requirements apply to all business that provide PSTN connected voice communications to an end user. Relevant quote from the FCC’s First Report and Order below:
For purposes of our rules, we also adopt a definition of “voice service” that aligns with the TRACED Act. The TRACED Act employs a broad definition of “voice service” that includes “without limitation, any service that enables real-time, two-way voice communications, including any service that requires [I]nternet [P]rotocol-compatible customer premises equipment … and permits outbound calling, whether or not the service is one-way or two-way voice over [I]nternet [P]rotocol.” The TRACED Act definition is limited, however, to service “that is interconnected with the public switched telephone network and that furnishes voice communications to an end user.” Thus, the rules we adopt today apply to originating and terminating voice service providers and exclude intermediate providers.
Source: FCC-20-42A1, paragraph 37
Asterisk Implementation:
Pull request 3085 on the pjsip project adds support for embedded headers in redirects. This can be used to insert an Identity header into the SIP INVITE going to the intermediate provider (e.g., VoIP Innovations). The patch can be applied to Asterisk by rebuilding from source.
Disclosure: I work for TransNexus.
Disclaimer: All content in this message is intended for general information only, and should not be construed as legal advice, tax advice, or financial advice applicable to your particular situation. Before taking any action based on this message, you should consider your personal situation and seek professional advice.
Given a lot of people haven’t upgraded, and that maybe even applies to resellers, do you know if promiscuous redirection, on chan_sip, works for headers in URIs?
