[Serusers] Re: [Serdev] Auth* changes

Greger V. Teigre greger at teigre.com
Fri Apr 22 18:56:22 CEST 2005


See inline.

Juha Heinanen wrote:
>> 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.

With Bogdan's changes I thought this was the plan, not just an idea?!  It 
seemed sort of halfway to add sip-avp loading to authentication and not 
does_uri_exist

> because both
> caller and callee may have the same attributes, i suggested to add
> "caller_" and "callee_" prefix into avp names.

Again, I though (maybe just hoped) that this adopted as the convention. I 
believe there are many people who assume, as I do, that functionality 
introduced in 0.9.0 will be followed through in subsequent versions.

> using rpid as an
> example, callee can very well have an rpid that will be used if
> callee decides to forward the call.

I have exactly this issue with a Cisco GW. I need to use callee rpid for 
making sure that billing works correctly with an Ericsson AXE.

>> 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.

Yes, I think this is fine as long as a SIP-Session always has caller in 
username and Call-Check always callee.  One immediate problem is what I 
pointed out in my last post: There seems to be impossible to differentiate 
between a REGISTER auth and an INVITE auth.  Though not off the top of my 
head, there are probably scenarios where it would be useful to be able to 
return AVPs used in registration only.

> regarding removing auth_radius, i need it for other things (such as
> sems related stuff) and would thus like to keep it.

avp_radius, you mean? I didn't know, but then I don't use sems.
g-) 




More information about the sr-users mailing list