– Kamailio SIP Server –

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
troubleshooting:radius [2006/12/19 09:41] – 81.180.83.75troubleshooting:radius [2007/04/19 00:00] (current) – external edit 127.0.0.1
Line 1: Line 1:
 +====== OpenSER - Troubleshooting: Radius ======
 +
 +**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).
 +
 +===== Troubleshooting Stuff =====
 +
 +{{indexmenu>troubleshooting|js}}
  

Trace: