(RADIATOR) VoIP Block Time Woes
hugh at open.com.au
Thu Dec 20 22:25:29 CST 2001
Hello Zebaulon -
I think you are on the right track with the use of Handlers.
I will need to see a trace 4 debug from Radiator showing the accounting
packets received from the Cisco in all 3 of the cases you describe below.
It would also be useful to have a copy of your configuration file (no
On Fri, 21 Dec 2001 14:48, Zebaulon Kansal wrote:
> I've run into an interesting problem when setting up prepaid
> calling card services using VoIP, a Cisco AS5300, and RADIATOR running
> on FreeBSD.
> We are wanting to be able to sell prepaid calling cards, with
> the card number being the person's home phone number + 4-digit random
> number. We have the Cisco setup something along the lines of this:
> call application voice debit tftp://blah.blah/ivr/app_debit.tcl
> call application voice deibt language 1 en
> call application voice debit set-location en 0 tftp://blah/audio/en/
> call application voice debit warning-time 30
> call application voice debit uid-len 10
> call application voice debit pin-len 4
> We are using a hacked-up version of Block-Time-SQL to make all
> this work (basically Block-Time-SQL with modifications to use the Cisco
> attributes.) All of it works fine except for one problem. Whenever a
> caller hangs up, if they have called from their home phone, they end up
> being billed double (or triple) the time they used. I tracked it down
> to this problem:
> The access server sends a Stop record for the actual call they
> made out over the VoIP network. Radiator does the appropriate SQL query
> to deduct the number of seconds used from their account. This is what
> we want.
> The access server sends another Stop record for the call that
> they placed INTO our access server. The Acct-Session-Time for this one
> is the amount of time they were on the call PLUS the time it took them
> to enter their card #, etc. Radiator does the appropriate SQL query to
> deduct the number of seconds here from their account also. Not what we
> want. (Because now they've been deducted TWICE.) This happens because
> their USERNAME entry in the database is equal to their ANI, which is
> what the Cisco uses as User-Name on these records.
> If the caller placed a call that was local to the server (some
> of our callers are local to the server, but NOT local to places that
> the server CAN call local itself) then the server simply creates a VoIP
> connection to itself on loopback, and then places the call over the
> phone again. This will generate an additional Stop record for that,
> which gets deducted, and well, you see the picture.
> It would be nice if there was a way to filter accounting somehow
> so that only ONE time would be deducted. I tried doing this with a
> <Handler> statement, and it doesn't seem to work. Is there a better way
> to filter accounting requests other than Handlers?
> I'll have to look at this one some more in the morning, but I
> thought MAYBE someone out there had done this before and could give me
> some pointers to save me having to re-invent the wheel. :) Any ideas
> from anyone on how we could do this? I know, changing the card number
> to a totally-random 14 digit would probably fix it, but we'd also like
> to (at some point) be able to have people dial in with their home phone,
> and simply be prompted for the phone number to call. After collecting
> the digits, it would read back their credit time, and place the call.
> So, at that point, their ANI has to be tied to the card somehow...
> Any help/ideas would be appreciated. Thanks. :)
> Archive at http://www.open.com.au/archives/radiator/
> Announcements on radiator-announce at open.com.au
> To unsubscribe, email 'majordomo at open.com.au' with
> 'unsubscribe radiator' in the body of the message.
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.
More information about the radiator