What would filing a complaint improve to this process?
Because it should never have gotten to this point. They are lucky that somebody has not already died.
> What would filing a complaint improve to this process?
It would encourage proper testing, and proper development practices that would prevent such a bug from occurring. Why was the system so poorly designed that Microsoft Teams could cause a hang during a 911 call in the first place?
Can't be sure about that. If someone died because they were unable to call 911, who is going to know afterwards?
Usually there's a hidden config register where we can change "the number for 911", so for some portion of testing, we'll set that to "Chris's phone" and inundate a coworker with calls, but once we've been through a shakedown with that, it's time to coordinate with the local PSAP and identify a slow time when they can field some real test calls from us.
There are all sorts of safeguards here -- they want a regular phone number for one of the testers, so if the test phone malfunctions in any way (say, calls complete but audio doesn't open), they can reach us out-of-band. And it's always perfectly clear that they can cancel the activity at any time, if enough real 911 calls come in that they don't have spare operators for our testing.
It's been a long time since I was on the carrier side, but I remember doing tower turn-ups, we'd also place one test call per carrier-sector, to make sure the location info was transferred correctly. Similar coordination but it was largely a formality because it was usually just 3 or 6 calls, and very brief ones at that.
In the instant case, both the phone maker (Google) and the carrier (unsure) should've exercised this in their acceptance testing. Since it sounds like a Teams bug, it's understandable that they didn't catch it, but also unacceptable that Teams could interfere with the ability to dial 911. Since we've now learned that apps can interfere with that, this hugely balloons testing requirements until/unless they fix the OS so apps cannot interfere.
When I worked at Motorola doing mobile infrastructure, you couldn't even merge your code into a release candidate branch unless it was tested against emergency calls, for all the reasons you listed (plus more).
We used giant attenuators screwed on to the antenna plugs because everything had to be running at full power to ensure that it was as life-like as possible. Every once in a while, though, someone didn't screw the attenuator on tight enough and the emergency call would be picked up on the real mobile network and the fire department would show up in our parking lot.
There is most likely an issue but we don't really know what it is. how do you know it's not on the Verizon side?
Most likely half the 911 calls in the US are made from Android phones and we never heard of common issues.
he had contacted Google support, but unfortunately, he do not get response now.
i know it isn't a verizon problem, because google tried to blame teams.
I don't know your definition of playing it down.
It needs to be a carefully managed feature, but it's certainly not "zero need".
911/112/etc. calls should just not be screenable or blockable by apps or susceptible to third party app crashes. They should be short-circuited to just happen on the default phone app, with little possibility for any interference from apps on the system.
or where you can test it, but that testing is not sufficient to ensure the functionality works
then your design is not fit for purpose.
This is such a stupid argument, so out of the billions of android phone, it should never never happen? If you don't want hardware / software to fail never use it then.
Next you use a landline phone, for some reason 911 does not work, oops. But I was told 911 should work 100% of the time.
Problem will always happen to some degree.
And this is an even dumber argument. Yes software can fail, but a critical piece of software like this should have as few failure modes as possible. This bug would have been preventable through proper design and testing. There is no good reason to allow any third party integrations to interfere or become involved with dialing an emergency number, and oh so many reasons to outright forbid it.
You wouldn't pass a bug in a pacemaker off as "oh, shit happens". So why would you take that stance on a bug may prevent people calling emergency services in a potential life or death situation? Are you even listening to yourself?
This is critical software and it needs to be tested. Tested properly. It's thinking like this that gives software engineering a poor reputation as a discipline and leads to incidents like the Therac-25.
Like Microsoft with Windows, Google releases their security fixes for Android monthly. And January 4 is obviously the date for the next one (it goes out at the beginning of each month, and AFAIK the December one has already gone out). So the fix (which might even be ready already) is going to be released on the first opportunity.
This is at the same time as we head into a) the holiday season in much of the world, b) winter in much of the world, c) an ongoing pandemic that is dealing with the spread of a new variant and the roll out of not only initial vaccines but also boosters.
Having emergency calls not go through because of a bug needs to be fixed immediately, not subject to some update cycle.
Unless there is malicious intent, I do not really see the added benefit of a lawsuit or complaint to the regulator.
It’s not like this is some random Joe shop that missed a small feature. This is Google and Microsoft, two of the biggest tech companies out there, making billions while not even caring to follow society’s rules (move fast and break things right? All in the name of scaled super fast profit)
What’s the alternative? Just have 911 calls fail every once in a while since everybody is too busy with their feature work to look into it?
(googling says: https://developer.android.com/guide/topics/connectivity/tele... and hook up a test device )
I've no idea how exactly this bug happened and therefore whether the following has any relation to that issue or not, but if you want VOIP apps and similar things to work, you do need to allow the "I've got a phone number and I want to place a call" step to be intercepted, because otherwise how are you supposed to make a call via VOIP etc. when selecting a number from your contacts list, a phone link in a browser, etc. if that step was hardcoded to the regular phone app?
Android already differentiates between normal calls and emergency calls. Normal will be intercepted, emergency shouldn't be. And an emergency call is required to still work even if a SIM card is not present in your device.
Emergency is required to work a certain way, by law, and is documented to work that way, but didn't happen in the case of this bug. The OS is responsible for emergency calls, the dialler, which may be third party, for normal calls.
PS: At least where I live, emergency services will show up at your house if you make a few 0-second 911 calls
You're supposed to do this when setting up new VOIP service too, to make sure location information is reported correctly. It's quite a normal thing and they're not at all surprised by it.
I would go so far as to say there are 2 types of phone people: Those who've placed a lot of 911 test calls, and those who're placing their users at risk.
I assume you see this through the lens of "bugs happen, as long as developers make a sincere effort that's fine" under which most software development takes place. But this is absolutely the wrong way to look at this, and I bet you wouldn't apply this framework to physical engineering artifacts which are subject to legislation ensuring safety standards like bridges, cars or heaters.
If they've BUILT a system where apps can interfere with the ability to place calls, AND NOT written appropriate exceptions for 911 calls to bypass all such interference, AND NOT tested such exceptions, then there's a huge problem. That is absolutely the regulator's business.
I can't speak to the way modern phones are designed, but in earlier ones, 911 calls have all sorts of special status. They override pretty much all the phone's self-preservation mechanisms:
Transmitter deck too hot, normal calls can't be placed? 911 overrides that; the phone will melt itself if that's what it takes to get your call through.
Battery too low, normal call would be dropped so the phone can shut itself down without corrupting its flash filesystem? 911 overrides that, it will run until the circuitry physically ceases to function, in case that buys you a few more minutes of contact with the operator who might save your life.
Power control? Some phones would allow higher wattage when docked in a car-kit, but limit themselves to a lower power level when hand-held, to comply with tissue absorption regulations. Guess what limits go out the window when you call 911! Of course it's not gonna use the power unless it needs it, but if weak signal would cause a normal call to drop, 911 calls can tap into extra capability.
They will do ANYTHING to make that call go through.
And for software to fuck it up in the name of some obscure feature that clearly didn't get adequate testing, is unconscionable and spits in the face of literal decades of engineering effort.