Not from me. Although I was wondering whether replacing the script with an HTTP interface similar to that of NowMMS might not be wiser...
P. On Feb 24, 2006, at 12:32, Dziugas Baltrunas wrote: > Hi again, > > any objections on this from others? > > On 2/22/06, Dziugas Baltrunas <[EMAIL PROTECTED]> wrote: >> Hi, >> >> thanks for the fix. However, some nuances about the whole billing >> procedure remain. >> >> 1) Currently (after the fix) a call to external script will be made >> for each of the recipients (billing-library functionality). Having >> some prepaid customer trying to send a message, this might lead to >> incorrect check for the balance, if, say, customer has a sufficient >> balance only to send MMS for 3 recipients, but originally there were, >> say 4 recipients. This will work as expected if only one call to the >> external script providing all recipients or at least count of them as >> script's parameters would be made. >> >> 2) I productional environments IMHO real billing should be made only >> after the message was sent (or queued for delivery). I guess for this >> purpose prov-server-notify-script was dedicated. However, currently >> parameters provided to this script are not sufficient to implement >> billing as the script is called per message, but not per recipient. >> Some additional parameters such as message id and size of the message >> would be also useful here. >> >> I would like to get some more opinions on the billing logic and >> how it >> was initially designed to work. I'm mainly referring to simple but >> efficient NowSMS billing (acutally callbacks) model, which is >> described here (see MMSSend PreAuth Callback and MMSSend Accounting >> Callback): >> >> http://www.nowsms.com/support/bulletins/TB-NOWSMS-001.htm >> >> Currently callbacks for Sending an MM in mbuni are as follows: >> >> 1. Call to billing-library to check if there is sufficient balance to >> send an MM for all the recipients. >> 2. For each of the MM recipients there is a call to resolver-library >> to check whether is local or foreign recipient or MM shall be sent to >> VASP. >> 3. prov-server-notify-script is called in case of MM was queued for >> delivery. Here real billing should happen. >> >> Correct me if I'm wrong. >> >> On 2/21/06, Paul Bagyenda <[EMAIL PROTECTED]> wrote: >>> Fixed I hope and updated to CVS. >>> >>> On Feb 21, 2006, at 16:35, Dziugas Baltrunas wrote: >>> >>>> Hi, list, >>>> >>>> what was the purpose for the code in mmsc/ >>>> mms_billing_shell.c::mms_billmsg(): >>>> >>>> for (i=0;i<list_len(to);i++) { >>>> Octstr *s; >>>> s = octstr_format("%s '%s' '%s'", octstr_get_cstr >>>> (script), >>>> octstr_get_cstr(from), octstr_get_cstr(list_get(to, i))); >>>> >>>> if (s) { >>>> system(octstr_get_cstr(s)); >>>> octstr_destroy(s); >>>> } >>>> } >>>> >>>> ? >>>> >>>> As you can see return value from the script currently is ignored >>>> so we >>>> should reconsider this and either pass all the recipients in one >>>> pass >>>> or check if WEXITSTATUS(system(octstr_get_cstr(s))) is always >>>> possitive for each of the recipients. >>>> >>>> -- >>>> Dziugas >>>> >>>> _______________________________________________ >>>> Devel mailing list >>>> Devel@mbuni.org >>>> http://mbuni.org/mailman/listinfo/devel_mbuni.org >>> >>> ----------------------------------------------- >>> Trek the Rwenzori's. Or just see them online - http:// >>> www.rwenzori.com/gallery.htm >>> >>> >>> _______________________________________________ >>> Devel mailing list >>> Devel@mbuni.org >>> http://mbuni.org/mailman/listinfo/devel_mbuni.org >>> >> >> >> -- >> Dziugas >> > > > -- > Dziugas > > _______________________________________________ > Devel mailing list > Devel@mbuni.org > http://mbuni.org/mailman/listinfo/devel_mbuni.org ----------------------------------------------- Trek the Rwenzori's. Or just see them online - http:// www.rwenzori.com/gallery.htm _______________________________________________ Devel mailing list Devel@mbuni.org http://mbuni.org/mailman/listinfo/devel_mbuni.org
