VoiceCallManager.Dial() fails when roaming & area code specified

Bug #1239869 reported by Tiago Salem Herrmann on 2013-10-14
32
This bug affects 4 people
Affects Status Importance Assigned to Milestone
dialer-app (Ubuntu)
Undecided
Unassigned
ofono (Ubuntu)
Undecided
Alfonso Sanchez-Beato

Bug Description

I have noticed that calling my other phone number without the area code works fine, but if I call it using the area code the call is made but it is impossible to actually interact with it (hangup/set speaker and mute mode).

After debugging it a bit I found out that ofono returns an error when I dial the number using the area code (log attached), making telepathy-ofono also fail to create the new voice channel, but immediately after that telepathy-ofono receives a CallAdded from ofono. The call is actually created, but to a slightly different phone number, which contains a big prefix used to make long distance calls here in my country.
The interesting part is that it only happens when I am using a sim card that can only register to the network in roaming mode. My suspicious is that this redirect is made by the simcard or the operator.

This telepathy-ofono failure when creating the channel is what makes the ui unresponsive (no hangup, for example), as it breaks the regular flow in telepathy-ofono.

My suggestion would be to either fix this issue and return the voice call object path as usual, or return a specific error so telepathy-ofono can deal with this extra case where the voice call object path won't be returned right away even if the call will be successfully created afterwards.

Tiago Salem Herrmann (tiagosh) wrote :
Tony Espy (awe) on 2013-10-15
Changed in ofono (Ubuntu):
assignee: nobody → Tony Espy (awe)
Tony Espy (awe) on 2013-10-15
summary: - ofono returns an error on Dial() in roaming mode.
+ VoiceCallManager.Dial() fails when roaming & area code specified
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in ofono (Ubuntu):
status: New → Confirmed

The attached traces show that RIL_REQUEST_DIAL returns error code 0x13 instead of 0 (non-error). However, the subsequent GET_CURRENT_CALLS shows a call with the dialled number, but with a prefix (014 instead of 0) because of the apparent redirection.

0x13 is not actually defined in ril.h. Some explanation about where this code comes from would be helpful to determine whether it can be considered a success return code or not.

This traces show the same problem. Error code 0x13 is returned when dialling, and the call is redirected. In this case 123 is redirected +18056377243 (T-Mobile US voice mail number).

An easy workaround is to simply consider code 0x13 equivalent to 0 (=SUCCESS). However, some explanation on where this number comes from is needed.

Interestingly, calling the same number in a BQ Aquaris does not produce the error: REQUEST_DIAL reply has return code 0, although the number is redirected as in mako.

Changed in ofono (Ubuntu):
assignee: Tony Espy (awe) → Alfonso Sanchez-Beato (alfonsosanchezbeato)

It turned out that error code 0x13 is specific to Qualcomm modems. A fix can be found in:

https://github.com/rilmodem/ofono/pull/74

Changed in ofono (Ubuntu):
status: Confirmed → In Progress
Tiago Salem Herrmann (tiagosh) wrote :

I can confim the patch fixes the issue.
Thanks.

Tony Espy (awe) wrote :

@Alfonso

Your pull request basically implements what was suggested in comment #5. This makes sense as long as the caller notices that the phone number was re-directed ( ie. the number changed ). Also, this pull request seems to be based off logic from Cyanogenmod.

How does vanilla AOSP handle this?

AOSP simply does not handle this: its ril.h it does not define this error code. The error codes come from the codeaurora [1], which is sponsored by Qualcomm and implements Snapdragon optimizations for Android. Cyanogenmod took the code from them, ril.h and parts in the java telephony service that handle this.

To be honest, the best solution would be to define a QUALCOMM vendor and check the code just for this, but as mako is our reference platform and is Qualcomm-based, I just made AOSP=QUALCOMM, which also seems to be the approach of Cyanogenmod, as it uses those codes by default. If we need to implement more Qualcomm specific bits in the future we will have to go this path. For instance, Qualcomm also implements multi-sim support (check struct RIL_SelectUiccSub in [1]).

[1] https://www.codeaurora.org/cgit/external/gigabyte/ag-gb-dsds-7227/plain/hardware/ril/include/telephony/ril.h

Launchpad Janitor (janitor) wrote :
Download full text (4.1 KiB)

This bug was fixed in the package ofono - 1.12.bzr6858+14.10.20140501-0ubuntu1

---------------
ofono (1.12.bzr6858+14.10.20140501-0ubuntu1) utopic; urgency=low

  [ Tony Espy ]
  * [ Tony Espy ] build, gril, rilmodem, plugins/ril, test: call-
    forwarding support. [ Alfonso Sanchez-Beato ] build, gril,
    plugins/rildev: dynamic plugin loading for ril-type modems.   The
    new rildev plugin reads an environment variable to determine
    which   device plugin   to load ( defaults to the standard ril
    plugin ). build, gril, plugins/ril, rilmodem, unit: radio-settings
    support.   Allow radio technology ( ie. use 2G-only ) preference to
    be configured. [ Tony Espy ] test: update remaining test scripts to
    Python 3. build, src, plugins, src/gprs: add MMS support.   Added
    new android-provision plugin and associated -apndb code   to
    provision GPRS and MMS contexts using apns-conf.xml as the primary
      provisioning database, while mobile-broadband-provider-info is
    still   queried in order to pickup additional Apns. Also added
    support for   combined Internet/MMS contexts by allowing MMS
    specific properties   to be set for OFONO_GPRS_CONTEXT_TYPE_INTERNET
    contexts. [ Alfonso Sanchez-Beato ] rilmodem/ussd: Fix USSD Initiate
    hang (LP: #1299227 ). gril, rilmodem, unit: add SIM write support.
      This allows ofono's core call-forwarding and message-waiting logic
      to update persistent state on the SIM, in order to preserve it
    across   reboots. build, gril, include, plugins, src,
    drivers/mtkmodem, drivers/rilmodem: add MTK support.   This change
    adds support for MTK-ril modems without breaking compatibility
      with AOSP-ril modems. examples, include, plugins, src: support for
    gid type MVNOs in Android APN database. gril, rilmodem: fix for call
    redirections (LP: #1239869).   This fix checks and ignores a
    Qualcomm specific error   code that indicates a call has been re-
    directed by an   operator while roaming. build, gril, rilmodem,
    unit: add call-barring support. gril, mtkmodem, rilmodem, unit: MTK
    followup changes.   This change adds unit tests for MTK specific
    messages.   It also consolidates parsing logic for parsing data
      call lists, which is a valid payload for multiple message   types.
    Finally, the deactivate data call logic on start-   up has been re-
    worked to query the active calls before   attempting to deactivate
    any. src/smsutil: use UTF-16 instead of UCS-2 (LP: #1269017).   If
    an incoming SMS is indicated to be UCS-2, use UTF-16   instead to
    decode so that emoji's ( which use larger   codepoints than can be
    encoded in UCS-2 ) are properly   decoded. [ Jussi Pakkanen ]
    phonesim: add a DBus control interface.   This control interface has
    been added in order to make   phonesime more flexible for auto-pilot
    testing of   Touch's network-indicator code. [ Alfonso Sanchez-Beato
    ] android-apndb.c/-provision.c: fix string comparisions.   Change
    all usage of g_str_equal() to g_strcmp0(). This   fixes a crash that
    may happen if the SIM doesn't contain   a SPN file. gril: switch
    process to radio user.   Te...

Read more...

Changed in ofono (Ubuntu):
status: In Progress → Fix Released
Tony Espy (awe) on 2014-05-16
Changed in dialer-app (Ubuntu):
status: New → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers