22 Apr
2005
22 Apr
'05
11:08 p.m.
Hello,
Juha Heinanen wrote:
I don't see the main impact on being able to diff between a REGISTER and
INVITE auth request. This is mainly an issue when it comes to very
complex radius database back-ends. From my experience, not too much
ressources are wasted here because the db backends on production radius
services are usually powerful enough to serve even the REGISTER load of
a highly populated Ser Proxy.
Greger V. Teigre writes:
In my oppinion, it is an administrator's issue to be able to distinguish
between caller and callee attributes. However, the does_uri_exist
functionality is still missing. A common practice with prefixes is
certainly recommended.
In my experience, anything possible needs to be done to avoid as many
radius queries as possible, because they are very expensive
performance-wise.
My personal opinion: Despite the latest commits,
AVP loading from RADIUS is
still in transition from being an add-on (avp_radius module) to being
integrated in auth_radius and uri_radius. I would love to get rid of one
auth (we have three today for each INVITE).
i too have floated the idea that authentication would return from radius
caller avps and does_uri_exist function callee avps. this way you would
not need to make any extra radius calls. because both caller and callee
may have the same attributes, i suggested to add "caller_" and
"callee_"
prefix into avp names. using rpid as an example, callee can very well
have an rpid that will be used if callee decides to forward the call.
This gives
another question: Should Session-Type=Call-check always
indicate that SIP-AVPs for callee should be returned, or is there
other scenarios? (I don't really know, we haven't, but others may?)
my thinking has been that service type implicitly tells, which
attributes should be returned. if Service-Type is SIP-Session, radius
returns caller attributes and in case of Call-Check callee attributes.
you could still use the same database table for both.
regarding removing auth_radius, i need it for other
things (such as sems
related stuff) and would thus like to keep it.
Referring to avp_radius, I wouldn't remove it. It's interesting for
non-auth proxies like outbound proxies.
Going back to the original discussion, please do not revoke the given
functionality in rel_0_9_0, but create a legacy option (with default=on)
to fall-back to the outdated Sip-Rpid reply attribute when it comes to RPID.
Regards,
Martin Koenig