On Sun, 2010-08-08 at 12:06, Alejandro Guerrieri wrote: > 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.
I agree with with your opinion, if it counts :) > 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 > > > > > -- Kind regards, Milan -------------------------------------------------- Arvanta, IT Security http://www.arvanta.net Please do not send me e-mail containing HTML code.
