Hi I have problem to properly handle OpenSer request in Freeradius. When I switch on debug mode in freeradius I've got LISTING 1 (below). In the first part of log we can see that INVITE message was received and authorize_check (defined by _check_query ) SQL statement was called and I've got proper result. After that message was parsed and values from Digest-Attributes was moved to named Digest- attributes e.g Digest-Method In my radius solution I have to return to OpenSer few attributes when I detect that Digest-Method is equal to INVITE. But I cannot return attributes by authorize_check because when authotize_check db procedure is called Digest-Method is not set (only I can see Digest-Attributes). After call to authorize_check, freeradius parse request and I have complete set of values:       Digest-User-Name = "test001"       Digest-Realm = "server1.test.pl"       Digest-Nonce = "44b414bb1e6165386992a6c367a1ce2b1682ba32"       Digest-URI = "sip:+4800001@server1.test.pl"       Digest-Method = "INVITE" But after this part only one DB procedure is called: test.postauth() (defined by postauth_query in postgres.sql) but this procedure  cannot return attributes - It can returns only one string. I have questions: - how to return list attributes when message is parsed ? Is it possible to configure that radius will call sql statement after parsing a message - how to access all Digest-Attrbute from unparsed message when I put '%{Digest-Attributes}' in query I can see only first attribute - Is possible to control order of  parsing in my example orders is:     - receive of 'raw' request     - execution authorize check     - parsing of raw message (message "mod_digest: Converting Digest-Attributes to something sane")   But in post http://lists.freeradius.org/mailman/htdig/freeradius-users/2004-September/03 6519.html order is following      - receive of 'raw' request     - parsing of raw message (message "mod_digest: Converting Digest-Attributes to something sane") - execution authorize check   Do you know how to achieve last order ? Should I change something in conf. files? Part of  my postgres.conf file: authorize_check_query = "SELECT * FROM test.authorize_check('%{SQL-User-Name}', '%{Digest-URI}', '%{Service-Type}')"       postauth_query = "SELECT test.postauth('%{Digest-Method}', '%{Digest-Attributes:-0}', '%{Digest-Attributes:-3}')" LISTING 1 --------- rad_recv: Access-Request packet from host 153.19.130.250:34032, id=245, length=237       User-Name = "test001@server1.test.pl"       Digest-Attributes = "\n\ttest001"       Digest-Attributes = "\001\026server1.test.pl"       Digest-Attributes = "\002*44b414bb1e6165386992a6c367a1ce2b1682ba32"       Digest-Attributes = "\004#sip:+4800001@server1.test.pl"       Digest-Attributes = "\003\010INVITE"       Digest-Response = "1475e3bd94becc734d77893ddcd70046"       Service-Type = IAPP-Register       Sip-URI-User = "test001"       NAS-Port = 5060       NAS-IP-Address = 153.19.130.250   Processing the authorize section of radiusd.conf modcall: entering group authorize for request 3   modcall[authorize]: module "preprocess" returns ok for request 3   modcall[authorize]: module "chap" returns noop for request 3 rlm_digest: Adding Auth-Type = DIGEST   modcall[authorize]: module "digest" returns ok for request 3     rlm_realm: Looking up realm "server1.test.pl" for User-Name = "test001@server1.test.pl"     rlm_realm: No such realm "server1.test.pl"   modcall[authorize]: module "suffix" returns noop for request 3     users: Matched entry DEFAULT at line 5     users: Matched entry DEFAULT at line 42   modcall[authorize]: module "files" returns ok for request 3 radius_xlat:  'test001@server1.test.pl' rlm_sql (sql): sql_set_user escaped user --> 'test001@server1.test.pl' radius_xlat:  'SELECT * FROM test.authorize_check('test001@server1.test.pl', '', '')' rlm_sql (sql): Reserving sql socket id: 3 rlm_sql_postgresql: query: SELECT * FROM test.authorize_check('test001@server1.test.pl', '', '') rlm_sql_postgresql: Status: PGRES_TUPLES_OK rlm_sql_postgresql: affected rows = radius_xlat:  '' radius_xlat:  '' radius_xlat:  '' rlm_sql (sql): Released sql socket id: 3   modcall[authorize]: module "sql" returns ok for request 3 modcall: leaving group authorize (returns ok) for request 3   rad_check_password:  Found Auth-Type Digest auth: type "digest"   Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 3     rlm_digest: Converting Digest-Attributes to something sane...       Digest-User-Name = "test001"       Digest-Realm = "server1.test.pl"       Digest-Nonce = "44b414bb1e6165386992a6c367a1ce2b1682ba32"       Digest-URI = "sip:+4800001@server1.test.pl"       Digest-Method = "INVITE" A1 = test001:server1.test.pl:gdfi A2 = INVITE:sip:+4800001@server1.test.pl H(A1) = 1307e5525ca6a7907307ad0af15dbb42 H(A2) = 5bfbcc6c93b4debf70853f609176ff45 KD = 1307e5525ca6a7907307ad0af15dbb42:44b414bb1e6165386992a6c367a1ce2b1682ba32:5b fbcc6c93b4debf70853f609176ff45 EXPECTED 1475e3bd94becc734d77893ddcd70046 RECEIVED 1475e3bd94becc734d77893ddcd70046   modcall[authenticate]: module "digest" returns ok for request 3 modcall: leaving group authenticate (returns ok) for request 3 Login OK: [test001@server1.test.pl/<no User-Password attribute>] (from client server1 port 5060)   Processing the post-auth section of radiusd.conf modcall: entering group post-auth for request 3 rlm_sql (sql): Processing sql_postauth radius_xlat:  'test001@server1.test.pl' rlm_sql (sql): sql_set_user escaped user --> 'test001@server1.test.pl' radius_xlat:  'SELECT test.postauth('=5Cn=5Cttest001', '=5Cn=5Cttest001', '=5Cn=5Cttest001')' radius_xlat:  '/var/log/freeradius/sqltrace.sql' rlm_sql (sql) in sql_postauth: query is SELECT test.postauth('', '=5Cn=5Cttest001', '=5Cn=5Cttest001') rlm_sql (sql): Reserving sql socket id: 2 rlm_sql_postgresql: query: SELECT test.postauth('', '=5Cn=5Cttest001', '=5Cn=5Cttest001') Regards Michal Szymanski -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.9.10/384 - Release Date: 2006-07-10