Nabibigo ang MMS sa Android kapag naka-on ang VPN: unahin ang ruta ng carrier
Gumagamit ang mga mensaheng may larawan ng sarili nilang ruta ng carrier at sariling kakayahan ng network, kaya walang pinatutunayan ang gumaganang pagba-browse. Paghiwalayin ang SMS, MMS at RCS bago hawakan ang VPN.
Naglo-load ang mga web page, gumagana ang mga tawag, at ang mensaheng may larawan ay nananatiling nasa pagpapadala nang walang error na maaari mong aksyunan. Ang kombinasyong iyon ay hindi pagkaantala ng internet. Ang MMS ay serbisyo ng carrier na may sariling configuration at sariling daan ng paghahatid, at sa Android maaaring humiling ang platform ng partikular na network para dito sa halip na gamitin muli ang rutang tinahak ng iyong browser. Tatlong desisyon ang sumusunod: aling uri ng mensahe ang talagang nabigo, kanino ang transportasyon, at kung may kinalaman ba ang VPN.
Aling uri ng mensahe ang talagang nabigo
Ang SMS, MMS ng carrier at RCS ay tatlong magkaibang serbisyo na nagbabahagi ng isang window ng usapan. Hindi sinasabi ng bula sa thread kung alin ang ginamit, at ang pag-aayos ng isa ay hindi tumatama sa iba. Ang nabigong mensaheng may larawan na talagang mensaheng RCS ay hindi maaayos sa pagbabago ng mga setting ng APN, at ang MMS na hindi kailanman umalis sa telepono ay hindi maaayos sa muling pagpaparehistro ng RCS.
Itatag ang pagkasira sa pinakasimpleng salita na mayroon: dumarating ba ang SMS na teksto lamang, nabibigo ba ang maliit na larawan sa pagpapadala, sa pagtanggap o sa dalawa, at nauna ba ang pagkasira sa VPN. Kung ang sagot ay ang mga papasok na larawan lamang ang nabibigo, tinitingnan mo ang daan ng pag-download, na kumikilos nang iba kaysa daan ng pag-upload sa limitadong network.
Humihiling ang MMS ng network, hindi lamang ruta
Inilalantad ng Android ang mga operasyon ng MMS sa pamamagitan ng SmsManager at serbisyo ng MMS ng platform, na maaaring humiling ng cellular network na may kakayahan sa MMS para sa partikular na subscription. Ito ay mas makitid na kahilingan kaysa sa pagbubukas ng app ng koneksyong HTTPS sa default na ruta. Ito rin ang dahilan kung bakit ang VPN na nagdadala ng lahat ng ordinaryong trapiko ay maaaring mabuhay kasama ng gumaganang daan ng MMS, at kung bakit lumilitaw ang kabaligtarang kombinasyon bilang pagkasira.
Mahalaga ang pagkakaiba dahil tumuturo ito sa magkaibang responsable. Kung hindi matugunan ang kahilingan ng MMS ng platform, ang problema ay nasa panig ng subscription o carrier. Kung nagtagumpay ito ngunit humihinto ang paglilipat habang aktibo ang VPN, ang integrasyon ng network ng app o ang patakaran ng VPN ang mas mabuting pinaghihinalaan. Ang paghula sa pagitan ng dalawa ang pinakamaraming nawawalang oras sa ganitong uri ng ulat.
| What you observe | Where to look first |
|---|---|
| No mobile data at all, SMS also fails | Subscription, carrier data service, SIM state |
| Browsing works, MMS fails only with the VPN on | The app's network integration or the VPN policy |
| MMS fine, RCS will not register | RCS registration, unrelated to the MMS transport |
| MMS fails on one SIM but not the other | Which subscription owns mobile data, and which sent the message |
Huwag galawin ang configuration ng carrier
Panatilihin ang inilaan na APN ng carrier, address ng MMS server at mga setting ng proxy kung ano ang mga ito. Ang pagbabago ng VPN sa iyong pag-uugali sa pagba-browse ay hindi dahilan upang idikit ang hindi pamilyar na APN o pampublikong DNS server; hindi ginagamit ng MMS ang resolver na gusto ng iyong browser, at ang maling APN ay sumisira sa nag-iisang daang gumagana.
Sa teleponong may dalawang SIM, suriin ang dalawang magkaibang bagay: aling subscription ang may mobile data ngayon, at sa aling subscription ipinadala ang mensahe. Karaniwan ang sumubok sa SIM na nagkataong may data habang ang nabigong thread ay nakatali sa isa. Ang lumang third-party na messaging app ay maaari ring gumamit ng custom o lumang daan ng network na kumikilos nang iba kaysa daang isinama sa system, kaya mas gustuhin ang dokumentadong mode ng app na inaalagaan kaysa sa mga label ng menu na natatandaan mo mula sa lumang bersyon.
Pakitirin ang paghahambing
Panatilihing pare-pareho ang lahat maliban sa isang variable na sinusuri mo: parehong app, parehong tatanggap, parehong subscription, isang maliit at hindi sensitibong larawan ng pagsubok. Itala kung nabibigo ang pagpapadala, pagtanggap o pareho, ano ang eksaktong teksto ng error, at kung nagbabago ang resulta kapag aktibo ang VPN.
Kung pinapayagan ng patakaran sa personal na device, ang maikling paghahambing na walang VPN ay naghihiwalay sa dependency. Ito ay diagnosis, hindi rekomendasyon na magtrabaho nang walang proteksyon, at sa managed o naka-lock na device ang sinusuportahang workflow ay nagmumula sa administrator at hindi sa post sa forum. Iwasan ang paulit-ulit na pagpapadala ng pribadong media para lamang muling likhain ang pagkasirang maaari mong likhain nang isang beses.
Ano ang ibibigay sa suporta, at ano ang hindi dapat ipalagay
Kung tanging ang kaso na aktibo ang VPN ang nabibigo, ang kapaki-pakinabang na ulat ay naglalaman ng pangalan at bersyon ng client, bersyon ng messaging app, uri ng network, subscription na ginagamit at ang eksaktong lokal na oras ng pagkasira. Sa limang katotohanang iyon, maaaring ihanay ng isang tao ang pagkasira sa mga log ng carrier at client sa halip na manghula.
Huwag ipalagay na ang pagbubukod sa messaging app ay ang lunas. Ang mga bahagi ng telephony ng system ay maaaring magmay-ari ng bahagi ng operasyon, at ang patakarang humaharang nang walang VPN ay kumikilos nang iba kaysa sa simpleng pagbubukod, kaya ang app ay maaaring patuloy na mabigo habang mukhang ibinukod. Subukan ang pagbubukod bilang hypothesis, itago ang resulta, at ibalik ito kung hindi sinusuportahan ng ebidensya.