Re: Discussion: Prepaid counting

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.