Closed Bug 1060702 Opened 5 years ago Closed 5 years ago

[SMS] MMS messages received on roaming sim continuiously download message

Categories

(Firefox OS Graveyard :: RIL, defect)

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(b2g-v1.4 affected, b2g-v2.0 affected, b2g-v2.1 affected)

RESOLVED INVALID
Tracking Status
b2g-v1.4 --- affected
b2g-v2.0 --- affected
b2g-v2.1 --- affected

People

(Reporter: jdegeus, Unassigned)

References

()

Details

(Whiteboard: [2.1-flame-test-run-1])

Attachments

(6 files)

Description:
When users are using a international roaming sim card to receive a MMS, the users will receive the MMS however the message will continiously sit on downloading message. If the user receives a message with a subject/title, users will see the title/subject displayed, however the message just continously download. 

Setup:
Have 2 devices, 1 device with a US based sim and 1 device with a international sim such as a Taiwan based sim

Device 1: Taiwan based sim
Device 2: US Based sim

Repro Steps:
1) Update a Flame to 20140828040204
2) Device 1: With International Sim enter Settings
	a) Select Messaging Settings> Set Auto Retrieve to "On with roaming"
	b) Select Back> Cellular & Data> Sim 1> Data Roaming enabled
	a) To send out of the USA to the Taiwan based sim enter +8669(XXX)-XXXXX
3) Device 2: Select Messages> New Message> Attach a image or add a subject
4) Device 1: Observe MMS is received but continiously sits on downloading MMS

Actual:
MMS messages received on roaming sim continiously download message

Expected:
MMS messages download successfully

Environmental Variables:
Device: Flame Master (319mb)
Build ID: 20140828040204
Gaia: 3a838afca295c9db32e1a3ec76d49fb7fe7fd2d2
Gecko: 3be45b58fc47
Version: 34.0a1 (Master)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Repro frequency: 3/3
Link to failed test case: https://moztrap.mozilla.org/manage/case/8258/
See attached: Logcat and youtube attached
This issue DOES OCCUR on Open C 2.0, Open C 1.4, Flame 2.1 (512mb), Flame 2.0 (319mb), Flame 1.4 (319mb)

Actual: MMS continously sits on downloading message

Flame 2.1

Environmental Variables:
Device: Flame Master (512mb)
Build ID: 20140829040202
Gaia: 007f3c50cf69f044628a23c2376c6d88aa45f617
Gecko: d697d649c765
Version: 34.0a1 (Master)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Flame 2.0

Environmental Variables:
Device: Flame 2.0 (319mb)
BuildID: 20140829000203
Gaia: 5bf3b8cdea15e62ce7bf77a15085a18e24e33c44
Gecko: 5bcf98ed9885
Version: 32.0 (2.0)
Firmware: v123
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Flame 1.4

Environmental Variables:
Device: Flame 1.4 (319mb)
Build ID: 20140829063010
Gaia: d6a1e9366dfcf9dd3d84661338996cb36b9a7e00
Gecko: 6de69ed3c146
Version: 30.0 (1.4)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Open C 2.0

Environmental Variables:
Device: Open_C 2.0
BuildID: 20140829000203
Gaia: 5bf3b8cdea15e62ce7bf77a15085a18e24e33c44
Gecko: 5bcf98ed9885
Version: 32.0 (2.0)
Firmware: v123
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Open C 1.4

Environmental Variables:
Device: Open_C 1.4
BuildID: 20140829063010
Gaia: d6a1e9366dfcf9dd3d84661338996cb36b9a7e00
Gecko: 6de69ed3c146
Version: 30.0 (1.4)
Firmware: P821A10v1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0


----------------------------------------------------------------

Open 2.1 devices never received MMS messages therefore i am unsure if this issue occurs on Open C 2.1

Open C 2.1

Environmental Variables:
Device: Open_C Master
Build ID: 20140829040202
Gaia: 007f3c50cf69f044628a23c2376c6d88aa45f617
Gecko: d697d649c765
Version: 34.0a1 (Master)
Firmware Version: P821A10V1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?]
Set NI 
1 to clarify if its a regression to bug 1057973. Where MMS is not able to download if APN is shared for both internet and MMS.
2. It seems that the debug flag was not enabled during capturing the log. Can we have logcat & tcpdump again with the steps in the following link:
https://github.com/bevis-tseng/Debug_Tools

Thanks!
Component: Gaia::SMS → RIL
Attached file capture.pcap
Attached file logcat.txt
Attached new logcat & tcpdump. 

Forgot to attach a youtube video of the issue: http://youtu.be/xGOufhUjMKE
Thanks for capturing the log.
After checking the error cause of setting up data call we got an error "ServiceOptionNotSubscribedError".

It seems that the test SIM didn't subscribe a data call plan.
Can we double confirm this?

If yes, it will be nice to have this check as part of the pre-condition in this test case. :)

Thanks!
I'm pretty sure the roaming SIM had an active data calling plan when this issue was written up but I will let the reporter double check this. Please check this Jordan.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage-]
Flags: needinfo?(ktucker) → needinfo?(jdegeus)
We can also checking this with other reference phone with the same test SIM if needed. :)
(In reply to Bevis Tseng [:bevistseng] (btseng@mozilla.com) from comment #8)
> We can also checking this with other reference phone with the same test SIM
> if needed. :)

In addition, the MMS of this test SIM goes with different APN named "emome" than default data "internet".
So the condition might be different if you have default data plan but not the MMS data plan.
Attached file capture.pcap
I have been able to browse the web on 3G while WiFi was disabled however I still am unable to send/receive MMS's on multiple devices.

Here are the following settings for both Data and MMS:

Data:
APN: internet
Identifier: [blank]
Password: [blank]
HTTP proxy host: [blank]
HTTP proxy port: [blank]
MMS proxy: [blank]
MMS port: [blank]
MMSC: [blank]
Authentication: [Not defined]
APN Type: default
Protocol: Not defined
Roaming protocol: Not defined

MMS Settings:
APN: emome
Identifier: [blank]
Password: [blank]
HTTP proxy host: [blank]
HTTP proxy port: [blank]
MMS proxy: 10.1.1.1
MMS port: 8080
MMSC: http://mms.emome.net:8002
Authentication: Not defined
APN Type: mms
Protocol: Not defined
Roaming protocol: Not defined
Attached file threadtime_logcat.txt
Attached are new logcats, threadtime logcats and a new TCP dump
Flags: needinfo?(jdegeus) → needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage-] → [QAnalyst-Triage?]
I repro'd this issue using 2 different Flame 2.1 (319mb) as well as a Open C 2.1

Flame 2.1

Environmental Variables:
Device: Flame 2.1
BuildID: 20140910000202 (319mb)
Gaia: 79dc972d637ff5ef7667b231e93118b4ed83ba9c
Gecko: 0890010015a2
Version: 34.0a2 (2.1)
Firmware: V123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Open C 2.1

Environmental Variables:
Device: Open_C 2.1
BuildID: 20140910000202
Gaia: 79dc972d637ff5ef7667b231e93118b4ed83ba9c
Gecko: 0890010015a2
Version: 34.0a2 (2.1)
Firmware Version: P821A10V1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
Can you look into this Linear? Do have a MMS plan on our Emome's SIM with the phone number +886978725132?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker) → needinfo?(nli)
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
Hello, 

Just confirm with carrier provider, as long as the data plan is active, it should be able to send/receive MMS without specific setting. 
Since we have active data plan already, no MMS plan needed actually.  

Thanks.
Flags: needinfo?(nli)
From the latest attached logs in comment 11 & 12, I still saw the same error "ServiceOptionNotSubscribedError" while setting up "emome" data connection.

Can we test MMS with the same test SIM on other Android/iPhone devices to see if the same symptom happened?
Keywords: qawanted
Flags: needinfo?(jdegeus)
Retesting this issue on a Android device, i was unable to send MMS messages. I was able to send SMS messages without issues.

Is this potentially an issue with our Roaming Sim?
Flags: needinfo?(jdegeus)
Hello, 

Contact with carrier and they reply that if the SIM card can send SMS and also be able to connect to Internet, then it should be able to send MMS messages without any configuration.
(In reply to Linear Li [:nli][moco-tw] from comment #18)
> Hello, 
> 
> Contact with carrier and they reply that if the SIM card can send SMS and
> also be able to connect to Internet, then it should be able to send MMS
> messages without any configuration.

Hi Linear,

By my understanding, for CHT SIM, internet & mms are using different APN settings,
where internet applies "internet" APN and MMS applies "emome" APN.

Sorry, no offense.
I was wondering if carrier provides correct information for this subscriber,
because, from the radio response from the modem in comment 16, we were told that this SIM was not subscribed for emome APN connection and we met the same problem on other reference device as well. :(
(In reply to Bevis Tseng [:bevistseng] (btseng@mozilla.com) from comment #19)
> (In reply to Linear Li [:nli][moco-tw] from comment #18)
> > Hello, 
> > 
> > Contact with carrier and they reply that if the SIM card can send SMS and
> > also be able to connect to Internet, then it should be able to send MMS
> > messages without any configuration.
> 
> Hi Linear,
> 
> By my understanding, for CHT SIM, internet & mms are using different APN
> settings,
> where internet applies "internet" APN and MMS applies "emome" APN.
> 
> Sorry, no offense.
> I was wondering if carrier provides correct information for this subscriber,
> because, from the radio response from the modem in comment 16, we were told
> that this SIM was not subscribed for emome APN connection and we met the
> same problem on other reference device as well. :(

Hi All,

Just double confirmed with Linear & the Customer Service of CHT, the emome 
service was not able to be subscribed for this test SIM because it applied
a mutually exclusive internet data plan.

We'll try to choose a different plan to enable emome and allow MMS service 
to be used on this test SIM. :)
Thanks Bevis for helping to figure out the root cause!

I've applied an new voice plan that could make emome service enable, but sadly the new plan wouldn't be active till 1th Oct CST according to CHT policy.
Please give it a try till then. 
Sorry that you have to wait one more week. :(

Thank you for all your patience.
Hello, 

Sorry for late. It should work now.
Could you please give it a try and let me know how it goes?

Thank you. :)
Flags: needinfo?(jdegeus)
QA Contact: aalldredge
I was unable to reproduce this issue on 2.0 Flame, 2.1 Flame, or 2.2 Flame.

Environmental Variables:
Device: Flame 2.2 Master
BuildID: 20141022133013
Gaia: 27a1d1baaa8e375b70e043efee67d5f2206c330b
Gecko: 7e2fb51abd4b
Version: 36.0a1 (2.2 Master)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

Device: Flame 2.1
BuildID: 20141022081833
Gaia: 734d3547fb6c65e8bc4dd1a52b26f70bdfee7474
Gecko: 9646e94a041c
Version: 34.0 (2.1)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Device: Flame 2.0
BuildID: 20141022081832
Gaia: ec722129a962704fda0dd5f39e7efd01261ae946
Gecko: 52280df0e39f
Version: 32.0 (2.0)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Result:
The MMS messages were downloaded automatically, and completed downloading.
QA Whiteboard: [QAnalyst-Triage+][lead-review+] → [QAnalyst-Triage?][lead-review+]
Flags: needinfo?(jdegeus) → needinfo?(jmitchell)
Keywords: qawanted
All branches were shallow flashed in previous comment.
So now it's working :)

Hey Bevis, just want to understand if this error state is something we could detect and report to the user?
Flags: needinfo?(btseng)
(In reply to Julien Wajsberg [:julienw] from comment #25)
> So now it's working :)
> 
> Hey Bevis, just want to understand if this error state is something we could
> detect and report to the user?

Sorry to say no for now by current design.  :-(

We have file a bug 904514 to enhance the network management.
In which more information about the connection status and the reason why we are not able to established the connection will report to the caller and then, in that case, we could provide more precise information to the user about this.
Flags: needinfo?(btseng)
Filed Bug 1087898 about this.

Closing this bug then.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → INVALID
Flags: needinfo?(jmitchell)
QA Whiteboard: [QAnalyst-Triage?][lead-review+] → [QAnalyst-Triage+][lead-review+]
You need to log in before you can comment on or make changes to this bug.