995486 - CDMA MO MMS is not working on v1.4

Status: RESOLVED DUPLICATE of bug 1007542

(Firefox OS Graveyard :: RIL, defect)

Description

[Nivi]

Attachment: log file

CDMA MO MMS is not working with Verizon sim. I set the APN correctly but it doesn't work.
I am attaching the log.

Comment 1

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

04-11 16:14:28.542   223   223 I Gecko   : -@- MmsService: sendRequest: register proxy filter to 
04-11 16:14:28.542   223   223 E GeckoConsole: [JavaScript Error: "NS_ERROR_MALFORMED_URI: Component returned failure code: 0x804b000a (NS_ERROR_MALFORMED_URI) [nsIIOService.newURI]" {file: "jar:file:///system/b2g/omni.ja!/components/MmsService.js" line: 501}]

Comment 2

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

From the attached log, I saw 2 suspicious point:
1. For the 1st MO MMS, it seems that the MMSC is empty. (Incorrect configuration)
2. For 2nd/3rd MO MMS, we got 0 from server after sending. 
I am wondering if we send it after resolving the mmsc host name.
There was an race condition that was resolved in bug 976897.

NI reporter for
1. What is your revision of the gecko for testing?
2. Is WiFi On/Connected while testing?
3. Can we have a tcpdump and adb logcat for further analysis?

Thanks & regards,
Bevis Tseng
--
Log analysis:
[1] Invalid MMSC url when sending 1st MMS:
04-11 16:14:28.542   223   223 E GeckoConsole: [JavaScript Error: "NS_ERROR_MALFORMED_URI: Component returned failure code: 0x804b000a (NS_ERROR_MALFORMED_URI) [nsIIOService.newURI]" {file: "jar:file:///system/b2g/omni.ja!/components/MmsService.js" line: 501}]

[2] Got Strange HTTP status equal to 0 when sending 2nd/3rd MMS:
04-11 16:16:22.230   223   223 I Gecko   : -@- MmsService: xhr done, but status = 0, statusText = 
04-11 16:16:22.230   223   223 I Gecko   : -@- MmsService: Fail to send. Will retry after: 300000

04-11 16:21:32.753   223   223 I Gecko   : -@- MmsService: xhr done, but status = 0, statusText = 
04-11 16:21:32.753   223   223 I Gecko   : -@- MmsService: Fail to send. Will retry after: 300000

Comment 3

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

In addition, may I know 
1. what device are you using for sending MMS via CDMA network in VzW?
   AFAIK, we didn't officially support MMS in CDMA network yet.
2. Is Data traffic in the data connection with type MMS really workable in the test device?
   From the log, I saw MmsService get HTTP response immediately with status 0 after HTTP request.
   I am wondering if the network interface in kernel is really workable?

Comment 4

[Nivi]

We have seen the malformed URI error even after entering the MMSC correctly. That might be a separate bug for someone from Mozilla to look into. A colleague of mine reported the same behavior and said we have to re-type the same MMSC info several times until the malformed URI error goes away.

I did the same and after re-typing same MMSC, I was able to get past the error while sending the 2/3 MMS.

To answer your questions -
1. We are testing on our equivalent of Sora.
2. WiFi is not connected.
3. I can send some more logs (adb logcat and tcpdump) later today.
4. Gecko SHA 1 - d02b9250ef7fedafc6c709dfcc899844b8624ab6.
5. Is Data traffic in the data connection with type MMS really workable in the test device? We tested MMS on gsm on the same device and that works.

Let me know if you have further questions.

Thanks,
Nivi.

(In reply to Bevis Tseng [:bevistseng] ([e-mail]) from comment #2)
> From the attached log, I saw 2 suspicious point:
> 1. For the 1st MO MMS, it seems that the MMSC is empty. (Incorrect
> configuration)
> 2. For 2nd/3rd MO MMS, we got 0 from server after sending. 
> I am wondering if we send it after resolving the mmsc host name.
> There was an race condition that was resolved in bug 976897.
> 
> NI reporter for
> 1. What is your revision of the gecko for testing?
> 2. Is WiFi On/Connected while testing?
> 3. Can we have a tcpdump and adb logcat for further analysis?
> 
> Thanks & regards,
> Bevis Tseng
> --
> Log analysis:
> [1] Invalid MMSC url when sending 1st MMS:
> 04-11 16:14:28.542   223   223 E GeckoConsole: [JavaScript Error:
> "NS_ERROR_MALFORMED_URI: Component returned failure code: 0x804b000a
> (NS_ERROR_MALFORMED_URI) [nsIIOService.newURI]" {file:
> "jar:file:///system/b2g/omni.ja!/components/MmsService.js" line: 501}]
> 
> [2] Got Strange HTTP status equal to 0 when sending 2nd/3rd MMS:
> 04-11 16:16:22.230   223   223 I Gecko   : -@- MmsService: xhr done, but
> status = 0, statusText = 
> 04-11 16:16:22.230   223   223 I Gecko   : -@- MmsService: Fail to send.
> Will retry after: 300000
> 
> 04-11 16:21:32.753   223   223 I Gecko   : -@- MmsService: xhr done, but
> status = 0, statusText = 
> 04-11 16:21:32.753   223   223 I Gecko   : -@- MmsService: Fail to send.
> Will retry after: 300000

Comment 5

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

Hi,

To narrow down the problem of sending MMS, 
can we capture the adb logcat & tcpdump in the following condition:
1. Ensure that Default Data & WiFi are disabled.
2. Make sure that MMS Configuration is correct. (No NS_ERROR_MALFORMED_URI while sending MMS)
3. Reboot the device.
4. Start to capture & test. (Please make sure that adb logcat is captured from bootup for better analysis.)

Thanks & regards,
Bevis Tseng

Comment 6

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

Attachment: tcpdump

upload tcpdump binary to capture the .pcap:
1. push tcpdump into android device.
2. tcpdump -i any -p -s 0 -w /data/capture.pcap

Comment 7

[Nivi]

Hi Bevis,

Will send you a dump as soon as we can collect one.

Thanks,
Nivi.

Comment 8

[Nivi]

Attachment: mms_cdma_fail.logcat

Hi Bevis,

Please find attached the logs without data and wifi on. No data was captured on the tcpdump.

Thanks,
Nivi.

Comment 9

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

(In reply to Nivi from comment #8)
> Created attachment 8408587 [details]
> Please find attached the logs without data and wifi on. No data was captured
> on the tcpdump.

Hi Nivi,

After checking the log, we didn't found anything abormal in RadioInterfaceLayer & MmsService.
The APN vzwinternet is established normally and MMS started sending after the connection is established.
However, we always got HTTP status = 0 from the response as we saw in previous testing.

As you mentioned, no data was captured on the tcpdump.
I am wondering again if there is something wrong in lower layer (for example, in driver) that
causes the data not able to pass through this data connection even it is established.
Otherwise, we are supposed to capture something in the tcpdump instead.

Is it possible to ping or send some data from command line or run some test script to 
the host of "mms.vtext.com" or other accessible ip address to prove this?

Thanks,
Bevis
--
Here is the log analysis for your reference:

[Get send request from App]

04-17 14:22:14.136   226   226 I Gecko   : -@- MmsService: send: aParams: {}
04-17 14:22:14.236   226   226 I Gecko   : -@- MmsService: Saving sending message is done. Start to send.



[Ask Radio Interface to setup mms data connection]

04-17 14:22:14.246   226   226 I Gecko   : -@- MmsService: acquire: buffer the MMS request and setup the MMS data call.
04-17 14:22:14.246   226   226 I Gecko   : -*- DataConnectionHandler[0]: setupDataCallByType: mms
04-17 14:22:14.246   226   226 I Gecko   : -*- RILNetworkInterface[0:2]: Going to set up data connection with APN vzwinternet
04-17 14:22:14.246   226   750 I Gecko   : RIL Worker: [0] Received chrome message {"radioTech":8,"apn":"vzwinternet","user":"","passwd":"","chappap":3,"pdptype":"IP","rilMessageClientId":0,"rilMessageToken":11,"rilMessageType":"setupDataCall"}



[Data Call was established]

04-17 14:22:28.828   226   750 I Gecko   : RIL Worker: [0] Handling parcel as REQUEST_SETUP_DATA_CALL
04-17 14:22:28.838   226   226 I Gecko   : -*- RadioInterface[0]: Received message from worker: {"status":0,"suggestedRetryTime":-1,"cid":"0","active":2,"type":"IP","ifname":"rmnet0","ipaddr":"10.224.214.103/28","dns":["198.224.168.135","198.224.171.135"],"gw":"10.224.214.104","state":1,"radioTech":8,"apn":"vzwinternet","user":"","passwd":"","chappap":3,"pdptype":"IP","rilMessageType":"datacallstatechange","rilMessageClientId":0}
04-17 14:22:28.848   226   226 I Gecko   : -*- RILNetworkInterface[0:2]: Data call ID: 0, interface name: rmnet0, APN name: vzwinternet



[Start to send MMS after mms data connection is established]

04-17 14:22:28.888   226   226 I Gecko   : -@- MmsService: Got the MMS network connected! Resend the buffered MMS requests: number: 1
04-17 14:22:28.888   226   226 I Gecko   : -@- MmsService: flushPendingCallbacks: 1 pending callbacks with status: 0
04-17 14:22:28.888   226   226 I Gecko   : -@- MmsService: sendRequest: register proxy filter to http://mms.vtext.com/servlets/mms
04-17 14:22:28.888   226   226 I Gecko   : -@- MmsService: applyFilter: MMSC/Content Location is matched with: {"uri":"{\"spec\":\"http://mms.vtext.com/servlets/mms\",\"prePath\":\"http://mms.vtext.com\",\"scheme\":\"http\",\"userPass\":\"\",\"username\":\"\",\"password\":\"\",\"hostPort\":\"mms.vtext.com\",\"host\":\"mms.vtext.com\",\"port\":-1,\"path\":\"/servlets/mms\",\"asciiSpec\":\"http://mms.vtext.com/servlets/mms\",\"asciiHost\":\"mms.vtext.com\",\"originCharset\":\"UTF-8\",\"ref\":\"\",\"specIgnoringRef\":\"http://mms.vtext.com/servlets/mms\",\"hasRef\":false}","mmsProxyInfo":null}



[Got abnormal response immediately after sending MMS]

04-17 14:22:29.078   226   226 I Gecko   : -@- MmsService: xhr done, but status = 0, statusText =

Comment 10

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

Hi Nivi,

In addition, when you said no data captured from tcpdump, does that means after pull out the file |capture.pcap| mentioned in comment 6, you are not able to see anything by opening it with wiredshark [1]?

[1] http://www.wireshark.org/

Comment 11

[Nivi]

Hi Bevis,

I tried getting data up on my device since the last time I tested this but I am unable to do so. So I couldn't test pinging the MMSC.
At this point, I don't know when I can get it up but I will keep trying.

When we captured data from tcpdump, the file was empty. There was nothing in the pcap file.

Thanks,
Nivi.

(In reply to Bevis Tseng [:bevistseng] ([e-mail]) from comment #10)
> Hi Nivi,
> 
> In addition, when you said no data captured from tcpdump, does that means
> after pull out the file |capture.pcap| mentioned in comment 6, you are not
> able to see anything by opening it with wiredshark [1]?
> 
> [1] http://www.wireshark.org/

Comment 12

[Nivi]

Hi Bevis,

In addition, when we turned wifi on along with data, then we could capture some tcpdump.
Please let me know if this extra information helps.

I could share the tcpdump in that scenario if you want. Let me know.

Thanks,
Nivi.

Comment 13

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

(In reply to Nivi from comment #12)
> Hi Bevis,
> 
> In addition, when we turned wifi on along with data, then we could capture
> some tcpdump.
> Please let me know if this extra information helps.
> 
> I could share the tcpdump in that scenario if you want. Let me know.
> 
> Thanks,
> Nivi.

Hi Nivi,

Thanks. 
However, I think what we need are the packets through mms data connection.
The information will be meaningful only if the packets are sent/received via
the ip-address bound by the mms data connection. :(
If the packet from mms data connection cannot be captured,
I think there might be something wrong in this data connection.

Bevis

Comment 14

[Nivi]

Hi Bevis,

I have some new info for you.

We were able to get data up on the device and I tried to ping the MMSC. When using the URI (http//mms.vtext.com/servlets/mms), I wasn't able to ping the MMSC but using the IP address we were able to get a reply back.

We got the IP while testing the same thing on Android and we were able to ping the MMSC using the URI.

I don't know if it's a DNS/routing issue on ffos.

Also, we tried using the IP as the MMSC in the message settings - http://IP address and we got past the malformed URI error so assumed that works and we still got no data in the tcp dump.

Let me know if this helps.

Thanks,
Nivi.

Comment 15

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

Hi Nivi,

Thanks for your information. :)

Based on this info,
I still have some questions in-lined to you to clarify.

(In reply to Nivi from comment #14)
> Hi Bevis,
> 
> I have some new info for you.
> 
> We were able to get data up on the device and I tried to ping the MMSC. When
> using the URI (http//mms.vtext.com/servlets/mms), I wasn't able to ping the
> MMSC but using the IP address we were able to get a reply back.
> 
> We got the IP while testing the same thing on Android and we were able to
> ping the MMSC using the URI.
> 
> I don't know if it's a DNS/routing issue on ffos.
To clarify the DNS/Routing issue of "mms.vtext.com", Is it possible to 
1. set the DEBUG flag to true in NetworkManager[1] to capture the logs
2. add one more log in [2] to see what hostname was requested to be resolved.
> 
> Also, we tried using the IP as the MMSC in the message settings - http://IP
> address and we got past the malformed URI error so assumed that works and we
> still got no data in the tcp dump.
Does that also means you got no data in tcpdump 
when you tried to ping the MMSC with it's IP address?

In addition, may I know if MMS was sent when you changed the MMSC config to
"http://IP-Address/servlets/mms" ?
If no, may I know what is the response printed in MmsService.js [3] ?

Thanks,
Bevis

> 
> Let me know if this helps.
> 
> Thanks,
> Nivi.

[1] http://hg.mozilla.org/releases/mozilla-b2g30_v1_4/file/123485e733d5/dom/system/gonk/NetworkManager.js#l111
[2] http://hg.mozilla.org/releases/mozilla-b2g30_v1_4/file/123485e733d5/dom/system/gonk/NetworkManager.js#l657
[3] http://hg.mozilla.org/releases/mozilla-b2g30_v1_4/file/123485e733d5/dom/mobilemessage/src/gonk/MmsService.js#l683

Comment 16

[Preeti Raghunath(:Preeti)]

Adam

Does VZN support CDMA? FFOS doesn't support VZN SIM and hence requesting next steps here.

Comment 17

[Preeti Raghunath(:Preeti)]

Upon triage with partner the issue needs to be looking at CDMA MMS failure.

Comment 18

[Nivi]

Hi Bevis,

I set debug flags to true in NetworkManager, MmsService and ril in general.

Today, I observed that we could ping mms3.vtext.com and not mms.vtext.com.

So, I tried sending a MMS with two MMSC setting: http://ip addr/servlets/mms
and http://mms3.vtext.com/servlets/mms.

For the first case, I got a -

04-30 11:17:18.165   233   233 I Gecko   : -@- MmsService: xhr done, but status = 0, statusText = 
04-30 11:17:18.165   233   233 I Gecko   : -@- MmsService: Fail to send. Will retry after: 300000

For the second case, I got a 

04-30 15:04:44.175   225   225 I Gecko   : -@- MmsService: xhr success, response headers: Server: Apache

We seem to get a HTTP OK in this case but I can't find it in the tcpdump.
The MMS fails to send though.

I am attaching all the new log files and tcpdumps I captured.

In addition, I see that when I run our ril, the code to resolve hostname gets invoked. I have copied a snippet of that from our logs in mms_mo_cdma_partner_ril.log. When I tested on partner ril, I don't see any resolving host name debug messages. I am curious as to why this happens? Maybe you can take a look.

Thanks,
Nivi.

(In reply to Bevis Tseng [:bevistseng] ([e-mail]) from comment #15)
> Hi Nivi,
> 
> Thanks for your information. :)
> 
> Based on this info,
> I still have some questions in-lined to you to clarify.
> 
> (In reply to Nivi from comment #14)
> > Hi Bevis,
> > 
> > I have some new info for you.
> > 
> > We were able to get data up on the device and I tried to ping the MMSC. When
> > using the URI (http//mms.vtext.com/servlets/mms), I wasn't able to ping the
> > MMSC but using the IP address we were able to get a reply back.
> > 
> > We got the IP while testing the same thing on Android and we were able to
> > ping the MMSC using the URI.
> > 
> > I don't know if it's a DNS/routing issue on ffos.
> To clarify the DNS/Routing issue of "mms.vtext.com", Is it possible to 
> 1. set the DEBUG flag to true in NetworkManager[1] to capture the logs
> 2. add one more log in [2] to see what hostname was requested to be resolved.
> > 
> > Also, we tried using the IP as the MMSC in the message settings - http://IP
> > address and we got past the malformed URI error so assumed that works and we
> > still got no data in the tcp dump.
> Does that also means you got no data in tcpdump 
> when you tried to ping the MMSC with it's IP address?
> 
> In addition, may I know if MMS was sent when you changed the MMSC config to
> "http://IP-Address/servlets/mms" ?
> If no, may I know what is the response printed in MmsService.js [3] ?
> 
> Thanks,
> Bevis
> 
> > 
> > Let me know if this helps.
> > 
> > Thanks,
> > Nivi.
> 
> [1]
> http://hg.mozilla.org/releases/mozilla-b2g30_v1_4/file/123485e733d5/dom/
> system/gonk/NetworkManager.js#l111
> [2]
> http://hg.mozilla.org/releases/mozilla-b2g30_v1_4/file/123485e733d5/dom/
> system/gonk/NetworkManager.js#l657
> [3]
> http://hg.mozilla.org/releases/mozilla-b2g30_v1_4/file/123485e733d5/dom/
> mobilemessage/src/gonk/MmsService.js#l683

Comment 19

[Nivi]

Attachment: Log file when using MMSC as http://ip_addr/....

Comment 20

[Nivi]

Attachment: Log file when using MMSC as http://mms3.vtext.com/...

Comment 21

[Nivi]

Attachment: Tcpdump when using MMSC as http://mms3.vtext.com/...

Comment 22

[Nivi]

Attachment: Log snippet when resolve hostname is called.

Comment 23

[Preeti Raghunath(:Preeti)]

(In reply to Preeti Raghunath(:Preeti) from comment #16)
> Adam
> 
> Does VZN support CDMA? FFOS doesn't support VZN SIM and hence requesting
> next steps here.

VZN is the biggest CDMA deployer.

Comment 24

[Hema Koka [:hema]]

Need your help for this bug. please have someone in your team take this on.

Comment 25

[Ken Chang[:kenkai]]

(In reply to Preeti Raghunath(:Preeti) from comment #23)
> (In reply to Preeti Raghunath(:Preeti) from comment #16)
> > Adam
> > 
> > Does VZN support CDMA? FFOS doesn't support VZN SIM and hence requesting
> > next steps here.
> 
> VZN is the biggest CDMA deployer.
We don't have a CDMA device launched in VZN yet. It seems not an 1.4+ bugs. Moreover, this bug comes from a architecture change of Kitkat, we don't have a quick solution for this now.

Comment 26

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

Hi Nivi,

Thanks for enabling more logs. I got some useful information from the logcat and tcpdump.

After checking the new logs,
I found that the scenario is different to the one we have seen in comment 2:
1. both tcpdump & the adb logcat told us that the hostname was resolved successfully
   with ip equal to 69.78.88.6.
2. The MMS send-req was transmitted to the MMSC.
3. However, there seems something wrong while parsing the response of the send-req that
   cause MmsService verdict that the MO MMS is failed.

Since the PDU is printed in the log, I'll try to repo this locally to see what's going on
while parsing the resposne of the M-Send-Req.

--

04-30 15:04:44.175   225   225 I Gecko   : -@- MmsService: xhr success, response headers: Server: Apache

04-30 15:04:44.175   225   225 I Gecko   : Content-Type: application/vnd.wap.mms-message

04-30 15:04:44.175   225   225 I Gecko   : Date: Wed, 30 Apr 2014 22:04:44 GMT

04-30 15:04:44.175   225   225 I Gecko   : Connection: Keep-Alive

04-30 15:04:44.175   225   225 I Gecko   : Content-Length: 102

04-30 15:04:44.175   225   225 I Gecko   : 
04-30 15:04:44.175   225   225 I Gecko   : -@- MmsService: res: {"0":140,"1":129,"2":152,"3":123,"4":53,"5":48,"6":101,"7":53,"8":49,"9":52,"10":97,"11":52,"12":45,"13":50,"14":97,"15":57,"16":51,"17":45,"18":52,"19":97}
04-30 15:04:44.175   225   225 I Gecko   : -@- MmsService: res: {"0":98,"1":48,"2":45,"3":97,"4":50,"5":97,"6":53,"7":45,"8":53,"9":101,"10":49,"11":57,"12":102,"13":101,"14":56,"15":97,"16":97,"17":100,"18":98,"19":99}
04-30 15:04:44.175   225   225 I Gecko   : -@- MmsService: res: {"0":125,"1":0,"2":141,"3":145,"4":139,"5":48,"6":51,"7":49,"8":69,"9":55,"10":68,"11":51,"12":49,"13":50,"14":53,"15":49,"16":54,"17":48,"18":48,"19":48}
04-30 15:04:44.175   225   225 I Gecko   : -@- MmsService: res: {"0":48,"1":51,"2":66,"3":52,"4":48,"5":48,"6":48,"7":48,"8":49,"9":0,"10":146,"11":132,"12":147,"13":79,"14":114,"15":105,"16":103,"17":105,"18":110,"19":97}
04-30 15:04:44.175   225   225 I Gecko   : -@- MmsService: res: {"0":116,"1":111,"2":114,"3":32,"4":65,"5":100,"6":100,"7":114,"8":101,"9":115,"10":115,"11":32,"12":78,"13":111,"14":116,"15":32,"16":70,"17":111,"18":117,"19":110}
04-30 15:04:44.175   225   225 I Gecko   : -@- MmsService: res: {"0":100,"1":0}
04-30 15:04:44.185   225   225 I Gecko   : -@- MmsService: Fail to send. Will retry after: 300000

Comment 27

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

(In reply to Nivi from comment #18)
> In addition, I see that when I run our ril, the code to resolve hostname
> gets invoked. I have copied a snippet of that from our logs in
> mms_mo_cdma_partner_ril.log. When I tested on partner ril, I don't see any
> resolving host name debug messages. I am curious as to why this happens?
> Maybe you can take a look.
I think the difference is how the nsINetworkInterface is implemented in MOZ RIL and QC_RIL.
For MOZ RIL, if the apn is shared APN, in this case, |default| and |mms| share the same APN.
The |type| return from nsINetworkInterface.type will always be |NETWORK_TYPE_MOBILE| if
|default| type is already connected in prior to |mms|.

That's why NetworkManager.setExtraHostRoute() was not invoked, because 
|mms| connection shares the same routing of |default| connection. :)

> 
> Thanks,
> Nivi.

Comment 28

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

Hi Nivi,

Here is the decoded response PDU of M-Send-Conf at [1] after JSON.stringifying it:
{
  "headers": {
    "x-mms-message-type":129,
    "x-mms-transaction-id":"{8a1f1fdf-0da5-4527-b4b1-f13b4cd6531c}",
    "x-mms-mms-version":17,
    "message-id":"031E7D093C5200001F600001",
    "x-mms-response-status":224,
    "x-mms-response-text":{"text":"Originator Address Not Found"}
  },
  "type":129
}

It seems that VzW's MMSC said that we didn't specify the |Originator Address| in this MO MMS PDU.
However, according to the |From| field defined in |6.1.1 Send Request| 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 current implementation, we specify the |Insert-address-token| and expect this to be filled
in the server side.
If this is the only reason that cause MO MMS failed,
you can hard-code the MDN/MSISDN of your test UICC to the |from| field in [3] to give it a try.

However, after checking the AOSP implementation, I found that 
Besides the |From| field in MMS Header, there are also some customer-specific fields in
HTTP header[4][5] that we might need to specify.
(AOSP provides a hook for vendor to specify the extra parameters needed by different carriers.
However, we don't know what parameters are for each carrier.) :-(

The better way to clarify this is 
1. Get Formal requirement from VzW to see what else needed to be specified when sending MMS.
2. Capture a tcpdump from a reference phone able to send a MMS in VzW network for reference.

Regards,
Bevis

[1] http://hg.mozilla.org/releases/mozilla-b2g28_v1_3/file/bf3fe474bf50/dom/mobilemessage/src/gonk/MmsService.js#l1292
[2] http://technical.openmobilealliance.org/Technical/release_program/docs/MMS/V1_3-20110913-A/OMA-TS-MMS_ENC-V1_3-20110913-A.pdf
[3] http://hg.mozilla.org/releases/mozilla-b2g28_v1_3/file/bf3fe474bf50/dom/mobilemessage/src/gonk/MmsService.js#l1087
[4] http://androidxref.com/4.3_r2.1/xref/packages/apps/Mms/src/com/android/mms/transaction/HttpUtils.java#181
[5] http://androidxref.com/4.3_r2.1/xref/packages/apps/Mms/src/com/android/mms/transaction/HttpUtils.java#175

Comment 29

[Preeti Raghunath(:Preeti)]

1.4+ for partner testing

Comment 30

[Nivi]

Thanks Bevis for all the info. I will try to test with the Originator address in the from field. Also capture a tcp dump on a device that sends MMS on verizon.

Will update the thread as soon as I can get to testing and getting all this info.

Ta,
Nivi.

Comment 31

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

(In reply to Preeti Raghunath(:Preeti) from comment #29)
> 1.4+ for partner testing

We've kept clarifying the root cause of this problem no matter it's 1.4+ or not.

So far, the problem is more likely to be some customization needed for VzW network 
which is out of the scope of OMA standard.
It is not possible to have any solution until we have clear understanding of 
VzW's requirement if the customization is needed. :-(

Those try/error we have done only helps to prove that the customization is needed
to support MMS in VzW network.

Bevis

Comment 32

[Ken Chang[:kenkai]]

Hi Michael,
  We understand that this issue is a critical issue for Verizon.
However, now we don't have an official product and a launching plan for Verizon, this bug seems not an 1.4+ bug. Do you have any concern if we fix/clarify this bug after 1.4?

Comment 33

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

I found some interesting information after googling the mms problem in VzW network in [1]:
    <!-- Additional http parameters used in MMS http request.
         Parameters are seperated by '|'. Optional. -->
    <string name="httpParams">x-up-calling-line-id: 1##LINE1##|X-VzW-MDN: 1##LINE1##</string>
    <!-- Substitution key to be used when adding the users telephone number (Line1) to the
         httpPrams at runtime. Optional. -->
    <string name="httpParamsLine1Key">##LINE1##</string>

This is the overlay used by Samsung Galaxy Nexus i515 for VzW.
It seems that, in addition to the |FROM field| in MMS header,
we will also have to specified these 2 parameters in the HTTP header in [2] by
xhr.setRequestHeader("x-up-calling-line-id", "1##LINE1##");
xhr.setRequestHeader("X-VzW-MDN", "1##LINE1##");
Where ##LINE1## has to be replaced to the MDN read from UICC.

Hi Nivi,

You can also give this a try to see if we are able to send the MMS 
after these extra parameters are added.  :-)

Thanks,
Bevis
--
[1] https://android.googlesource.com/device/samsung/toro/+/jb-dev/overlay/packages/apps/Mms/res/xml/mms_config.xml
[2] http://hg.mozilla.org/releases/mozilla-b2g28_v1_3/file/84623449f558/dom/mobilemessage/src/gonk/MmsService.js#l651

Comment 34

[Nivi]

Hi Bevis,

Thanks for finding out the other parameters as well. I will add all the extra 3 fields to the http request and see if we can send an MMS successfully.

Thanks,
Nivi.

Comment 35

[Nivi]

Hi Bevis,

I was able to send an MMS by setting the From field like below - 

let from = {address: "1111111111", type: "PLMN"}
msg.headers["from"] = from;

in both -
http://hg.mozilla.org/releases/mozilla-b2g28_v1_3/file/bf3fe474bf50/dom/mobilemessage/src/gonk/MmsService.js#l1087
and 
http://hg.mozilla.org/releases/mozilla-b2g28_v1_3/file/bf3fe474bf50/dom/mobilemessage/src/gonk/MmsService.js#l1390

Maybe the second one was not needed. I am not sure.

I compared behavior with android and it seems like Android sets the From field to insert_address as well but somehow before sending the MMS it gets translated to "FROM: PhoneNumber/TYPE=PLMN" in the sniffed http packet (for both CDMA and GSM MMS packets). So maybe Android always sets the FROM field. We need to figure out the missing links and implement the same for gecko to work. We could either use this bug to fix that issue or close this and open another one for the from=null case. Let me know.

Thanks,
Nivi.

Comment 36

[Preeti Raghunath(:Preeti)]

ni to answer Nivi's comments

Comment 37

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

(In reply to Nivi from comment #35)
> Hi Bevis,
> 
> I was able to send an MMS by setting the From field like below - 
> 
> let from = {address: "1111111111", type: "PLMN"}
> msg.headers["from"] = from;
> 
> in both -
> http://hg.mozilla.org/releases/mozilla-b2g28_v1_3/file/bf3fe474bf50/dom/
> mobilemessage/src/gonk/MmsService.js#l1087
> and 
> http://hg.mozilla.org/releases/mozilla-b2g28_v1_3/file/bf3fe474bf50/dom/
> mobilemessage/src/gonk/MmsService.js#l1390
> 
> Maybe the second one was not needed. I am not sure.

Hi Nivi,

Thanks for giving it a trial.
I think both are needed where 1st one is for the MO MMS and 
2nd one is for replying a read report of the read MT MMS.

> 
> I compared behavior with android and it seems like Android sets the From
> field to insert_address as well but somehow before sending the MMS it gets
> translated to "FROM: PhoneNumber/TYPE=PLMN" in the sniffed http packet (for
> both CDMA and GSM MMS packets). So maybe Android always sets the FROM field.
> We need to figure out the missing links and implement the same for gecko to
> work. We could either use this bug to fix that issue or close this and open
> another one for the from=null case. Let me know.
> 

I would like to confirm the FORM field you mentioned shall be the one in
MMS header instead of HTTP header, right?

After checking the implementation in AOSP, you are right, 
the FROM field will be set again with the phone number if available before encoding in [1][2].

However, I am not pretty sure if the solution of having FROM field filled is enough 
to resolve all the MMS transaction problem in VzW nework.
I am wondering more why those extra parameters like X-VzW-MDN 
are needed mentioned in comment 33.
In client side, there are 2 additional transactions will be fired:
RetrieveTransaction (To request a retrieval of a incoming MMS)
AcknowledgeTransaction (An ACK to M-Retrieve.conf)
The FROM field is not defined in the MMS header of these 2 transaction.
However, if VzW's MMSC requests to check the MDN from the X-VzW-MDN in HTTP header for
these transactions, we might encounter failure again in this cases.


> Thanks,
> Nivi.


[1] http://androidxref.com/4.3_r2.1/xref/packages/apps/Mms/src/com/android/mms/transaction/SendTransaction.java#108
[2] http://androidxref.com/4.3_r2.1/xref/packages/apps/Mms/src/com/android/mms/transaction/ReadRecTransaction.java#84

Comment 38

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

Do we need to land the solution of |filling FROM field with phone number| in 1.4?
I'd prefer to have this after 1.4 because thing might go wrong if 
1. the phone number we read from UICC is incorrect.
2. or there is any MMSC that only allow the dummpy |Insert-address-token| in FROM field.
If yes, this might cause new regression and delay the delivery of current ongoing projects.

Since, there is no formal CDMA project to be delivered by MOZ,
I'd like to suggest to have this solution in master,
and vendors could pick up the patch if needed.

Bevis

Comment 39

[Anshul]

(In reply to Bevis Tseng [:bevistseng] ([e-mail]) from comment #38)
> Do we need to land the solution of |filling FROM field with phone number| in
> 1.4?
> I'd prefer to have this after 1.4 because thing might go wrong if 
> 1. the phone number we read from UICC is incorrect.
> 2. or there is any MMSC that only allow the dummpy |Insert-address-token| in
> FROM field.
> If yes, this might cause new regression and delay the delivery of current
> ongoing projects.
Bevis, I am checking with the partner to see if they are able to send MMS successfully with the Madai network. Right now the partners are seeing a different issue so until then we may hold on to pushing the change to 1.4. I am removing 1.4 blocking flag until partner confirms they need this fix.

> 
> Since, there is no formal CDMA project to be delivered by MOZ,
> I'd like to suggest to have this solution in master,
> and vendors could pick up the patch if needed.
> 
As I understand 1.4 is the formal CDMA project to be delivered by Moz and other partners.

> Bevis

Comment 40

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

(In reply to Anshul from comment #39)
> Bevis, I am checking with the partner to see if they are able to send MMS
> successfully with the Madai network. Right now the partners are seeing a
> different issue so until then we may hold on to pushing the change to 1.4. I
> am removing 1.4 blocking flag until partner confirms they need this fix.
> 
Thanks.
> > 
> > Since, there is no formal CDMA project to be delivered by MOZ,
> > I'd like to suggest to have this solution in master,
> > and vendors could pick up the patch if needed.
> > 
> As I understand 1.4 is the formal CDMA project to be delivered by Moz and
> other partners.
Sorry, I didn't said it precisely. 
What I want to mention is CDMA for VzW, since 
we talked about the problem of MMS in VzW network.

I'll still try to provide a patch asap.
Then, we can land it when needed. :-)

Bevis

Comment 41

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

I've addressed problem related to FROM field in MMS Header in bug 1007542.
If there is any other issues regarding sending MMS in CDMA network,
we can start the initial discussion here.

Comment 42

[Anshul]

I have confirmation from the partners that they need this feature for 1.4. Renominating it for 1.4.

Comment 43

[Inder]

Looks like fix in bug 1007542 should be sufficient for now.

Comment 44

[Anshul]

Fix for bug 1007542 fixed this issue.