[Serusers] Re: [Serdev] Auth* changes
Martin Koenig
martin.koenig at toplink-plannet.de
Fri Apr 22 23:08:17 CEST 2005
Hello,
Juha Heinanen wrote:
>Greger V. Teigre writes:
>
> > 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.
>
>
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.
> > 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.
>
>
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.
>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
More information about the sr-users
mailing list