vedyna.ZMS

This midlet (MIDP 2.0) uses the zlib compression algorithm in order to manage more than 160 chars in one SMS

This midlet handles the exchange of ZMS between mobile phones. The main difference with the normal SMS exchange is related to compression/decompression of SMS text before transmission/after reception. It uses the zlib compression algorithm (precisely, JZLib, a Java zlib implementation).
The midlet registers itself on SMS port 6677, in order to autostart at the reception on a new ZMS.

Why ZMS maximum length is 133?
As you already know, the Short Message Service allows the exchange of text messages, up to 160 chars (without concatenation mechanism) between mobile phones. The real number of octets used by the Short Message Service is equal to 140. Each char is encoded by using 7 bit alphabet. A simple math formula (140*8/7) brings to the well-known 160 value.
ZMS are exchanged as binary messages (140 octets = 140 bytes) and a slice of this space is used to transport the port information (7 bytes).
Another very simple math formula (140-7) brings to the 133 value.

From ETSI GSM 03.38 Techical Spec: "The TP-Data-Coding-Scheme field, defined in GSM 03.40, indicates the data coding scheme of the TP-UD field,...".
The DCS field tells us how the user data (eg. the text message) is encoded. The default value of the DCS field is 0x00 (using the default alphabet). The most interesting information is related to the usage of Bit 5 of the DCS field:
- if set to 0, indicates the text is uncompressed
- if set to 1, indicates the text is compressed using the GSM standard compression algorithm. (yet to be specified)

I do not know your feeling, but I am waiting for this functionality as standard capability on my next mobile phone....