1029453 - Not able to receive the MMS Message sent by Open C in 'Free' Operator

Status: RESOLVED INVALID

(Firefox OS Graveyard :: Vendcom, defect)

Description

[kris]

Attachment: logs0624.7z

User Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36

Steps to reproduce:

In French,mmsc specific configuration is as follows：

"15": [
    {"carrier":"Free","apn":"free","type":["default","supl"]},
    {"carrier":"Free MMS","apn":"mmsfree","mmsc":"http://212.27.40.225","type":["mms"]}
  ],

Send a MMS


Actual results:

Testing machine can not receive MMS.


Expected results:

Testing machine should receive MMS.

Comment 1

[kris]

Please check this issue,tks.

Comment 2

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

Hi Kris -

For MMS/SMS relevant issue, we need RIL layer logs and TCP Dump logs. Please follow the instruction here:

https://github.com/bevis-tseng/Debug_Tools.

Please do help to get the logs we need such that we can help you to check this bug

Thanks

Vance

Comment 3

[kris]

Attachment: capture.pcap

Comment 4

[kris]

Attachment: logcat.txt

Log files named logcat.txt and capture.pcap have been provided.Hope this will help resolve this issue.

Comment 5

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

Hi Bevis -

Mind taking a look at the log first?

Vance

Comment 6

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

Hi,

I didn't see anything wrong according to the attached logs. :(
1. There were 2 MMS transaction sent successfully from the attached tcpdump at 10:10:46 and 10:11:29 with positive reponse from the server.
2. It seems that the logcat was not correctly captured, the earliest timestamp of the log is started at 10:12:00.

Please ensure you have applied the script "enable_debug_flags.sh" to enable the related logs tags before "adb logcat -v threadtime" and make sure you start adb logcat & tcpdump before sending/receiving mms. After capturing the logcat, you supposed to see "MmsService" related keywords are printed.
With correct capture of tcpdump, you supposed to see m-send-req/m-send-conf if you read it from the wiredshark.

In addition, can reporter describe the issue more precisely:
1. The title of this bug told us not able to send MMS.
2. However, the desciption told us that the test machine was not able to receive a MMS.
Looks quite confusing, right?

Comment 7

[kris]

Attachment: OpenC1Send-OpenC1Receive-PASS.7z

Test 1:
Open C 1 send mms, Open C 1 receive, successfully

Comment 8

[kris]

Attachment: OpenC1Send-OpenC2Receive-FAIL.7z

Test 2:
Open C 1 send mms, Open C2 receive, fail, Open C 2 can not received mms

Comment 9

[kris]

Attachment: Vec4GSend-OpenC1Receive-PASS.7z

Test 3:
Android Reference Phone Vec4G send mms, Open C receive, successfully

Comment 10

[kris]

Test 4:
Open C send mms, Android Reference Phone Vec4G receive, fail, Vec4G can not received mms

Test 4 does not provide a log. Another three tests's logs are attached, please check it.
For failed case, we can not receive the mms-notification-ind with short message.

Comment 11

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

According the the desciption and logs, we are not able to see anything wrong in device side because the MMSC always told us the sending request is done successfully even in Test 2.
Need help from modem/or network side to see why the mms-notification was not delivered to the receiving device instead.

Comment 12

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

Hi Bevis -

Let's expecting the worst here. Supposed there is nothing wrong with modem side, the device simply didn't receive any mms notification. So under this circumstance, is there anything/suggestions we can provide to partner to help further clarify this problem?

One thing i can think of is to build a TB which changes the UAProf to some Android devices and try again...

Any other ideas?

Thanks for your help

Comment 13

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

No, the suggestion I've so far is similar to your and is to diff all the fields in MMS-Send-Req PDUs between Open C and Android Reference phone and have some change to see if there is any impact. :(

Comment 14

[RuiLi]

Attachment: androidSendMMS_OK.pcap

This is the log for sending mms by android device. I find 'Host: mms.free.fr' in http HOST header, but in our OPENC device, this one is 'Host: 212.27.40.225'.

Comment 15

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

Hi Ruili - 

As mentioned, the host only affect MO MMS, not MT MMS.

Hi Bevis

I roughly check the pcap logs, the only different fields are:

1. Read report request
2. From
3. Transcation ID

Honestly i really don't know what might cause this problem, on a guesstimation, i will say most likely is 3, then 2, then 1....

Any idea?

Thanks

Vance

Comment 16

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

(In reply to Vance Chen [:vchen][[e-mail]] from comment #15)
> 1. Read report request
> 2. From
> 3. Transcation ID
> 
> Honestly i really don't know what might cause this problem, on a
> guesstimation, i will say most likely is 3, then 2, then 1....
> 
> Any idea?
> 
> Thanks
> 
> Vance

Thanks, Vance for checking the difference of the PDUs.
The suspicious one shall be 'From'.
According to the |From| field defined in |6.1.1 Send Request| & |6.7.2 PDU Read Report 
| of OMA MMS Encapsulation Protocol [2]:
"
 The originator MMS Client MUST send either its address or an |Insert-address-token|.
 In case of token, the MMS Proxy-Relay MUST insert the correct address of 
 the originator MMS Client.
"
In our implementation, we put "|Insert-address-token|" the value of |From| field.
In the PDU composed by the reference phone, it's "2345" which looks neither a |Insert-address-token| nor the MSISDN of the originator.

Is it a customization to fill "2345" in From for carrier Free?

Comment 17

[:gerard-majax]

I can confirm the issue. No problem when sending from Free Mobile to Free Mobile. Sending from Free Mobile to Bouygues or Orange fails.

Log finished with:
> I/Gecko   ( 2500): -@- MmsService: Sending MMS succeeded.

MMS never received.

Comment 18

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

(In reply to Alexandre LISSY :gerard-majax from comment #17)
> I can confirm the issue. No problem when sending from Free Mobile to Free
> Mobile. Sending from Free Mobile to Bouygues or Orange fails.
> 
> Log finished with:
> > I/Gecko   ( 2500): -@- MmsService: Sending MMS succeeded.
> 
> MMS never received.

Hi Alex -

Just want to double check with you, so are you saying it is OK to send MSS from one FFOS device(device A) with Free SIM card to another FFOS device(device B) with Free SIM card? The MMS can be sent from device A and can be received in device B?

Comment 19

[:gerard-majax]

(In reply to Vance Chen [:vchen][[e-mail]] from comment #18)
> (In reply to Alexandre LISSY :gerard-majax from comment #17)
> > I can confirm the issue. No problem when sending from Free Mobile to Free
> > Mobile. Sending from Free Mobile to Bouygues or Orange fails.
> > 
> > Log finished with:
> > > I/Gecko   ( 2500): -@- MmsService: Sending MMS succeeded.
> > 
> > MMS never received.
> 
> Hi Alex -
> 
> Just want to double check with you, so are you saying it is OK to send MSS
> from one FFOS device(device A) with Free SIM card to another FFOS
> device(device B) with Free SIM card? The MMS can be sent from device A and
> can be received in device B?

Exactly.

Comment 20

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

> 
> Is it a customization to fill "2345" in From for carrier Free?

Hi Bevis -

Partner is still checking why if there is any specific reason to use 2345, but in the mean time, they want to build a TB that pack the From field to 2345/TYPE=PLMN, could you kindly provide some tips to them regarding how to modify MmsService.js和MmsPduHelper.jsm to achieve that?

Thanks for your help

Vance

Comment 21

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

(In reply to Vance Chen [:vchen][[e-mail]] from comment #20)
> > 
> > Is it a customization to fill "2345" in From for carrier Free?
> 
> Hi Bevis -
> 
> Partner is still checking why if there is any specific reason to use 2345,
> but in the mean time, they want to build a TB that pack the From field to
> 2345/TYPE=PLMN, could you kindly provide some tips to them regarding how to
> modify MmsService.js和MmsPduHelper.jsm to achieve that?
> 
> Thanks for your help
> 
> Vance

Sure,

All partner has to do is to conditionally change 2 lines in [1][2]:
  msg.headers["from"] = null;
  headers["from"] = null;
to
  msg.headers["from"] = { address: "2345", type: "PLMN" };
  headers["from"] = { address: "2345", type: "PLMN" };

Then, MmsPduHelper shall encode it accordingly.

[1] http://hg.mozilla.org/releases/mozilla-b2g28_v1_3/file/e1f405094f41/dom/mobilemessage/src/gonk/MmsService.js#l1087
[2] http://hg.mozilla.org/releases/mozilla-b2g28_v1_3/file/e1f405094f41/dom/mobilemessage/src/gonk/MmsService.js#l1390

Comment 22

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

Attachment: Patch: Add Phone Number into FROM Field of MMS Header when transmitting MMS PDU to network

Comment 23

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

Hi Vance,

Another patch worthy to try is attached in comment 22 which tries to fill the |MSISDN| into |from| instead of |Insert-address-token| if available.

Comment 24

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

(In reply to Bevis Tseng [:bevistseng] ([e-mail]) from comment #23)
> Hi Vance,
> 
> Another patch worthy to try is attached in comment 22 which tries to fill
> the |MSISDN| into |from| instead of |Insert-address-token| if available.

Got it, thanks Bevis, will ask patch to build a TB with this patch to verify as well

Vance

Comment 25

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

Hi Bevis -

According to partner feedback, Open C still cannot receive MMS with our patches and the modification of From field. Attached please find the new logs again. 

I am run out of ideas now...Any suggestions?

Thanks

Comment 26

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

Attachment: free.pcap

New logs

Comment 27

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

(In reply to Vance Chen [:vchen][[e-mail]] from comment #25)
> Hi Bevis -
> 
> According to partner feedback, Open C still cannot receive MMS with our
> patches and the modification of From field. Attached please find the new
> logs again. 
> 
> I am run out of ideas now...Any suggestions?
> 
> Thanks

I have no idea now as well... :(
I didn't see anything wrong from the MMS-PDU. 
It is hard to tell what's wrong because there is also no error reported from the network side.

In addition, is it possible for vendor to double confirm from the modem side that 
there is no incoming SMS which represents the MMS notification?

Comment 28

[Guo Hailin]

(In reply to Bevis Tseng [:bevistseng] ([e-mail]) from comment #27)
> (In reply to Vance Chen [:vchen][[e-mail]] from comment #25)
> > Hi Bevis -
> > 
> > According to partner feedback, Open C still cannot receive MMS with our
> > patches and the modification of From field. Attached please find the new
> > logs again. 
> > 
> > I am run out of ideas now...Any suggestions?
> > 
> > Thanks
> 
> I have no idea now as well... :(
> I didn't see anything wrong from the MMS-PDU. 
> It is hard to tell what's wrong because there is also no error reported from
> the network side.
> 
> In addition, is it possible for vendor to double confirm from the modem side
> that 
> there is no incoming SMS which represents the MMS notification?

Yes, I confirmed that there is no incoming SMS carring the m-notification-ind.

Comment 29

[:gerard-majax]

Had feedback and a look at the packets sent over wire.

The content type of the payload is:
> application/vnd.wap.multipart.related; type=application/smil; start="<smil>

Please note this '"', it may be the root cause of this.

Comment 30

[RuiLi]

 Could you help me how to remove it?

Comment 31

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

ni Alexandre per Comment#30

Comment 32

[:gerard-majax]

(In reply to RuiLi from comment #30)
>  Could you help me how to remove it?

I can confirm that the 'start' token gets encoded as a QuotedString in dom/mobilemessage/src/gonk/WspPduHelper.jsm. This is not a code path I know at all, and people are starting to fight regarding spec compliance. Someone knowing this should be able to fix it, but I really have no time to hack into this right now.

Comment 33

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

ni Bevis.

Hi Bevis, mind taking this one?

Comment 34

[Vicamo Yang [:vicamo][:vyang]]

Bevis takes PTO for a few days.

Comment 35

[Vicamo Yang [:vicamo][:vyang]]

(In reply to RuiLi from comment #30)
>  Could you help me how to remove it?

https://mxr.mozilla.org/mozilla-central/source/dom/mobilemessage/src/gonk/WspPduHelper.jsm#2740
It's in ${B2G}/gecko/dom/mobilemessage/src/gonk/WspPduHelper.jsm, inside the table WSP_WELL_KNOWN_PARAMS. If you may, please change it from:

  add("start", 0x0A, TextValue);

To:

  add("start", 0x0A, TextString);

Comment 36

[:gerard-majax]

Vicamo, thanks, this does the trick for me :)

I could send my MMS from Free Mobile to Orange F, and the MMS was properly received. I tested it against my own Orange F SIM card in Flame and against a friend's in an iPhone.

Comment 37

[Vicamo Yang [:vicamo][:vyang]]

(In reply to Alexandre LISSY :gerard-majax from comment #36)
> Vicamo, thanks, this does the trick for me :)
> I could send my MMS from Free Mobile to Orange F, and the MMS was properly
> received. I tested it against my own Orange F SIM card in Flame and against
> a friend's in an iPhone.

I'm to provide a patch to allow overriding predefined value type. We'll going to need Gaia's help to pass a new per-operator preference for this.

Comment 38

[Vicamo Yang [:vicamo][:vyang]]

OMA-MMS-ENC-V1_2-20050301-A, chapter 7 "Binary Encoding of Protocol Data Units":

  Note: Table 38 in [WAPWSP] contains bugs at Expected BNF Rules for Value.
  “Text-value” must be used for parameter values instead of “Text-string”.

OMA-TS-MMS_ENC-V1_3-20110913-A, subclause 7.1 "Special Considerations Regarding Usage of WSP in MMS":

  Table 38 in [WAPWSP] contains bugs at Expected BNF Rules for Value.
  “Text-value” MUST be used for parameter values instead of “Text-string”.

Comment 39

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

Hi Alexandre -

I was told that the Free also modify on the server side in order for the MMS to work on the older version of Open C, 

Would you mind testing again w/o Vicamo's modification to see if now we can receive MMS w/o any problem?

Thanks

Vance

Comment 40

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

Update my finding so far regarding encoding |start| parameter with value equal to |<smil>| in MMS header:
1. As mentioned in comment 38, the |start| parameter shall be encoded in |Text-Value|.
2. Where Text-value = No-value | Token-text | Quoted-string.
3. According to RFC2616[1], "<" and ">" are |separators| instead of |tokens|.
4. That's why |<smil>| is encoded in |Quoted-string| instead.
5. The reason why AOSP didn't contains quote in the |start| parameter is that
   |Text-String| is always used to encode it which doesn't follow the standard
   mentioned in comment 38. [2]

[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec2.html
[2] http://androidxref.com/4.3_r2.1/xref/frameworks/opt/mms/src/java/com/google/android/mms/pdu/PduComposer.java#878

Comment 41

[:gerard-majax]

Yes, it does work now that Free did some changes on their MMSC.

Comment 42

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

Per discussion with ZTE engineers, we both agree that the FFOS decode behavior follows the spec. Since now Free already modify the MMSC, we think it is best to change nothing on the device side to avoid any potential compatibility issue in the future. 

Close as INVALID