(RADIATOR) VoIP Block Time Woes

[Hugh Irvine]

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 
secrets).

regards

Hugh


On Fri, 21 Dec 2001 14:48, Zebaulon Kansal wrote:
> Hi,
>
> 	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.