VSA Processing embedded values

[Ben Gatewood]

I agree - horrific. The vendor is Broadsoft who make (actually very good IMHO) VoIP PABX products.

I don’t need to ‘do’ anything with the value other than store it into the DB in an appropriately recognisable column. It’s relevant to the Call Detail Record that the PABX is sending me. I’d much rather have each of these 'overloaded’ VSAs broken out into a separate column like the ‘normal’ VSAs so I have to do less in the mediation layer. That is, rather than having a single DB column with values like: “272=Yes”, "372=2678148:1” etc. etc.

Thanks very much for your help.

Ben

On 31 Dec 2014, at 13:23, Alan DeKok <aland at deployingradius.com> wrote:

> On Dec 31, 2014, at 5:16 AM, Ben Gatewood <Ben.Gatewood at essensys.co.uk> wrote:
>> I am processing Accounting records from a vendor who overloads VSA 255 to extend the range of available attributes. For instance, they may send something like this:
>> 
>> VENDOR-Attr-255 = "272=Yes”
>> 
>> Which really means VSA 272 = “Yes”
> 
>  Which is a terrible idea.  Horrific, even.
> 
>> I am struggling a bit to figure out how to process these effectively. I found rlm_attr_rewrite but I can’t see a way to make it split the string and drop the “272=“ part. Is there a way to do this in unlang at all or am I going to need to bring in rlm_python or similar?
> 
>  Removing the “272=“ text won’t help.  You’ll get a bare “Yes”, which isn’t very meaningful.
> 
>  I’d have to ask WHICH vendor does this.  That information shouldn’t be secret.  And WHY you need this re-written.  What are you doing with the data?
> 
>  There’s likely a better way of getting the “Yes” out, which doesn’t involve rewriting an attribute.
> 
>  Alan DeKok.
> 
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html