4 ms·

> Why raise hell about this? Because it should never have gotten to this point. They are lucky that somebody has not already died. > What would filing a compl

by messe 5y ago

> Why raise hell about this? 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?

nikanj 5y ago
What kind of testing (and from whom) would have caught this?
- deleted 5y ago
  [deleted]
- isbvhodnvemrwvn 5y ago
  Google should have built in some mechanism which verifies that the integration from Teams can't prevent calling 911 - either as part of Play Store verification, or as a general test of their system (they delegate to other apps, if these fail or hang the native mechanism should take over).
  - midjji 5y ago
    Or just generally make it impossible to interfere with the calling process. There is zero need for it after all.
    - rjmunro 5y ago
      Having something that can screen calls for spam, something that can stop you accidentally dialling a premium rate number and getting an unexpected large bill, or something that can intercept a call and route it over a cheaper VoiP connection is really useful. It needs to be a carefully managed feature, but it's certainly not "zero need".
      - megous 5y ago
        Adn that's ok. 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.
- deleted 5y ago
  [deleted]
- michaelt 5y ago
  If you have a design where you cannot test 911 functionality, 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.
- deleted 5y ago
  [deleted]
- myself248 5y ago
  At least in vehicle infotainment systems, we test 911 functionality EXTENSIVELY. It's a major part of call testing, because dialing 911 overrides all sorts of lockouts and exercises code paths that aren't otherwise well-covered by testing. 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.
  - OldHand2018 5y ago
    > At least in vehicle infotainment systems, we test 911 functionality EXTENSIVELY. It's a major part of call testing, because dialing 911 overrides all sorts of lockouts and exercises code paths that aren't otherwise well-covered by testing. 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.
ifdefdebug 5y ago
> They are lucky that somebody has not already died. Can't be sure about that. If someone died because they were unable to call 911, who is going to know afterwards?
- bsagdiyev 5y ago
  At least a few, I’d gather: https://www.fcc.gov/news-events/podcast/personal-story-behind-karis-law https://www.fcc.gov/news-events/podcast/personal-story-behin...
Thaxll 5y ago
> Because it should never have gotten to this point. They are lucky that somebody has not already died. 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.
- messe 5y ago
  > 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. [...] 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.
OrangeMusic 5y ago
Are you a developer? Do you not know that bug-free software doesn't exist?

by messe 5y ago

nikanj 5y ago

What kind of testing (and from whom) would have caught this?

deleted 5y ago
[deleted]
isbvhodnvemrwvn 5y ago
Google should have built in some mechanism which verifies that the integration from Teams can't prevent calling 911 - either as part of Play Store verification, or as a general test of their system (they delegate to other apps, if these fail or hang the native mechanism should take over).
- midjji 5y ago
  Or just generally make it impossible to interfere with the calling process. There is zero need for it after all.
  - rjmunro 5y ago
    Having something that can screen calls for spam, something that can stop you accidentally dialling a premium rate number and getting an unexpected large bill, or something that can intercept a call and route it over a cheaper VoiP connection is really useful. It needs to be a carefully managed feature, but it's certainly not "zero need".
    - megous 5y ago
      Adn that's ok. 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.
deleted 5y ago
[deleted]
michaelt 5y ago
If you have a design where you cannot test 911 functionality, 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.
deleted 5y ago
[deleted]
myself248 5y ago
At least in vehicle infotainment systems, we test 911 functionality EXTENSIVELY. It's a major part of call testing, because dialing 911 overrides all sorts of lockouts and exercises code paths that aren't otherwise well-covered by testing. 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.
- OldHand2018 5y ago
  > At least in vehicle infotainment systems, we test 911 functionality EXTENSIVELY. It's a major part of call testing, because dialing 911 overrides all sorts of lockouts and exercises code paths that aren't otherwise well-covered by testing. 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.

ifdefdebug 5y ago

> They are lucky that somebody has not already died. Can't be sure about that. If someone died because they were unable to call 911, who is going to know afterwards?

bsagdiyev 5y ago
At least a few, I’d gather: https://www.fcc.gov/news-events/podcast/personal-story-behind-karis-law https://www.fcc.gov/news-events/podcast/personal-story-behin...

Thaxll 5y ago

> Because it should never have gotten to this point. They are lucky that somebody has not already died. 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.

messe 5y ago
> 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. [...] 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.

OrangeMusic 5y ago

Are you a developer? Do you not know that bug-free software doesn't exist?