VoiceCallManager.Dial() fails when roaming & area code specified
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.
Related branches
Tiago Salem Herrmann (tiagosh) wrote : | #1 |
Changed in ofono (Ubuntu): | |
assignee: | nobody → Tony Espy (awe) |
summary: |
- ofono returns an error on Dial() in roaming mode. + VoiceCallManager.Dial() fails when roaming & area code specified |
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:
Changed in ofono (Ubuntu): | |
status: | Confirmed → In Progress |
Tiago Salem Herrmann (tiagosh) wrote : | #7 |
I can confim the patch fixes the issue.
Thanks.
Tony Espy (awe) wrote : | #8 |
@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]).
Launchpad Janitor (janitor) wrote : | #10 |
This bug was fixed in the package ofono - 1.12.bzr6858+
---------------
ofono (1.12.bzr6858+
[ 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-
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_
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/
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-
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...
Changed in ofono (Ubuntu): | |
status: | In Progress → Fix Released |
Changed in dialer-app (Ubuntu): | |
status: | New → Invalid |
Status changed to 'Confirmed' because the bug affects multiple users.