Hi, I'll definitely have a look at your code! I'm thinking about extending the functionality so that general purpose billing info could be passed to the smsc code, just how, I'm not sure yet.
Radiolinja is my target also, but I'd like to make it work also with Telia in Finland, who does it in a similar way, but requires a http based check if the msisdn can be billed (this falls obiously out of scope of kannel). Also, the billing information should be passable to my smsc_cgw implementation, which requires a quite heavy modification to work with billable MT messages. How about adding a billing octstr to the msg structure, that could be used by all smsc implementations that support the functionality? Setting the value correctly would be up the application calling kannel, and would be controlled by a "billing=" parameter or a X-Kannel-Billing http header. Location information is also something that could be added in the same way. Any thoughts? Regards, -- Anders Lindh FlyerOne Ltd -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Pekka Ahmavuo Sent: 8. helmikuuta 2002 16:24 To: [EMAIL PROTECTED] Subject: Re: CIMD tariff classes Hello Anders, > > I know this has been discussed before, but has anybody taken the > effort to implement tariff classes for CIMD? If not, I need to do it. > > (I know this is a CIMD only thing, as almost all other SMSCs don't > support extra billing information. What would be the right way to > implement a thing like this? Maybe extending the msg structure, > allowing it to contain billing information that can be used by all > SMSCs... ?) > > Thanks, > > -- > Anders Lindh > FlyerOne Ltd from the url: http://www.netland.fi/kannel/gateway-tariff-19-10.tar.gz you can find Oct 19th cvs kannel with my tariff class changes. I believe it should be relatively easy to update it to the latest cvs. Please test it extensively before taking it into production. I have had some problems with one installation, and I am not sure if it was because of bugs in my code, bugs in the rest of the kannel or if there was something wrong with the Linux installation (a Debian development version). Let me know if you find any bugs from my code. Fixes are wellcome. Please let me know also if you dont have any problems. When I sure enough that my code is relatively bug-free I will commit the changes into the cvs. >From below you can find some info about my tariff class changes. br, Pekka Ahmavuo Netland Oy ---------- Here is what I have done so far regarding the cimd2 tariff class. First some backgrounds: Two parameters are involved in setting the billing information, the "tariff class" and "service description". (Altough this may be specific to Finnish operator Radiolnja. Please comment if you know that some other CIMD2 operator treats he billing info in some other way). Tariff class defines how much the message from the application to the mobile costs the receiver (i.e. how much the client pays). Tariff class has predefined integer values, for example, SMS with tariff class 4 costs the client 1,42 FIM. When the tariff class is set, the service description should be also set to zero. If service description set to 1,the message if free to the client and a fee is charged from the application. Some examples: Message from the application to the mobile: tariff class: 4 service description: 0 => mobile pays 1.42 FIM Message from the application to the mobile: tariff class: 4 service description: 1 => application pays 0.60 FIM + VAT The implementation: I have added cimd2_tariff_class and cimd2_sdesc-paramaters to the sendsms-interface and corresponding X-Kannel-CIMD2-Tariff-Class and X-Kannel-CIMD2-Service-Description HTTP-headers. Setting the the HTTP-headers requires that sms-service group variable x-accept-kannel-headers is true. If a message with a tariff class is splitted into several SMSs, the service description is set to 1 for other than the first SMS, meaning that only the first SMS is billed from the customer and the application pays the rest of the SMSs. (For example, the client pays the same fee of a picture message regardless if it is split into two or three SMSs.) TODO: - Should the application be able to set different tariff class/service description values for splitted SMSs? - Should we add config file variables for setting default tariff class/service description values? Btw, treating the SMSC specific paramaters like the common paramaters leads to a quite ugly impelementation. Smsbox.c that was obviously meant to be generic becomes now polluted with SMSC specific code. I still think that some kind of generic mechnism for adding the SMSC specific paramaters would lead to cleaner architecture and would make our lifes easier. Even if you think that SMSC specific parameters must be static members of Mgs.sms-struct, could you still consider of some kind of hooks for function pointers or some other mechanism for separating the SMSC specific code from smsbox.c?
