Verizon MMS protocol issue (voice note/video not playing)

[Yidish]

@sh7411usa

MtkCarrierConfig.apk

carrier_config_carrierid_1839_Verizon-Wireless.xml

<?xml version="1.0" encoding="utf-8" standalone="yes"?>

<carrier_config>

<boolean name="carrier_default_wfc_ims_roaming_enabled_bool" value="true" />

<boolean name="aliasEnabled" value="true"/>

<boolean name="allowAttachAudio" value="false"/>

<boolean name="allow_add_call_during_video_call" value="false"/>

<boolean name="allow_adding_apns_bool" value="false"/>

<boolean name="allow_hold_in_ims_call" value="false"/>

<boolean name="allow_merge_wifi_calls_when_vowifi_off_bool" value="false"/>

<boolean name="apn_expand_bool" value="false"/>

<boolean name="broadcast_emergency_call_state_changes_bool" value="true"/>

<boolean name="carrier_allow_turnoff_ims_bool" value="false"/>

<boolean name="carrier_name_override_bool" value="true"/>

<boolean name="carrier_promote_wfc_on_call_fail_bool" value="true"/>

<boolean name="carrier_volte_available_bool" value="true"/>

<boolean name="carrier_volte_provisioned_bool" value="true"/>

<boolean name="carrier_volte_provisioning_required_bool" value="false"/>

<boolean name="carrier_vt_available_bool" value="true"/>

<boolean name="carrier_wfc_ims_available_bool" value="true"/>

<boolean name="disable_voice_barring_notification_bool" value="true"/>

<boolean name="drop_video_call_when_answering_audio_call_bool" value="true"/>

<boolean name="dtmf_type_enabled_bool" value="true"/>

<boolean name="editable_wfc_mode_bool" value="false"/>

<boolean name="editable_wfc_roaming_mode_bool" value="true"/>

<boolean name="enableMMSReadReports" value="false"/>

<boolean name="enableMultipartSMS" value="true"/>

<boolean name="enabledNotifyWapMMSC" value="true"/>

<boolean name="enabledTransID" value="true"/>

<boolean name="is_ims_conference_size_enforced_bool" value="true"/>

<boolean name="mdn_is_additional_voicemail_number_bool" value="true"/>

<boolean name="mmsCloseConnection" value="true"/>

<boolean name="notify_handover_video_from_lte_to_wifi_bool" value="true"/>

<boolean name="notify_handover_video_from_wifi_to_lte_bool" value="true"/>

<boolean name="notify_vt_handover_to_wifi_failure_bool" value="true"/>

<boolean name="operator_selection_expand_bool" value="true"/>

<boolean name="gps.persist_lpp_mode_bool" value="true"/>

<boolean name="prefer_2g_bool" value="false"/>

<boolean name="rtt_supported_bool" value="true"/>

<boolean name="show_apn_setting_cdma_bool" value="true"/>

<boolean name="use_rcs_presence_bool" value="false"/>

<boolean name="sms_requires_destination_number_conversion_bool" value="true"/>

<boolean name="support_3gpp_call_forwarding_while_roaming_bool" value="false"/>

<boolean name="support_downgrade_vt_to_audio_bool" value="false"/>

<boolean name="support_pause_ims_video_calls_bool" value="true"/>

<boolean name="support_swap_after_merge_bool" value="false"/>

<boolean name="treat_downgraded_video_calls_as_video_calls_bool" value="true"/>

<boolean name="video_calls_can_be_hd_audio" value="false"/>

<boolean name="mtk_vt_over_wifi_check_wfc_enable_bool" value="false" />

<boolean name="voicemail_notification_persistent_bool" value="true"/>

<boolean name="wifi_calls_can_be_hd_audio" value="false"/>

<boolean name="world_mode_enabled_bool" value="true"/>

<int name="aliasMaxChars" value="48"/>

<int name="aliasMinChars" value="2"/>

<int name="carrier_default_wfc_ims_mode_int" value="1"/>

<int name="carrier_default_wfc_ims_roaming_mode_int" value="1"/>

<int name="ims_conference_size_limit_int" value="5"/>

<int name="lte_earfcns_rsrp_boost_int" value="6"/>

<int name="maxImageHeight" value="1944"/>

<int name="maxImageWidth" value="2592"/>

<int name="maxMessageSize" value="1258291"/>

<int name="maxSubjectLength" value="80"/>

<int name="recipientLimit" value="20"/>

<int name="smsToMmsTextThreshold" value="7"/>

<int name="volte_replacement_rat_int" value="6"/>

<int name="wfc_spn_format_idx_int" value="1"/>

<string name="carrier_eri_file_name_string">eri_311480.xml</string>

<string name="carrier_name_string">Verizon</string>

<string name="default_vm_number_string">\*86</string>

<string name="emailGatewayNumber">6245</string>

<string name="httpParams">x-up-calling-line-id: 1##LINE1NOCOUNTRYCODE##|X-VzW-MDN: 1##LINE1NOCOUNTRYCODE##</string>

<string name="uaProfTagName">Profile</string>

<string name="sim_country_iso_override_string">us</string>

<string-array name="boosted_lte_earfcns_string_array" num="2">

    <item value="600-1199"/>

    <item value="1950-2399"/>

</string-array>

<string-array name="call_forwarding_blocks_while_roaming_string_array" num="2">

    <item value="\*71"/>

    <item value="\*72"/>

</string-array>

<string-array name="carrier_data_call_permanent_failure_strings" num="11">

    <!--M: \[VzW\] Data Framework

           \[LTE\]\[DR\]\[6.9\] VZ_TC_DATARTRY_53688; VZ_REQ_LTEDATARETRY_7767:

           For LTE Release 11 and earlier UEs, we should retry the same APN once for

           fail cause: 8, 27, 29, 32, 33, 112. -->

    <!--<item value="OPERATOR_BARRED"/>-->

    <!--<item value="MISSING_UNKNOWN_APN"/>-->

    <item value="UNKNOWN_PDP_ADDRESS_TYPE"/>

    <!--<item value="USER_AUTHENTICATION"/>-->

    <item value="ACTIVATION_REJECT_GGSN"/>

    <!--<item value="SERVICE_OPTION_NOT_SUPPORTED"/>-->

    <!--<item value="SERVICE_OPTION_NOT_SUBSCRIBED"/>-->

    <item value="NSAPI_IN_USE"/>

    <item value="ONLY_IPV4_ALLOWED"/>

    <item value="ONLY_IPV6_ALLOWED"/>

    <item value="PROTOCOL_ERRORS"/>

    <item value="RADIO_POWER_OFF"/>

    <item value="TETHERED_CALL_ACTIVE"/>

    <item value="RADIO_NOT_AVAILABLE"/>

    <item value="UNACCEPTABLE_NETWORK_PARAMETER"/>

    <item value="SIGNAL_LOST"/>

</string-array>

<string-array name="carrier_metered_apn_types_strings" num="3">

    <item value="default"/>

    <item value="dun"/>

    <item value="supl"/>

</string-array>

<string-array name="carrier_metered_roaming_apn_types_strings" num="4">

    <item value="default"/>

    <item value="dun"/>

    <item value="mms"/>

    <item value="supl"/>

</string-array>

<string-array name="dial_string_replace_string_array" num="2">

    <item value="\*611:+19085594899"/>

    <item value="\*86:+1MDN"/>

</string-array>

<string-array name="filtered_cnap_names_string_array" num="2">

    <item value="WIRELESS CALLER"/>

    <item value="UNKNOWN NAME"/>

</string-array>

<string-array name="ims_reasoninfo_mapping_string_array" num="10">

    <item value="332|simultaneous call limit has already been reached|1403"/>

    <item value="332|Forbidden: Simultaneous Call Limit Has Already Been Reached|1403"/>

    <item value="338|another device sent all devices busy response|1404"/>

    <item value="501|call completion elsewhere|1014"/>

    <item value="501|call has been pulled by another device|1016"/>

    <item value="510|call has been pulled by another device|1016"/>

    <item value="501|another device sent all devices busy response|1404"/>

    <item value="510|another device sent all devices busy response|1404"/>

    <item value="1014|call has been pulled by another device|1016"/>

    <item value="\*|Call is dropped due to Wi-Fi signal is degraded|1407"/>

</string-array>

<string-array name="read_only_apn_fields_string_array" num="20">

    <item value="name"/>

    <item value="proxy"/>

    <item value="port"/>

    <item value="user"/>

    <item value="password"/>

    <item value="server"/>

    <item value="mmsc"/>

    <item value="mmsproxy"/>

    <item value="mmsport"/>

    <item value="mcc"/>

    <item value="mnc"/>

    <item value="authtype"/>

    <item value="type"/>

    <item value="protocol"/>

    <item value="roaming_protocol"/>

    <item value="bearer"/>

    <item value="bearer_bitmask"/>

    <item value="carrier_enabled"/>

    <item value="mvno_type"/>

    <item value="mvno_match_data"/>

</string-array>

<int-array name="lte_rsrp_thresholds_int_array" num="4">

    <item value="-115"/>

    <item value="-105"/>

    <item value="-95"/>

    <item value="-85"/>

</int-array>

<int-array name="cdma_enhanced_roaming_indicator_for_home_network_int_array" num="11">

    <item value="64"/>

    <item value="65"/>

    <item value="66"/>

    <item value="76"/>

    <item value="77"/>

    <item value="78"/>

    <item value="79"/>

    <item value="80"/>

    <item value="81"/>

    <item value="82"/>

    <item value="83"/>

</int-array>

<string name="5g_icon_display_grace_period_string"

    value="connected_mmwave,any,3;not_restricted_rrc_idle,not_restricted_rrc_con,2"/>

<string name="5g_icon_display_secondary_grace_period_string"

    value="connected_mmwave,not_restricted_rrc_idle,60"/>



<boolean name="mtk_resume_hold_call_after_active_call_end_by_remote" value="true"/>

<boolean name="mtk_disallow_outgoing_calls_during_video_or_voice_call_bool" value="true"/>

<boolean name="ignore_rtt_mode_setting_bool" value="true"/>

<boolean name="mtk_vt_dialpad_support_bool" value="true" />

<boolean name="support_auto_decline_upgrade_request_bool" value="false" />

<boolean name="rtt_supported_for_vt_bool" value="false"/>

<boolean name="rtt_upgrade_supported_bool" value="true"/>

<boolean name="rtt_downgrade_supported_bool" value="false"/>

<boolean name="mtk_rtt_video_switch_supported_bool" value="false"/>

<boolean name="mtk_rtt_auto_accept_request_bool" value="true"/>

<boolean name="mtk_multi_rtt_calls_supported_bool" value="true"/>

<boolean name="mtk_mt_rtt_without_precondition_bool" value="true"/>

<boolean name="allow_hold_call_during_emergency_bool" value="true"/>

</carrier_config>

Proposed solution

Claude’s 2 cents (actually, it probably cost more than that):

Verizon MMS Compression Bug on Qin F21 — Root Cause Analysis

Background

Verizon users on the Qin F21 (and similar small-form-factor Android phones built on MediaTek chipsets) experience two related MMS problems:

1. Received images are heavily compressed — blurry, often unreadable text in screenshots or documents

2. Voice notes are unplayable (separate but related issue, addressed in ROM 613)

The forum consensus was that the issue is tied to how the device identifies itself to Verizon’s servers, not to the messaging app in use. The problem affects Google Messages, QKSMS, and every other third-party app. Only Verizon’s own Message+ app is immune, because it uses a proprietary out-of-band authentication mechanism rather than the standard Android MMS stack.

This document traces the problem from the Android framework all the way down to the specific missing lines in the carrier config APK.

---

How Android MMS Works — The Relevant Path

When a message app (Google Messages, etc.) needs to send or receive an MMS, it does not handle the HTTP transaction itself. Instead it delegates to the Android telephony framework via SmsManager.getCarrierConfigValues() and the platform MMS service. The sequence is:

1. The messaging app calls SmsManager.getCarrierConfigValues(subId)

2. This hits SmsController.getCarrierConfigValuesForSubscriber() in the telephony framework

3. SmsController reads the CarrierConfig bundle for the active SIM — the config that carrier config APKs (like MtkCarrierConfig) supply

4. A filtered subset of those keys is returned to the messaging app

5. The messaging app (or the platform MMS service) uses those values to construct the HTTP POST to Verizon’s MMSC (Multimedia Messaging Service Center)

The MMSC is Verizon’s server-side component. It receives inbound MMS, decides what quality/resolution to use when delivering to the recipient, and delivers it. The quality decision is driven by the device identity headers in the HTTP request.

---

Investigation Step 1 — The Carrier Config APK

The device ships with a MediaTek-customized carrier config APK at /system_ext/priv-app/MtkCarrierconfig/MtkCarrierConfig.apk. This APK contains per-carrier XML files under assets/ that supply carrier-specific settings to Android’s CarrierConfigManager.

The file for Verizon is:

assets/carrier_config_carrierid_1839_Verizon-Wireless.xml

There is also a legacy fallback keyed to Verizon’s MCC/MNC:

assets/carrier_config_mccmnc_311012.xml

The DefaultCarrierConfigService.smali (the APK’s only Java class) shows the config loading priority: it tries carrierid_<specificCarrierId>_*, then carrierid_<carrierId>_*, then carrierid_<mccmncDerivedId>_*, and finally falls back to carrier_config_mccmnc_<mcc><mnc>.xml. All four tiers are merged, with higher-priority tiers winning on conflicts.

MMS-Relevant Keys in the Verizon Config

Scanning the Verizon XML against the full set of MMS-relevant carrier config keys:

Key	Value in Verizon XML	Purpose
uaProfTagName	"Profile"	HTTP header name for UAProf
uaProfUrl	not present	URL placed in the UAProf header
userAgent	not present	Override for the HTTP User-Agent string
httpParams	`x-up-calling-line-id: 1##LINE1NOCOUNTRYCODE##	X-VzW-MDN: 1##LINE1NOCOUNTRYCODE##`
maxImageWidth	2592	Max width before sending
maxImageHeight	1944	Max height before sending
maxMessageSize	1258291 (~1.2 MB)	Max total MMS size

The httpParams field correctly injects the subscriber’s phone number into every MMSC request. The maxImage* values are generous. But uaProfUrl and userAgent — the two keys that tell Verizon’s MMSC what device it is talking to — are completely absent.

The same absence exists in carrier_config_mccmnc_311012.xml, the fallback config.

---

Investigation Step 2 — The Telephony Framework

To confirm exactly how these keys travel from the config file to the MMS HTTP request, telephony-common.jar was decompiled with jadx. The jar contains the Android telephony framework classes compiled for this device.

The critical method is SmsController.getMmsConfig(), located at com/android/internal/telephony/SmsController.java:389:

private static Bundle getMmsConfig(BaseBundle config) {
    Bundle filtered = new Bundle();
    // ... boolean and int keys omitted for brevity ...
    filtered.putString("uaProfTagName", config.getString("uaProfTagName"));  // line 415
    filtered.putString("userAgent",     config.getString("userAgent"));       // line 416
    filtered.putString("uaProfUrl",     config.getString("uaProfUrl"));       // line 417
    filtered.putString("httpParams",    config.getString("httpParams"));      // line 418
    filtered.putString("emailGatewayNumber", config.getString("emailGatewayNumber"));
    // ...
    return filtered;
}

This method is called by the public system service method getCarrierConfigValuesForSubscriber() (line 379), which is what SmsManager.getCarrierConfigValues() ultimately invokes. Every messaging app on the device goes through this exact code path.

What this confirms:

• uaProfUrl is read verbatim from the carrier config bundle and forwarded to every MMS client. Since the Verizon XML doesn’t set it, every app gets back null.

• userAgent is likewise read and forwarded. Since it is also absent, every app gets back null.

• When the MMS HTTP client receives null for uaProfUrl, it sends no Profile: header (or an empty one). When it receives null for userAgent, it falls back to constructing a generic User-Agent from android.os.Build.MODEL, which on this device resolves to something containing "Qin F21".

---

What Verizon’s MMSC Does With This

When Verizon’s MMSC receives an MMS POST it evaluates two HTTP headers to determine device capabilities:

1. The Profile: Header (UAProf)

The Profile: header (whose name comes from uaProfTagName) contains a URL pointing to a UAProf XML — a standardized device capability declaration. It describes things like maximum supported image resolution, accepted MIME types, and screen dimensions.

A certified Verizon device (e.g. Samsung Galaxy S22) sends something like:

Profile: http://wap.samsungmobile.com/uaprof/SM-S901U.xml

Verizon’s MMSC fetches that URL, reads the profile, confirms the device can handle full-resolution content, and delivers the MMS at full quality.

The Qin F21 sends no Profile: header at all because uaProfUrl is null. The MMSC sees an unrecognized device and falls back to its lowest-common-denominator delivery policy: aggressive downscaling.

2. The User-Agent Header

As a secondary identity signal, the MMSC also inspects the HTTP User-Agent string. For the Qin F21, with no userAgent override in carrier config, the MMS stack assembles a string from system properties that includes the literal device model name — something like:

Dalvik/2.1.0 (Linux; U; Android 11; Qin F21 Build/...)

"Qin F21" is not in Verizon’s certified-device database, so even if the MMSC falls back to UA-string-based identification, it still cannot match the device to a known capability profile.

Why Message+ Is Immune

Verizon’s own Message+ app bypasses the standard Android MMS stack entirely. It registers the device with Verizon’s servers using the account credentials from the Verizon app, receiving a session token that the MMSC trusts regardless of what Profile: header is sent. Third-party apps have no access to this registration mechanism and rely entirely on the carrier config values.

Why the maxImage* Values Don’t Help

A common suggestion is to increase maxImageWidth and maxImageHeight. These values control what the sending device does before uploading — they cap the resolution the local device will encode before posting to the MMSC. They have absolutely no effect on what the MMSC does when delivering to the Qin F21. The compression being reported is happening on the delivery path, server-side, based on Verizon’s assessment of the recipient device’s capabilities.

---

The Fix

The fix requires patching MtkCarrierConfig.apk to add the two missing keys.

Files to Modify

1. MtkCarrierConfig/assets/carrier_config_carrierid_1839_Verizon-Wireless.xml — primary Verizon config

2. MtkCarrierConfig/assets/carrier_config_mccmnc_311012.xml — MCCMNC fallback config

Keys to Add

<string name="uaProfUrl">URL_OF_CERTIFIED_DEVICE_UAPROF</string>
<string name="userAgent">UA_STRING_OF_CERTIFIED_DEVICE</string>

Both values should reference the same certified Verizon device, so the MMSC sees a consistent identity across both signals.

Sourcing the Correct Values

The safest way to get confirmed working values is to dump the carrier config from a real Verizon-certified Android device:

adb shell dumpsys carrier_config

Look for the uaProfUrl and userAgent entries in the Verizon block. Any modern Pixel (6, 7, 8) or Samsung Galaxy S-series certified for Verizon will have these set. The UAProf URLs are public — they live on manufacturer servers (e.g. wap.samsungmobile.com, wap.samsungmobile.com, or Google’s static servers for Pixel) and can be fetched in a browser to verify they describe a high-capability device.

Example of what a complete, working Verizon config entry looks like (values are illustrative — use real values sourced from a certified device):

<string name="uaProfUrl">http://wap.samsungmobile.com/uaprof/SM-S901U.xml</string>
<string name="userAgent">Mozilla/5.0 (Linux; Android 12; SM-S901U Build/SP1A.210812.016; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/96.0.4664.45 Mobile Safari/537.36</string>

Rebuilding and Deploying the APK

# Repack with apktool
apktool b MtkCarrierConfig -o MtkCarrierConfig-patched.apk

# Sign with the platform key (required — this is a priv-app)
java -jar signapk.jar platform.x509.pem platform.pk8 \
     MtkCarrierConfig-patched.apk MtkCarrierConfig-signed.apk

# Push to device (requires root)
adb root
adb remount
adb push MtkCarrierConfig-signed.apk \
     /system_ext/priv-app/MtkCarrierconfig/MtkCarrierConfig.apk
adb shell chmod 644 /system_ext/priv-app/MtkCarrierconfig/MtkCarrierConfig.apk
adb reboot

After reboot, verify the config was loaded with:

adb shell dumpsys carrier_config | grep -E "uaProfUrl|userAgent|uaProfTagName"

Both new keys should appear with their values for the Verizon subscription.

---

Why This Will Work

The Android MMS path from messaging app to MMSC is a direct, transparent chain:

Carrier Config XML
      ↓
CarrierConfigManager (system service)
      ↓
SmsController.getMmsConfig()        ← telephony-common.jar, confirmed
      ↓
SmsManager.getCarrierConfigValues() ← what every messaging app calls
      ↓
MMS HTTP client
      ↓  Profile: <uaProfUrl>
      ↓  User-Agent: <userAgent>
      ↓  x-up-calling-line-id: <phone>
      ↓  X-VzW-MDN: <phone>
Verizon MMSC

Every link in this chain is confirmed. The only broken links are the two missing values in the XML. Once they are present, the MMSC will receive a Profile: header pointing to a known certified device’s UAProf, look up that device’s declared capabilities (full resolution, large JPEG, etc.), and deliver MMS content accordingly.

No changes are needed to any messaging app. The fix is purely in the carrier config layer, which is the correct and intended place for per-carrier MMS tuning in Android’s architecture.

---

Summary Table

Component	File / Location	Finding
Carrier Config APK	MtkCarrierConfig/assets/carrier_config_carrierid_1839_Verizon-Wireless.xml	uaProfUrl and userAgent absent
MCCMNC Fallback	MtkCarrierConfig/assets/carrier_config_mccmnc_311012.xml	Same two keys absent
Telephony Framework	telephony-common.jar → SmsController.java:389–424	Confirms both keys forwarded verbatim to all MMS clients; null when absent
Identity Header	uaProfTagName = "Profile"	Header name is correct; URL to put in it is missing
User-Agent	userAgent key	No override; device sends “Qin F21” which Verizon doesn’t recognize
Size Limits	maxImageWidth/Height, maxMessageSize	Already generous; irrelevant to server-side compression on delivery

So, bekitzur tl;dr vechulu - we need a profile header and a user agent from a certified device. Rabbosai?
hint

on the Qin V6.1.3 there is another file in system/system_ext/etc/custom.conf which it has the user agent for mms and UAprofile…

[jumptoheaven]

Anyone with a Pixel. adb shell dumpsys carrier_config | findstr “uaProfUrl userAgent”

[Yidish]

Can do tomorrow.

Does it have any unique information in it, or it’s just general info which is the same on any pixel?

[jumptoheaven]

Idk. Tried it on a Samsung and it came up blank.

Maybe a pixel is different?

[Zvi_Wolf]

@jumptoheaven

Anyone with a Pixel. adb shell dumpsys carrier_config | findstr “uaProfUrl userAgent”

Note on Linux replace finstr with grep

[flipphoneguy]

And in termux replace adb shell with sudo

[jumptoheaven]

@jumptoheaven

adb shell dumpsys carrier_config | findstr "uaProfUrl userAgent

Claude says

That’s a really astute observation. These values might be set in a layer that dumpsys carrier_config doesn’t show — specifically:

• Samsung has SemCarrierConfig (their proprietary layer)

• TCL and other brands may have their own OEM config layer

• Google Pixels have CarrierSettings.apk with binary protobuf configs

All of these sit outside the standard Android CarrierConfigManager that dumpsys reads from. So dumpsys would show empty even if the values are actually being used at a lower level.

This would mean:

1. The UAProf theory might actually still be correct

2. Samsung and TCL do have these values set, just invisibly to dumpsys

3. The F21 Pro has no such proprietary layer, so the values are genuinely missing

To test this theory on the Samsung without root, you could install Network Log or PCAPdroid on it — no root needed, uses Android VPN API — and capture the actual HTTP headers it sends to mms.vtext.com when receiving an MMS.

If the Samsung’s actual HTTP request shows a x-wap-profile header with a URL, that confirms the values are there but hidden from dumpsys.

Worth trying before we go further down the APN path. Can you install PCAPdroid on the Samsung or any Smartphone?

Set it up on the Samsung to capture MMS traffic:

1. Install PCAPdroid on the Samsung

2. Open PCAPdroid and start a capture

3. Set the target app to Messages (or whatever SMS app is default)

4. Have someone send the Samsung an MMS

5. Stop the capture

6. Export the pcap file and pull it to Windows via USB

7. Open in Wireshark and look at the HTTP headers in the request to mms.vtext.com

Specifically we want to see if the Samsung’s request contains:

x-wap-profile: http://...
User-Agent: ...

If it does — those values exist but are hidden from dumpsys, the UAProf theory is still alive, and we need to find a way to inject those same headers on the F21 Pro.

If it doesn’t — then Samsung gets full quality MMS through some completely different mechanism and we need to rethink entirely.

This is probably the single most useful test we can do right now. Do you want to try it?

It would be very hard for me to try this as I don’t use a Smartphone… If anyone else can that would be really helpful.

Spent way too much time on this already

[Yidish]

here you go for commands dumpsys carrier_config
adb shell dumpsys carrier_config.zip (19.9 KB)

[ars18]

pcapdroid will not help for this, does not get routed that way.

Here’s the full mms (picture) download request on a OnePlus 12 on Verizon:

stuffs

MMS DOWNLOAD REQUESTS — captured via strace on com.android.phone
Captured: 2026-05-28 09:43–09:46 EDT
Device: OnePlus (UA code: odopcph2583)
Your number: [YOUR_NUMBER]
MMS APN IP:  10.145.180.101  (vzwims APN, separate from internet APN 100.111.109.20)
Transport:   PLAIN HTTP (no TLS, no encryption)

====================================================================
TRANSACTION 1
====================================================================
Time:    09:44:07 EDT
MMSC:    63.59.166.90 port 80  (Verizon)
Local:   10.145.180.101:48562

--- REQUEST (exact bytes on wire) ---
GET /servlets/mms?message-id=09791460AEBE0000C6A0010101 HTTP/1.1
Accept: */*, application/vnd.wap.mms-message, application/vnd.wap.sic
Accept-Language: en-US
User-Agent: odopcph2583
Profile: http://uaprof.vtext.com/OnePlus/odopcph2583/odopcph2583.xml
Connection: close
x-up-calling-line-id: [YOUR_NUMBER]
X-VzW-MDN: [YOUR_NUMBER]
Host: 63.59.166.90
Accept-Encoding: gzip

--- RESPONSE ---
HTTP/1.1 200 OK
Date: Thu, 28 May 2026 13:44:07 GMT
Server: Apache
Content-Length: 131250
Connection: close
Content-Type: application/vnd.wap.mms-message

MMS PDU headers (decoded):
  X-Mms-Message-Type:    m-retrieve-conf
  X-Mms-Transaction-Id:  09791460AEBE0000C6A0010101
  X-Mms-Message-Id:      09791460AEBE0000C6A00101
  X-Mms-From:            [SENDER_NUMBER]/TYPE=PLMN
  X-Mms-To:              [YOUR_NUMBER]/TYPE=PLMN
  Attachment filename:   123_1.jpeg
  Body:                  JPEG image (128 KB, JFIF magic confirmed)

====================================================================
TRANSACTION 2
====================================================================
Time:    09:44:13 EDT
MMSC:    63.59.166.90 port 80  (Verizon)
Local:   10.145.180.101:34662

--- REQUEST (exact bytes on wire) ---
GET /servlets/mms?message-id=097914611A970000D580020101 HTTP/1.1
Accept: */*, application/vnd.wap.mms-message, application/vnd.wap.sic
Accept-Language: en-US
User-Agent: odopcph2583
Profile: http://uaprof.vtext.com/OnePlus/odopcph2583/odopcph2583.xml
Connection: close
x-up-calling-line-id: [YOUR_NUMBER]
X-VzW-MDN: [YOUR_NUMBER]
Host: 63.59.166.90
Accept-Encoding: gzip

--- RESPONSE ---
HTTP/1.1 200 OK
Date: Thu, 28 May 2026 13:44:12 GMT
Server: Apache
Content-Length: 75078
Connection: close
Content-Type: application/vnd.wap.mms-message

MMS PDU headers (decoded):
  X-Mms-Message-Type:    m-retrieve-conf
  X-Mms-Transaction-Id:  097914611A970000D580020101
  X-Mms-Message-Id:      097914611A970000D5800201
  X-Mms-From:            [SENDER_NUMBER]/TYPE=PLMN
  X-Mms-To:              [YOUR_NUMBER]/TYPE=PLMN
  Attachment filename:   123_1.jpeg
  Body:                  JPEG image (73 KB, JFIF magic confirmed)

====================================================================
TRANSACTION 3
====================================================================
Time:    09:44:15 EDT
MMSC:    63.59.139.26 port 80  (Verizon, alternate MMSC)
Local:   10.145.180.101:42568

--- REQUEST (exact bytes on wire) ---
GET /servlets/mms?message-id=0E79146141CC00000B40000101 HTTP/1.1
Accept: */*, application/vnd.wap.mms-message, application/vnd.wap.sic
Accept-Language: en-US
User-Agent: odopcph2583
Profile: http://uaprof.vtext.com/OnePlus/odopcph2583/odopcph2583.xml
Connection: close
x-up-calling-line-id: [YOUR_NUMBER]
X-VzW-MDN: [YOUR_NUMBER]
Host: 63.59.139.26
Accept-Encoding: gzip

--- RESPONSE ---
HTTP/1.1 200 OK
Date: Thu, 28 May 2026 13:44:15 GMT
Server: Apache
Content-Length: 109856
Connection: close
Content-Type: application/vnd.wap.mms-message

MMS PDU headers (decoded):
  X-Mms-Message-Type:    m-retrieve-conf
  X-Mms-Transaction-Id:  0E79146141CC00000B40000101
  X-Mms-Message-Id:      0E79146141CC00000B400001
  X-Mms-From:            [SENDER_NUMBER]/TYPE=PLMN
  X-Mms-To:              [YOUR_NUMBER]/TYPE=PLMN
  Attachment filename:   123_1.jpeg
  Body:                  JPEG image (107 KB, JFIF magic confirmed)

====================================================================
WHAT VERIZON SEES (for every MMS you download)
====================================================================
1. Your phone number (MDN) in two headers:
     x-up-calling-line-id: [YOUR_NUMBER]
     X-VzW-MDN: [YOUR_NUMBER]

2. Your exact device model (OnePlus UA code odopcph2583) in two places:
     User-Agent: odopcph2583
     Profile: http://uaprof.vtext.com/OnePlus/odopcph2583/odopcph2583.xml

3. The message-id from the WAP-Push notification — Verizon already stored
   the full MMS on their server before your phone fetched it. You are
   retrieving a copy from their store.

4. The full plaintext conversation (sender, recipient, attachments) is
   returned in the HTTP body. There is no encryption at any layer.

5. No M-NotifyResp.ind POST was observed — your device silently fetches
   without acknowledging back to the MMSC (or the ACK happens via SMS/WAP).

[flipphoneguy]

Now that you have this it should be real easy. Not sure if every device works differently though. I can’t test cuz I’m in Israel

[ars18]

Run on f21 pro and send an mms:

bash mms_capture.sh

mms_capture.sh (12.9 KB)

Need to be rooted obviously.

Upload results.

[flipphoneguy]

So basically @ars18 if you upload your carrier config, there’s good chances we can just modify any phones carrier config with the values from yours.

[ars18]

OnePlus 12

CarrierConfig.apk (262.6 KB)

[walt_cohn]

I changed the UAProf url to the OnePlus in custom.conf and carrierconfig.xml and it it didn’t help

[flipphoneguy]

Same exact as aosp. Not here. According to Claude’s research in aosp docs, the other options are com.verizon.mips.services or maybe some sort of overlay in vendor or something

But I’m not gonna pull you down this rabbit hole especially since I don’t even know for sure Claude is right (unless you really want to )

[flipphoneguy]

In which files? Why’d you think it was supposed to go there?

[walt_cohn]

/data/user_de/0/com.android.phone/files/carrierconfig-com.android.carrierconfig-89148000006944261898-1839.xml

/system/system_ext/etc/custom.conf

The first because Claude claimed it should be there and the second someone here pointed out that the qin stores the profurl there.

[ars18]

Run on f21:

MMSCapture.apk (337.0 KB)

@flipphoneguy ur template. Thanks

[walt_cohn]

[+] strace ready: /data/local/tmp/strace_mmsc
[+] com.android.phone found (PID 1915)
[*] Output dir: /data/local/tmp/mms-capture-20260528-124507
[*] Strace running — 45s window
[*] Send yourself an MMS NOW
[+] Capture window closed.
[*] strace log:
Attaching to PID=1915
WARNING: linker: Warning: “/data/local/tmp/strace_mmsc” unused DT entry: unknown processor-specific (type 0x70000001 arg 0x0) (ignoring)
Illegal instruction

MMS DOWNLOAD REQUESTS – captured via strace on com.android.phone
Captured: 2026-05-28
Transport: PLAIN HTTP (no TLS, no encryption)

No MMSC transactions found.
Log lines captured: 4

All connect() calls in log:
(none)

[ars18]

MMSCapture.apk (341.0 KB)

My strace not compatible. Try this build