[asterisk-biz] Experimental/new VoIP rate search engine.

Alex Balashov abalashov at evaristesys.com
Mon Jan 5 02:09:06 CST 2009


Also, a particular instance of a sucky situation doesn't invalidate my 
position that it's okay to bill off a signaling basis on a broad, 
methodological level.  Or does it?

Alex Balashov wrote:

> Yeah, I understand.  It's easy for me to preach the importance of simply 
> finding the problem and fixing it, but these problems are often 
> impossibly burdensome to track down and fix, to the extent it's even 
> feasible to do so.
> 
> I'd just drop the carrier if I were you.
> 
> 1. Do you have this problem with other carriers?   To the same degree?
> 
> 2. What happens when you do proxy the media and use that as your 
> accounting basis;  does your billing reconcile with this carrier almost 
> perfectly?
> 
> 3. Any correlation on the itemised portion/CDRs on the bill between 
> particular numbers and/or destinations and eccentrically long calls?
> 
> -- Alex
> 
> Nitzan Kon wrote:
> 
>> I totally agree with you in principal, but the problem is that
>> the issue is not on our side. It is on the carrier side. I'm
>> making an assumption here, but if out of many carriers we use
>> only one displays these symptoms then something is wrong with
>> THEIR system - not ours.
>>
>> In other words - I can't fix it nor find out what is wrong, because 
>> nothing is wrong on our side. I suspect it's related
>> to them not proxying the calls - but I could be wrong. When
>> I complained I was told "your server probably didn't send a
>> SIP BYE" which may or may not be true, but even if it is true
>> I think the idea that a crashed server or lost packets on the
>> client side would cause a call to continue forever or until a pre-set 
>> max timeout is ridiculous on a carrier level. They
>> MUST account for such situations.
>>
>> To make things worse- the fact that the carrier is making
>> quite a bit of extra profit from this bug gives them zero
>> incentive to fix it and all the incentive in the world to
>> blame it on our server, our users' CPE, or the weather. It's
>> not THEIR $$$ at stake so they don't give a crap.
>>
>> Of course, it *IS* their $$$ at stake when they lose our
>> business - but that's a whole different story...
>>
>> --- On Mon, 1/5/09, Alex Balashov <abalashov at evaristesys.com> wrote:
>>
>>> Most of my response to this has already been captured in
>>> some form by Kristian and Ken, but just to sum up:
>>>
>>> 1. I didn't say that these types of signaling errata
>>> don't occur.  They do.  They should be treated as a cost
>>> of doing business.  If they account for a nontrivial
>>> percentage of lost revenue, you've got a more
>>> fundamental problem of a technical nature somewhere and need
>>> to fix the problem at the source.
>>>
>>> The lost money should be utterly trivial in comparison to
>>> the amount of money you would need to spend to handle all
>>> media from customers in a way that is reliable, scalable and
>>> reasonably mitigates QoS issues. Scalability is probably the
>>> biggest cost, even though it is not visible as an immediate,
>>> short-term cash outflow.
>>>
>>> As with most other things in business, it needs to be
>>> Pareto-optimal.
>>>
>>> 2. As Ken alluded, if you have a nontrivial amount of such
>>> occurrences, there is most likely a technical problem
>>> somewhere.  You, your vendors, or your suppliers are doing
>>> something wrong.
>>>
>>> SIP signaling is not inherently flawed in its relationship
>>> to accounting, or exceptionally unreliable compared to other
>>> signaling technologies where the transport and switching
>>> assembly entails a separate signaling and bearer plane.  SIP
>>> does have reliable retransmission of initial and sequential
>>> requests as well as final replies, and they do work--if
>>> you're losing more than an infinitesimal fraction of
>>> them, you've got a network or equipment problem in the
>>> path.  CPE disappearing due to shoddy power or connectivity
>>> can be mitigated through the use of session timers, as
>>> Kristian suggested.
>>>
>>> You need to figure out what the problem is.
>>>
>>> At the root of this, what I'm advocating is not a
>>> reckless disregard for cost control or billing discrepancies
>>> as much as it is a lean, fundamentals-based, back-to-basics,
>>> no-nonsense technical and backoffice process strategy.
>>>
>>> By the way, 179811 - 130740 is a difference of 49071.  249
>>> / 49071 is an average per-minute rate of half a penny
>>> ($.005), so let's say for assumption's sake that the
>>> rest of your traffic (the 130k minutes) consists of
>>> $.005/min flat.  That's $650, which means your overage
>>> is 38% of the rest of your gross.  If you have that kind of
>>> billing errata, you've got far, far more fundamental
>>> issues per million than random CDR slips due to missing
>>> signaling in normal operating conditions should produce. While nobody 
>>> knows what that exposure figure is, it
>>> shouldn't be ~25% of your bill!
>>>
>>> I've successfully set up SIP-only usage accounting for
>>> an operation that does over 3 million minutes a month, and
>>> their discrepancies with their upstream carriers (yes, they
>>> use SIP trunks) average an error margin of maybe 1.2%.  Now,
>>> this is a viciously thin-margin space, so really, 1.2% is
>>> too high and I'm trying to get that corrected for them. I should 
>>> follow my own advice.
>>>
>>> -- Alex
>>>
>>> Nitzan Kon wrote:
>>>
>>>> --- On Sun, 1/4/09, Alex Balashov
>>> <abalashov at evaristesys.com> wrote:
>>>>> Many of them have claimed they lose a ton of money
>>> from accounting problems caused by the unreliability of
>>> signaling (as though SIP doesn't have reliable
>>> retransmission of transactional messages or something) but
>>> they've never shown me any numbers to substantiate that.
>>>> OK, here's some statistics for the month of
>>> December for
>>>> the carrier in question:
>>>>
>>>> Our record shows:
>>>> 100,504 calls
>>>> 130,740:27 minutes total
>>>>
>>>> Their record shows:
>>>> 100,161 calls (probably just time difference here
>>>> 179,811.28 minutes total
>>>>
>>>> Their record shows total rate charged $229 higher than
>>> what
>>>> our billing system determined we SHOULD have been
>>> charged.
>>>> In other words- $229 extra have been charged due to
>>> signaling
>>>> problems - and this is just one month.
>>>>
>>>> I used to ask them for refunds for these but to be
>>> honest it's
>>>> such a PITA that I just gave up and started routing
>>> most of
>>>> our traffic to other carriers.
>>>>
>>>> Bad billing is bad for business no matter how great
>>> your
>>>> call quality is. :)
>>>>
>>>> -- Nitzan
>>>> http://www.comparevoipproviderrates.com/
>>>>
>>>> _______________________________________________
>>>> --Bandwidth and Colocation Provided by
>>> http://www.api-digital.com--
>>>> asterisk-biz mailing list
>>>> To UNSUBSCRIBE or update options visit:
>>>>   
>>> http://lists.digium.com/mailman/listinfo/asterisk-biz
>>>
>>>
>>> -- Alex Balashov
>>> Evariste Systems
>>> Web    : http://www.evaristesys.com/
>>> Tel    : (+1) (678) 954-0670
>>> Direct : (+1) (678) 954-0671
>>> Mobile : (+1) (678) 237-1775
>>
>> _______________________________________________
>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>
>> asterisk-biz mailing list
>> To UNSUBSCRIBE or update options visit:
>>    http://lists.digium.com/mailman/listinfo/asterisk-biz
> 
> 


-- 
Alex Balashov
Evariste Systems
Web    : http://www.evaristesys.com/
Tel    : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (678) 237-1775



More information about the asterisk-biz mailing list