MMI support in Telephony API

[hsinyi]

Hi there,
I am opening this issue for discussing MMI support.

In Mozilla API, we have mozMobileConnection.sendMMI() to address MMI command. Having separate sendMMI() and dial() functions is good for context, but we realize that with separate APIs, the app, API user, needs to parse an input string following 3GPP spec. 22.030 before making a correct choice of API usage, dial() or sendMMI().

The argument being discussed is:
Do we want our API user to take care of the 3gpp specification themselves, i.e. doing the MMI parsing stuff? If not, then unifying dial() and sendMMI() seems a possible solution?

Please visit [1] to see mozilla discussion threads.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=889737

[zolkis]

A few background links:
MMI spec: http://www.etsi.org/deliver/etsi_ts/122000_122099/122030/10.00.00_60/ts_122030v100000p.pdf

The way e.g. oFono handles it:
https://github.com/intgr/ofono/blob/master/doc/mmi-codes.txt

If I understand right, the question is whether could we have a single "magical" method to which we give whatever the user types in, and which would determine whether the string is a number (i.e. call 'dial'), or a USSD/MMI string, etc.

The problem is that parsing MMI at app level is asking too much from apps.
I am waiting for comments.

[zolkis]

I propose we define the supported use cases in more detail. This also affects UX design, so we should NOT make assumptions about UX, but we have to take examples for the use cases. So, consider the following use case:

• user opens dialer application
• user starts to type
• (UX choice) when the string typed in so far matches an emergency number, the UI may change accordingly
• (UX choice) when the string typed in so far matches any standalone MMI command, the UI may change accordingly
• (UX choice) when the string typed in so far matches a SEND-able code, the UI may change accordingly
• (other UX choices) ...

Hence, we need a method to check input strings against supported codes, also usable for validation (called after each typed in character). The method would return the supported list of classifications, which could be: "emergency" (even broken down eventually to "emergency-police", "emergency-fire", "emergency-health", etc), "standalone-mmi", "send-mmi", "unknown" (or equivalent integer enums).

The recommendation for dialer applications could be the following:

1. dialer app calls this method on each typed in character, and may change the UI.
2. Once the SEND/green button is pressed, the application calls the method for the final validation, and executes the following steps:
   2.1. if the string is an emergency number, dial the emergency call
   2.2. if the string is a standalone MMI code, launch the necessary UI actions for PIN change etc
   2.3. if the string is a SEND-able code, then call the SupplementaryServices.Initiate() method (or equivalent, such as sendMMI in your case); to be discussed
   2.4. otherwise, the string is to be validated as a remote party identifier (e.g. phone number) among the available telephony services, and that is left to the implementation of the dial() method.

This proposal still requires some logic to be implemented in the apps, but offloads the burden of parsing all codes. In the same time it enables UX choices, which would not be possible if the checks were done within one single dispatching method (e.g. dial()) behind the scenes.

However: for also supporting that use case, we could add a boolean DialOptions property for telling the implementation that dial() should interpret e.g. MMI, with a default value "false". If set to "true" when dial() is called, then the implementation would return error when this is not implemented, otherwise execute the steps 2.*.

What do you think?