DEFECT DESCRIPTION: The MMS can't be received by the phone, i have done several test but al the test fail. But the MMs can be sent by the phone. Video link: https://copy.com/bnGz2XPzD7t1C3fD REPRODUCING PROCEDURES: 1.Insert orange SIM,open the data roaming. 2.Create a MMS,then send it to self. 3.The MMS can be sent, but can't receive it.----KO P.S. 1. I found the MMS APN from network log same as other phone. For example PIXI3-35, and it can send and receive the MMS when insert the same orange SIM card. 2. I insert local China mobile SIM, and the China mobile SIM can send and recieve the MMS.

Can you please test if this works with another device (Android) ?

Hi reporter, After further analysis of the received SMS PDU which contains a MMS notification, I found that this shall be an issue in carrier side instead: 1. the value of originator ports in the SMS PDU was set to 61341. 2. According to |9.2.3.24.4 Application Port Addressing 16 bit address| in 3GPP TS 23.040, the application port in range of |49152 – 65535| and are reserved for future allocation. In addition, in |9.2.3.24.4 Application Port Addressing 16 bit address|: " A receiving entity shall ignore (i.e. skip over and commence processing at the next information element) any information element where the value of the Information-Element-Data is Reserved or not supported. " That's the reason why these ports are ignored by our implmentation. [1] I'd like to suggest to have Orange's help to check why the originating port filled by MMSC is illegal according to the 3GPP standard mentioned above. Thanks! [1] https://hg.mozilla.org/mozilla-central/file/5b625f3f1fe5/dom/system/gonk/ril_worker.js#l5799

Update the header information of the decoded PDU for your reference: 07913386094000F0 SMSC 44 1st octet of SMS-TPDU 05850286F0 Originator Address 00 PID F5 DCS 51206030853040 TIMESTAMP 80 UDL 06 UDHL 05040B84EF9D IEI: 16-bit IEI_APPLICATION_PORT_ADDRESSING_SCHEME_16BIT: destinationPort: 2948, originatorPort: 61341

(In reply to comment #1) > Comment from Mozilla:Can you please test if this works with another device > (Android) ? PIXI3-35 is an Andorid device, and it can send and receive MMS when insert the same Orange SIM as I said at comment #0. Thanks!

Question in comment 1 is answered in comment 11.

NI reporter for the problem we found in carrier side in comment 9.

Created an attachment (id=1159112) PIXI34 mtklog.rar (In reply to comment #13) > Comment from Mozilla:NI reporter for the problem we found in carrier side in > comment 9. Sorry, but the Android device Pixi3-4 could send and receive the MMS. The attachment is the mtklog of Pixi3-4. Could you have a look.

Created an attachment (id=1159112) PIXI34 mtklog.rar (In reply to comment #13) > Comment from Mozilla:NI reporter for the problem we found in carrier side in > comment 9. Sorry, but the Android device Pixi3-4 could send and receive the MMS. The attachment is the mtklog of Pixi3-4. Could you have a look.

Created an attachment (id=1159112) PIXI34 mtklog.rar (In reply to comment #13) > Comment from Mozilla:NI reporter for the problem we found in carrier side in > comment 9. Sorry, but the Android device Pixi3-4 could send and receive the MMS. The attachment is the mtklog of Pixi3-4. Could you have a look.

Yes, we know Android & iPhone does, but the root cause is clearly: They both didn't follow the specification mentioned in comment 9. You can remove the check in the ril_worker mentioned in comment 9. The MMS shall be received without problem. It will be nice to let carrier get notice of this instead of working around it.

Created an attachment (id=1159112) PIXI34 mtklog.rar (In reply to comment #13) > Comment from Mozilla:NI reporter for the problem we found in carrier side in > comment 9. Sorry, but the Android device Pixi3-4 could send and receive the MMS. The attachment is the mtklog of Pixi3-4. Could you have a look.

Created an attachment (id=1159112) PIXI34 mtklog.rar (In reply to comment #13) > Comment from Mozilla:NI reporter for the problem we found in carrier side in > comment 9. Sorry, but the Android device Pixi3-4 could send and receive the MMS. The attachment is the mtklog of Pixi3-4. Could you have a look.

Created an attachment (id=1159112) PIXI34 mtklog.rar (In reply to comment #13) > Comment from Mozilla:NI reporter for the problem we found in carrier side in > comment 9. Sorry, but the Android device Pixi3-4 could send and receive the MMS. The attachment is the mtklog of Pixi3-4. Could you have a look.

(In reply to sync-1 from comment #20) > Created attachment 8561808 [details] > PIXI34 mtklog.rar > > Created an attachment (id=1159112) > PIXI34 mtklog.rar > > (In reply to comment #13) > > Comment from Mozilla:NI reporter for the problem we found in carrier side > in > > comment 9. > > Sorry, but the Android device Pixi3-4 could send and receive the MMS. > > The attachment is the mtklog of Pixi3-4. Could you have a look. Please see my answer in comment 17.

(In reply to comment #17) > Comment from Mozilla:Yes, we know Android & iPhone does, but > the root cause is clearly: They both didn't follow the specification mentioned > in comment 9. > You can remove the check in the ril_worker mentioned in comment 9. > The MMS shall be received without problem. I change the code like below, is that right? diff --git a/dom/system/gonk/ril_worker.js b/dom/system/gonk/ril_worker.js index df286e8..6a38541 100644 --- a/dom/system/gonk/ril_worker.js +++ b/dom/system/gonk/ril_worker.js @@ -8007,11 +8007,8 @@ GsmPDUHelperObject.prototype = { // 3GPP TS 23.040 clause 9.2.3.24.4: "A receiving entity shall // ignore any information element where the value of the // Information-Element-Data is Reserved or not supported" - if ((dstp < PDU_APA_VALID_16BIT_PORTS) - && (orip < PDU_APA_VALID_16BIT_PORTS)) { header.destinationPort = dstp; header.originatorPort = orip; - } break; } case PDU_IEI_CONCATENATED_SHORT_MESSAGES_16BIT: { > It will be nice to let carrier get notice of this instead of working around it.

(In reply to sync-1 from comment #22) > (In reply to comment #17) > > Comment from Mozilla:Yes, we know Android & iPhone does, but > > the root cause is clearly: They both didn't follow the specification > mentioned > > in comment 9. > > You can remove the check in the ril_worker mentioned in comment 9. > > The MMS shall be received without problem. > > I change the code like below, is that right? > > diff --git a/dom/system/gonk/ril_worker.js b/dom/system/gonk/ril_worker.js > index df286e8..6a38541 100644 > --- a/dom/system/gonk/ril_worker.js > +++ b/dom/system/gonk/ril_worker.js > @@ -8007,11 +8007,8 @@ GsmPDUHelperObject.prototype = { > // 3GPP TS 23.040 clause 9.2.3.24.4: "A receiving entity shall > // ignore any information element where the value of the > // Information-Element-Data is Reserved or not supported" > - if ((dstp < PDU_APA_VALID_16BIT_PORTS) > - && (orip < PDU_APA_VALID_16BIT_PORTS)) { > header.destinationPort = dstp; > header.originatorPort = orip; > - } > break; > } > case PDU_IEI_CONCATENATED_SHORT_MESSAGES_16BIT: { > > > > > > > It will be nice to let carrier get notice of this instead of working > around it. Yes!

This is _not_ povb. This is "part of carrier". Dear TCL, will you please report the issue to Orange ?

(In reply to comment #24) > Comment from Mozilla:This is _not_ povb. This is "part of carrier". > Dear TCL, will you please report the issue to Orange ? I don't know yet. I already pass it to Dengwei and waiting he answer. Thanks!

Hi Julien, DengWei is PM of TCL. I will sync up with him about this issue and update later. Thanks!

After talk with Dengwei & Feiyan, I had pass it to CTS and they will report the issue to Orange. Thanks!

Dear Dengwei, This issue has been resolved. The solution is remove the check in ril_worker: diff --git a/dom/system/gonk/ril_worker.js b/dom/system/gonk/ril_worker.js index df286e8..6a38541 100644 --- a/dom/system/gonk/ril_worker.js +++ b/dom/system/gonk/ril_worker.js @@ -8007,11 +8007,8 @@ GsmPDUHelperObject.prototype = { // 3GPP TS 23.040 clause 9.2.3.24.4: "A receiving entity shall // ignore any information element where the value of the // Information-Element-Data is Reserved or not supported" - if ((dstp < PDU_APA_VALID_16BIT_PORTS) - && (orip < PDU_APA_VALID_16BIT_PORTS)) { header.destinationPort = dstp; header.originatorPort = orip; - } break; } case PDU_IEI_CONCATENATED_SHORT_MESSAGES_16BIT: { Please close this bug. Thanks!

(In reply to sync-1 from comment #28) > Dear Dengwei, > > This issue has been resolved. The solution is remove the check in > ril_worker: Hi, I wouldn't say this is a solution but a evidence to prove that there is some problem in server side as mentioned in comment 9. > > diff --git a/dom/system/gonk/ril_worker.js b/dom/system/gonk/ril_worker.js > index df286e8..6a38541 100644 > --- a/dom/system/gonk/ril_worker.js > +++ b/dom/system/gonk/ril_worker.js > @@ -8007,11 +8007,8 @@ GsmPDUHelperObject.prototype = { > // 3GPP TS 23.040 clause 9.2.3.24.4: "A receiving entity shall > // ignore any information element where the value of the > // Information-Element-Data is Reserved or not supported" > - if ((dstp < PDU_APA_VALID_16BIT_PORTS) > - && (orip < PDU_APA_VALID_16BIT_PORTS)) { > header.destinationPort = dstp; > header.originatorPort = orip; > - } > break; > } > case PDU_IEI_CONCATENATED_SHORT_MESSAGES_16BIT: { > > > > Please close this bug. Thanks! Please do let Orange be aware of this. Otherwise, we will encounter this problem and workaround it again and again in next product.

Bevis, what are the implications of not following the spec if our competitors are doing it? Maybe we could put this check behind a pref "mms.spec.strict = true", defaulting to _not_ doing the check?

(In reply to Julien Wajsberg [:julienw] from comment #30) > Bevis, what are the implications of not following the spec if our > competitors are doing it? > Maybe we could put this check behind a pref "mms.spec.strict = true", > defaulting to _not_ doing the check? These port numbers are reserved by 3GPP for future allocation according to 3GPP TS 23.040: " 49152 – 65535 are reserved for future allocation by 3GPP. For a port number in this range an application must be made to 3GPP. " For WAP push, the ports are well-allocated: '2948' for WAP Push connectionless session service (client side) in IANA. (Destination Port) '9201' for WAP session service in IANA. (Originator Port) In addition, it is possible to receive SMS with port numbers not only from the carrier but also from other application providers. I don't see too much implication of not following the spec if our competitors are doing it, but IMO, this is a good protection to restrict carriers and application providers to allocate these port numbers arbitrarily.

I have the same issue in France. Once I removed the check from comment 9 it works fine. Here is the log for a successful reception on the Orange France network once I removed the check.

I have a Geeksphone Revolution which worked fine with Orange and Firefox OS 1.3. 2 weeks ago the version was upgraded to 2.0 and now I can send MMS but not received.

(In reply to Julien Wajsberg [:julienw] from comment #32) > Created attachment 8570586 [details] > Orange France > > I have the same issue in France. > > Once I removed the check from comment 9 it works fine. > > Here is the log for a successful reception on the Orange France network once > I removed the check. excuse me i have never change any source code/pref on B2G, Who can we do this ? i don't know if it's the good place for ask this

Hey, this is not really easy because this is some code that lives in Gecko (albeit in JavaScript). You need to pull omni.ja from your device (which is a zip file), change the file in the zip file, and push it back. Ovbiously you need a root access. So I'd recommend that you don't try this.

(In reply to Julien Wajsberg [:julienw] from comment #35) > Hey, > > this is not really easy because this is some code that lives in Gecko > (albeit in JavaScript). You need to pull omni.ja from your device (which is > a zip file), change the file in the zip file, and push it back. Ovbiously > you need a root access. So I'd recommend that you don't try this. I have do this modif on my flame and on the revolution geeksphone it's work perfectly :D, thanks ! another question if y update the phone, my modification are erased no ?

(In reply to raiduk_belar from comment #36) > (In reply to Julien Wajsberg [:julienw] from comment #35) > > Hey, > > > > this is not really easy because this is some code that lives in Gecko > > (albeit in JavaScript). You need to pull omni.ja from your device (which is > > a zip file), change the file in the zip file, and push it back. Ovbiously > > you need a root access. So I'd recommend that you don't try this. > > I have do this modif on my flame and on the revolution geeksphone it's work > perfectly :D, thanks ! another question if y update the phone, my > modification are erased no ? Yes they are !

Requesting a blocking status: with this issue we can't receive a MMS from the Orange network, and it seems to be worldwide. Even if the issue is likely at Orange side, I think it will be very long and difficult to change it. Moreover I think our behavior is simply wrong: we should not just ignore the content without any notice to the user. I strongly think we should relax the check done in our code, still outputting something in the log so that we know something is wrong from the carrier side. But the end user is hit by this issue and that's why I think we need to change this. The check in our code is there since the start but it's the first time we have an issue with this. Bevis, I wonder if some change elsewhere in the code could have triggered the issue? Maybe this check + another faulty code that changed more recently triggers this? For example I see some places where we test for equality with "SMS_APPLICATION_PORT_INVALID", but in this case, destinationPort/originatorPort would be undefined?

(In reply to Julien Wajsberg [:julienw] from comment #38) > Requesting a blocking status: with this issue we can't receive a MMS from > the Orange network, and it seems to be worldwide. > > Even if the issue is likely at Orange side, I think it will be very long and > difficult to change it. Moreover I think our behavior is simply wrong: we > should not just ignore the content without any notice to the user. > > I strongly think we should relax the check done in our code, still > outputting something in the log so that we know something is wrong from the > carrier side. > But the end user is hit by this issue and that's why I think we need to > change this. > > The check in our code is there since the start but it's the first time we > have an issue with this. > Yes, I agree. This becomes annoying to us and the device users. I'll provide a patch that only prints a warning instead of removing this port Information-Element in the received PDU. > > Bevis, I wonder if some change elsewhere in the code could have triggered > the issue? Maybe this check + another faulty code that changed more recently > triggers this? > > For example I see some places where we test for equality with > "SMS_APPLICATION_PORT_INVALID", but in this case, > destinationPort/originatorPort would be undefined? No, actually, these 'undefined' is converted to SMS_APPLICATION_PORT_INVALID before storing into DB. [1] This is to ensure we have will-defined scope of these properties in the related interfaces whose implementation will be replaced by QC. [1] https://dxr.mozilla.org/mozilla-central/source/dom/system/gonk/RadioInterfaceLayer.js#2073

triage: the team triage feels it's necessary to block on 2.2 since receiving MMS is basic function. needinfo to Bhavana to consider whether it should be uplifted to 2.1.

This patch is to warn reserved port numbers in 16-bit-port IEI in the log instead of ignoring it as mentioned in comment 9 according to 3GPP standard. This helps our device users to receive MMS in Orange network properly. Hi Edgar, May I have your review for this change? Thanks!

Bevis, reading again your comment 9, I've 2 concerns here. 1. Only the originator port is invalid (61341), but the destination port is valid (2948). However we ignore both information. Maybe we should not ignore the destination port? 2. Moreover, I don't really understand the goal of these 2 information. I don't see where they're used in the code. Is it really normal that we ignore the whole MMS just because we ignore these 2 unused information?

Dear reporter, could you please precise if you tried with a french Orange SIM or another Orange SIM?

Dear reporter, it would be really nice to know all SIM you used where you reproduce the issue. Thanks a lot ! (Note: I'm in contact with a Orange engineer)

(In reply to comment #43 & comment #44) Dear Mozilla, This bug is reported by CTS from France. And I use the French Orange SIM card reproduce it at China. Thanks

(In reply to Julien Wajsberg [:julienw] from comment #42) > Bevis, reading again your comment 9, I've 2 concerns here. > > 1. Only the originator port is invalid (61341), but the destination port is > valid (2948). However we ignore both information. Maybe we should not ignore > the destination port? Hi Julien, According to |9.2.3.24.4 Application Port Addressing 16 bit address| in 3GPP TS 23.040, the entire "Information Element" has to be ignored: " A receiving entity shall ignore (i.e. skip over and commence processing at the next information element) any information element where the value of the Information-Element-Data is Reserved or not supported. " And this single "Information Element" contains the pair of destination/originator ports. In the new patch, I've ignored this check to have this IEI available to upper layer. > 2. Moreover, I don't really understand the goal of these 2 information. I > don't see where they're used in the code. Is it really normal that we ignore > the whole MMS just because we ignore these 2 unused information? Yes, it's normal: 1. There is a 2nd level filter for destination port in [1] and the only app we register to |_portAddressedSmsApps| is WDP_PORT_PUSH(2948) for WAP Push usage. 2. Since the IEI was removed by current implementation, there is no destination port for us to find the register callback in [1]. More information to you: The content of the rest sms binary is varied according to the port number. This allows developers to carry various information via SMS. For example, Nokia defines series of port numbers for proprietary usage of Nokia Smart Messaging where each port number identifies a specific mime-type of binary data such as vCard, vCalendar, ringtone and etc. See 5.1.1 NBS Protocol of Smart Messaging in [2] for detailed info. (Unlike EMS(Enhanced Messaging Service) defined in 3GPP which uses IEI types to identify the content in the same message.) Hope these information is clear to answer your questions. :) [1] https://hg.mozilla.org/mozilla-central/file/985070813323/dom/mobilemessage/gonk/SmsService.js#l107 [2] http://affon.narod.ru/GSM/ssm100.pdf

(In reply to Julien Wajsberg [:julienw] from comment #44) > Dear reporter, it would be really nice to know all SIM you used where you > reproduce the issue. Thanks a lot ! > > (Note: I'm in contact with a Orange engineer) You didn't ask to me but, personnaly i had the probleme with a french Orange SIM

Hey Bevis, is the filtering done at [1] ? I actually fail to understand this part of code :/ * if we have a destinationPort ** if we have a handler for this destinationPort *** use this handler ** return (in both cases) So that means that if we have a destinationPort but no handler, we also ignore the message ? That doesn't really work with what I understood so far, don't we have a destinationPort in our case? And should we really ack the SMS reception (the "return true") when we ignore the message ? Same for the next condition at [2]. [1] https://dxr.mozilla.org/mozilla-central/source/dom/mobilemessage/gonk/SmsService.js#628 [2] https://dxr.mozilla.org/mozilla-central/source/dom/mobilemessage/gonk/SmsService.js#636-639 Thanks Bevis for your answers.

(In reply to Julien Wajsberg [:julienw] from comment #48) > Hey Bevis, > > is the filtering done at [1] ? Yes. > > I actually fail to understand this part of code :/ > * if we have a destinationPort > ** if we have a handler for this destinationPort > *** use this handler > ** return (in both cases) > > So that means that if we have a destinationPort but no handler, we also > ignore the message ? That doesn't really work with what I understood so far, > don't we have a destinationPort in our case? > > And should we really ack the SMS reception (the "return true") when we > ignore the message ? Same for the next condition at [2]. Yes, as I said in comment 46, the content of binary data is varied per port-pair. There is nothing we can do if we receive opaque data and we don't know how to decode it for now. Unless we are going to support App directed SMS that is available in Android for market apps to listen to the binary data received from specific ports. To ignore it and to return positive ACK is the only thing we can do for now from SMS perspective. Otherwise, we just waste SMSC's resource to deliver it again and again until the valid period of that SMS is expired. > > [1] > https://dxr.mozilla.org/mozilla-central/source/dom/mobilemessage/gonk/ > SmsService.js#628 > [2] > https://dxr.mozilla.org/mozilla-central/source/dom/mobilemessage/gonk/ > SmsService.js#636-639 > > Thanks Bevis for your answers.

Comment on attachment 8571883 [details] [diff] [review] Patch v1: Allow to receive WAP Push in which reserved port numbers is used. Review of attachment 8571883 [details] [diff] [review]: ----------------------------------------------------------------- ::: dom/system/gonk/ril_worker.js @@ +7415,5 @@ > let dstp = (this.readHexOctet() << 8) | this.readHexOctet(); > let orip = (this.readHexOctet() << 8) | this.readHexOctet(); > dataAvailable -= 4; > + if ((dstp => PDU_APA_VALID_16BIT_PORTS) > + || (orip => PDU_APA_VALID_16BIT_PORTS)) { Nit: Put || to the end of previous line e.g. if ((...) || (...)) { }

Comment on attachment 8571883 [details] [diff] [review] Patch v1: Allow to receive WAP Push in which reserved port numbers is used. Will update after the nits is addressed.

Address nits.

update try server result: https://treeherder.mozilla.org/#/jobs?repo=try&revision=7cbcea6f869f

Comment on attachment 8572991 [details] [diff] [review] Patch v2: Allow to receive WAP Push in which reserved port numbers is used. r=echen NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings. [Approval Request Comment] Bug caused by (feature/regressing bug #): N/A User impact if declined: Not possible to receive MMS in Orange network. Even this is a problem in network-side mentioned in comment 9, we'd like to lower the restriction instead of waiting carrier to fix it. Testing completed: Yes, and also verified by vendor in comment 28. Risk to taking this patch (and alternatives if risky): No. String or UUID changes made by this patch:No.

Bevis, can you request approval for 2.1 as well? For sure I have the problem in 2.1 too (which is normal: we have the same issue in all versions since we support MMS)?

Comment on attachment 8572991 [details] [diff] [review] Patch v2: Allow to receive WAP Push in which reserved port numbers is used. r=echen NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings. [Approval Request Comment] Bug caused by (feature/regressing bug #): N/A User impact if declined: Not possible to receive MMS in Orange network. Even this is a problem in network-side mentioned in comment 9, we'd like to lower the restriction instead of waiting carrier to fix it. Testing completed: Yes, and also verified by vendor in comment 28. Risk to taking this patch (and alternatives if risky): No. String or UUID changes made by this patch:No.

(In reply to Julien Wajsberg [:julienw] (PTO March 7th -> 15th) from comment #55) > Bevis, can you request approval for 2.1 as well? For sure I have the problem > in 2.1 too (which is normal: we have the same issue in all versions since we > support MMS)? Sure, but we still need 2.1+ for landing as well.

(In reply to Bevis Tseng[:bevistseng][:btseng] from comment #57) > (In reply to Julien Wajsberg [:julienw] (PTO March 7th -> 15th) from comment > #55) > > Bevis, can you request approval for 2.1 as well? For sure I have the problem > > in 2.1 too (which is normal: we have the same issue in all versions since we > > support MMS)? > > Sure, but we still need 2.1+ for landing as well. Sorry, it's already 2.2+. Let's wait for approval-mozilla-b2g34+ for 2.1.

https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/7004f1d278ed https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/421ee858039c

QAnalysts don't have Orange SIM cards