[Serusers] Re: [Serdev] Auth* changes

[Martin Koenig]

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