| Summary: | ASTERISK-06464: [branch] cdr_radius module | ||
| Reporter: | phsultan (phsultan) | Labels: | |
| Date Opened: | 2006-03-02 18:23:52.000-0600 | Date Closed: | 2008-01-15 17:10:12.000-0600 |
| Priority: | Major | Regression? | No |
| Status: | Closed/Complete | Components: | Core/General |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) cdr_radius.c.diff ( 1) cdr_radius.readme ( 2) cdr_radius.readme.2 ( 3) cdr_radius-ama-disposition.0.1.patch ( 4) dictionary.asterisk | |
| Description: | Hi all, I added a 'cdr_radius.so' module based on the 'radiusclient-ng' library. It produces only 'stop' records. Here is an example of a record, taken from a FreeRADIUS server 'detail' file, and running on the same computer : Fri Mar 3 00:03:13 2006 Acct-Status-Type = Stop Calling-Station-Id = "7899" Called-Station-Id = "0123456789" Acct-Session-Time = 57 NAS-Port = 0 Acct-Delay-Time = 0 NAS-IP-Address = 127.0.0.1 Acct-Unique-Session-Id = "bd030dd14f5ecbc5" Timestamp = 1141340593 More verbose records could be dumped by feeding a common dictionary file for both the RADIUS client running on Asterisk, and the RADIUS server. Installation : -------------- - install the radiusclient-ng API (tested version 0.5.2) - add the cdr_radius.c file under the 'asterisk/cdr' directory of your Asterisk installation - patch the 'asterisk/cdr/Makefile' with the provided patch This patch will have 'make' compile 'cdr_radius.so' if the 'radiusclient-ng.h' header file has been located on your system. The RADIUS configuration file is expected to be found at '/usr/local/etc/radiusclient-ng/radiusclient.conf' ****** ADDITIONAL INFORMATION ****** Branch: oej/cdr_radius | ||
| Comments: | By: Olle Johansson (oej) 2006-03-03 01:49:10.000-0600 What's the license for the radiusclient-ng library? URL? By: phsultan (phsultan) 2006-03-03 03:06:34.000-0600 URL : http://developer.berlios.de/projects/radiusclient-ng/ The license is BSD. By: Olle Johansson (oej) 2006-03-03 04:09:32.000-0600 The RC_CONFIG_FILE seems a bit platform dependent (hardlinked to /usr/local/etc) - is that always the case? By: Olle Johansson (oej) 2006-03-03 04:11:11.000-0600 Why are many fields commented out? No room for them in the radius record, or? By: Olle Johansson (oej) 2006-03-03 04:15:14.000-0600 opening branch "cdr_radius" for this code By: Olle Johansson (oej) 2006-03-03 04:19:32.000-0600 It's using the NetBSD license with the advertising clause: "3. All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by the NetBSD Foundation, Inc. and its contributors. " By: Olle Johansson (oej) 2006-03-03 05:00:04.000-0600 Also added to test-this-branch By: phsultan (phsultan) 2006-03-03 09:24:31.000-0600 The autotools generated 'configure' script sets the installation prefix to '/usr/local' by default, and the configuration directory to '${PREFIX}/etc'. Maybe we can leave the choice of an alternative configuration directory or file for cdr_radius.so at compile time? Regarding the bunch of commented out fields, I tried to find out which of the cdr_csv.so fields could be matched in the default radiusclient-ng 'dictionary' file. We will need to populate this file both on the RADIUS client and server, so that we can get *detailed* records. By: miconda (miconda) 2006-03-06 12:20:08.000-0600 We have a similar cdr_radius version using radiusclient-ng library, but is a bit more customizable. The radiusclient configuration file can be set via configuration file as well as the service type. We used only private AVP ids and the implementation follows closely the other cdr_* applications from asterisk. I posted the c source, the asterisk radius dictionary and the configuration file at: http://www.openser.org/tmp/asterisk/ I think the best way is to merge some of the features and get the best out of the two. By: Olle Johansson (oej) 2006-03-06 12:52:40.000-0600 miconda: We need to get that code uploaded here and a disclaimer from you. Looking forward to merging your code! (Philippe is away travelling, so he can't answer right now). By: miconda (miconda) 2006-03-07 06:41:01.000-0600 Here is the tarball with the c source, config file and radius dictionary. The patch for makefile applies here as well. By: Olle Johansson (oej) 2006-03-07 07:29:37.000-0600 miconda: What's the status with the disclaimer? By: miconda (miconda) 2006-03-08 04:33:00.000-0600 I filled the disclaimer (disclaim.changes) and faxed to +1-256-971-6890. By: phsultan (phsultan) 2006-03-22 12:19:21.000-0600 miconda, thank you for this code. I merged some parts of it in the attached asterisk-cdr_radius.0.2.patch file, and completed this file with private attribute value pairs. I slightly modified your dictionary.asterisk file in order to add a Digium vendor code to it. I think we have now a quite verbose and simple cdr_radius module. This patch is intended to be applied to the cdr/cdr_radius.c file, taken from Olle's "cdr_radius" branch. I followed your suggestion regarding the configuration file, with two changes : - named the file "radius.conf" instead of "cdr_radius.conf", because it can be used by the "res_auth" module which provides RADIUS authentication - got rid of the "service-type" variable (see some reasons why after). The file "radius.conf" is attached. We need to use Vendor Specific Attribute Value Pairs, so it is just a matter of writing a new dictionary file (namely dictionary.asterisk, as you did), that contains private attributes *and* a Vendor Code. Usually, this code is the IANA PRIVATE ENTERPRISE NUMBER, which for Digium is 22736. The corresponding dictionary.asterisk file is attached. We do not need to specify a new Service-Type value if we want to dump private AVPs, moreover we *should* not do so because : - that would not work with most RADIUS server implementation, that accept to add a private dictionary file in such case - that would add unnecessary complexity to the cdr_radius module - the necessary IANA registration process might take some time : see ยง2.1 in RFC 3575 - Vendor-Specific extensions can achieve the wanted goal. Testing procedure : -------------------- - install the radiusclient-ng API (tested version 0.5.2) - checkout Olle's "cdr_radius" branch : #svn checkout http://svn.digium.com/svn/asterisk/team/oej/cdr_radius - apply the patch : #patch -p0 < asterisk-cdr_radius.0.2.patch - compile and install - write the "radius.conf" file (usually in /etc/asterisk) - feed the dictionaries of both RADIUS client and server : For radiusclient-ng ******************** Copy this line at the end of the main dictionary file : $INCLUDE /usr/local/etc/radiusclient-ng/dictionary.asterisk For FreeRADIUS *************** Similar procedure, the main dictionary file is etc/raddb/dictionary Testing results : ------------------ Here is the kind of dumped accounting tickets, taken from a FreeRADIUS detail file (phone numbers and IP address modified): Wed Mar 22 17:15:50 2006 Acct-Status-Type = Stop Asterisk-Acc-Code = "" Asterisk-Src = "philippesultan" Asterisk-Dst = "0123456789" Asterisk-Dst-Ctx = "from-sip-clients" Asterisk-Clid = "\"philippe.sultan\" <philippesultan>" Asterisk-Chan = "SIP/philippe.sultan-e85e" Asterisk-Dst-Chan = "SIP/10.0.0.1-f5a6" Asterisk-Last-App = "Dial" Asterisk-Last-Data = "SIP/00123456789@10.0.0.1" Asterisk-Start-Time = "2006-03-22 17:15:43" Asterisk-Answer-Time = "2006-03-22 17:15:45" Asterisk-End-Time = "2006-03-22 17:15:50" Asterisk-Duration = 7 Asterisk-Bill-Sec = 5 Asterisk-Disposition = "ANSWERED" Asterisk-AMA-Flags = "DOCUMENTATION" NAS-Port = 0 Acct-Delay-Time = 0 NAS-IP-Address = 127.0.0.1 Acct-Unique-Session-Id = "bd030dd14f5ecbc5" Timestamp = 1143044150 By: Olle Johansson (oej) 2006-03-22 12:33:13.000-0600 Patch committed to branch. Welcome home, Philippe :-) By: Olle Johansson (oej) 2006-03-22 12:35:09.000-0600 I would suggest that you work together to write a doc/radius.txt README file. By: Jeffrey C. Ollie (jcollie) 2006-03-22 15:08:14.000-0600 Can we please log dates and times in a non-ambigiuous format? This is especially important with CDR records. It's very likely that CDR records will be compared with other logs to trace calls. I've attached a patch that records dates and times in UTC, and adds a 'Z' to indicate that the time is in UTC. By: phsultan (phsultan) 2006-03-23 11:43:11.000-0600 Hi Olle, the attached patch (cdr_radius-doc_radius.0.1.patch) to doc/cdrdriver.txt includes the installation procedure. It assumes that the 'dictionary.asterisk' file is available to the user. Maybe Daniel wants to complete/modify it, as SER/OpenSER includes a RADIUS module that comes with an extensive documentation. By: phsultan (phsultan) 2006-03-23 11:47:50.000-0600 jcollie: maybe this can be configured in cdr.conf just as it is for csv? Example: [radius] usegmtime=yes ;log date/time in GMT loguniqueid=yes ;log uniqueid loguserfield=yes ;log user field By: Olle Johansson (oej) 2006-03-23 14:48:03.000-0600 updated the doc with cdr_radius-doc_radius.0.1.patch By: Jeffrey C. Ollie (jcollie) 2006-03-23 16:19:29.000-0600 OK, here's a new patch that makes logging in gmtime/localtime configurable from cdr.conf. Also makes it possible to enable/disable logging of unique id and user field at runtime from cdr.conf rather than at compile time. By: Jeffrey C. Ollie (jcollie) 2006-03-23 22:02:31.000-0600 New patch gets rid of commented-out #defines that are no longer needed. By: miconda (miconda) 2006-03-24 02:50:18.000-0600 I have some basic documentation about cdr_radius. I am in the process of writing a more complete documentation about OpenSER and Radius integration. I will try to get a version for asterisk as well. I am traveling rigjt now, I will be back at the begining of next week and go on with this discussion. By: phsultan (phsultan) 2006-03-24 05:14:20.000-0600 jcollie: compilation failed because of a few syntax errors. fixed in cdr_radius4.txt Apart from this, I succesfully tested the proposed configuration options. By: Olle Johansson (oej) 2006-03-26 17:49:46.000-0600 jcollie: I need a confirmation of your disclaimer. Thanks. By: Jeffrey C. Ollie (jcollie) 2006-03-26 18:48:22.000-0600 Yep, have had a disclaimer on file for a while. By: Olle Johansson (oej) 2006-03-26 20:30:06.000-0600 cdr_radius4.txt committed to cdr_radius and test-this-branch branches. Thanks! Pls tell me if I missed a patch. By: phsultan (phsultan) 2006-03-27 03:12:35.000-0600 Tested in test-this-branch Olle, after a short and exciting weekend ;) No missing patch. By: wILMAR cAMPOS (willcampos) 2006-03-28 18:33:47.000-0600 Can I log the remote client ip address with this module? By: Jeffrey C. Ollie (jcollie) 2006-03-28 23:09:11.000-0600 Is there a reason that we need to serialize sending accounting packets with the mutex? By: phsultan (phsultan) 2006-03-29 11:00:57.000-0600 wilcampos: you can record the info made available to any CDR driver by the CDR engine, which are described in the ast_cdr struct (include/asterisk/cdr.h). Unfortunately, I cannot find a value that would match your need in this structure. By: phsultan (phsultan) 2006-03-29 11:24:30.000-0600 jcollie: nope, a new local port is reserved each time a record is sent, so there is no need to keep locking the radius_log calls. Patch 'cdr_radius-nomutex.0.1.patch' attached. By: Olle Johansson (oej) 2006-03-29 11:24:31.000-0600 Like all CDRs you can set the CDR userfield to anything available in the dial plan. The dial plan functions will give you IP address for some of the VoIP channels. By: miconda (miconda) 2006-03-29 11:58:08.000-0600 I have just uploaded initial version of a readme file about how to configure an Asterisk system to send CDRs to a RADIUS server. Some more work has to be put in. By: phsultan (phsultan) 2006-04-14 10:01:52 miconda: thanks, that's a very valuable document. Here are my comments. The drawing should group Asterisk and the RADIUS client together, as they reside on the same computer. Otherwise, users might be confused. The final part of section 2.b, and section 2.c that describe FreeRADIUS server configuration refer to the Authentication (digest auth). We might not want to detail this information for the CDR module we are working on right now, as the module is only tied to the Accounting RADIUS function. In section 3, I don't think it's necessary to explicitly include cdr_radius.so in /etc/modules.conf, as long as you set the 'autoload' parameter to 'yes'. Two files are used for configuring cdr_radius.so : /etc/asterisk/radius.conf for RADIUS only parameters, and /etc/asterisk/cdr.conf (section [radius]) for more CDR specific configuration parameters, thus following jcollie's suggestion in previous messages. Thank you again Daniel. By: miconda (miconda) 2006-04-25 10:44:24 phsultan: your comments about the readme are ok for me. That document was provided as a starting point to work on it, for sure it needs improvements and adjustments to fit for Asterisk. You can reuse only the parts which make sense to write the appropriate documentation. I will try to help as much as possible. By: Serge Vecher (serge-v) 2006-05-04 13:05:49 miconda: can you please update your readme to reflect psultan's comments? Also, does cdr_radius-nomutex.0.1.patch need to be integrated into the branch? By: Jeffrey C. Ollie (jcollie) 2006-05-04 13:56:00 The "cdr_radius4.txt" patch has been applied, but none of the other patches/files have made it into the branch. By: Serge Vecher (serge-v) 2006-05-04 14:01:31 Olle: I've cleaned up the old patches; the following need a commit to the branch as per jcollie: 1. radius.conf 2. dictionary.asterisk 3. cdr_radius-nomutex.0.1.patch 4. cdr_radius.readme THANX! By: phsultan (phsultan) 2006-05-05 08:53:04 Uploaded new version of the README file (cdr_radius.readme.2) that follows the lastest notes on the topic, so that miconda just needs to check the file. Comments and improvements are welcome. By: miconda (miconda) 2006-05-05 15:13:29 The readme file looks good. I think that it must be decided (if not done yet) where the dictionary.asterisk will be located after asterisk installation and reflect that in the readme. By: Jeffrey C. Ollie (jcollie) 2006-05-05 15:28:31 I would think that having dictionary.asterisk in configs in SVN and /etc/asterisk (or wherever you put your config files) when installed would work best. By: Koh Joey Chong (joeychong) 2006-05-10 04:31:20 Where is the asterisk-cdr_radius.0.2.patch ? I unable to find this file. Sorry! I'm new on this. How do I get the file? using SVN? By: phsultan (phsultan) 2006-05-10 04:50:53 joeychong: the patch was committed to the cdr_radius branch a few weeks ago. By: Koh Joey Chong (joeychong) 2006-05-10 06:39:05 how to get the asterisk-cdr_radius.0.2.patch from the cdr_radius branch? By: phsultan (phsultan) 2006-05-10 07:01:46 joeychong: you don't need to apply the mentioned patch anymore. Just check out cdr_radius : #svn checkout http://svn.digium.com/svn/asterisk/team/oej/cdr_radius And follow the rest of the installation procedure. By: phsultan (phsultan) 2006-05-11 14:02:35 The dictionary file, named 'dictionary.digium' has been included in FreeRADIUS' CVS HEAD version : http://lists.freeradius.org/pipermail/freeradius-devel/2006-May/009790.html This means we don't need to include it into FreeRADIUS anymore. It's however still needed in the radiusclient-ng dictionary repository. Maybe we should rename the 'dictionary.asterisk' file to 'dictionary.digium', as these files usually refer to companies, and place it under configs. jcollie: I don't think we should place the dictionary under /etc/asterisk, as it is not intended to be modified. I will reflect the changes in the README file when we agree. By: Jeffrey C. Ollie (jcollie) 2006-05-11 16:17:57 Is there a released version of FreeRADIUS that has the dictionary in it? Maybe the dictionary should be kept in the documentation subdirectory, people that need cdr_radius will have to install the dictionary manually until we can get the dictionary into a released version of radiusclient-ng. By: phsultan (phsultan) 2006-05-12 02:44:13 The dictionary is likely to be included in the next released version of FreeRADIUS. I agree on keeping the dictionary in the documentation subdir. By: Jeffrey C. Ollie (jcollie) 2006-05-16 11:19:08 miconda, can you verify that you faxed your disclaimer to the proper number? Digium's fax number is +1-256-864-0464. We can't proceed any further until we get a disclaimer from you. By: miconda (miconda) 2006-05-16 11:58:26 I signed the disclaimer and faxet to +1-256-971-6890 on March 08, 2006. I got the number from Olle. Now I am traveling, being currently at VoN, so I can resend it at the end of the week, if you cannot find it. By: phsultan (phsultan) 2006-05-18 11:41:43 Added a patch (cdr_radius-autoconf.0.1.patch) to move the radiusclient-ng checks in autoconf (bootstrap.sh must be run). Modified files are : - configure.ac - makeopts.in - cdr/Makefile The AST_EXT_LIB macro yields a forbidden "-" character in a variable name of the 'configure' shell script because of the library name (radiusclient-ng), so I made no use of it in 'configure.ac'. The patch also corrects cdr_radius.c to get rid of some compilation warnings. By: Russell Bryant (russell) 2006-05-18 18:59:51 I added the patch against cdr_radius.c. I'm going to work on fixing up the AST_EXT_LIB macro so it doesn't have the problem you saw with the library having a "-" in the name. I hope to have this merged in to the trunk in the next couple of days. Stay tuned! :) By: Russell Bryant (russell) 2006-05-18 20:15:24 miconda, that fax number is not the correct one. If you could resend it to the number mentioned my jcollie when you get a chance, we can move ahead with getting this into the trunk. Thanks! By: Russell Bryant (russell) 2006-05-18 21:09:17 I believe I have committed all of the remaining files and changes discussed here. I am also done going through the code doing code review on it. As soon as we get this disclaimer issue cleared up, I am ready to merge it. Also note that as a part of my changes, I moved the single option that was in /etc/asterisk/radius.conf to be in /etc/asterisk/cdr.conf with the rest of the options for this module. If you are using this code, please update and make sure everything still works as expected even after all of the changes I have made. Thanks! By: phsultan (phsultan) 2006-05-19 06:09:47 Updated and tested. There's a small problem with the string values of 'AMA Flags' and 'DISPOSITION', fixed in cdr_radius-ama-disposition.0.1.patch. The dictionary.asterisk file should be renamed dictionary.digium to match FreeRADIUS' naming. The following files should be deleted, now that Russell fixed a bunch of things : - radius.conf - cdr_radius4.txt - cdr_radius-nomutex.0.1.patch - cdr_radius-autoconf.0.1.patch By: Sergey Basmanov (sb) 2006-05-19 07:33:48 rlm_acct_unique: WARNING: Attribute Acct-Session-Id was not found in request, unique ID MAY be inconsistent rlm_acct_unique: WARNING: Attribute User-Name was not found in request, unique ID MAY be inconsistent rlm_acct_unique: Hashing 'NAS-Port = 0,Client-IP-Address = 192.168.1.1,NAS-IP-Address = 192.168.1.1,,' rlm_acct_unique: Acct-Unique-Session-ID = "ab3775a26417c6bb". Is this ok? Or may be cdr_radius should set Acct-Session-Id ? By: Jeffrey C. Ollie (jcollie) 2006-05-19 07:35:28 Files deleted per phsultan. By: Jeffrey C. Ollie (jcollie) 2006-05-19 07:37:31 Maybe Acct-Session-Id should be set to UNIQUEID and User-Name set to the channel name? By: Sergey Basmanov (sb) 2006-05-19 07:51:42 Seems we should take care of Acct-Session-Id and User-Name. Two calls: Acct-Unique-Session-Id = "ab3775a26417c6bb" Timestamp = 1148041466 and Acct-Unique-Session-Id = "ab3775a26417c6bb" Timestamp = 1148042854 Seems all records will have same session-id. By: Sergey Basmanov (sb) 2006-05-19 08:19:00 Attached patch as suggested. Now server logs: rlm_acct_unique: Hashing 'NAS-Port = 0,Client-IP-Address = 192.168.1.1,NAS-IP-Address = 192.168.1.1,Acct-Session-Id = "1148044489.24",User-Name = "Zap/1-1"' By: Russell Bryant (russell) 2006-05-19 08:53:43 Is there any reason that the channel and the unique ID need to be added more than once? If this patch is applied, perhaps the other channel and unique id value pairs should be removed. By: Sergey Basmanov (sb) 2006-05-19 09:14:56 Well, by using Acct-Session-Id and User-Name attributes, raduis server creates Acct-Unique-Session-Id. As I know (may be I'm wrong) this attribute is used by server to unique identify this session (call in our case) when doing something with data. For example when client sending updates for session (or any other events) server makes hash (see my previous post - how) and then looks in database for corresponding record. So, Asterisk-Chan and Asterisk-Unique-ID must be sent anyway, because it's part of cdr data. But we should supply some values to radius server (Acct-Session-Id and User-Name) to allow it unique identify our session. It seems that Channel and Unique-Id best fits our needs. Please correct me if I'm wrong. By: Russell Bryant (russell) 2006-05-19 09:20:44 sb, do you have a disclaimer on file with Digium? By: Jeffrey C. Ollie (jcollie) 2006-05-19 09:20:51 Well, FreeRADIUS uses the User-Name, Acct-Session-Id, NAS-IP-Address, Client-IP-Address and NAS-Port settings to generate a unique id to track accounting records. I don't think that it hurts to have the channel and uniqueid duplicated in the radius packet, especially since the unique id isn't guaranteed to be in the packet. Down the road, it'd be nice to be able to do custom fields as well... By: Sergey Basmanov (sb) 2006-05-19 09:53:54 russell: of course, disclaimer is on file and sent long time ago. By: Russell Bryant (russell) 2006-05-19 11:27:29 Thanks, just making sure. The patch has been added. By: Kevin P. Fleming (kpfleming) 2006-05-19 16:17:53 miconda's disclaimer has been received and filed. By: Russell Bryant (russell) 2006-05-20 17:35:16 This has been merged into the trunk in revision 29094. Thank you to everyone involved in this report! By: Digium Subversion (svnbot) 2008-01-15 17:10:12.000-0600 Repository: asterisk Revision: 11684 A team/oej/cdr_radius/ ------------------------------------------------------------------------ r11684 | oej | 2008-01-15 17:10:11 -0600 (Tue, 15 Jan 2008) | 2 lines Branch for issue ASTERISK-6464 - cdr_radius (Philippe Sultan) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=11684 | ||