Problem: The RADIUS SIP-AVP attributes are not imported into openser's AVPs
Answer: Make sure the RADIUS dictionary of radiusclient is complete and understands the SIP-AVP attribute (225). Also if there are other RADIUS attributes in the RADIUS response, they must be defined in the dictionary, otherwise radiusclient will discard all RADIUS attributes (also the known ones).
Problem: No RADIUS packets are sent from OpenSER
Answer: One possible problem that stops the Radiusclient library from sending out data, is if the servers configuration file for radiusclient-ng is not readable by the OpenSER user. After a default install of radiusclient-ng, the servers file is only readable by root, so if your OpenSER server is not running as root, the file persmissions will need to be changed.
Problem: Can't authenticate sip client with digest authentication
Answer: The problem is dictionary.radius don't have the attribute Digest-User-Password. Add this to dictionary.radius: ATTRIBUTE Digest-User-Password 1073 string
Answer 2: It's matching your DEFAULT entry in files (setting the Auth-Type to none) but the sql module is later changing the Auth-Type to “digest” - see http://lists.iptel.org/pipermail/serdev/2005-October/006086.html
Problem: CDRTool ( ⇐ 5.0.10): With multi-leg call accounting turned on, only a single record is written to radacct
Answer:
The reason radius was not writing multiple records when (for example, the acc table had multiple records written for the same call) was because the “CDRTool modified” radacct table has the “sess_id” index set as UNIQUE.
The sess_id index is created from the following fields: I
AcctSessionId SipFromTag SipToTag
It appears that in a multi-leg (for example call forwarding) accounting situation, the above three fields are identical.
One fix is to redefine “sess_id” so it is to be computed based on some fields including leg-specific info (thus making is UNIQUE).
Another fix is to redefine sess_id so it's ok to have duplicates (not UNIQUE).