Emergency numbers other than 112 and 911 (and 999 for the UK) are not available in emergency mode

Bug #1444883 reported by Wenfang Si
22
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Canonical System Image
Fix Released
High
Bill Filler
dialer-app (Ubuntu)
Fix Released
High
Gustavo Pichorim Boiko
ofono (Ubuntu)
Invalid
High
Unassigned
telephony-service (Ubuntu)
Fix Released
High
Gustavo Pichorim Boiko
telephony-service (Ubuntu RTM)
Fix Released
High
Gustavo Pichorim Boiko

Bug Description

arale device, r177, ubuntu-touch/vivid-proposed

Steps
1. Emergency mode (e.g. Lock phone with a passcode, slide left, tap on "Emergency Call")
2. try input 911, 112 ==> OK
2. try input 110, 119 ==> "Dial" button is inactive after number is input

Expect
Allow these numbers in emergency mode

Tags: emergency

Related branches

Revision history for this message
Evan Wang (wsy324) wrote :

The emergency call number (110, 112, 119) works on Arale r183,
but another two number (120, 122) not, they are also emergency call number in China.

Revision history for this message
Sebastien Bacher (seb128) wrote :

Thank you for your bug report, could you provide some extra informations
- are those numbers available if you use the same SIM in a phone using another OS (android, iOS, ...)
- do you know how to adb shell to the device? could you run "/usr/share/ofono/scripts/list-modems" and give the output there?

Changed in dialer-app (Ubuntu):
importance: Undecided → High
status: New → Incomplete
affects: dialer-app (Ubuntu) → telephony-service (Ubuntu)
Revision history for this message
Evan Wang (wsy324) wrote :
Download full text (3.4 KiB)

Hi Sebastien, I collected the emergency call numbers of Mainland China only (not include Hong Kong&Macau, and Taiwan), and they are all available in my android phone(XiaoMi) with the same SIM card.

110 Police
119 Fire
120 Ambulance
122 Traffic Accident

Here is the output of "/usr/share/ofono/scripts/list-modems" on Arale r46, channel: ubuntu-touch/tangxi/devel-proposed

$ /usr/share/ofono/scripts/list-modems
[ /ril_0 ]
    Model = Fake Modem Model
    Manufacturer = Fake Manufacturer
    Online = 1
    Lockdown = 0
    Type = hardware
    Emergency = 0
    Revision = MOLY.LR9.W1421.MD.LWTG.MP.V6.P11, 2014/09/10 10:13
    Powered = 1
    Interfaces = org.ofono.ConnectionManager org.ofono.Phonebook org.ofono.CallBarring org.ofono.CallForwarding org.ofono.CallSettings org.ofono.SupplementaryServices org.ofono.NetworkRegistration org.ofono.SmartMessaging org.ofono.PushNotification org.ofono.MessageManager org.ofono.MessageWaiting org.ofono.RadioSettings org.ofono.SimManager org.ofono.CallVolume org.ofono.VoiceCallManager org.ofono.NetworkTime
    Features = gprs ussd net sms rat sim
    Serial = 862095022035486
    [ org.ofono.ConnectionManager ]
        RoamingAllowed = 0
        Bearer = lte
        Attached = 1
        Powered = 1
        Suspended = 0
    [ org.ofono.Phonebook ]
    [ org.ofono.CallBarring ]
        VoiceOutgoing = international
        VoiceIncoming = disabled
    [ org.ofono.CallForwarding ]
        ForwardingFlagOnSim = 0
        VoiceNoReply =
        VoiceUnconditional =
        VoiceNoReplyTimeout = 20
        VoiceNotReachable = +8613800100103
        VoiceBusy = +8613800000000
    [ org.ofono.CallSettings ]
        CalledLinePresentation = disabled
        CallingNamePresentation = unknown
        HideCallerId = default
        CallingLinePresentation = enabled
        CallingLineRestriction = disabled
        VoiceCallWaiting = enabled
        ConnectedLinePresentation = unknown
        ConnectedLineRestriction = unknown
    [ org.ofono.SupplementaryServices ]
        State = idle
    [ org.ofono.NetworkRegistration ]
        Strength = 83
        Mode = auto
        Technology = edge
        CellId = 25617
        MobileNetworkCode = 00
        Name = CMCC
        MobileCountryCode = 460
        LocationAreaCode = 4335
        Status = registered
    [ org.ofono.SmartMessaging ]
    [ org.ofono.PushNotification ]
    [ org.ofono.MessageManager ]
        ServiceCenterAddress = +8613800100500
        UseDeliveryReports = 0
        Bearer = cs-preferred
        Alphabet = default
    [ org.ofono.MessageWaiting ]
        VoicemailWaiting = 0
        VoicemailMailboxNumber =
        VoicemailMessageCount = 0
    [ org.ofono.RadioSettings ]
        ModemTechnologies = gsm umts lte
        TechnologyPreference = lte
        FastDormancy = 0
    [ org.ofono.SimManager ]
        Retries =
        FixedDialing = 0
        BarredDialing = 0
        ServiceNumbers = [] = ''
        MobileCountryCode = 460
        PinRequired = none
        SubscriberIdentity = 460027013766397
        CardIdentifier = 898600c00115
        SubscriberNumbers =
        Present ...

Read more...

Revision history for this message
Sebastien Bacher (seb128) wrote :

thanks, the log has

" [ org.ofono.VoiceCallManager ]
        EmergencyNumbers = 112 911"

so it seems like ofono is getting the wrong information (or the SIM card only has those and more heuristic are needed/android is adding numbers from some other list)

Changed in telephony-service (Ubuntu):
status: Incomplete → New
Revision history for this message
Pat McGowan (pat-mcgowan) wrote :

Can we look into whether we are properly handling updates from the network / modem to the emergency number list.
Also does it make sense to allow the user to enter any number from the default list in addition to what the sim provides.

Changed in ofono (Ubuntu):
status: New → Confirmed
assignee: nobody → Alfonso Sanchez-Beato (alfonsosanchezbeato)
importance: Undecided → High
Revision history for this message
Pat McGowan (pat-mcgowan) wrote :

also see bug #1334860

tags: added: emergency
Revision history for this message
Tony Espy (awe) wrote :

How about we start with what SIM card is installed in the phone? Is CMCC, China Mobile?

When ofono starts, if a valid SIM is inserted in the phone, ofono will try to read the emergency numbers from the file EF_ECC ( emergency number list ). It tries two different formats to ensure that it's able to read the file from a wide variety of SIM cards. When one of these reads completes, ofono builds a composite emergency number list using:

 - the list of emergency numbers read from the network ( always empty, as RIL/rilmodem don't support this )

 - if a valid SIM is present, the numbers read from the SIM EF_ECC file

 - if a SIM is not present, the numbers "119, 118, 999, 110, 08, and 000" are added

 - finally the default numbers "911" and "112" are added

Also, please note that bug #1334860 discusses a similar problem with operators in Brazil. Their SIMs are not programmed property, and the emergency numbers are found in the 'ServiceNumbers' list from the SIM instead. The only plausible solution for this was the idea that maybe we should instead be using libphonenumber to provide a canonical list of emergency operators vs. relying on SIM cards.

I checked, and there are no ServiceNumbers present on the SIM either ( see list-modems output ).

Revision history for this message
Alfonso Sanchez-Beato (alfonsosanchezbeato) wrote :

Some general comments:

1. Yes, ofono supports importing emergency numbers from those provided by the network. However, after taking a look to ril.h it looks like it is not implemented in AOSP (and I have not seen it in MTK ril.h Android, although maybe they use an Android property for sharing them, you never know). The only ofono driver that I see supports this it "ifxmodem" (Infineon).

2. There is nothing that prevents ofono to try to start a call even if there is no SIM present, it does not check against the list of emergency numbers. Imo dialer-app should not check the list either and allow the user to try to start a call even if there is no SIM. The network does know which numbers are for emergencies and which not. So I have added a task for dialer-app.

3. I think that emergency calls specifics are handled essentially by the modem and the network. The list can be used to do things like displaying "emergency" in the dialer when calling one of the numbers, or to avoid the modem to go offline when that happens and so on, but it should not be used to put restrictions on other numbers. We simply cannot know for sure which numbers are emergency and which not, so we should be safe here.

Revision history for this message
Alfonso Sanchez-Beato (alfonsosanchezbeato) wrote :

For this concrete bug I find it interesting that the file on the SIM does exist and that its content is "112 911" (otherwise we would have had the default ofono list, which does include 110 and 119).

@Wenfang, could you please attach the output of the "getprop" command? Some properties are related to emergency numbers.

Revision history for this message
Alfonso Sanchez-Beato (alfonsosanchezbeato) wrote :

I have checked that in my Android phones I can try to call non-emergency numbers with locked or no SIM.

Revision history for this message
Tony Espy (awe) wrote :

@Alfonso -

I just checked my Nexus5 and it the Emergency Dialer rejects the call immediately if the number entered is not an emergency number. I didn't go so far as checking the RIL trace, but as the dialog pops up right away, it's doubtful it initiated a call and got a response from the network that quickly.

Also re: comment #8 items 2 & 3, I'm not sure I agree with your 'no restrictions' proposal. Again, I think at minimum before going down this path, we should research using libphonenumber as previously discussing with the dialer-app developers. I think we also should further investigate Android as you and I have seen quite different behavior. Let's put this on the agenda for next week's network/telephony meeting and ask the dialer-app devs to join.

Revision history for this message
Evan Wang (wsy324) wrote :

@Alfonso, attached the output of the "getprop" command,fyi.

Revision history for this message
Alfonso Sanchez-Beato (alfonsosanchezbeato) wrote :

@Tony, I have dialled a non-emergency number, without SIM, using the "dial-number" ofono script. The radio logs shows:

05-25 05:42:06.748 1879 1885 D use-Rlog/RLOG-AT: ATDXXXXXXXXX;
...
05-25 05:42:06.754 1879 1899 D use-Rlog/RLOG-AT: +CME ERROR: 100

so rild tries to dial, although the modem responds immediately with an "unknown" error. This fits your observation about the call being quickly rejected, and also that the radio layer does try to dial. IMHO I think this confirms that it is better to let the modem and the network handle emergency codes: the modem/network does not inform us which numbers are emergency, so we should better be safe and not make assumptions in the dialer-app that could prevent the user to make an emergency call.

Re: the CMCC SIM, in the list of properties that Evan has attached we have:

[ril.ecclist]: [112,911]

Same emergency codes as in ofono. These numbers must come from the SIM, and apparently rild does not add any numbers to these. IMO the SIM profile is simply wrong. Being this a Chinese SIM, 110 and 119 should be on the SIM file that provides the emergency numbers. This is worrying, as it implies that we cannot blindly trust the list of emergency codes on the SIM. And we cannot just simply trust the numbers in libphonenumber.

I do not imply with this that we cannot improve the list of emergency number, either using libphonenumber or trying to find a way to ask the modem the list (maybe using directly some AT command?): but I do think that we *must* be safe here, and *first* let dialer-app dial any number even when there is no SIM/the SIM is locked. There is no harm here, as the modem/network will reject the call if the number is not emergency.

Revision history for this message
Tony Espy (awe) wrote :

@Alfonso

What device did you use and what software was it running ( ie. what version of Android )?

Regarding the SIM being programmed wrong in this case, yes it's worrying, but it's also a fact of life that some operators will do a poor job of programming their SIMs. This isn't the first case of invalid SIM programming we've seen.

I'm not sure why you think we can't trust the numbers in libphonenumber as one of it's intended uses is to solve this very issue.

Regarding allowing the dialer-app to dial any number... I guess you've convinced me that there's no major harm in allowing this. I will say however that ofono's emergency logic ( ie. the code that identifies when an emergency call is in progress ) won't work if/when such a SIM is used, so I still think we need to investigate usage of libphonenumber.

Revision history for this message
Alfonso Sanchez-Beato (alfonsosanchezbeato) wrote :

@Tony

I did the testing with Ubuntu/arale.

Let me reword what I said for libphonenumber: I was trying to say that libphonenumber is probably not 100% accurate. We can and should use it, but we should not prevent the user to call numbers that are not there either.

Finally, right, the specific things that are done for emergency calls (I think that the only one in ofono is that you cannot offline the modem, I do not know what other pieces of the system do under emergency conditions) would not be done in those cases, but that is a minor issue compared to not being able to call emergency codes.

Revision history for this message
Jean-Baptiste Lallement (jibel) wrote :

Any progress on this issue? It is the same problem in France the following numbers are not recognized:

- Medical emergency/accidents/ambulance (SAMU): 15
- Fire brigade: 18
- Police: 17
- 114 for deft and mute people

summary: - Emergency numbers for China (110,119) are not available in emergency
- mode
+ Emergency numbers other than 112 and 911 (and 999 for the UK) are not
+ available in emergency mode
Revision history for this message
Alfonso Sanchez-Beato (alfonsosanchezbeato) wrote :

@jibel. to summarize:

1. Solution is to let the user call any number even if there is no SIM. It is harmless and should be done even when we have (2). I think that this is a modification of telephony-service.

2. Long term solution to identify emergency codes is to use libphonenumber, as we cannot rely completely on SIM files and rild does not notify ofono of the network current emergency numbers.

Changed in canonical-devices-system-image:
status: New → Confirmed
importance: Undecided → High
assignee: nobody → Bill Filler (bfiller)
milestone: none → ww34-2015
Bill Filler (bfiller)
Changed in telephony-service (Ubuntu):
assignee: nobody → Gustavo Pichorim Boiko (boiko)
Changed in dialer-app (Ubuntu):
assignee: nobody → Gustavo Pichorim Boiko (boiko)
importance: Undecided → High
Revision history for this message
Gustavo Pichorim Boiko (boiko) wrote :

This is the same bug as #1334860

We need to switch telephony-service, dialer-app, etc to use libphonenumber's emergency number database instead of relying on ofono to get the list

Revision history for this message
Tony Espy (awe) wrote :

@Alfonso

Regarding comment #18... Yes, loosening the restriction when there's no SIM(s) or there are PIN/PUK locked SIM(s) in the phone makes sense, however this bug describes a phone with a SIM that hasn't been unlocked from the Welcome screen.

As the user didn't bother, or didn't have the phone's lock code, they accessed the emergency dialer and tried to use the French emergency codes and failed. If we allow any number to be dialed at this point, it allows anyone to use the phone without first unlocking. I don't think this is acceptable, however it probably should be reviewed with product management.

So... I *still* think someone needs to do the due diligence around libphonenumber and determine whether or not the French emergency numbers are correctly identified. The ShortNumberInfo class offers several emergency number methods. One minor pain is that the methods require a region codes ( eg. "US" = United States, "CN" = China, "FR" = France, ... ). We might need create a mapping between mobile country codes and region codes in order to use the libphonenumber for this purpose. Here's the github repo:

https://github.com/googlei18n/libphonenumber

Also, at this point, I agree with you that the additional logic should be added at a higher layer than ofono. That said, a wish list bug could be opened for adding support for network-communicated emergency numbers, but as there currently isn't a standard RIL mechanism to do so, it's probably not worthwhile. As such, I'm changing the status of the ofono task to Invalid.

Changed in ofono (Ubuntu):
status: Confirmed → Invalid
assignee: Alfonso Sanchez-Beato (alfonsosanchezbeato) → nobody
Changed in telephony-service (Ubuntu):
status: New → Confirmed
Changed in telephony-service (Ubuntu RTM):
status: New → Confirmed
importance: Undecided → High
assignee: nobody → Gustavo Pichorim Boiko (boiko)
Bill Filler (bfiller)
Changed in canonical-devices-system-image:
status: Confirmed → In Progress
Changed in dialer-app (Ubuntu):
status: New → In Progress
Changed in telephony-service (Ubuntu):
status: Confirmed → In Progress
Changed in telephony-service (Ubuntu RTM):
status: Confirmed → In Progress
Revision history for this message
Łukasz Zemczak (sil2100) wrote :
Download full text (4.1 KiB)

This bug was fixed in the package telephony-service 0.1+15.04.20150810.1-0ubuntu1 in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay

---------------

telephony-service (0.1+15.04.20150810.1-0ubuntu1) vivid; urgency=medium

  [ Tiago Salem Herrmann ]
  * Check contact results on the client side. Phone comparison in the
    server side is not reliable. (LP: #1476833)
  * Use libphonenumber for phone number validation, normalization and
    comparison. (LP: #1471545, #1444883, #1334860)

telephony-service (0.1+15.10.20150727-0ubuntu2~gcc5.1) wily; urgency=medium

  * No change upload built with GCC 5.

telephony-service (0.1+15.10.20150727-0ubuntu1) wily; urgency=medium

  [ CI Train Bot ]
  * Resync trunk. added: po/cy.po

  [ Gustavo Pichorim Boiko ]
  * Make sure outgoing calls are not set as accepted by the approver.
    (LP: #1476826)

telephony-service (0.1+15.10.20150717-0ubuntu1) wily; urgency=medium

  [ Gustavo Pichorim Boiko ]
  * Specify the domain when translating unknown and private number
    strings. (LP: #1470938)

telephony-service (0.1+15.10.20150709-0ubuntu1) wily; urgency=medium

  [ Gustavo Pichorim Boiko ]
  * Sync the fixes that were released in OTA5: (LP: #1384274, #1433068,
    #1412709, #1427286, #1453004)

telephony-service (0.1+15.10.20150706.1-0ubuntu1) wily; urgency=medium

  [ Alberto Aguirre ]
  * No change rebuid against platform-api 3

telephony-service (0.1+15.10.20150701-0ubuntu1) wily; urgency=medium

  [ CI Train Bot ]
  * Resync trunk.

  [ Tiago Salem Herrmann ]
  * Update to telepathy-qt 0.9.6.1

telephony-service (0.1+15.10.20150617-0ubuntu1) wily; urgency=medium

  [ CI Train Bot ]
  * New rebuild forced.

  [ Gustavo Pichorim Boiko ]
  * Make it possible to specify the list of supported protocols
    dynamically by installing .protocol files in /usr/share/telephony-
    service/protocols

  [ Tiago Salem Herrmann ]
  * Add multimedia connection manager support
  * Remove slashes when normalizing phone numbers. (LP: #1462090)

telephony-service (0.1+15.10.20150608.4-0ubuntu1) wily; urgency=medium

  [ Gustavo Pichorim Boiko ]
  * Make it possible to remove call notifications from the messaging
    menu (LP: #1455408)

  [ Tiago Salem Herrmann ]
  * Fix TelepathyHelperTest and HandlerTest.

telephony-service (0.1+15.04.20150521.1-0ubuntu1) vivid; urgency=medium

  [ CI Train Bot ]
  * Resync trunk. added: po/cs.po

  [ Tiago Salem Herrmann ]
  * Properly move ringtone calls to a separate thread.

telephony-service (0.1+15.04.20150511.1-0ubuntu1) vivid; urgency=medium

  [ CI Train Bot ]
  * Resync trunk.

  [ Gustavo Pichorim Boiko ]
  * Fix voicemail detection on CallEntry. (LP: #1449710)

telephony-service (0.1+15.04.20150430.1-0ubuntu1) vivid; urgency=medium

  [ CI Train Bot ]
  * Resync trunk.

  [ Gustavo Pichorim Boiko ]
  * Add an initial set of tests to make sure USSD is working.
  * Make it possible to clear the notifications. This is intended to be
    used by application tests.

  [ Tiago Salem Herrmann ]
  * Add an USSDManager instance to each OfonoAccountEntry. (LP:
    #1438273)

telephony-service (0.1+15.04.20150421-0ubuntu1) vivid; urgency=medium

  [ G...

Read more...

Changed in telephony-service (Ubuntu RTM):
status: In Progress → Fix Released
Changed in canonical-devices-system-image:
status: In Progress → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package dialer-app - 0.1+15.10.20150810-0ubuntu1

---------------
dialer-app (0.1+15.10.20150810-0ubuntu1) wily; urgency=medium

  [ CI Train Bot ]
  * Resync trunk.

  [ Tiago Salem Herrmann ]
  * Improve emergency number validation with libphonenumber. (LP:
    #1444883, #1334860, #1308365)

 -- CI Train Bot <email address hidden> Mon, 10 Aug 2015 21:06:08 +0000

Changed in dialer-app (Ubuntu):
status: In Progress → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package telephony-service - 0.1+15.10.20150810.1-0ubuntu1

---------------
telephony-service (0.1+15.10.20150810.1-0ubuntu1) wily; urgency=medium

  [ Tiago Salem Herrmann ]
  * Check contact results on the client side. Phone comparison in the
    server side is not reliable. (LP: #1476833)
  * Use libphonenumber for phone number validation, normalization and
    comparison. (LP: #1471545, #1444883, #1334860)

 -- CI Train Bot <email address hidden> Mon, 10 Aug 2015 22:45:07 +0000

Changed in telephony-service (Ubuntu):
status: In Progress → Fix Released
Changed in canonical-devices-system-image:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.