Not sure what you mean by Interconnected VoIP provider, I am just a volunteer that helps a non for profit organization run their phone system.
In any case the insights everyone is providing here are very helpful and thanks for that.
The FCC has defined “ interconnected VoIP service ” as those VoIP services that: 1) enable real-time, two-way voice communications; 2) require a broadband connection; 3) require IP-compatible customer equipment; and 4) permit subscribers to receive calls from and place calls to the Public Switched Telephone Network.
Well you would fall under the MLTS Admin classification. That means you are subject to the fines, fees and any judgement that could be leveled by the FCC. So you really need to understand how this works and what you need to do because they will fine you and as I said it’s around $10K initially and $500/day you keep yourself out of compliance. I’m not sure how you or a non-profit could survive those fines without being hurt by them in a huge way.
I believe the new GPS self-management IVR included with ABC v16e might be able to help you in this regard. This pngnpbx-abc-ivr-diy-gps context lets your users program their own GPS co-ordinates using DTMF on their phones – no extra GUIs, portals, etc. – into encrypted format stored inside the internal Asterisk DB, in about a minute or less per phone, complete with fun selections of stock Asterisk voice prompts as previously recorded by Allison Smith, the voice of Asterisk. The information is only decrypted at limited points, so you cannot do “database show” and see every plain-text dispatchable location in one screen grab. I consider this as privacy improvement over the centralized systems being proposed by others.
The mini-HOWTO includes instructions on routing 123*222 into this IVR. So updating your roaming address is as easy as “123*ABC” !
If the call goes straight through to the PSAP, as I have proposed, and then ChanSpy is used to connect a conference bridge into the existing call, then your concerns will be vitiated.
However, I am also not convinced that your interpretation of the law is correct. Admittedly, the law is ambiguous. The word “directly” can have many different meanings, particularly when you interpret it in a technical sense rather than in accordance with its ordinary meaning.
Generally speaking, the words contained in laws are interpreted using their ordinary meaning, and not technical meanings only known to experts in any particular field.
If the word “directly” were to include the technical details of SIP and IP connections, then it could mean that the call would have to be routed from the IP address of the endpoint directly to the IP address of the PSAP, and could not pass RTP or possibly even signalling through any intermediary systems. That interpretation would be wholly unreasonable and also impossible given how SIP works. I think that your interpretation, that if Asterisk treats the call is completed for billing purposes at any time before it hits the PSAP, the call is not “directly” routed, is similarly unreasonable.
I think that the best interpretation of “directly” is that nobody else can answer the call and prevent it from reaching a PSAP. For example, it would violate the law if a 911 call was routed to your local security desk, or to corporate HQ’s security desk, or the front desk at a hotel, rather than to the PSAP.
If the endpoint is put into a conference bridge and a PSAP is called and connected as well, that would very likely satisfy the law’s requirements since the caller would have an audio path to the PSAP that could not be interrupted or blocked by anyone else. The fact that Asterisk treats the call as having been completed once it hits the conference bridge part of the dialplan would not likely be a relevant consideration to the FCC, since the dialplan continues by routing the call to the PSAP.
For these reasons, I do not believe that it is likely that the FCC would interpret the word “directly” to mean that you can cannot use conference bridge commands in your Asterisk dialplan as part of the process of connecting the caller to the PSAP. As long as the 911 caller gets routed to a PSAP and can talk to them, without anyone else intercepting or blocking the call from doing so, I suspect that the law would be complied with.
However, as I’ve said above, there is a potential ambiguity in the regulations, and there is a risk that the FCC could interpret the word “directly” differently than I have. For example, the FCC might interpret the law to prevent the connection of anyone other than a PSAP into the call. So, for example, if you used a conference bridge, and then connected a front desk onto the call, the FCC might take issue with the addition of the third party into the call. I doubt, however, that they would take issue with the use of the Asterisk conference bridge commands by itself, since that is a level of technical detail beyond the scope of the regulations.
And if the FCC were concerned about joining others into the call, the FCC would not care whether it was done by way of conferencebridge or ChanSpy. Again, the FCC would not be concerned with technical details, but rather with the actual impact that it has on the call, i.e., in my example, the addition of a person to the call other than the PSAP.
If you want certainty on this, you can always submit a request to the FCC to clarify what it means.
Also bear in mind that Asterisk is a B2BUA, hence there are no “directly routed calls”, just bridged calls from the injured party to hopefully the PSAP. ChanSpy effectively bridges into the A leg, the proposal here seems so bridge into the B leg, I don’t see much of a difference if that is ‘illegal’ then the law is indeed an ass…
Perhaps another one for the lawyers
1 Like
I agree. In Tin Can Mode, ABC will send that OG caller straight through.
More technically, just before the Dial() is executed in the dial plan, a stand-alone ChanSpy is started on the OG caller, via Originate; one leg of this ‘golem’ is anchored to a (new) ConfBridge and the other ‘half’ runs ChanSpy to barge-in on the OG caller. This allows any other friends who answer before the remote end answers to start talking with each other and the OG caller (since friends Always Be Conferencing.) The ChanSpy is reaped once the remote end answers, at which point, everybody joins into the ConfBridge (with the friends who are in there from the start.) The transition upon answer from Dial() → ConfBridge() is nearly transparent to the participants – there might be a little echo.
Again, IANAL, but besides the definition of “directly” – which is vitiated in most recent versions of ABC due to Tin Can Mode – the question of “automated dispatchable location” is another point of contention…
Fixed devices. The rules for fixed devices operating on MLTS, fixed telephony, VoIP, or TRS require provision of automated dispatchable location with each 911 call, which means that the location information is generated automatically, without any action by the 911 caller when placing the call.
With ABC, you can configured the “announce” option, like so (from Example #2):
AELSub(pngnpbx-abc-init,abctest,record,3600,,announce,)
…that will set the internal ABC conf type name to abctest, save WAVs of each call leg of each participant into separate files, limit to one hour, and automatically announce GPS TTS to the remote end as soon as they answer. Actually it will play back to the entire ConfBridge when the remote end answers. (To shut up the bot, press #; to hear the GPS again, press * (SPLAT - YOU ARE HERE.))
Yes, you still need to configure GPS information, but there is a helpful IVR for end users to do this themselves included with ABC v16e, which takes about a minute to complete by dialing 123*222. I think it makes for more enjoyable user experience, even for over-worked IT Teams needing to roll this out sometime in the next year to potentially hundreds and thousands of phones:
- Hold cell phone in one hand with GPS app open to show current LAT/LON/ELV.
- With other hand, dial 123*222 on desk phone, follow prompts and enter the GPS co-ordinates using DTMF touch pad on the desk phone.
- Move on to the next phone in about 60-90 seconds. (Longer if you are training the user to self-manage in the future.)
I understand the GPS TTS idea is not perfect. But it could immediately work better with PSAPs in rural areas that do not yet accept E911 fully. My hope is that more SIP providers will start accepting RFC6442 Geolocation headers ASAP.
I did not say it was in any way any where in the OP. Please read it again. If your point was lack of discussion on the Asterisk forums makes sense somehow, I do not agree. For example, I think support for Geolocation SIP headers per RFC6442 is certainly within scope of discussion for many, many VoiP projects, including both FreePBX and Asterisk.
Also, I wanted to provide some updates on the most recently released version of Already Be Conferencing v16e, which I am pleased to report did since vitiate (love that word thanks @AdHominem) many of your other concerns expressed elsewhere in this post on the main thread.
Quite Simply – putting on my Tin Can here – there are new facts in the ABC configuration that I hope you’ll consider more fully, as work continues on changing and improving the work.
To help you this month, dear reader, and if properly configured, ABC can streamline notifications to people you choose whenever what you define as an emergency number is dialed – be it 911/922/933/999/etc. is called for testing, or whatever your locality uses if outside the USA, up to you you how you configure it in FreePBX/Asterisk – by way of the following notification methods, again, depending on your specific configuration needs:
-
Conference Calls. Between the caller; remote end eg. PSAP; and on-site staff such as Security, Mental Health, Front Desk, etc., allowing quicker rendering of local assistance - sometimes before remote end even answers the phone, let alone roll the truck. This somewhat novel approach might work well for rural areas and other locations where it is still legal (but it is not completely unheard of.)
-
Voicemail. First 30 seconds of call are recorded (configurable time limits coming in next version.)
-
Email. Via voicemail-to-email trigger/feature already inside Asterisk that you can manage from stock FreePBX GUI eg. for IT alerts. (Admittedly this exists in many other options.)
-
SMS. Via voicemail-to-email-to-mobile using carrier gateways like “
vtext.com” and such. (This too exists elsewhere.)
To help this month and into the future, and if properly configured, ABC includes support for dispatchable location transmission (see also “Dynamic Location Routing” in your web searches) via GPS co-ordinates packed inside some of the basic Geolocation SIP headers defined in RFC6442 - which a small handful of SIP providers can already accept. (Others require street address and additional information - planning this for the next version - still testing providers.)
But ABC strives to go above and beyond the minimal requirements, in many ways.
The latest versions include options for in-band audio messages to announce the location via Text-To-Speech using existing stock Asterisk voice prompts, either automatically upon remote end answer or whenever a call participant presses the * key - SPLAT - YOU ARE HERE. This may be helpful for deaf callers; or others unable to speak; or mis-directed VoiP calls from children that end up in the “national PSAP” call centers; or those in rural areas that lack E911-enabled PSAPs, such as remote mining facilities with no street address to send the helicopter to.
Location information is stored in encrypted format while at rest on the PBX, but transmitted in the clear as-needed, such as the following scenarios:
-
GPS is sent during call flows you initialize according to your custom emergency dial plan rules in FreePBX/Asterisk (there’s test examples included with ABC and even a mini-HOWTO for FreePBX users to help get started in v16e.)
-
GPS is spoken when users are self-updating their GPS data internally, direct on a phone call from their soft/hard phones to the specialized IVR menus included in ABC.
-
During separate IT testing and verification processes, etc.
Also, to be very clear, I AM NOT A LAWYER, and the choices you make in customizing Already Be Conferencing configuration for your specific environment – from redirecting 922 calls to 933, to choosing between the ever-popular Tin Can Mode vs. more modern Simple Mode – are yours to keep with your free gift copy of Already Be Conferencing v16e, and do with as you like for your own purposes.
Current version is now v16g “Great Yurts Edition”. Compared to the previous v16f this one:
- Adds Yurts, Palaces, Paladins and Trolls.
- Adds subnet ID based caller ID selection.
OK, so I’m going to ask you a serious question because you are putting a lot of work into this. Here it goes:
You have taken into consideration that all MLTS systems must comply to the laws in the US. Sangoma just released their updates for this, all future FreePBX releases have it because they must. This goes for Thirdlane, ScopServ or any other MLTS vendor using Asterisk as their voice engine. So with that in mind, how will you make your solution something that people will want to use when they will already have a compliant solution baked in?
Glad you asked!
Honestly, I am still not satisfied with the current state of competing solutions to next week’s problem!
Also, the situation is incredibly fluid right now. It was only two days ago that Sangoma first “baked in” their solution into the FreePBX testing/EDGE branch, with stable release not planned until two days from now. Then of course there is the module signing fiasco threatening to disrupt some other solutions – perhaps as early as next week – which ABC completely avoids.
Disregarding current events, here’s some reasons you might want to consider ABC for your next project…
- ABC is licensed CC0 for maximum integration opportunity.
- ABC does not require FreePBX (but can be integrated with it, see Examples in file.)
- ABC works with stock Asterisk (although it is a little PJSIP heavy right now.)
- ABC is pure dial plan with no dependencies outside of the Asterisk Extension Language.
And I think the FEATURES list from near the top of the latest v16g file might help make the technical distinction more clear between ABC and competitors:
FEATURES
~ Multiple notification options: Conf Call, Page, Voicemail, Email, SMS.
~ Subnet ID based Caller ID options: currently IPv4 /24-/30 networks.
~ Dynamic temporary pool call back number ↔ caller ID mapping and routing.
~ DIY phone-based geolocation update support for changing GPS info via IVR.
~ Single press DTMF options to play back Dispatachable Location in-band.
~ Same DTMF options also display the DL info on the desk phone screen.
~ Optional automated playback of GPS co-ordinates to remote end upon answer.
~ Dynamic Location Routing via RFC 6442 Geolocation (with some SIP providers.)
~ Optional full call recording of each participant leg of the conference.
~ Instant (Simple Mode) or delayed (Tin Can Mode) bridging for caller.
~ Easy integration with existing ASTERISK and FreePBX(R) installations.
~ Examples included showing usage with FreePBX emergency caller ID numbers.
~ Coming Soon: Complete Ansibile-ized build on fresh Debian 10.
There is no competing solution for this. That is on the MLTS vendors to do, this isn’t a stand alone solution option. You get a Mitel PBX, Mitel has their solution in the PBX. You get a Panasonic PBX, they have the solution in their PBX. You get any software based PBX, it’s still an MLTS system so they have the solution in the PBX. So again, at this point you are “competing” against every MLTS vendor using Asterisk as their engine.
The only real competition is with the carriers that need to have solutions. Will they give 100 DID+Location to the customer or will they be able to use Dynamic Location Routing? THAT is going to depend on the carrier the PBX admin chooses.
Also, a follow up question. What is the support plan for your solution? Is there one?
I don’t understand. What was the Clearly IP module if not free market competition ? How does ABC not fit in to free market competition of solutions to these problems ?
I agree. And maybe include every MLTS vendor that needs to rip out their non-Asterisk based system before January 2021 dispatchable location requirements start kicking-in because their (previous) offering is not field-upgradeable to support the changes to existing systems per Ray Baum Act ?
ABC does both – it already offers some support for (new) DLR using GPS, as well as the (old) registered address “buy all the DIDs” approach. I agree it depends on the carrier what you can do.
Do you want to try out ABC and help do this ? 
The Clearly IP module ties into Clearly IP SIP Trunking and Clearly IPs Dynamic Routing solution. It’s a commercial solution that requires a specific commercial service.
So you’re saying Mitel,Avaya, Panasonic and all those need to rip out their PBXes? You’re confusing a vendor (maker) with an installer/admin.
Also Dispatchable Location refers to the record received by the PSAP when the call is made. Most modern non-software PBXes such as Mitel support an Outbound CallerID per station which because most of those work with PRIs and PRIs come with 100 DIDs means each station can have a DID. Each DID can have its own 911 Dispatchable Location record in the database. Problem solved, Dispatchable Location achieved.
Except you’re assuming GPS is being used. Have you actually looked at what carriers who provide this service are doing and how they expect certain formats? Because many want SIP headers that has data specific to their service.
No, I do not want to but you really need to have this figured out the way you’re pushing this. You’re going to leave people stuck and wondering how to get support for your solution.
Subtle point taken, but any vendors offering direct-from-the-factory full-blown-MLTS maintenance/lease/warranty/support agreements as part of their business model will probably be affected.
I posted snippets of the Federal Register from December earlier in this thread. Here is a pertinent portion regarding Panasonic’s comments:
- Panasonic states that the definition of a “person engaged in the business of installing an MLTS” should be limited to initial installation and configuration of the system or substantial improvement, “lest over-long potential liability risk the exit of skilled installers from the market.” We decline to limit the definition to initial installation and configuration of the system, as Panasonic requests. Panasonic presents no data to support its conclusion that this would lead to the exit of skilled installers from the market.[8]
I disagree, slightly. The DL refers to the information. Getting the DL to the PSAP automatically is separate from the DL itself. Again, from a couple of footnotes in the Federal Register:
- We agree with Avaya that service providers may use any technology that delivers dispatchable location, including any technology that complies with NENA i3 specifications.
- In other words, the dispatchable location information associated with a fixed MLTS device must be conveyed to the PSAP when a user places a 911 call, without further intervention by the user at the time it places the call. As noted below, an MLTS operator or manager may rely on an enterprise customer to acquire, maintain, and keep up-to-date the location information associated with a fixed MLTS device.
That sounds nice but may represent change for many PRI configurations.
For example, the ability to mask individual per-station DIDs on normal calls, such as putting the main company number out the trunk as the Caller ID number, and only revealing the individual per-station DIDs as the Caller ID numbers during emergency calls, might not be available on all MLTS platforms.
Yes 
please send more!
Bummer 
1 Like
While all of this sounds very interesting, the one question I’d ask the OP is if he bounced the specifics of his implementation off of any FCC representatives and/or legal resources. It’s one thing to release a new feature module for something relatively ancillary, such as a new SMS package or something. But when it comes to complying with very specific FCC regulations that can result in legal exposure depending…that’s something I personally wouldn’t undertake and promote unless I had vetted it to the Nth degree with iron clad points of reference!
2 Likes
Then one should reasonably ask the same question of Sangoma, apparently their very recently released solution in fact does pretty well the same as @penguinpbx amended “Tin-can” solution of over a week ago , a) make the call to your chosen PSAP, b) bridge the call to other “interested parties”
So I will 
Sangoma, can you let please let us know exactly what your legal department thinks of where and what legal liabilities are involved for us by relying on your solution ?
1 Like
No, it does not based on everything I’ve seen. Sangoma’s solution injects one line of dialplan code into the Outbound Route that calls an AGI script which initiates a call to the Page Group plays the announcements and then uses ChanSpy() on the caller’s channel while dialing out the trunk…
In my opinion, a bridge is a bridge, page groups are bridges as is chan_spy, all calls in Asterisk are bridged, if all participants are sharing media they are ultimately ‘bridged’ even if some are muted. it really is semantics as to what you call it and how the bridge is initiated and endpoints added to it.
We all concede that the originator must initiate a direct call to the PSAP (by means of a bridge, because that is all Asterisk can do), how the other ‘notifications’ are engendered then follows, @penguinpbx attempt seems to go much farther to use other methods out of band to the audio bridge.
Please describe the difference of the two end results and why the courts would prefer one over the other.
They don’t care if it is a software PBX that can do flips and twirls. It’s based on the common market denominator and that is hardware based. So it is simple, a station dials 911 those digits must map/route to a PSAP which is over the “trunk” to the PSTN in almost every case. It doesn’t matter the specific PBX method/terms that is what it must do. Then there should be notifications in some format.
So FreePBX already complied with the ability to make an Emergency Outbound Route, with being able to set Emergency CallerID per extension/station. The only thing FreePBX needed was the notifications part. That is what this covers and since that is the only thing grandfathered (notifications) they were pretty covered. Now their notification method does not impede the 911 call in anyway to the caller or the operator. It pages phones and allows them to Spy if answered.
The OPs way has 911 routed as an internal route to an internal conference bridge that then uses initiates numerous additional calls that conference everyone, including the operator, into a conference bridge. Therefore the caller is not routed to a PSAP they are routed to a conference bridge. That also means that if there is an actual issue with the trunk/PRI the caller will not get a busy signal, they will not be alerted the line is having problems, they are sitting in a conference bridge waiting for others to join them including 911 no ring back, no way to tell of call progression, just dead air. I doubt making the MoH on ringing until another joins the conference will work as if someone joins that isn’t the 911 operator the caller will not know that. At that point you are now trying to make it look like a call is happening when there isn’t one.
I guess we are reading different threads here. I saw a Tin-can suggestion to cover that , did you?
(Personally I like the concept of calling ‘the big red car’ from my Yurt with a tin-can)
1 Like