[Serusers] avp_db_load fails with avp as source

Greger V. Teigre greger at teigre.com
Sun Nov 6 09:34:20 CET 2005


Ah, of course, but why don't you set the text string to the call scope? Or 
maybe better (if you want multiple avpairs and not one where you do regex 
testing): follow Jiri's advice?
g-)
----- Original Message ----- 
From: "brett-ser-list" <brett-ser-list at worldcall.net>
To: <serusers at lists.iptel.org>; "Greger V. Teigre" <greger at teigre.com>
Sent: Friday, November 04, 2005 8:29 AM
Subject: Re: [Serusers] avp_db_load fails with avp as source


>I keep coming back to that. However, a user can be a member of multiple 
>calling scopes. for
> example 1)Houston 2)LongDistance 3)Information
>
> And I can't figure out how to do it nicely that way.. seems like maybe I'd 
> have to create a
> seperate column for each callscope? Surely there sure be a different way.. 
> I simply want to
> load a *list* of avps based on login credentials.. seems simple enough, 
> right?
>
> -Brett
>
> ---------- Original Message ----------------------------------
> From: "Greger V. Teigre" <greger at teigre.com>
> Date:  Fri, 4 Nov 2005 08:10:04 +0100
>
>>Brett,
>>I have never used avpairs with sql (I use radius), but I believe the
>>avp_db_load statement should be removed alltogether.  The avps_column_str
>>instructs the auth module to load the value in the callscope column ON
>>SUCCESSFUL AUTHENTICATION, i.e. when the user is authenticated, the avp is
>>already loaded and ready to be used.
>>g-)
>>
>>----- Original Message ----- 
>>From: "brett-ser-list" <brett-ser-list at worldcall.net>
>>To: <serusers at lists.iptel.org>
>>Sent: Friday, November 04, 2005 2:30 AM
>>Subject: [Serusers] avp_db_load fails with avp as source
>>
>>
>>> Hello All,
>>> I'm trying (desperately) to use avp_db_load with an avp:
>>> version: ser 0.9.3 (i386/linux)
>>> flags: STATS: Off, USE_IPV6, USE_TCP, DISABLE_NAGLE, USE_MCAST,
>>> DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
>>> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
>>> MAX_URI_SIZE 1024, BUF_SIZE 65535
>>> @(#) $Id: main.c,v 1.197 2004/12/03 19:09:31 andrei Exp $
>>> main.c compiled on 12:28:21 Aug 16 2005 with gcc 3.3
>>>
>>> modparam("auth_db","avps_column_str","callscope")
>>> modparam("avpops","avp_aliases","callgroups=i:200")
>>> modparam("avpops","avp_aliases","callscope=i:500")
>>> avp_db_load("$callscope","$callgroups/avps") ;
>>>
>>> In watching the debug, I see the avp loaded just fine from the database
>>> from the auth_db parameter:
>>> 3(1735) DEBUG:avpops:print_avp: p=0xf51c20d8, flags=3
>>> 3(1735) DEBUG:                 name=<callscope>
>>> 3(1735) DEBUG:                 val_str=<200>
>>>
>>> but the above avp_db_load line is resulting in:
>>> 3(1735) DEBUG:avpops:get_val_as_str: no avp found
>>> 3(1735) ERROR:avpops:load_avps: failed to get uuid
>>>
>>> I also notice that it doesn't even bother to hit the database after the
>>> auth_db hit. So unless the avp table has been cached (Which I have no 
>>> idea
>>> if it has..) how would it know?
>>>
>>> Seems like error #1: no avp found? Seems like it doesn't like my syntax
>>> but according to the avpops documentation, it should be right:
>>> source = (sip_uri|avp_alias|str_value)
>>> ['/'('username'|'domain'|'uri'|'uuid')]
>>>
>>>
>>> note:
>>> avp_db_load("$callscope/uuid","$callgroups/avps") ;
>>> gives me:
>>> 0(0) ERROR:avpops:fixup_db_avp: source/flags "callscope" unknown!
>>>
>>> Look, what I really want to do is use the authentication credentials to
>>> load an avp. Isn't that was avp is for? I don't want the FROM or the TO 
>>> or
>>> the [R]URI, but the actual AUTHentication username. Any ideas??
>>>
>>> Thanks!!
>>> BTW, I've tried the newest SER DEVEL CVS, and OPENSER 1.0 with basically
>>> the same results. Some custom modules I have would also make me want to
>>> stick with 0.9.0.
>>>
>>> -Brett
>>>
>>> _______________________________________________
>>> Serusers mailing list
>>> serusers at lists.iptel.org
>>> http://lists.iptel.org/mailman/listinfo/serusers
>>>
>>>
>>
>>
> 




More information about the sr-users mailing list