Re: [OpenSIPS-Users] Maybe it's a bug
Hi folks We implemented millisecond billing in our platform, so no need to round on the Opensips layer, the rounding is done in our business billing layer. This way customers can have a different rounding than VoIP providers. It's not a way to penalize customers, but some providers just work differently than others and you cannot demand them to work "your way". I suggest store a float (instead of integer) with milliseconds included OR an option to store milliseconds on a separated column. Regards On Tue, Jun 9, 2020 at 4:45 PM Calvin Ellison wrote: > +1 to ceil() rounding, and stating in the documentation that this is > the method used. Alternatively, some new option to specify ceiling, > floor, round, truncate, etc. > > I can back up SM's claim that a single billing interval discrepancy > will cost people real money. Clarification in the documentation will > help people avoid that pitfall. I also concur with Vlad that the > duration in milliseconds is preferable. The millisecond data can help > to settle any billing disputes from clients or vendors, and it > demystifies CDRs for everyone: one field for actual call duration in > ms, another field for call duration after rounding, and/or one for the > final charged call duration after rounding and billing interval. > > > > Regards, > > Calvin Ellison > Senior Voice Operations Engineer > calvin.elli...@voxox.com > > > On Tue, Jun 9, 2020 at 12:14 PM Johan De Clercq wrote: > > > > Upwards seems best. > > ___ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Maybe it's a bug
+1 to ceil() rounding, and stating in the documentation that this is the method used. Alternatively, some new option to specify ceiling, floor, round, truncate, etc. I can back up SM's claim that a single billing interval discrepancy will cost people real money. Clarification in the documentation will help people avoid that pitfall. I also concur with Vlad that the duration in milliseconds is preferable. The millisecond data can help to settle any billing disputes from clients or vendors, and it demystifies CDRs for everyone: one field for actual call duration in ms, another field for call duration after rounding, and/or one for the final charged call duration after rounding and billing interval. Regards, Calvin Ellison Senior Voice Operations Engineer calvin.elli...@voxox.com On Tue, Jun 9, 2020 at 12:14 PM Johan De Clercq wrote: > > Upwards seems best. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Maybe it's a bug
+1 Always ALWAYS round up, never down (in terms of ms to secs) +1 Also do your billing were your application is, not on a proxy. On Tue, 9 Jun 2020 at 19:58, Liviu Chircu wrote: > On 09.06.2020 15:43, Saint Michael wrote: > > I talked to Vlad, who I believe wrote the code, and he does not think > > it is a bug and I should use the ms and not the seconds. But thousands > > of businessmen will not spot this and thus their billing will never > > match the carrier, and they will lose money. If anybody thinks for a > > second that a call with a 200 OK will be free, is dreaming. Not in > > America. > > Hi, SM! > > Opinion #1: I doubt that anyone who is serious about their billing & > revenue (e.g. your nitpicky carrier) would leave to randomness the > answer to the most basic question of: "does our platform correctly bill > each call?". No disrespect here, just maybe highlighting the fact that > your platform could benefit from a bit more testing. > > Opinion #2: we could definitely change the default of the > second-accurate precision to be _greedy_ instead of _generous_. I bet > most people (myself included) would be more happy with a ceil() [1] > behavior instead of a trunc() [2] one. That is: round _upwards_, not > _downwards_. More opinions would be useful here! > > Best regards, > > [1]: man ceil > [2]: man trunc > > -- > Liviu Chircu > www.twitter.com/liviuchircu | www.opensips-solutions.com > > > ___ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Regards, David Villasmil email: david.villasmil.w...@gmail.com phone: +34669448337 ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Maybe it's a bug
Upwards seems best. Outlook voor iOS<https://aka.ms/o0ukef> downloaden Van: Users namens Liviu Chircu Verzonden: Tuesday, June 9, 2020 8:58:24 PM Aan: OpenSIPS users mailling list Onderwerp: Re: [OpenSIPS-Users] Maybe it's a bug On 09.06.2020 15:43, Saint Michael wrote: > I talked to Vlad, who I believe wrote the code, and he does not think > it is a bug and I should use the ms and not the seconds. But thousands > of businessmen will not spot this and thus their billing will never > match the carrier, and they will lose money. If anybody thinks for a > second that a call with a 200 OK will be free, is dreaming. Not in > America. Hi, SM! Opinion #1: I doubt that anyone who is serious about their billing & revenue (e.g. your nitpicky carrier) would leave to randomness the answer to the most basic question of: "does our platform correctly bill each call?". No disrespect here, just maybe highlighting the fact that your platform could benefit from a bit more testing. Opinion #2: we could definitely change the default of the second-accurate precision to be _greedy_ instead of _generous_. I bet most people (myself included) would be more happy with a ceil() [1] behavior instead of a trunc() [2] one. That is: round _upwards_, not _downwards_. More opinions would be useful here! Best regards, [1]: man ceil [2]: man trunc -- Liviu Chircu www.twitter.com/liviuchircu<http://www.twitter.com/liviuchircu> | www.opensips-solutions.com<http://www.opensips-solutions.com> ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Maybe it's a bug
On 09.06.2020 15:43, Saint Michael wrote: I talked to Vlad, who I believe wrote the code, and he does not think it is a bug and I should use the ms and not the seconds. But thousands of businessmen will not spot this and thus their billing will never match the carrier, and they will lose money. If anybody thinks for a second that a call with a 200 OK will be free, is dreaming. Not in America. Hi, SM! Opinion #1: I doubt that anyone who is serious about their billing & revenue (e.g. your nitpicky carrier) would leave to randomness the answer to the most basic question of: "does our platform correctly bill each call?". No disrespect here, just maybe highlighting the fact that your platform could benefit from a bit more testing. Opinion #2: we could definitely change the default of the second-accurate precision to be _greedy_ instead of _generous_. I bet most people (myself included) would be more happy with a ceil() [1] behavior instead of a trunc() [2] one. That is: round _upwards_, not _downwards_. More opinions would be useful here! Best regards, [1]: man ceil [2]: man trunc -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Maybe it's a bug
I have been wondering why my billing never matched the invoice from my carrier and I think I found the issue. I pass a few million calls a day. It turns out that Opensips is not rounding upwards the ms to calculate seconds, and that is done at the source code. This issue leads to absurds like a call with 100 ms being reported as zero seconds, and a call with 1200 ms being reported as 1 second, etc. In the first case, 100ms, my carrier will consider this call 1 second, rounded to 6 seconds minimum (6/6). So there a jus lost 6 seconds that I am not charging to my customer but I am paying for. If you have millions of calls, 50%, that fall into the lower half of 1000ms, like 24400 ms, that they are reported as 24 seconds, but my carrier thinks is 25 seconds, and he rounds it to 30, there I lost another 6 seconds. I talked to Vlad, who I believe wrote the code, and he does not think it is a bug and I should use the ms and not the seconds. But thousands of businessmen will not spot this and thus their billing will never match the carrier, and they will lose money. If anybody thinks for a second that a call with a 200 OK will be free, is dreaming. Not in America. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
