[FFOS2.0][Woodduck][HOMO][Orange AMEA] MMS cant be received by the phone

RESOLVED FIXED in Firefox 39, Firefox OS v2.1

Status

Firefox OS
RIL
P2
normal
RESOLVED FIXED
3 years ago
2 years ago

People

(Reporter: sync-1, Assigned: bevis, NeedInfo)

Tracking

(Blocks: 1 bug, {verifyme})

unspecified
2.2 S7 (6mar)
verifyme

Firefox Tracking Flags

(blocking-b2g:2.1+, firefox37 wontfix, firefox38 wontfix, firefox39 fixed, b2g-v1.4 wontfix, b2g-v2.0 wontfix, b2g-v2.0M wontfix, b2g-v2.1 fixed, b2g-v2.1S fixed, b2g-v2.2 fixed, b2g-master fixed)

Details

(Whiteboard: [SUMO-b2g])

Attachments

(11 attachments, 1 obsolete attachment)

(Reporter)

Description

3 years ago
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) ?
Component: Gaia::SMS → RIL
Flags: needinfo?(sync-1)
(Reporter)

Comment 2

3 years ago
Created attachment 8560317 [details]
MTK log
(Reporter)

Comment 3

3 years ago
Created attachment 8560320 [details]
APN info in setting menu.
(Reporter)

Comment 4

3 years ago
Created attachment 8560321 [details]
MTK log
(Reporter)

Comment 5

3 years ago
Created attachment 8560326 [details]
LOG
(Reporter)

Comment 6

3 years ago
Created attachment 8560328 [details]
APN info in setting menu.
(Reporter)

Comment 7

3 years ago
Created attachment 8560330 [details]
MTK log
(Reporter)

Comment 8

3 years ago
Created attachment 8560332 [details]
MMS reception fail
(Assignee)

Comment 9

3 years ago
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
(Assignee)

Comment 10

3 years ago
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
(Reporter)

Comment 11

3 years ago
(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!

Updated

3 years ago
Summary: [HOMO][HOMO][Orange AMEA] MMS cant be received by the phone → [FFOS2.0][Woodduck][HOMO][Orange AMEA] MMS cant be received by the phone
(Assignee)

Comment 12

3 years ago
Question in comment 1 is answered in comment 11.
Flags: needinfo?(sync-1)
(Assignee)

Comment 13

3 years ago
NI reporter for the problem we found in carrier side in comment 9.
Flags: needinfo?(sync-1)
(Reporter)

Comment 14

3 years ago
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.
(Reporter)

Comment 15

3 years ago
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.
(Reporter)

Comment 16

3 years ago
Created attachment 8561807 [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.
(Assignee)

Comment 17

3 years ago
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.
(Reporter)

Comment 18

3 years ago
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.
(Reporter)

Comment 19

3 years ago
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.
(Reporter)

Comment 20

3 years ago
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.
(Assignee)

Comment 21

3 years ago
(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.
(Reporter)

Comment 22

3 years ago
(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.
(Assignee)

Comment 23

3 years ago
(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!
Whiteboard: povb
This is _not_ povb. This is "part of carrier".

Dear TCL, will you please report the issue to Orange ?
Whiteboard: povb
(Reporter)

Comment 25

3 years ago
(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!

Comment 26

3 years ago
Hi Julien,
DengWei is PM of TCL. I will sync up with him about this issue and update later. 
Thanks!
Blocks: 1054172
(Reporter)

Comment 27

3 years ago
After talk with Dengwei & Feiyan, I had pass it to CTS and they will report the issue to Orange. Thanks!
(Reporter)

Comment 28

3 years ago
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!
(Assignee)

Comment 29

3 years ago
(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?
Flags: needinfo?(btseng)
(Assignee)

Comment 31

3 years ago
(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.
Flags: needinfo?(btseng)
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.

Comment 33

3 years ago
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.

Comment 34

3 years ago
(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.

Comment 36

3 years ago
(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?
blocking-b2g: --- → 2.1?
Flags: needinfo?(btseng)
(Assignee)

Comment 39

3 years ago
(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
Assignee: nobody → btseng
Flags: needinfo?(sync-1)
Flags: needinfo?(btseng)
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.
blocking-b2g: 2.1? → 2.2+
Flags: needinfo?(bbajaj)
(Assignee)

Comment 41

3 years ago
Created attachment 8571883 [details] [diff] [review]
Patch v1: Allow to receive WAP Push in which reserved port numbers is used.

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!
Attachment #8571883 - Flags: review?(echen)
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?
Flags: needinfo?(btseng)
Dear reporter, could you please precise if you tried with a french Orange SIM or another Orange SIM?
Flags: needinfo?(sync-1)
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)

Updated

3 years ago
Whiteboard: [SUMO-b2g]
(Reporter)

Comment 45

3 years ago
(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
(Assignee)

Comment 46

3 years ago
(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
Flags: needinfo?(btseng)

Comment 47

3 years ago
(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.
Flags: needinfo?(btseng)
(Assignee)

Comment 49

3 years ago
(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.
Flags: needinfo?(btseng)

Comment 50

3 years ago
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 ((...) ||
    (...)) {
}
Attachment #8571883 - Flags: review?(echen) → review+
(Assignee)

Comment 51

3 years ago
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.
Attachment #8571883 - Attachment is obsolete: true
(Assignee)

Comment 52

3 years ago
Created attachment 8572991 [details] [diff] [review]
Patch v2: Allow to receive WAP Push in which reserved port numbers is used. r=echen

Address nits.
Attachment #8572991 - Flags: review+
(Assignee)

Comment 53

3 years ago
update try server result:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=7cbcea6f869f
Keywords: checkin-needed
(Assignee)

Comment 54

3 years ago
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.
Attachment #8572991 - Flags: approval-mozilla-b2g37?
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)?
(Assignee)

Comment 56

3 years ago
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.
Attachment #8572991 - Flags: approval-mozilla-b2g34?
(Assignee)

Comment 57

3 years ago
(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.
status-b2g-v1.4: --- → wontfix
status-b2g-v2.0: --- → wontfix
status-b2g-v2.0M: --- → wontfix
status-b2g-v2.1: --- → affected
status-b2g-v2.1S: --- → affected
status-b2g-v2.2: --- → affected
status-b2g-master: --- → affected
(Assignee)

Comment 58

3 years ago
(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/integration/b2g-inbound/rev/cc00a8050143
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/cc00a8050143
Status: NEW → RESOLVED
Last Resolved: 3 years ago
status-firefox39: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 2.2 S7 (6mar)

Updated

3 years ago
blocking-b2g: 2.2+ → 2.1+
Flags: needinfo?(bbajaj)

Updated

3 years ago
Keywords: verifyme

Updated

3 years ago
Attachment #8572991 - Flags: approval-mozilla-b2g37?
Attachment #8572991 - Flags: approval-mozilla-b2g37+
Attachment #8572991 - Flags: approval-mozilla-b2g34?
Attachment #8572991 - Flags: approval-mozilla-b2g34+
https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/7004f1d278ed
https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/421ee858039c
status-b2g-v2.1: affected → fixed
status-b2g-v2.2: affected → fixed
status-b2g-master: affected → fixed
status-firefox37: --- → wontfix
status-firefox38: --- → wontfix

Comment 62

3 years ago
https://hg.mozilla.org/releases/mozilla-b2g34_v2_1s/rev/421ee858039c
status-b2g-v2.1S: affected → fixed
QAnalysts don't have Orange SIM cards
QA Whiteboard: QAExclude
Flags: needinfo?(jmercado)
Flags: needinfo?(jmercado)
You need to log in before you can comment on or make changes to this bug.