Returning several values in the same attributes - bug or feature?

[biuro at globeinphotos.com]

I've noticed very strange behavior of freeradius. After processing of 
'digest' message I invoke 'authorize_reply_query'
that returns list of values in SIP-AVP parameter

In log it looks like this

[cut]
radius_xlat:  'SELECT * FROM
test.authorize_reply('SIP','test002 at server1.test.pl',
'sip:+48580001 at server1.test.pl', 'INVITE' )'
rlm_sql_postgresql: query: SELECT * FROM
test.authorize_reply('SIP','test002 at server1.test.pl',
'sip:+48580001 at server1.test.pl', 'INVITE' )
rlm_sql_postgresql: Status: PGRES_TUPLES_OK
rlm_sql_postgresql: affected rows =
[cut]
Sending Access-Accept of id 8 to 153.19.130.250 port 44072
	SIP-AVP == "#1:+48580001"
	SIP-AVP == "#2:3"
	SIP-AVP == "#3:4"
Finished request 0
Going to the next request

As you see radius returns 3 attributes and it is ok.

But I also receive 'non-digest' message:

rad_recv: Access-Request packet from host 153.19.130.250:44073, id=9, 
length=70
	User-Name = "+48580001 at server1.test.pl"
	Service-Type = SIP-Callee-AVPs
	NAS-Port = 0
	NAS-IP-Address = 153.19.130.250

I do not why for this message radius invoke:
-	authorize_check_query
-	authorize_group_check_query
-	authorize_group_reply

but I do not know why radius DOES NOT invoke authorize_reply_query!!  Do you
know why ??
Because authorize_reply_query is not invoked I put my logic to 
authorize_group_reply but it appeared that sql statement in
authorize_group_reply CAN only return only one row for the same attribute! I
thing it is a bug,  to be sure that it is not my bug I've put the same
functionality in authorize_repy_query (for digest messages) and it has worked
without any problem.

I would like that authorize_group_reply returns something like this:
	SIP-AVP == "#1:+48580001"
	SIP-AVP == "#test1"
	SIP-AVP == "#test2"

But it only returns:
	SIP-AVP == "#1:+48580001"

Any ideas? I cannot return values in other attributes, and in worst case I
return all values in one line of SIP-AVP but it is not best solution.

Michal Szymanski
http://blog.szymanskich.net