[OpenSER-Users] checking radius return attributes
Dan-Cristian Bogos
dan.bogos at gmail.com
Thu Aug 30 21:15:23 CEST 2007
Hi Danish,
sorry for replying to you so late, but I was out from the office today.
Here you go:
First of all, my bad, the returned value should be in the form:
return-code#0 if you want your value to be treated as an integer or
return-code:0 if 0 the AVP should be considered as string - has been a
while since I worked last time with those. By using a higher layer of
debug you should be able to see your avps converted inside when
received from radius.
The rest of your configuration looks good. Note that you can return
more AVP values with the same reply, so you can include the credit
amount as well:
SIP-AVP="return-code#0"
SIP-AVP="h323-credit-amount#4206"
Hope you will rock now.
Cheers,
DanB
On 8/30/07, danish.samad at vocalseeds.com <danish.samad at vocalseeds.com> wrote:
> Hi Dan,
> To test the functionality of SIP-AVP, I am trying to get theses avp's in
> the registration block, shown below. Basically on sucessful registration
> the radius server returns the following attributes in acces-accpet
>
> Attributes:
> SIP-AVP = "return-code=0"
> cisco-h323-credit-amount = "h323-credit-amount=4206"
>
> so after registration I am trying to get the return code value. The
> registration block is shown below
>
> route[2] {
> # -----------------------------------------------------------------
> # REGISTER Message Handler
> # ----------------------------------------------------------------
> xlog("L_NOTICE","Danish: Entering route[2]\n");
> xlog("L_NOTICE","Danish: Register message IPsrcaddr [$si],
> RecvdIPaddr[$Ri]\n");
> if (!search("^Contact:[ ]*\*") && nat_uac_test("2")) {
> xlog("L_NOTICE","Danish: In route[2] Found Nated contact\n");
> setflag(6);
> setbflag(6);
> # if you want OPTIONS natpings uncomment next
> setbflag(7);
> fix_nated_register();
> force_rport();
> };
>
> sl_send_reply("100", "Trying");
> if (!radius_www_authorize("192.168.0.99")) {
> www_challenge("192.168.0.99", "1");
> };
> consume_credentials();
>
> #avp_print();
> xlog("L_NOTICE","Danish: Before is set check\n");
> if(is_avp_set("$avp(s:return-code)")){
> xlog("L_NOTICE","Danish: return code is set \n");
> };
> xlog("L_NOTICE","Danish: After is set check\n");
> if(avp_check("$avp(s:return-code)", "eq/i:0/g"))
> {
> xlog("L_NOTICE","Danish: return code 0 received \n");
> };
>
> if (!save("location")) {
> sl_reply_error();
> };
>
> }
>
> In my logs I see
>
> 058) DEBUG:auth_radius:generate_avps: getting SIP AVPs from avpair 225
> 4(11058) Danish: Before is set check
> 4(11058) Danish: After is set check
> 4(11058) DEBUG:avpops:ops_check_avp: no src avp found
>
> so both conditional avp checks fail and the last debug line is a bit worrying
> I traced the first debug line above to sterman.c->generate_avps()
> so just under this debug line I added this piece of code
>
> vp=rc_avpair_get(vp,attrs[A_SIP_AVP].v,0);
> if (vp != NULL)
> {
> DBG("DEBUG:auth_radius:generate_avps: strvalue %s\n",
> vp->strvalue);
> }
> else
> DBG("DEBUG:auth_radius:generate_avps: vp is null\n");
>
> and this is what I got
>
> 4(11058) DEBUG:auth_radius:generate_avps: getting SIP AVPs from avpair 225
> 4(11058) DEBUG:auth_radius:generate_avps: vp is null
>
> hence openser is not loading the SIP-avp in $avp(s:return-code). I think
> either I am missing something in the openser script or the way I am
> returning the attribute.
>
> all relevant definitions in the cfg are given below:
>
> loadmodule "/usr/local/lib/openser/modules/auth_radius.so"
> loadmodule "/usr/local/lib/openser/modules/uri_radius.so"
> loadmodule "/usr/local/lib/openser/modules/avp_radius.so"
> loadmodule "/usr/local/lib/openser/modules/avpops.so"
>
> modparam("auth_radius|uri_radius|avp_radius", "radius_config",
> "/usr/local/etc/radiusclient-ng/radiusclient.conf")
> modparam("mi_fifo", "fifo_name", "/tmp/openser_fifo")
>
> modparam("uri_db|usrloc", "db_url",
> "mysql://openser:openserrw@localhost/openser")
>
> modparam("nathelper", "natping_interval", 20)
> modparam("nathelper", "ping_nated_only", 1)
> modparam("nathelper", "rtpproxy_sock", "unix:/var/run/rtpproxy.sock")
> modparam("nathelper", "received_avp", "$avp(i:42)")
> modparam("nathelper", "sipping_bflag", 7)
> modparam("nathelper", "sipping_from", "sip:pinger at abc.org")
>
> modparam("registrar", "received_avp", "$avp(i:42)")
> modparam("usrloc", "db_mode", 2)
> modparam("usrloc", "nat_bflag", 6)
>
> Hope this explains everything and you would be in a better position to help.
>
> Regards,
> Danish
> ps: isnt there any sample script I can refer to for sip-avp radius
> configurations.
>
>
> > Hi Danish,
> >
> > can u post the full block where you are doing these checks?
> >
> > DanB
> >
> > On 8/29/07, danish.samad at vocalseeds.com <danish.samad at vocalseeds.com>
> > wrote:
> >> Hi Dan,
> >> Thanks for the explanation, things are more clear now. Now I am
> >> returning
> >> a SIP-AVP from radius (for authentication), this is what I see in the
> >> logs
> >>
> >> Attributes:
> >> SIP-AVP = "return-code=0"
> >> .......
> >>
> >> In my script I do
> >> avp_print();
> >> if(is_avp_set("$avp(s:return-code)")){
> >> xlog("L_NOTICE","return code is set \n");
> >> };
> >> if(avp_check("$avp(s:return-code)", "eq/0/g"))
> >> {
> >> xlog("L_NOTICE","return code 0 received \n");
> >> };
> >>
> >> none of the checks pass and nothing is printed from avp_print. In
> >> openser
> >> logs I see this line
> >>
> >> 1(32550) DEBUG:auth_radius:generate_avps: getting SIP AVPs from avpair
> >> 225
> >>
> >> am I missing some pre-requisites or what am I doing wrong.
> >>
> >> Regards,
> >> Danish
> >>
> >>
> >> > Hi Danish,
> >> >
> >> > for the moment you cannot process attributes other than SIP-AVP inside
> >> > openser script. This one is automatically converted into avp.
> >> > EG. A SIP-AVP attribute in the form of: "reason='No Credit'" should
> >> > automatically create an AVP named reason with value "No Credit".
> >> >
> >> > Hope that helps,
> >> > DanB
> >> >
> >> >
> >> > On 8/29/07, danish.samad at vocalseeds.com <danish.samad at vocalseeds.com>
> >> > wrote:
> >> >> Hi Dan,
> >> >>
> >> >> Thanks for your reply.
> >> >>
> >> >> Actually I am currently returning an integer status value in
> >> >> cisco-h323-return-code (a vendor specific attribute). So basically
> >> how
> >> >> can
> >> >> I extract the value returned in this attribute, compare it and then
> >> send
> >> >> and sl reply.
> >> >>
> >> >> Probably there is a way of loading this attr value in an avp and
> >> >> comparing
> >> >> it?
> >> >>
> >> >> Regards,
> >> >> Danish
> >> >>
> >> >> > Hello Danish,
> >> >> >
> >> >> > a solution would be returning a SIP-AVP, containing the reason for
> >> >> > failure, and then forward this to the client using sl.
> >> >> > Another one would be completely rewriting R-URI again from your
> >> >> > SIP-AVP and then send the request to an announcement server (eg:
> >> >> > ann:paymentrequired at your.server - which should play Payment
> >> Required
> >> >> > annoucement).
> >> >> >
> >> >> > Cheers,
> >> >> > DanB
> >> >> >
> >> >> > On 8/29/07, danish.samad at vocalseeds.com
> >> <danish.samad at vocalseeds.com>
> >> >> > wrote:
> >> >> >> Hi,
> >> >> >>
> >> >> >> I have configured openser-1.2 with a (commercial) third party
> >> radius
> >> >> >> server and it is working great. Now I have a requirement where I
> >> need
> >> >> to
> >> >> >> check a radius return attribute in case an access reject is
> >> received
> >> >> in
> >> >> >> response to an authorization request. Is there some way I can do
> >> >> this
> >> >> >> in
> >> >> >> the openser script.
> >> >> >>
> >> >> >> Basically I want to send a 402 payment required message to a sip
> >> >> client
> >> >> >> in
> >> >> >> case the call is rejected due low balance. In such cases radius
> >> >> returns
> >> >> >> a
> >> >> >> status response code with access reject.
> >> >> >>
> >> >> >>
> >> >> >> Thanks,
> >> >> >> Danish
> >> >> >>
> >> >> >> _______________________________________________
> >> >> >> Users mailing list
> >> >> >> Users at openser.org
> >> >> >> http://openser.org/cgi-bin/mailman/listinfo/users
> >> >> >>
> >> >> >
> >> >>
> >> >>
> >> >
> >>
> >>
> >
>
>
More information about the Users
mailing list