Citando Dave White <[EMAIL PROTECTED]>: > 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"?
PID value is passed thru from smsbox http interface to smsc connection and kannel doesn't mind with it. DCS is used internally in kannel and thus should be "controled" by it. That's why we have seperated fields to build DCS at the end. For example, if you set UDH and don't set coding, kannel will automatically (legacy behaviour) select 8 bit text and adapt your text data to it. Using coding, mclass, mwi and alt-dcs, every dcs combination can be done, if smsc modules supports it of course. EMI2 and AT2 surelly supports it. I can make a table in userguide with it's combinations to describe it. I vote -1 for having a DCS field outside smsbox and I don't see a requirement to split pid, but that's only MHO :) > Thanks, > > David WHITE > CONNECT AUSTRIA > > > -- Davi / Bruno.Rodrigues<at>Litux.Org Litux.org: 06:05:56 up 87 days, 7:21, 16 users, load average: 4.23, 3.66, 2.65 'Linux is obsolete (Andrew Tanenbaum)'
