I concur 100%, I've seen so many different approaches to billing that I think it's virtually impossible to build a one-size-fits-all solution to deal with it.
Even if you do, it would probably be very complex to configure and heavy on resources, and anyway soon a carrier would probably come up with a new, "innovative" approach that it wouldn't be able to be dealt with. That's why I think that a plugin approach would be the way to go. That way, plugins to deal with different scenarios could be developed to suit the particular needs at hand. Regards, -- Alejandro Guerrieri [email protected] On 08/08/2010, at 08:23, Konstantin Vayner wrote: > There are a lot of issues that arise when dealing with prepaid > > First of all, in many cases the balance is supposed to be per message type > (eg short text sms cost X, concatenated cost Y per message, wappush cost Z > per message). > Second, billing models often differ - in some cases we charge all messages > regardless (the customer "touches" our service - pays), in other cases - we > bill upon submission to target network (regardless if message was accepted > for delivery or rejected), in some - only if it was accepted , and in some > cases we even charge the customer when the message was successfully delivered > to handset (upon dlr reception). > Also, in some cases a whole concatenated message is billed asif it was a > single message (possibly by a different rate, possible at same). > > And all these might vary from customer to customer (its up to marketing to > decide how they charge the customers). > > I am not sure bb needs that much extra functionality/flexibility that can be > built in external application anyway > > Regards, > Konstantin > > On Sat, Aug 7, 2010 at 11:16 PM, Juan Nin <[email protected]> wrote: > I agree with Alejandro, this is specific for your needs, and may fit > other people's needs too, but it's not generic enough. > > For example, binfo may be used with some carriers, but not with > others. In my own experience I have never connected to a carrier where > I could use binfo for this purposes. > > As Alejandro says, a plugin approach would be better, so that you can > use whatever you want without adding specific cases logic into kannel. > > You could even implement it on your application side, with no need of > doing it directly on Kannel (of course may have it's benefits to do it > on Kannel side on certain cases though). > > > On Sun, Aug 1, 2010 at 3:28 PM, Alejandro Guerrieri > <[email protected]> wrote: > > This patch will definitely have its place for many people's requirement, > > but it's not generic enough for general usage imho. > > > > Personally speaking, I don't like the idea of clogging any boxes' code with > > non-generic stuff. The billing approach would work for some people, but > > surely won't be flexible enough for others. > > > > I like Stipe's "plugin approach" on his (commercial) smppbox: messages can > > be routed thru plugins, where you can implement all kind of stuff and > > add/remove them from your message pipeline. Using that approach, all kind > > of billing mechanisms could be implemented (along with many other stuff of > > course). > > > > Regards, > > -- > > Alejandro Guerrieri > > [email protected] > > > > > > > > On 01/08/2010, at 03:08, Rene Kluwen wrote: > > > >> Suppose I add 2 tables to sqlbox: > >> > >> mysql> describe sms_users; > >> +---------+--------------+------+-----+---------+-------+ > >> | Field | Type | Null | Key | Default | Extra | > >> +---------+--------------+------+-----+---------+-------+ > >> | binfo | varchar(100) | NO | PRI | NULL | | > >> | balance | float(10,0) | NO | | 0 | | > >> +---------+--------------+------+-----+---------+-------+ > >> 2 rows in set (0.00 sec) > >> > >> And: > >> > >> mysql> describe sms_rates; > >> +---------+--------------+------+-----+---------+-------+ > >> | Field | Type | Null | Key | Default | Extra | > >> +---------+--------------+------+-----+---------+-------+ > >> | prefix | varchar(100) | NO | PRI | | | > >> | smsc | varchar(100) | NO | PRI | | | > >> | rate | float(10,4) | NO | | 0.0000 | | > >> | country | varchar(255) | YES | | | | > >> +---------+--------------+------+-----+---------+-------+ > >> 4 rows in set (0.00 sec) > >> > >> And suppose I match prefix/smsc against sms_rates and draw the variable > >> "rate" from it. > >> > >> Next, I check the sms_users table with the binfo field (not sure if this is > >> a good idea or not) and I withdraw "rate" from "balance" if "balance" is > >> big > >> enough. Once balance reaches 0, sqlbox will refuse to relay further > >> messages > >> to bearerbox. > >> > >> Attached is a patch that does the trick (for now, only mysql engines). > >> Note: > >> This code hasn't been tested yet and probably contains a bug or two. > >> > >> But I am posting it anyway to see what the almighty Kannel Developers have > >> to say about it. > >> > >> This patch is especially useful if you want your clients to have access to > >> an open smppbox with a limited amount of credits. But also it works for > >> smsboxes and sqlboxes, as you please. > >> > >> I made a small patch to open smppbox that allows passing of binfo. > >> > >> == Rene > >> > >> <prepaid_1.patch> > > > > > > > > > > -- > Juan Nin > 3Cinteractive / Mobilizing Great Brands > http://www.3cinteractive.com > >
