995897 - [OPEN C_1.3]Set Up Call (Call Set Up) option not working properly

Status: RESOLVED INVALID

(Firefox OS Graveyard :: Vendcom, defect)

Description

[yuhui]

Attachment: 54607 - STK SetupCall.zip

User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.2; Zune 4.7; .NET4.0C; .NET4.0E; Tablet PC 2.0; TCO_20140414110917)

Steps to reproduce:

A.- Overview Description (technical background, concise explanation of the bug):
When we execute this command, the call is stablished but it´s displayed the
text "22404" instead of "llamada 2".
B.- Steps to Reproduce (initial conditions, required resources, step by step
instructions to reproduce):
1. Go to STK, Movistar-->Set up Call-->Set up


Actual results:

C.- Actual Result (current bad behaviour that is reported as a bug):
The handset stablish the call, but it´s displayed the text "22404" (phone
number) instead of "Llamada2".


Expected results:

D.- Expected Result (correct behaviour wished):
When selecting the option Set Up, the application will make a call to 22404
displaying the text “Llamada 2 “

Comment 1

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

Hi Anshul, could you help to find someone to check this one first?

Comment 2

[Anshul]

Nivi, could you please take a look.

Comment 3

[Nivi]

Hi Yuhui,

Could you file an SR for this? Meanwhile I am investigating the issue on our side.

Thanks,
Nivi.

Comment 4

[Nivi]

I looked into the issue. It seems like the logs shared are incomplete. I am seeing certain STK commands in the logs but missing some. For instance, the logs should have a UNSOL_STK_EVENT_NOTIFY and a STK_HANDLE_CALL_SETUP_REQUESTED_FROM_SIM event if set up call command was processed correctly. Could you please collect logs again and send them to us for further analysis.

In addition, I tested set up call and I do see it working correctly as expected. I do see the Call message on the dialer screen.

Let me know if you have any additional questions.

Thanks,
Nivi.

Comment 5

[yuhui]

Dear:

In the proactive command SET_UP_CALL:
IN gstk_find_length_of_length_value() and length_value[0] is 0x8   
alpha[0], 0x4c, L                                                  
alpha[1], 0x6c, l                                                  
alpha[2], 0x61, a                                                  
alpha[3], 0x6d, m                                                  
alpha[4], 0x61, a                                                  
alpha[5], 0x64, d                                                  
alpha[6], 0x61, a                                                  
alpha[7], 0x32, 2                                                  
alpha[8], 0x0,  

Decoded address[0]: 0x2 
Decoded address[1]: 0x2 
Decoded address[2]: 0x4 
Decoded address[3]: 0x0 
Decoded address[4]: 0x4

Now, it is displayed the text "22404" (phone number). We want it is displayed the text  "Llamada2".

Thanks

Comment 6

[Nivi]

Hi Yuhui,

Is the alpha here the second alpha id in the PDU? Can you send me the PDU for the proactive command?
That would be helpful. The spec says the second alpha id is the Call message. If this is the first alpha id, it will be the confirm message showed on confirmation screen. Please confirm.

Also, please send another set of logs and wait for the call to end after set up call to terminate the logs.
That will help greatly. 

Thanks,
Nivi.

Comment 7

[Nivi]

Hi Yuhui,

Could you please file an SR?

Thanks,
Nivi.

Comment 8

[yuhui]

Dear:

In the QXDM log, the APDU is:
980 Jan  6  00:02:10.793  [06]  0x14CE  UIM DS Data
Length     = 125
Block
   --------------------------------------------------
   |   |          |    |Data                        |
   |#  |Type      |Slot|Data|Timestamp              |
   --------------------------------------------------
   |  0|   RX Data|   1|  12|                       |
   |  1|   RX Data|   1|  D0|                       |
   |  2|   RX Data|   1|  19|                       |
   |  3|   RX Data|   1|  81|                       |
   |  4|   RX Data|   1|  03|                       |
   |  5|   RX Data|   1|  01|                       |
   |  6|   RX Data|   1|  10|                       |
   |  7|   RX Data|   1|  00|                       |
   |  8|   RX Data|   1|  82|                       |
   |  9|   RX Data|   1|  02|                       |
   | 10|   RX Data|   1|  81|                       |
   | 11|   RX Data|   1|  83|                       |
   | 12|   RX Data|   1|  06|                       |
   | 13|   RX Data|   1|  04|                       |
   | 14|   RX Data|   1|  81|                       |
   | 15|   RX Data|   1|  22|                       |
   | 16|   RX Data|   1|  04|                       |
   | 17|   RX Data|   1|  F4|                       |
   | 18|   RX Data|   1|  05|                       |
   | 19|   RX Data|   1|  08|                       |
   | 20|   RX Data|   1|  4C|                       |
   | 21|   RX Data|   1|  6C|                       |
   | 22|   RX Data|   1|  61|                       |
   | 23|   RX Data|   1|  6D|                       |
   | 24|   RX Data|   1|  61|                       |
   | 25|   RX Data|   1|  64|                       |
   | 26|   RX Data|   1|  61|                       |
   | 27|   RX Data|   1|  32|                       |
   | 28|   RX Data|   1|  90|                       |
   | 29|   RX Data|   1|  00|                       |
   | 30| Timestamp|   1|    |1601/01/01 00:00:06.467|
   | 31|   TX Data|   1|  80|                       |
   | 32|   TX Data|   1|  F2|                       |
   | 33|   TX Data|   1|  00|                       |
   | 34|   TX Data|   1|  01|                       |
   | 35|   TX Data|   1|  00|                       |
   | 36| Timestamp|   1|    |1601/01/01 00:00:06.472|


Rx0:
***APDU Parsing***
FETCH
Logical Channel: 0
UICC instruction class
CLA - No SM used between terminal and card
Proactive command data: 
  Command Details
    Command Number             : 1
    Command Type               : SET UP CALL
    Command Qualifier          : if not busy on another call
  Device ID
    Source ID                  : SIM
    Destination ID             : network
  Address
    Type of Number             : Unknown
    Numbering Plan ID          : ISDN/telephony
    Dialing Number             : 22404
  Alpha ID (user conf)         : "Llamada2" (SMS alphabet (8bits))
Status Words - 0x90 0x00 - Normal ending of the command

Comment 9

[yuhui]

Attachment: M20140408_133320.7z

File "M20140408_133320.7z" is the QXDM log

Comment 10

[Nivi]

Hi Yuhui,

Thanks for sending the info. This helps.
I am working to figure out what's going on with the new info you provided.
Will let you know.

Thanks,
Nivi.

Comment 11

[Nivi]

Hi Yuhui,

I have one more question for you. I think there is a little bit of contradiction between expected outcome and observed outcome.

If you look in the APDU parsing from comment #8, the data shows - 
Alpha ID (user conf)         : "Llamada2" (SMS alphabet (8bits)).

So this string is being treated as the user confirmation message which is the correct behavior you are seeing currently. The specs (TS 11.14 section 6.4.13	SET UP CALL) suggest that the first alpha identifier is the user confirmation message and the second alpha identifier is the call message but the PDU that you sent us has only one alpha id. So we are doing the right thing here.

I verified against Android code and they do the same as us.

Could you please tell us how you are deriving the expected outcome? Is it from a spec or some requirement? 
Please let us know.

Thanks,
Nivi.

Comment 12

[Fernando R. Sela (no CC, needinfo please) [:frsela]]

We're not sure if this can be affected by the bug 1031227

Can you enable debug traces for SystemMessages module in gecko (dom/messages/*.js* files) and upload the results here or into the bug 1031227

Thanks in advance.

Comment 13

[Juanjo Iglesias]

Bug checked with buri master build (comm ril) and unagi master and 1.3 build (ref ril) having different results. Please see below and logcat attached.

Buri master build 01/07 (comm ril):
gecko 59acc6, gaia 505008f

Using the corresponding STK sim card, when going to STK, Movistar-->Set up Call-->Set up, the device shows: Llamada 2, but nothing happens when tapping on it. Screenshot and adb log attached

Unagi master build 01/07 and 1.3 (ref ril): 
Master:gecko d7320fc, gaia  505008f
1.3: gecko 1840602, gaia  e5f7bbd

When going to STK, Movistar-->Set up Call-->Set up, the dialer is open showing as the caller the number 22404. Please see logcat attached

Both results are wrong, as described in the expected in comment #0, the device should make the call  to number 22404 but showing Llamada 2 in the attention screen instead of the number directly.

Comment 14

[Juanjo Iglesias]

Attachment: Hamachi Master Llamada2.png

Comment 15

[Juanjo Iglesias]

Attachment: Hamachi_Master.txt

Comment 16

[Juanjo Iglesias]

Attachment: Unagi-master.txt

Comment 17

[Fernando R. Sela (no CC, needinfo please) [:frsela]]

I saw a resultCode 0x10 (STK_RESULT_UICC_SESSION_TERM_BY_USER) !
probably because you didn't pressed the OK button

The screenshot doesn't shows you the buttons. This was fixed here [1][2] because KeyboardManager changed and now returns the same if the keyboard is hidden or not.
But this patch is not landed yet (I'm waiting review)

Can you test with this other patch applied to verify when you press the correct button?

Thanks in advance.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1028789
[2] https://github.com/mozilla-b2g/gaia/pull/21177/files#diff-7b4cd981b7b9c4669c33a8cecd441af2R256

Comment 18

[Fernando R. Sela (no CC, needinfo please) [:frsela]]

Hi,

We suspect this bug could be caused by other ones fixed bug 1031227 and bug 1028789

Can you test again with the last master branch?

Thanks in advance

Comment 19

[Beatriz Rodríguez [:brg]]

Unfortunately, we need to book lab resources to make this test. We will do our best to test it soon. Please let us know which should be the branch/patches/logs needed so we can fix it in one session :-)

Comment 20

[Salvador de la Puente González [:salva]]

Attachment: [WIP] Avoid a potential race condition.

The patch touches the system to avoid a race condition between the callscreen reading a non already set iccmessage setting and while the STK is still working.

It adds some traces as well in such a way the tester can enable Gaia debug traces from the developer menu and the logs can be retrieved via logcat.

I've touched the dump utililty as well to display where is the DUMP call. As you, Fernando, created the utility, I leave the enhancement in this patch to ease the debugging and testing but I think is better to remove once we verify the patch works and open a separated bug for that.

WDYT?

Thank you!

Comment 21

[Fernando R. Sela (no CC, needinfo please) [:frsela]]

Comment on attachment 8462521 [details] [review]
[WIP] Avoid a potential race condition.

Thank you Salva, nice proposal.

Really is better your method (answer the SIM after the second alpha is stored.

Regarding the DUMP function improve, I love it ;) - Hope this method will be used along all gaia ;)

Finally, I think for STK is better to leave the DUMP traces after land since this is a difficult to debug functionality so all information we've is welcome.

Comment 22

[Salvador de la Puente González [:salva]]

According to recent logs in Gaia, the command being received by System app with the Set Up Call parameters does not include the `callMessage` field. As said in comment #11, all point to the STK command not including this field. I'm not totally sure if displaying the first alpha instead of the second is the right thing to do here. I'm going to close the bug as invalid.

Let's reopen if, ensuring an STK command with 2nd alpha, it is not displayed in the dialer.