*2 and *8 are valid phone numbers in Venezuela. This is a cert blocker.

Device: Flame Build ID:20140620111452 Gaia: 6a137334 STR: 1. USe a MOVISTAR VENEZUELA SIM card and make a call to a two digit number (*2 or *8) 2. After the call is established, the following error message is shown: Unable to make a phone call now. (See attached screenshot)

I'm getting this in my logs: E/GeckoConsole( 1026): Content JS ERROR at app://communications.gaiamobile.org/dialer/js/telephony_helper.js:153 in handleError: Unexpected error: UnspecifiedError I verified that we're sending the correct parameters to telephony.dial() [1], which in this case are sanitizedNumber='*2', cardIndex=0. I also verified, just to be completely certain, that this isn't being treated as a USSD/MMI code (even though the UX flow wouldn't suggest that at all). [2] It seems that this UnspecifiedError is the fallback code for an error we don't know anything about in Gaia. [3] Hsin-Yi, can you take a look please? I think this might also be a good mentored bug for Tamara. [1] https://github.com/mozilla-b2g/gaia/blob/master/apps/communications/dialer/js/telephony_helper.js#L102 [2] https://github.com/mozilla-b2g/gaia/blob/master/apps/communications/dialer/js/mmi.js#L316 [3] https://github.com/mozilla-b2g/gaia/blob/master/apps/communications/dialer/js/telephony_helper.js#L153

Hi Doug, I could confirm that Gecko views *2 and *8 as valid numbers as well. Gecko sends the dial request with these two numbers to modem, not MMI command. I glanced over the gecko code again that gecko doesn't generate dial error 'Unexpected error' which is, instead, coming from modem. So I think we need more information from the reporter: 1) Did you test with a MOVISTAR VENEZUELA SIM card in a Venezuela home network or in a roaming network? 2) Could you reproduce the issue with other non-FxOS device? Thanks!

Hi I can reproduce this also with a MOVISTAR SPAIN Sim in Spain. It seems the problem is when you try to establish a connection but the other number is invalid/out of coverage/switch-off. I've called a valid number of a powered off device and the dialer on FxOS try to establish the call. FxOS try to establish the call but after few seconds the call is terminated without success. Now is when the FxOS device shows the message Unable to make a phone call now.

(In reply to mbarone from comment #6) > Hi > > I can reproduce this also with a MOVISTAR SPAIN Sim in Spain. It seems the > problem is when you try to establish a connection but the other number is > invalid/out of coverage/switch-off. > > I've called a valid number of a powered off device and the dialer on FxOS > try to establish the call. FxOS try to establish the call but after few > seconds the call is terminated without success. Now is when the FxOS device > shows the message Unable to make a phone call now. Then it sounds like an expected behaviour to me. If *2 or *8 are not seen as valid numbers by operator or if we are trying to reach someone which is not reachable via call, then modem will later inform us some message about the reason of the call disconnection.

Maybe UX can provide more detail if it is the expected behaviour.

(In reply to Beatriz Rodríguez [:brg] from comment #2) > *2 and *8 are valid phone numbers in Venezuela. This is a cert blocker. Neither Gaia nor gecko blocks the call to number *2 or *8. I don't think this is 2.0+. (In reply to mbarone from comment #8) > Maybe UX can provide more detail if it is the expected behaviour. I am not really sure I got your point. What's the expected result from your side then? NI Carrie for UX confirmation.

(In reply to mbarone from comment #6) > Hi > > I can reproduce this also with a MOVISTAR SPAIN Sim in Spain. It seems the > problem is when you try to establish a connection but the other number is > invalid/out of coverage/switch-off. Can you try putting that SIM in a non-FxOS device? > I've called a valid number of a powered off device and the dialer on FxOS > try to establish the call. FxOS try to establish the call but after few > seconds the call is terminated without success. Now is when the FxOS device > shows the message Unable to make a phone call now. What is the expected behavior here? I would assume that it's carrier-dependent. If this is actually a problem, it seems like a different one. It would be helpful to know what non-FxOS devices do in this case, as well. In general, I'm not sure what help UX can provide here. If this is indeed region/carrier-specific, then it's not really a UX decision, unless we want to override this behavior for some reason. Though I agree that the message that we're presenting to the user in the second case seems weird and out of place.

I'm changing this to unconfirmed. We need an exact STR that you can confirm is broken (i.e. results in unexpected functionality that we all agree on), even if we can't repro it ourselves.

If this is carrier dependent, then it's really difficult to provide the expected behavior here. However, I think the string doesn't illustrate the problem correctly. Can I have more details on the exact problem here? Thanks!

(In reply to Carrie Wang [:carrie] from comment #12) > If this is carrier dependent, then it's really difficult to provide the > expected behavior here. However, I think the string doesn't illustrate the > problem correctly. Can I have more details on the exact problem here? Thanks! Carrie, The error message came from operator/modem. In this case, all information we got is "UnspecifiedError" It's really hard for us to tell the accurate reason of call disconnection. But maybe you could provide a suggestion for a better wording when 'UnspecifiedError' is received?

NI :brg to help understand if this is a regression in 2.0? What exactly happens in 1.3 and 1.4 under the same scenario?

triage: waiting for beatriz's feedback

Thanks a lot for all the investigations and feedback here. Retesting today with unagi - master -moz ril- Gecko-03ddabe.Gaia-b597b86 (today build) and flame, the voice call is properly placed (although the number does not exist in Spain). This is ok. I guess the bug was caused by any regression becuase latest 1.3 -Gecko-e0bfab9.Gaia-e08beb0 is doing exactly the same as master. Closing as WFM. Thanks. Sorry for my delay.

Removing the nomination per Beatriz's comment