the API shouldn't list the emergency numbers but have a dialEmergency() method instead about telephony HOT 15 CLOSED

Second part ("have a dialEmergency() method") is rejected. It is not possible to trigger the emergency dial procedure, the modem/network determines if the call qualifies as emergency call. The normal dial() method MUST be used, e.g. dial("112"), or dial("911").

About the first part ("the API shouldn't list the emergency numbers"), did you mean removing the 'emergencyNumbers' property? What is the use case for removing it?
Are you concerned that it cannot be implemented on certain platforms? No problem, then the call returns an empty array. Further, the app can choose to use it or not use it, so it should be not a user use case problem of exposing this information "too easily". So I don't see any reason for removing it.

from telephony.

.emergencyNumbers would help fingerprinting given that it leaks information such as the country the user is currently in.

I also, I do not want a .dialEmergency() but a .dialEmergency('number'). That means the caller would explicitely say that he wants to call that number as an emergency number. Such method wouldn't work if the emergency passed number isn't an emergency number. If it is one, it would automatically allow the call to pass. For example, it would disable the airplane mode if enabled.

As far as I know, this method would be enough to solve use cases and requirements that exists around emergency numbers.

from telephony.

As said, dialEmergency('number') cannot be implemented.
dial(emergencyNumber) is the only way.

So basically you are suggesting removing the 'emergencyNumbers' property, but I still don't see the justification. The app can still hide it from the user. Do you want to prevent the dialer app from knowing that information at all? It already has dialer privileges, and already will have access to cell location... so there is no extra leaking risk.

We can still remove it, but not for the reasons you mentioned. It could be considered private information to the telephony middleware, for instance.

from telephony.

dialEmergency('number') is implementable, we have that in Firefox OS. Why do you think it is not implementable? The behaviour would be simple: if |number| isn't an emergency number, the call would fail.

The problem is not to hide the emergency numbers from the users but from the application. Also, the emergency numbers might be various, and the application will not know what they mean. Some European countries for example have an emergency numbers to call an ambulance, the police, etc. and since a few years an European one. So, giving this information can also be misleading: applications can do unexpected things with that.

Also, even if that is a light problem, emergencyNumber leaks private information. The current Telephony API isn't enough to guess where a person is located. Indeed, an application with telephony privileges will likely have enough privileges to access that information but the Telephony API has already a set of risks and we should make sure to not add more of them.

from telephony.

I have checked your implementation, but I disagree, it does not implement emergency dialing. What you actually implemented is "we are now in emergency-only mode so try call this number and return error if does not trigger emergency mode", and name it dialEmergency, which is misleading.
It is not the UI who decides the call is now in emergency mode. The way it actually works is that you dial the number, the modem makes the call, then the network signals the modem this is now emergency call, and the modem enters emergency callback mode on CDMA in the US - in GSM you can have both data and voice and this is not needed). The modem will have its list of emergency numbers, as well as it may find them on the SIM card, or from the network.

The way the current spec deals with emergency calls: if the device is in flight mode, but the device is capable of emergency calls, then the implementation must expose this via a telephony service and make it the default telephony service (which will only take emergency calls through, as all other calls will fail on the modem).

BTW I need to add a boolean emergency flag to TelephonyCall...

"Also, the emergency numbers might be various, and the application will not know what they mean."

Yes they do. Actually there are dialer apps which map themselves the emergency numbers across different countries, although I would argue this belongs to the telephony middleware.

from telephony.

As for removing the 'emergencyNumbers' property: we have a use case which requires this property: while PIN code query, if the user types an emergency number, a new button is shown permitting emergency dialing.
Therefore the application handling the PIN query MUST know the emergency numbers.
They can be fetched from the network, modem and SIM card (3GPP 31.102)
There is the AT+CEN command for querying the emergency numbers from the network (see 3GPP 27.007).
With that, we must support knowing the emergency numbers.

from telephony.

As for whether do we need an extra dialEmergency() method besides dial().
In GSM there is an emergency call initiation procedure after mobility management channel is established. The problem is that modems implement emergency calls in too many ways. Telephony middleware seem to diverge too in what is left to dialer apps and what is assumed to be done in the modems. In addition, we have the CDMA specific procedure for emergency callback mode which you inherited.
Having a correct and widely implementable API on top of all this is hard business.

One way that it surely works in all cases, is to dial an emergency number using the normal dial() method.
The network will signal back if the call is emergency, so a flag could be updated on the TelephonyCall objects. This is to be added to the current spec.

On the other hand it also makes sense to indicate that the call is meant to be an emergency call.
After a lot of reading (specs, books, modem docs, middleware code), thinking and talking with people, it seems that a dialEmergency() method without arguments should be feasible to implement on all platforms, modems, and networks, especially that eCall support is spreading and newer modems have AT commands for initiating emergency calls.

Note that adding an argument would introduce a lot of problems, and it is not needed. If in emergency-only mode, it is the responsibility of the implementation to check whether the modem supports direct emergency procedure, or if the typed in number needs to be checked against known emergency numbers. Whichever way, the method can be implemented.

So the proposal is the following:

• keep the emergencyNumbers property for the reason given above;
• introduce a new method dialEmergency() without parameters, which implements the logic above and would trigger an error condition if it fails (either by exception, of firing an error event on TelephonyManager object - feel free to choose); if this is difficult to implement for you, then we should drop this method for this version of the Telephony spec, until you can implement it;
• introduce a boolean emergency property to TelephonyCall, updateable by the implementation with an event
• also, log this "is emergency" information to call history.

@mounirlamouri @sicking please comment.

from telephony.

I am extremely confused about having dialEmergency() without parameters. In those regions with more than one emergency number, each has a different use (police, firemen, a generic one, etc). Not allowing to indicate which of them to dial makes no sense to me.

In addition, the trigger of an emergency call is in some cases the user typing the actual emergency number (e.g. in the application handling the PIN, as you mentioned previously). It would not make any sense the user typing a number and the application not having means to request the modem to dial the typed number but instead letting the implementation to choose one based on I don't know which obscure non-specified criteria.

from telephony.

@efullea If you are confused, imagine the users of this API... :-p. All use cases you mentioned work using the dial() method. As mentioned earlier in this thread, the 'emergencyNumbers' property is needed e.g. for recognizing emergency numbers typed in through the PIN request dialog. This was the original design and it works, without the need of having a 'dialEmergency' method.

Mozilla pressed on to have the dialEmergency method, for avoiding exposing the 'emergencyNumbers' property, which is feared to reveal which country the user is. But that needs to be exposed anyway. Even if we make a workaround and introduce an API for telling 'is this number so far an emergency number'? that would not reduce the risk that the dialer app would know which country the user is.

If we add a number parameter to dialEmergency, and if the number is not an emergency number, it expects to fail. But from that failure the (assumed malicious) dialer app can already figure out all emergency numbers anyway. So no problem is solved here, only some unnecessary complexity is added.

Therefore IMO we should return to the original design, remove dialEmergency() and keep dial() and 'emergencyNumbers'. What do you say?

from telephony.

@zolkis Note your PR which aims at solving this issue is not removing emergencyNumbers. In my view it is not such a critical issue to expose emergencyNumbers to the app, as the assumption is that apps using this API would be trusted. I am though open to workarounds that prevent this numbers to be easily accesible by the app, for instance the method you mention for asking whether a number is an emergency number or not. This could work in the PIN app use case. That app could check after every new digit is entered (or when the 3rd digit is entered) if the entered number is an emergency number. Note this is not adding any additional risk, as the app could get the same information by dialing that number, but the app is still not able to easily get this info just by looking at an attribute.

In any case we have to go for dialEmergency(number), as otherwise the API would not provide the required fucntionality.

Also we should keep both dial(number) and dialEmergency(number) as the behaviour may be different, e.g. dial would fail when invoked in airplane mode, or dialEmergency would need to check whether the number is really an emergency number.

from telephony.

"we should keep both dial(number) and dialEmergency(number) as the behaviour may be different, e.g. dial would fail when invoked in airplane mode, or dialEmergency would need to check whether the number is really an emergency number"

This already works with the "dial()" method. In flight mode, no telephony service is active, except the default emergency service (as stated in the spec) which only accepts emergency calls. The developers have a single interface for dial(), and it works transparently. The 'emergencyDial()' IMHO is not needed.

Yes, this is a trusted API. As stated above, there is an AT command for fetching emergency numbers from network. That information is supposed to be available to dialers. We could say web dialers are not trusted that much, so we invent a method to ask if a number is emergency, or not. But this does not solve the privacy issue for a malicious app, as it takes a second to figure out all emergency numbers anyway. So why not go the simple way and expose 'emergencyNumbers' as a property?

In addition, if we have a method like isEmergencyNumber(number), it cannot possibly guarantee its own functionality. It can just say "to my best knowledge, based on the available information this is not an emergency number" - however, it may actually be one, or vice versa. So IMO it's cleaner and less confusing to expose 'emergencyNumbers', as information available from the network, modem, SIM.

from telephony.

I agree with Zoltan here. I think the amount of privacy leaked by exposing the list of emergency number is IMHO acceptable given that someone that has access to this interface can listen to all incoming phone calls (big privacy implications) as well as place outgoing phone calls (big economic implications).

So I think we should just expose the list of emergency numbers and use the dial() function.

Unless there's some sort of network function for placing an emergency call? Or does the network API simply use the normal dial protocols?

from telephony.

Thanks Jonas, I think this is the simplest, while covering the functionality.

As explained above, dialers don't have direct access to the network emergency mode triggering, the modems hide that. Some modems do expose ATD112 (and even that is a "convenience interface"), but most don't, and the telephony middleware I am using (ofono) doesn't either, but it does expose emergency numbers. All checks regarding emergency mode are done in modem/telephony middleware (that would correspond to your RIL+API implementation). Even with CDMA emergency callback mode, that can, and should be encapsulated in the telephony middleware/API implementation.

So yes, as far as any dialer is concerned, all calls should be placed using the normal dialing protocol. Also, it is much simpler that way: we would like to avoid placing any logic concerning emergency calls into web dialers.

This design (dial() + emergencyNumbers) is already proven by multiple dialers implemented this way, and I bet it will be good enough. Of course we are in early stage of the API and things may change, but for now, I prefer leaving this part simple and proven, and move forward.

from telephony.

FWIW, I think what @zolkis has said makes sense.

from telephony.

Closing for now.

from telephony.