Woran liegt es wenn MMs mit Sound nicht übermittelt werden?

Situation: bei Versand über massenversand.de wurde die MM vom HTTP-Interface akzeptiert (Rückgabewert
»200 OK«, komischerweise jedoch anders als üblich ohne Längenangabe wie etwa »200 OK (49832))«. Während jedoch sonst nach eta 18 Sekunden eine SMS-Benachrichtigung dem Ziel-Handy erschien (ein nicht MMS-fähiges Endgerät), wurde in diesem Fall nichts empfangen (auch nach 12 Stunden nicht). Der Versuch wurde wiederholt mit einer reinen Text-MM (ohne Bilder oder Sound); dies gelang problemlos.

Im vorliegenden Fall waren die URLs derart beschaffen, dass der User Agent beeinflusste was abgerufen wurde: der korrekte Inhalt mit einem Browser, aber Inhalt einer Teergrube (Spammer-Falle) per Weiterleitung auf eine andere Subdomain wenn man wget verwendete (und wohl auch andere Spider-artige Programme). Das lag nicht daran dass der Subdomain-Name (noch) unbekannt wäre: es passierte auch bei schon sehr lange bestehenden Subdomains. Es lag an sog. HotLink-Schutz: direkter Zugriff auf Links zu Bildern und anderen Inhalten von anderen Internetseiten aus war unmöglich gemacht worden durch ein Script des Providers. Zugriffsversuche wurden an eine Teergrube weitergeleitet.

Dies scheint jedoch nicht das Problem gewesen zu sein: MMs mit Sound-Anhängen (im AMR-Format) wurden auch nach Behebung der Teergruben-Weiterleitung nicht versandt (es wurde keine Längenangabe zurückgegeben). Jedoch wurden MMs mit Bildern korrekt versandt (Längenangabe wurde zurückgegeben und nach
18 Sekunden traf die Benachrichtigung ein). Sie konnten im T-Mobile Webinterface korrekt angesehen werden
(mit konqueror jedoch nur in der Druckversion der MM).

Da massenversand.de die MMs korrekt nach Größe in die Statistik einfügt auch wenn keine Größenangabe zurückgegeben wurde (hier: 3 MMs wurden als »über 30 kByte« eingestuft) scheint die zurückzugebende Größenangabe eine Information zu sein die massenversand.de nicht selbst ermittelt sondern vom Netzbetreiber nach Übergabe der MM als Rückgabewert erhält. Am Vorhandensein dieser Information kann man also erkennen ob der Netzbetreiber die MM akzeptiert.

Also scheint die Encodierung (oder Größe) der Sound-Dateien zu bewirken dass der Netzbetreiber die MM nicht akzeptiert. Versuchsweise wurde statt selbst encodierter AMR-Dateien ein heruntergeladener AMR-Klingelton versandt der halb so groß wie das zuvor erfolgreich versandte Bild war. Dies gelang problemlos. Während konqueror unter www.mms.t-mobile.de nur Textinhalte (und in der Druckansicht auch Bilder) darstellen kann, kann firefox auch die Sounds abspielen. Es sind WAV-Dateien, z.B. »0s.amr.wav« die in der Druckansicht gespeichert werden können.

Um zu prüfen ob der Speicherort doch einen Einfluss auf den Erfolg der Nachrichtenübermittlung hat wurde nun derselbe Klingelton an einem Ort gespeichert an dem zuvor einmal eine selbst encodierte AMR-Datei gespeichert war aber nicht erfolgreich an ein Handy übermittelt werden konnte (http://mms.ansorgs.de/23.amr). Diese Nachricht wurde erfolgreich versandt (der Ort http://mms.ansorgs.de/ funktioniert also). Allerdings enthielt die MM die die _alte_, selbst aufgenommene AMR-Datei und der Rückgabewert enthielt auch eine entsprechende Größe: »200 OK (46812)« statt wie erwartet »200 OK (3469)«! (Vielleicht liegt das an Caching des Netzwerkbetreibers o.ä.). Diese AMR-Datei konnte auch korrekt angehört werden (in Form der WAV-Datei auf www.mms.t-online.de); die Codierung der AMR-Dateien ist also korrekt.

Der Fehler scheint also nicht an den AMR-Dateien zu liegen sondern an der Art des Versands (der Versand funktionierte wenn die (Bild- oder Sounddatei) manuell hochgeladen wurde und die URL danach ermittelt und in den entsprechenden HTTP-Parameter geschrieben wurde; mit einem eigenen Script das E-Mails zu MMs konvertiert und die Dateien (auf denselben Ort) hochlädt funktionierte der Versand nicht).

Also Test: eine MM versenden mit manuell hochgeladener selbst codierter AMR-Datei. Dies funktionierte problemlos (es wurde dieselbe AMR-Datei verwendet auf die vorher per Cache o.ä. fälschlich zugegriffen wurde). Auch Größe scheint also nicht das Problem zu sein (diese hatte 46 kByte).

Und nun Test: dieselbe AMR-Datei per E-Mail versenden, vom Script abrufen und automatisch hochladen lassen. (Konvertierung von WAV zu AMR ist bei diesem Test noch nicht notwendig.) Das Script hat keine Probleme mit Zugriffsrechten denn die automatisch hochgeladene AMR-Datei kann von jedem Browser aus abgerufen werden. Dieser Test jedoch funktionierte nicht (keine Größenangabe in der Antwort). Die automatisch hochgeladene Datei ist jedoch Bit für Bit identisch mit der zuvor manuell hochgeladenen Datei. Die automatisch hochgeladene Datei ist auch nicht fehlerhaft: verwendet man ihre URL in einer nun manuell versandten MM, wird diese einwandfrei zugestellt. Die Sendeprotokolle unterscheiden sich nicht in wichtigen Merkmalen (URL usw. sind gleich, nur dass einmal die Größenangabe bei der Rückantwort fehlt und einmal nicht).

Was sind nun die Unterschiede zwischen beiden Versandarten? Eventuell ist eine Wartezeit nach dem Upload der Datei und vor dem Versand der MM nötig. Das ist beim manuellen Versand gegeben, jedoch nicht beim automatischen Versand. Also wurde sleep(15) nach dem Upload und vor dem Versand eingefügt; die MM wurde jedoch nicht korrekt versandt (keine Rückgabe der Größe).

Jedoch zeigte der Versand reiner Textnachrichten über E-Mail-Konvertierung denselben Fehler (keine Rückgabe der Größe). Das Problem scheint also nicht an Wartezeiten oder ähnlichen schwer durchschaubaren Eigenschaften zu liegen. Es sollte also versucht werden, per Einzelversand eine MM zu erzeugen die genau dieselben Daten enthält wie die Text-MM die per E-Mail-Konvertierung nicht versandt werden konnte. Das war tatsächlich erfolgreich. Die Unterschiede bei manuell erfolgreich und erfolglos versandten MMs:

1. subject: bei erfolgreichem Versand ‘TestMM_2006-07-19_16.18’, bei erfolglosem Versand ‘(Matthias Ansorg [e-mail]:) TestMM_2006-07-19_16.29’
2. text[0]: bei erfolgreichem Versand ‘Testnachricht mit http://mms.ansorgs.de/26.amr’, bei erfolglosem Versand “Die AMR-Datei dieser Nachricht wurde hochgeladen, dann sleep(15), dann wurde die Nachricht gesandt.n” (mit Zeilenumbruch am Ende.).

Nun kann man die manuell zu versendende MM so anpassen dass sie akzeptiert wird. Das Problem lag hier am Feld “subject”: es darf bestimmte Sonderzeichen nicht enthalten, in diesem Fall kommen in Frage: runde oder eckige Klammern oder Doppelpunkt. Erlaubt sind jedoch (aufgrund erfolgreichen Versuchs): Unterstrich, Minus und Punkt.

Um weiteren derartigen Problemen vorzubeugen sollte auch die Länge des Headers (max. 36 Zeichen nach Schnittstellenbeschreibung von massenversand.de) und der Texte (je Text max. 300 Zeichen) eingehalten werden. Im Body sind beliebige Sonderzeichen jedoch erlaubt.