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 <[email protected]> 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 >>> <[email protected]> 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 _______________________________________________ --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
