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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ --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