Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

And why the hell does Google/Android allow 3rd party emergency phone service handlers at all?

Something critical like 911 should have one handler. Heck, I’d argue the phone system shouldn’t be allowed to be overloaded by a 3rd party at all. That just sounds like a bowl of buggy spaghetti.



Probably related to [1]:

"The FCC requires that providers of interconnected VoIP telephone services using the Public Switched Telephone Network (PSTN) meet Enhanced 911 (E911) obligations. E911 systems automatically provide emergency service personnel with a 911 caller's call-back number and, in most cases, location information.

To reduce possible risks to public safety, the FCC requires interconnected VoIP providers to:

- Automatically provide 911 service to all customers as a standard, mandatory feature. VoIP providers may not allow customers to "opt-out" of 911 service. "

Can Teams make phone calls?

[1] https://www.fcc.gov/consumers/guides/voip-and-911-service


From a user perspective, I think I’d expect one of two things on a cell-phone… - Teams (or other 3rd party) isn’t allowed to make telephone calls. The phone provides this service. Teams can continue making voice “calls” to other Teams users, it just can’t initiate telephone calls via PSTN.

- Teams (or other 3rd party) is allowed to take over calling duties from base software. But, only one call handling system can be active at a time.

Personally, I’m not sure why I’d want multiple handlers, or even a single alternate handler, so I’d pick the first option. If I’m missing a common use case, I’d like to hear it.


The problem the FCC is solving is:

Person is in an emergency, they pick up the closest device and dial 911.

That needs to go through, complete with location information.

The specific triggers for the rule were old-landline handsets plugged into VoIP boxes routing through carriers that didn't have E911 connections. A child would pick up the phone, dial 911, the other end wouldn't have the address, and the child wouldn't know it either.

This rule would appear to include _anything_ capable of making a call, including things that don't look like phones (tablets).

That is mixed with the desire for carriers (and others) to intercept long-distance and other calls (no signal, cheaper rates, etc).

Microsoft used to sell something which would automatically intercept and redirect calls to other private numbers off of the cell network. This allowed higher quality codecs and lower costs.

If the handset maker only supports 911 when there is a cell signal, then this runs afoul of the FCC rule. The handset could be used in a location with wifi (but no cell signal), and be used to make calls. Someone picks up that handset, tries to dial 911 and is denied.

Microsoft, since they're a VoIP provider, needs to deal with E911. Google, needs to be fault-tolerant in the 911 dialing path and have good fallbacks.


I understand that. But MS shouldn’t have to solve “route E911 on an Android phone”. Google has to solve that for the default dialer/call handler. I don’t understand why a call made from default Android would ever route back to MS Teams. All calling (at least for E911 and similar) should go through the default call handler via API. Or something like that. It sounds like Google has a really convoluted, error-prone implementation. I’m sure they had a good reason at the time, but looking in from the outside today, my first thought is “WTH were they thinking?”


The obvious prevalent use case is adding a business / work line via your company's VoIP provider to your personal handset (or a company one, for that matter). I'm sure this is very common, and I have both done and supported it at multiple employers. Personally I have also in the past used VoIP accounts for cheap long distance, but I maintain a cellular service for reliability with local calls.

Having this functionality integrate with the OS is much handier than the clunkiness of dealing with individual apps, and this idea of replaceable parts is a key advantage of Android in general.

Emergency calls probably warrant special care and maybe more rigid handling, I will grant, but there's no reason not to support this in general.



>And why the hell does Google/Android allow 3rd party emergency phone service handlers at all?

It doesn't, but the interaction of registering a bunch of 3rd party voip services interacts with the emergency call system in interesting ways, as explained in detail in the links Ars Technica article.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: