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

[Trixter aka Bret McDanel]

On Sun, 2009-01-04 at 23:12 -0600, Ken Rice wrote:
> I have seen this time and time again and it typically is 1 of 2 things that
> cause this problem... Either the buyers gear or the sellers gear is dropping
> calls for a variety of reasons...
> 
> However "missed a bye" is a pretty poor excuse for the situation... BYEs are
> acknowledged... And resent a number of times... Even if you did miss 1 BYE
> message, I doubt you missed 6 or 8 of them as the end terminating the call
> would resend them repeatedly until it gave up...
> 

unless there was a network error, and I think but am not certain that a
minimum of 3 retries is recommended and many stop at that point.
Further if the SIP application crashes or is unplugged you can see
similar situations where you may not get a bye.  

Then there are buggy end user devices that may not properly send the BYE
or may not retry or whatever.  There are a lot of different devices and
you cant guarantee that someone isnt using one that does this.

I believe this is why the larger voip providers (broadvoice, vonage,
etc) all terminate your call after 4 hours.  Even mobile phone companies
who have complaints from customers who had their phone dial while in
their pocket have put call duration limits on their networks to help
deal with this in a similar way (showing that its not just a voip
solution).


> A perfect example of how this can happen is where an ITSP is trying to route
> all their calls via asterisk and some telemarketer signs up and dropps 1000
> calls/sec on them. Asterisk is not designed to handle this kind of volume.
> (There are people out there that will claim this but I challenge them to
> publish a document with verifiable results) So you end up with a hung
> (deadlocked) or crashed system that eventually is reset and you just lost
> who knows how many calls and how many CDRs leaving you no good way to bill
> for the time or validate your bill from the upstream carrier. 


yeah that is why I wrote a script that would deal with this having only
upto 1 interval of downed calls, providing you can actually terminate
the ones in progress.  Basically what it does is ping some remote
resource (which can be multiple systems if desired) saying the call is
still up and allowing that central authority to say that the call should
be terminated or not.  This really was a sample framework for doing
prepaid applications to allow concurrent calls without reserving large
sums of money from the account per call, but it could trivially be used
to track billing for other applications as well.


> And this is
> not just an Asterisk issue this is any switching solution that gets
> overloaded be it asterisk, coppercom, nextone or even Sonus. (altho most of
> those guys have some radius based nibble billing so they atleast don't loose
> a full CDR)

the "nibble billing" is what my script did, very trivial perl script
although not asterisk compatible, it could be made to be that way.

-- 
Trixter http://www.0xdecafbad.com     Bret McDanel
pgp key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8AE5C721

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.digium.com/pipermail/asterisk-biz/attachments/20090105/259d60a0/attachment-0001.pgp