22 Apr
2005
22 Apr
'05
1:47 p.m.
Juha Heinanen wrote:
Bogdan-Andrei Iancu writes:
I have to agree with you are this point. I failed to notice this since
it is rather a incompatibility at Radius server level - it's about how
exactly the RPID value is sent: old version, as standalone A_SIP_RPID
Radius attr, now as A_SIP_AVP Radius attr in "rpid:value" format.
As far as I found out, this is the only issue, right? And can be easyly
fixed - before loading all general Radius attributes from A_SIP_AVP,
also look for A_SIP_RPID for backward compat. (maybe configurable)..
Do you find this acceptable from all point of view - compatibility and
cvs ruling?
bogdan
What you miss here - or I haven't made it
clear enough - is that the
auth* commit doesn't backport any new features, improvements, etc, but
backports a *cleanup* of these modules, cleanup which fixes a lot of
inconsistencies - which in my opinion goes into fixing area.
as i said, auth commit was not backwards compatible with what we had
before the commit. more specifically, before the commit, rpid was
returned from radius in SIP-RPID reply attribute to authentication
query, whereas it now is returned in SIP-AVP attribute. thus all
proxies that use radius for authentication stopped working after the
commit.
in order to maintain backwards compatibility at radius level, perhaps
you could add a check for existence of SIP-RPID attribute in the reply
and if it exists, assign its value to rpid avp?