EMS-Standard: mehrfarbige Bilder

Hi,
die originalspezifikation ist bei http://www.etsi.org in der download-gegend zu bekommen.

Such nach TS 23.040 und blaetter so lange bis du die versionen ueber 5.x hast.
Inwiefern dir das was hilft, kann ich natuerlich ned beurteilen.

cu
XlF

Nur s/w

Zitat

Zitat aus ETSI 23.040 Version 5.5.1 Kapitel 9.2.3.24.10.3.2 EMS Pictures
The pictures are plain black and white, no colours or grey scales are supported.

Man könnte aber ein Extended Object Format 6-bit colour bitmap anhängen (Kapitel 9.2.3.24.10.1.13).

Re: Nur s/w

Hi,

Zitat

Original geschrieben von Abi99
Man könnte aber ein Extended Object Format 6-bit colour bitmap anhängen (Kapitel 9.2.3.24.10.1.13).

Dummerweise ist mir kein Telefon bekannt, was die 5.x-Versionen der Spec *vollstaendig* (also inkl. der Farb-Bilder) unterstuetzt.

cu
Axel

Hi,

Zitat

Original geschrieben von Rainer25
Von X-5 zu X-5 (Selbsttest) aber hat der Versand von Farbbildern per EMS funktioniert. :confused: Dann muss doch zumindest das X-5 die Spezifikationen unterstützen (zumindest was den Farbbildversand angeht). Oder wie ist das jetzt gemeint?
Aber erst nach Anmeldung und komischem Ausfüllbogen...
Eigentlich wollte ich keine englische Dokumentation im schönsten Paragraphen-Slang, sondern mehr eine "menschliche" Erklärung von Leuten, die sich ein wenig mehr mit so etwas auskennen. Also wie ich das verstanden habe, können s/w-bilder im von mir genannten Format verschickt werden und können von jedem(?) EMS-fähigen Handy angezeigt werden. Soweit richtig?
Farbbilder kann ich nur zu anderen X-5 verschicken, oder zu Handy mit EMS Version 5.
Nebenbei: Was ist eigentlich "Magic4"? Ein Hersteller für SMS-Software? Ich habe laut "Handymagazin" das Release 5 der EMS-Software von Magic4, was immer das heißen mag. (Hilfe!)

- Der Download funktioniert definitiv ohne Anmeldung, ich habe nochmal nachgeguggt: http://pda.etsi.org/pda/queryform.asp , von dort landest du nach eingabe der dokumentennummer auf eine liste mit fundstellen, was im wesentlichen die verschiedenen versionen eines Dokumentes sind.

- Nachdem ich nur auf Basis eines 4.x-EMS-Standard implementiert hab, kann ich Dir leider auch nichts darueber berichten, nachdem MMS anscheinend doch im Kommen ist, weiss ich auch nicht, ob wir an EMS weiter arbeiten werden.

- schwarzweiss-Bilder koennen von jedem EMS-faehigen telefon verschicken und empfangen werden, Farbbilder halt nur mit Telefonen, die die Version 5.x unterstuetzen.

- Magic4 ist ein auf Mobile-messaging spezialisiertes Softwarehaus, die halt Loesungen fuer MMS, SMS und EMS anbieten. Lt. ihrer Webseite gehoere Hersteller wie Samsung, Ericsson, Motorola zu ihren Kunden.

cu
XlF

Ohne Anmedlung geht bei ETSI nix, kostet aber auch nix.
Magic4 bietet "fertige" SMS Klienten für Handys an. Teilweise haben die propitäre Lösungen, die sie trotz EMS immer noch nicht augegeben haben. Farbbilder gehen eben nur über "extended objects", womit kein SMS Klient was anfangen, wenn er extended objects nicht auch kennt (nicht abwärtskompatibel). Vielleicht ist es auch eine propitäre Magic4 Lösung, dafür müsste man sich die EMS mal roh ansehen.

Zitat

Original geschrieben von Rainer25
Gibt es eine Liste mit EMS-fähigen Mobilfonen und den jeweilligen Versionen?

Mit den jeweiligen Fähigkeiten, ja sowas gibt es, aber nicht von Sagem. Es gibt ein Kombi Sony Ericsson, Siemens, Motorola, Alcatel Dokument. Zu finden in deren Entwicklerabteilungs Seiten (kostenlose anmeldung erforderlich).

Zitat

Original geschrieben von Rainer25
Was sind Extended Objects?
EMS sind doch eine Erweiterung der SMS, im schlimmsten Falle müsste der Empfänger zumindest "Datenmüll" bekommen. Die Frage ist jetzt, warum gar kein Bild angezeigt wurde, sondern nur der übertragene Text.

Gute Frage, hab mit "extended objects" auch noch nix gemacht - weil die halt keiner kann/konnte. Bei EMS gibt es aber kaum Datenmüll, da sich diese Informationen immer in User Data Headern verstecken, welche dann nicht verstanden einfach nicht angezeigt werden. Oder die SMSC hat die sogar geschluckt.

Zitat

Original geschrieben von Rainer25
Wenn die Software eine proprietäre Lösung ist, sind dann die einzigen potentiellen Empfänger nicht diejenigen mit einem entsprechenden Mobiltelefon (also zumindest das MY X-5)? Wäre doch irgendwie blöd...

So definiert sich proprietär.

Zitat

Original geschrieben von Rainer25
EMS im Rohformat ansehen, das wäre mal einen Versuch wert. Über die Feiertage werde ich's mir mal anschauen. Datenkabel und Zeit sind vorhanden.

Terminal Fenster aufmachen und mit AT+CMGL=4 spielen. Vorher zur Sicherheit noch AT+CMGF=0, damit es auch PDUs sind. Dann mir als Private Nachricht schicken oder noch besser gleich Nobbi PDUspy.

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...