1100706 - [OPEN_C]In venezuela in the use of version, the first use of MMS, after using SMS, don't appear in the same session, but receive a message first, after received the MMS, will appear in the same session.

Status: RESOLVED INCOMPLETE

(Firefox OS Graveyard :: RIL, defect)

Description

[wu.jiabin]

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:33.0) Gecko/20100101 Firefox/33.0
Build ID: 20141113143407

Steps to reproduce:

1.Grab the log and found with 58 number in the beginning, and no with "58" opening number in one session.

2.According to the IP address of the distribution of MMS, we find the corresponding package, see from the TCP dump bag, MMS sender as "58" at the beginning, not in front of the "+".

3.Analysis is number matching problem.


Actual results:

1.In venezuela, receives "+ 58..."Text messages, and then to receive "58..."MMS, this information can be merged into one session.

2.But the first to receive "58..."Text message, and then to receive "+ 58..."Text messages, these messages will not be merged into one session


Expected results:

1.Normal receive SMS and MMS, and with the network in the region, "58...", no matter which first receive MMS and SMS, and join into the same session.

Comment 1

[Rachelle Yang [:ryang][[e-mail]]]

Hi Steve, would you please kindly help us if this is current design on 2.0, 2.1?

or is this a known bug?  Thank you very much !

Comment 2

[Rachelle Yang [:ryang][[e-mail]]]

Hi Jiabin,
could you please kindly provide more details on the SW build you are using ? 
such as is it tested on 2.0 , 2.1 ? and build ID, git commit info.

and please provide the log for our further investigation. Thank you very much!

Comment 3

[wu.jiabin]

Today Open C B09 version found a fault, receive certain number sent by MMS movistar network, the network side first 0 will become the number 58 (58) is become before met +, lead to receive MMS number not matching, and contacts after the number of SMS sent because box cannot match the same session;If you receive SMS again without receiving MMS, no problem.

Comment 4

[wu.jiabin]

Found the problem when we run on version 1.3

Comment 5

[Steve Chung [:steveck]]

(In reply to wu.jiabin from comment #3)
> Today Open C B09 version found a fault, receive certain number sent by MMS
> movistar network, the network side first 0 will become the number 58 (58) is
> become before met +, lead to receive MMS number not matching, and contacts
> after the number of SMS sent because box cannot match the same session;If
> you receive SMS again without receiving MMS, no problem.

Hi, I'm not sure I could totally understand your description. It seems the message comes from movistar will apply the country code, and this thread with international number does not combine with the the thread without country code prefix. I think we already handled this case. Is only reproducible in movistar, or other operator could reproduce it as well? Could you please upload a video about this issue for more information? Thanks!

Comment 6

[Julien Wajsberg [:julienw] (PTO -> Aug 14)]

Anyway, merging threads happens in Gecko. Maybe Bevis would know.

Comment 7

[Rachelle Yang [:ryang][[e-mail]]]

Hi Bevis, would you please kindly help look into this ? 
Thank you very much !

Comment 8

[Bevis Tseng[:bevis][:btseng](Exited)]

(In reply to Rachelle Yang [:ryang][[e-mail]] from comment #7)
> Hi Bevis, would you please kindly help look into this ? 
> Thank you very much !

1.3v is end of life.
Is it still reproducible in 2.1 or even in m-c branch?
If yes, please help to collect both adb logcat by the instruction below for main/radio logs and tcpdump for further analysis:
https://github.com/bevis-tseng/Debug_Tools

Thanks!

Comment 9

[Rachelle Yang [:ryang][[e-mail]]]

Hi Jiabin, would you please test the same scenario on FFOX 2.1 or 2.2? Thanks!
and if the issue still happened, kindly get needed logs per comment8.

Comment 10

[wu.jiabin]

Attachment: Desktop.zip

Comment 11

[Bevis Tseng[:bevis][:btseng](Exited)]

Hi,

The attachment didn't contain any log regarding MMS.
There are only 6 SMS from either 909 or [phone].
I cannot find too much information to the symptom of this bug.

From the issue description, the symptom only happens by the following test steps:
1. Receive a MMS from "58xxx".
2. Receive a SMS from "+58xxx".

In addition, we still didn't know which FFOS version did you test.

Hence, set NI to reporter again to:
1. Provide the correct FFOS version for clarification.
2. Capture main/radio logcat with debug flags enabled (https://github.com/bevis-tseng/Debug_Tools):
   - Please download and run the script of |enable_debug_flags.sh| before capturing the logs.
3. Capture the tcpdump of the MMS transaction.
   - Please follow the steps in the Debug_Tools link above to capture the tcpdump from the device.

Thanks!

Comment 12

[wu.jiabin]

Attachment: 2014-11-13-21-04-17.zip

Comment 13

[Bevis Tseng[:bevis][:btseng](Exited)]

I can not reproduce this symptom locally in v2.0, v2.1, m-c:
1. Receive a MMS from |584242049433|, then Receive a SMS from |[phone]|. 
   (Messages are combined into the same thread.)
2. Receive a SMS from |[phone]|, then Receive a MMS from |584242049433|. 
   (Messages are combined into the same thread.)

Set NI to reporter again to know which FFOS version was tested by reporter.

Comment 14

[chencong]

The FFOS version of reporter is v1.3.
gaia commit:667539f1ed4becc45b182a5f1046221d3eeb9e7c
gecko commit:1de6e0346b7a2f3854427b4d75d350bf98334d16

Comment 15

[Bevis Tseng[:bevis][:btseng](Exited)]

(In reply to Bevis Tseng [:bevistseng] ([e-mail]) from comment #13)
> I can not reproduce this symptom locally in v2.0, v2.1, m-c:
> 1. Receive a MMS from |584242049433|, then Receive a SMS from
> |[phone]|. 
>    (Messages are combined into the same thread.)
> 2. Receive a SMS from |[phone]|, then Receive a MMS from
> |584242049433|. 
>    (Messages are combined into the same thread.)
> 

I am now able to reproduce this with emulator even in m-c branch if I hard code the mcc to "734".
Need to figure out how these numbers were parsed by PhoneNumberUtils.jsm [1] when country code is taken into consideration.

[1] http://dxr.mozilla.org/mozilla-central/source/dom/phonenumberutils/PhoneNumberUtils.jsm

Comment 16

[wu.jiabin]

Attachment: LOGS.zip

Comment 17

[Joshua Mitchell (Inactive)]

comments 13-15 seem to satisfy the qa-wanted request - removing tag

Comment 18

[Bevis Tseng[:bevis][:btseng](Exited)]

Attachment: [Screenshot v1.3] Not reproducible in v1.3

Not reproducible in v1.3 on emulator with the same PDU captured from the log in comment 16.

Comment 19

[Bevis Tseng[:bevis][:btseng](Exited)]

Attachment: [Screenshot m-c] Not reproducible in m-c

Not reproducible in master branch on emulator with the same PDUs captured from the logs in comment 16.

Comment 20

[Bevis Tseng[:bevis][:btseng](Exited)]

Attachment: Patch to Fake MCC/MNC of the test network in the Emulator.

Comment 21

[Bevis Tseng[:bevis][:btseng](Exited)]

Sorry for late update because I was busy in other v2.2 stuff recently:
1. First of all, I have to apologize that I am not able to reproduce what I have seen in comment 15 
   anymore with fake mcc, no mater in v1.3, v2.0, v2.1, m-c. :(
   (See screenshots in comment 18 and comment 19.)
2. Because it's not reproducible in the environment we have, I'd like to share how I reproduced the
   symptom here for vendor to compare what's the difference in their ROM build and the test env:
   a. Apply the patch in comment 20 to the B2G emulator to fake the carrier info (mncmcc).
   b. After Emulator boot-up, turn off "Auto Retrieve" in the Settings. 
     (This will be more easier to identify the incoming MMS because it is not possible to retrieve 
      the MMS from carrier with emulator.)
   c. '> telnet localhost 5554 'to connect to the emulator.
   d. '> sms pdu <raw pdu>' to fake the incoming SMS to the emulator.
      You can replace the <raw pdu> to [1] for MMS notification and to [2] for the incoming SMS, where [1] includes the sender address of "584242049433" and [2] includes the sender address of "[phone]".

3. The logic of how phone numbers are parsed is in [3] and the logic of how the phone numbers are matched is in [4].

set NI to vendor to see if they could do more comparison of the behaviors between their ROM build and what I saw via the emulator mentioned above.

[1] 079185240400904544038109F9220441118261526289880605040B840000000607BEAF848DF7B4818C82984145794E627778635A496A766F79464D56008D908918803538343234323034393433332F545950453D504C4D4E008A808E02603D88058103016D9F83687474703A2F2F6D6D73322E6D6F7669737461722E636F6D2E76653A383038382F6D6D732F3F4145794E627778635A496A766F79464D5600
[2] 0791852404009045040C9185242440493300004111826103108905C142FA0D02
[3] http://hg.mozilla.org/releases/mozilla-b2g28_v1_3/file/b606d95b4011/dom/phonenumberutils/PhoneNumberUtils.jsm#l96
[4] http://hg.mozilla.org/releases/mozilla-b2g28_v1_3/file/b606d95b4011/dom/mobilemessage/src/gonk/MobileMessageDatabaseService.js#l1304

Comment 22

[Bevis Tseng[:bevis][:btseng](Exited)]

no further clue for analysis on this bug.