Ich poste die Antwort auf die PN hier, da die SMS Rohdaten keine persönlichen Informationen erhalten - ausser irgendwas ist im Bild, was ich nicht "per Hand" dekodiert habe.
0051FF00800000A79E84
080400C70201
167C0000B1
8D1400012E000400061414AAAAAA0603060384E6AE6AE60C0A82AFBE060583ABDF7D060681FA060982EFBE060683E7DF7D061E82FBEF0E2D0C1E263C16158369A69A06030C0606038318618606038518619A18660C090C060806816810098319A6861E1E8368619A101E1209141E8219A1143C8218660C6908
C8309BFD0E01
Das erste fette ist die Länge eines so genannten "User Data Header", dass sind Hintergrundinformationen in der SMS, die nach dem SMS Standard keinen Platz mehr im eigentlichen SMS Header (alles in der ersten Reihe) finden.
Die nächste Zeile ist ein User Data Header Element, welches eine verkette SMS signalisiert, allerdings mit einer 16 Bit langen ID - das muss auch so laut SMS Standard Kapitel 9.2.3.24.10.1.13ff Extended Object sein.
Die nächte Zeile ist ein Element, welches ein sogenanntes Compression Control (Kapitel 9.2.3.24.10.1.15) ist. Hierbei handelt es sich um eine LZSS Komprimierung, welche eines oder mehrere Extended Objects beinhaltet. Die eigentlich Daten beginnen in der nächsten Zeile, alles andere sind nur Kopfinformationen über die beinhaltete Objektgröße.
Die letzte Zeile ist dann der eigentliche Text von Dir: Hallo!
Ein SMS Parser weiss aufgrund der ersten fetten Lägenangabe, wann Textinformationen anfangen. Die fetten Dinge sind Längenangaben in Hexadezimal (Grundzahl 16, anstatt 10).
In der zweiten SMS dieser Verkettung geht das ganze Spiel einfach weiter:
0051FF00800000A74B40
080400C70202
1638
0C8369A1860A0C83BEFBEF08788C19A69A6BEFBEFBEE79E7EE790627060C83E79E7E060306038269AE081506030C0612180E09181B82EE7900
Hier hat dann der Copression Corntrol Element kein eigene Kopfinformationen mehr - wäre ja auch doppelt gemoppelt.
Der EMS Parser muss dann "nur" noch das Extended Object mit LZSS dekomprimieren. Die Betonung liegt auf nur. Von LZSS habe ich noch nix gehört, und müsste mich da jetzt noch einarbeiten, ob wirklich ein EMS "sauberes" frabiges Bild darin abgelegt ist - ich denke aber schon.
Es handelt sich folglich um neuste EMS Technologie in Deinem Sagem - wäre fast alleine ein Kaufgrund für mich - gute Arbeite Sagem bzw. gut eingekauft.
So und nun zu der Frage, warum es andere EMS Klienten nicht können, bzw. wo der Datenmüll bleibt.
Jeder SMS Parser, der User Data Header kennt, weiss ob es ein darin enthaltenes Element kennt oder nicht. Es weiss also was es nicht weiss. Alles unbekannte wird einfach verworfen und es wird beim nächten Header Element weiter gemacht. Die Informationen werden daher gar nicht bearbeitet und angezeigt. Nur ganz alte SMS Parser würden Datenmüll anzeigen, dass sind alle, die keine User Data Header kennen - was nichts mit EMS selbst zu tun hat. Beispiel wäre hier ein Sony Z5. Fast alle gängigen Geräte auf dem Markt kennen User Data Header und verwerfen die Infos folglich.
Wenn ein anderer EMS Klient das "Extended Object" nicht kennt, dann kennt es auch keine "Compression Control" (laut Kapitel 9.2.3.24.10.1.15 Satz 4). Jeder EMS Klient, der nicht Version 5 kompatibel ist, kann auch kein "Extended Object".
Ein EMS 5er müsste es eigentlich können - es gibt nur keines, oder? Alle andere verwerfen die Daten - finde ich auch sinnvoll, oder willst Du Datenmüll?
Nochmal dank an PDUSpy, der einiges geholfen hat - bin doch nicht mehr so gut beim per-Hand-dekodieren - aber mit dem Compession Control Element konnte es auch nix anfangen. Nobbi...