Re: (RADIATOR) VoIP Block Time Woes
Hi Zebaulon, I have done this before. Indeed, I do it now :) I wrote a prepaid card system from scratch for Cisco 5400's (identical to 5300's in voice terms - essentially the next generation hardware). There are two things here - one is related to understanding properly how voice accounting works on Cisco voice platforms, the other is the answer to your question about whether there is a 'trick' to organising to have prepaid cards only have their balance deducted 'once' per call, not once per valid 'Stop' record for the call (because, yes, there are multiple of those). First thing. Its normal, and expected, to generate multiple stop records. In case you aren't aware of it, all calls have four 'legs' in principle (in practice you can even generate -more- than four legs in practice under certain circumstances). Try reading these url's for a start: http://www.cisco.com/warp/public/788/voip/dialpeer_call_leg.html http://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/vapp_dev/vsaig3.htm It can take a while to get ones' head around this stuff. The pathological case of more than four legs happens when a call tries to use (say) h323 to reach a remote voice node, that node rejects the call, and the originating voice gateway then hairpin's the call out locally. In that case you wind up with a Stop record for the zero duration attempted VoIP call, then a non-zero duration call (of call type 'Telephony') via the local gateway for the hairpinned call. You can also wind up with less than four call legs for calls that don't succeed. You will also get accounting Stop records from TWO gateways, not just one - the 'local' gateway and the 'remote' one all generate accounting records. So a Handler might not be good enough, you really need to figure out exactly -which- Stop record you want to use. Each call leg has a duration, and those durations can differ (as you correctly indicate - one of them has the whole 'IVR' interaction time in it, others have the resulting leg durations for the parts of the call that involved attempts to commit telephony with someone). The critical thing about these legs is that you can work out which leg (1, 2, 3 or 4) you're seeing by looking at the h323-call-type and the h323-call-origin. The h323-call-type can be 'Telephony' or 'VoIP' (well those are the most common values); The h323-call-origin can be 'originate' or 'answer'. A 'standard' call leg set is literally: leg 1: Telephony/Answer(call from customer to your gateway) leg 2: VoIP/Originate (VoIP leg leaving your gateway to remote GW) leg 3: VoIP/Answer (the same connection arriving on the remote GW) leg 4: Telephony/Originate (the call into the PSTN made by the remote GW) In the standard case, the accounting records for legs 1 and 2 come from the local gateway and the accounting records for legs 3 and 4 come from the remote gateway. Take a look at the nice pictures on the cisco web site from those URL's I noted above. In cases where the call is hairpinned from the local voice gateway, there may be no VoIP legs at all, or there may (as indicated above) be a zero duration set of VoIP legs due to a remote failure followed by 'local' Telephony/Originate legs. This is actually a degenerate case where the local gw and the remote gw are the same gw, if you see what I mean. Second thing. You can handle this all 'properly', or you can use a hack. Of course :) What I do is get radiator to call an external perl program I wrote (worked out easier for me to deal with it that way), and the following is the logic in my code that decides whether to 'charge' the time inherent in a stop record that comes floating past the code... The critical point? That I decided after a lot of experimentation that the 'best' of the stop records to use is any leg which is of type 'originate' and which is of non-zero call duration, having discarded a few strange cases first. It turns out that there is only one of those per ultimate user session. By the way, what's the non-hack method? Doing it 'right' involves a LOT more work. That work involves using the h323-conf-id, which is the unique key across all legs in a call, to store every received leg of every call into sql tables, and to collect data from each of the legs as they arrive, and make a decision to bill once sufficient information is known about the call. This is actually very non-trivial in practice - some things you need to know are in some legs, some things you need to know are in others, and legs arrive separated in time, from the two gateways concerned, as the call proceeds. BUT: You actually don't need to do the above until you graduate to building a full post-paid billing engine for your VoIP nodes. I've done this, it's really quite non-trivial :) Ok -very- non-trivial :) Again, for prepaid, don't bother. The simple hack is to only 'act' on 'originate' records with nonzero call
(RADIATOR) VoIP Block Time Woes
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 [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) VoIP Block Time Woes
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 [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' 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 [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
