DCS and PID handling in Kannel

[Dave White]

The GSM data coding scheme (DCS) is broken up by Kannel into various seperate fields, as I've seen. The protocol id, however, is passed through as an opaque octet.

Why is that? PID could concievably be treated the same way as DCS, and broken up into human-friendly fields like replace_msg_class, message_type, etc.

On the other hand, I'd actually prefer the following:

DCS and PID should also be accepted (and sent to applications) as-is; any additional fields are sugar for the application (so the developers of CGI servers for Kannel don't need to deal with the full hairiness of the GSM params).

My problem with Kannel's DCS handling is that there are in many cases two valid representations for certain combinations of message class and user data coding scheme. Since Kannel shreds DCS into a bunch of fields, if I want to reconstruct the original DCS of the MO SM, I have a harmless but icky ambiguity; in many cases, I'll provide a new value that SHOULD be semantically equivalent, but MIGHT not be for some buggy devices/firmware/etc.

Wouldn't it be easier just to add an INTEGER field to the sms message type, and pass the DCS through "as-is"?

Thanks,

David WHITE
CONNECT AUSTRIA