[zffos1.1][P2][MMS] The DuT does not support size of 500 KB for MMS for one fo the mcc/mnc of Mexico operator

RESOLVED FIXED

Status

Firefox OS
Gaia::SMS
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: FangChen, Assigned: jaoo)

Tracking

unspecified
ARM
Gonk (Firefox OS)

Firefox Tracking Flags

(blocking-b2g:leo+, b2g18 fixed, b2g-v1.1hd fixed)

Details

(Whiteboard: khepera_48414 )

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
Built ID 20130823171628
Device: Ikura
QC RIL version: "ro.build.firmware_revision=V1.01.00.01.019.180"
gaia commit: 4916f82 Merge branch 'zte/ics_strawberry_cdr' of ssh://10.67.16.41:29418/quic/lf/releases/gaia into ics_strawberry_cdr
gecko commit: a1c2bb0 ZRL modify ACCEPT Http head for MMS

  A.- Overview Description (technical background, concise explanation of the bug):
    
    The DuT does not support size of 500 KB for MMS, according to Annex 059
    ________________________________________________________________________________
    B.- Steps to Reproduce (initial conditions, required resources, step by step instructions to reproduce):
    
    1.- Insert the SIM of Mexico
    2.- Go to Messages and create a new MMS
    3.- Attach a file more than 300 KB 
    4.- Check the message.
    ________________________________________________________________________________
    C.- Actual Result (current bad behaviour that is reported as a bug):
    
    When a file of more than 300 KB is attached, the DuT displays the next message: "The file you have selected is too large"
    ________________________________________________________________________________
    D.- Expected Result (correct behaviour wished):
    
    For MX the maximum size for MMS is of 500 KB according to annex 059
(Reporter)

Comment 1

5 years ago
according to ANNEX 59 from Telefonica,if the device support OMA, Multimedia Messaging Service versión 1.3,the maxsize of MMS will be different for every country as the following
Argentina: 600K
Chile: 300K
Colombia: 600K
Costa Rica: 300K
Ecuador: 600K 
El Salvador: 300K
Guatemala: 300K
México: 500K
Nicaragua: 300K
Panamá: 300K
Perú: 600K
Venezuela: 300K
Uruguay: 1024K
What I see in the APN.json file (https://github.com/mozilla-b2g/gaia/blob/v1-train/shared/resources/apn.json#L1008)is that the max size for Mexico is set to 512000 (I assume this is Bytes, not bits), so, as I understand it, it should be OK --> jaoo, am I right?

Fang Chen, could you please try to test these 3 cases: 
- Attaching a < 300K file
- Attaching a file > 300K but < 500K
- Attaching a file > 500K
Flags: needinfo?(josea.olivera)
Flags: needinfo?(fang.chen1)
(In reply to Juan Perez-Bedmar [:juanpbf]  - Back from holidays from comment #2)
> What I see in the APN.json file
> (https://github.com/mozilla-b2g/gaia/blob/v1-train/shared/resources/apn.
> json#L1008)is that the max size for Mexico is set to 512000 (I assume this
> is Bytes, not bits), so, as I understand it, it should be OK --> jaoo, am I
> right?
> 
I worked with Corey when he implemented it in bug 886757. The default value is 300K and only when this value change... we put a different value in bytes: 500kB --> 512000Bytes.

Adding some colleagues from the commercial RIL in case they were not aware of this implementation and can help here.

Nominating to leo because this issue is blocking the certification in latam region.
blocking-b2g: --- → leo?
Flags: needinfo?(josea.olivera) → needinfo?(anshulj)
Whiteboard: khepera_48414

Comment 4

5 years ago
Hello Beatriz, no work needed in commercial RIL for this issue as of now.
Flags: needinfo?(anshulj)
(Reporter)

Comment 5

5 years ago
our colleague has check this issue in lab,we found some problems ,according to ANNEX 59,MCC&MNC should be 334 03,but some comercial sim of Mexico has the MCC&MNC 334 030,we found in the lab,if the MCC &MNC is 334 03,the maxium size of MMS is 500k,but if the MCC&MNC is 334 030 ,the maxium size is only 300K.so I suggest add the 334 030 to the list of the MCC & MNC for Mexico
Flags: needinfo?(fang.chen1)

Updated

5 years ago
Whiteboard: khepera_48414 → khepera_48414 [POVB]
Minus since POVB
blocking-b2g: leo? → -
Hi, as agreed in the skype, we should include this change in the apn.json official file so any partner will have this parameter properly included and avoid certification issues from each OEM.
IMHO, this is not part of the Vendor work although they can modify this file as they need.
Changing the flags according to the comment.
blocking-b2g: - → leo?
Whiteboard: khepera_48414 [POVB] → khepera_48414

Comment 8

5 years ago
Hi Beatriz,

I suggest not putting this in the Moz repository since it is not common for all vendors. OEM Partner has worked on APN configuration since v1.1 and the overlapped work may mess up the configurations. I suggest pass this to ZTE for the modification for v1.1. Per our discussion, I said I will check with OEM partner to include this modification.
(Reporter)

Comment 9

5 years ago
this issue has been modified and verified in our lab,thanks all
Status: UNCONFIRMED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INVALID
Beatriz, Ivan, I really think like Beatriz here: we hsould have a correct apn.json in Mozilla's repository...

I don't see how this is vendor-dependant, it seems to me that it is rather carrier-dependant.
Flags: needinfo?(brg)

Comment 11

5 years ago
(In reply to Julien Wajsberg [:julienw] from comment #10)
> Beatriz, Ivan, I really think like Beatriz here: we hsould have a correct
> apn.json in Mozilla's repository...
> 
> I don't see how this is vendor-dependant, it seems to me that it is rather
> carrier-dependant.

Wajsberg, thank you for the comments. The "correct apn.json" you mentioned here is to include all carrier's setting in the future? So we will have more and more entries for different carriers in the APN.json in our repository? Is that what you mean?
Flags: needinfo?(felash)
(In reply to Julien Wajsberg [:julienw] from comment #10)
> Beatriz, Ivan, I really think like Beatriz here: we hsould have a correct
> apn.json in Mozilla's repository...
> 
> I don't see how this is vendor-dependant, it seems to me that it is rather
> carrier-dependant.
Julien you are right, this is not vendor-dependat. If we had a good repository we will save time in the future because all OEM will have the suitable parameters, even if they want to modify them because of any other reason.
This change will help to shorten TA process.
I would like to re-open this issue and nominate it to leo?
Status: RESOLVED → REOPENED
Ever confirmed: true
Flags: needinfo?(brg)
Resolution: INVALID → ---
Summary: [zffos1.1][P2][MMS](The DuT does not support size of 500 KB for MMS, according to Annex 059 → [zffos1.1][P2][MMS] The DuT does not support size of 500 KB for MMS for one fo the mcc/mnc of Mexico operator
Created attachment 800056 [details] [diff] [review]
911874.patch

Kaze, sadly Mexico have a couple of valid pair of MCC MNC codes and we only set the value of the operator size limit for MMS in bug 886757 for one of them. This bug add this size limit for the another pair of MCC MNC for Mexico. The change is quite easy, could you take a look please? Thanks.
Assignee: nobody → josea.olivera
Attachment #800056 - Flags: review?(kaze)
Even without thinking of OEM, I think a user that takes our source and build it himself and flash it should have a working phone in the end.
Flags: needinfo?(felash)
leo+ as it is a cert issue.
Preeti, you didn't set the leo+ flag.
Flags: needinfo?(praghunath)
Attachment #800056 - Flags: review?(kaze) → review+
master: https://github.com/mozilla-b2g/gaia/commit/f99ee54d9b8a5b182a987ff012e690f1269ecb43
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago5 years ago
Resolution: --- → FIXED
blocking-b2g: leo? → leo+
(Assignee)

Updated

5 years ago
status-b2g18: --- → affected
status-b2g-v1.1hd: --- → affected
Sorry about it. Since it is leo+ will leave it.
Flags: needinfo?(praghunath)
Uplifted f99ee54d9b8a5b182a987ff012e690f1269ecb43 to:
v1-train: 7b467f54bb6ff2abb240c5166b598bf424c67298
status-b2g18: affected → fixed
v1.1.0hd: 7b467f54bb6ff2abb240c5166b598bf424c67298
status-b2g-v1.1hd: affected → fixed
You need to log in before you can comment on or make changes to this bug.