[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sr-dev
Subject:    [Serdev] my radius scheme for call transfer and other things
From:       Juha Heinanen <jh () tutpro ! com>
Date:       2003-12-22 19:50:07
Message-ID: 16359.19183.455404.501157 () harjus ! tutpro ! com
[Download RAW message or body]

i have implemented radius based call transfer plus other things as
follows.

in order to decide what to do with a request bound to local domain, my
ser.cfg first calls radius_does_uri_exist function on the ruri.

that call either succeeds (ruri belongs to a local user) or fails
(doesn't belong to a local user).  in the positive case,
radius_does_uri_exist returns lots of information regarding the ruri as
reply items:

- uri alias (if ruri is not online, his alias may be.  i use this to
  allow the user to only register using his email uri but still be
  reachable also via his phone number.  i don't use the regular ser
  alias stuff at all).

- rpid (i use this to contain user's phone number uri and privacy
  information.  to be added to the request if it goes to pstn)

- zero to four diversion uris: unconditional, unavailable, busy, no
  answer (these will be used in case the user cannot be reached under
  different conditions)

- username to whom ruri belongs to (if the request gets diverted, used
  to later check if this user has right to divert the call to that
  particular destination)

i don't know what you think about this scheme, but it has worked very
well for me in practice.  it also helps to minimize radius calls.

in addition to radius_does_uri_exist i have implemented
radius_check_blocking that checks from radius if the user has the right
to access a given phone number.  in order to support this, i have two
new tables in my radius database:

- prefix (maps phone number prefixes to access list names)

- blocked (tells which access lists the user has subscribed to)

let me know if you want to adopt any of this to regular ser release.

-- juha


[prev in list] [next in list] [prev in thread] [next in thread]