VSA Processing embedded values

[Arran Cudbard-Bell]

> On 31 Dec 2014, at 08:45, Ben Gatewood <Ben.Gatewood at essensys.co.uk> wrote:
> 
> 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.

So you just need the attribute number and the value split out?

You can just use a regex

if (<vendor attr> =~ /^([0-9]+)=(.*)$/) {
	# integer available as %{1}
	# value available as %{2}
}

There's also the option of adding a RADIUS decoder xlat which operates
like the DHCP options decoder xlat.

But then we'd really need a pack module to help with forming the octet
string to feed into that.

Another way would be to accept xlats on the LHS of maps which expand into 
attribute names. 

if (<vendor attr> =~ /^([0-9]+)=(.*)$/) {
	update request {
		"%{vendor:<vendor attr>}-Attr-%{1}" := "%{2}"
	}
}

Vendor in this case operates like %{tag:} and gets you the vendor name
associated with the attribute.

If we tweaked dict_unknown_from_str to accept attribute names as well,
I think we could probably get rid of the Cisco AVPair hacks in the code,
and replace them with a policy.

What do people think? Seems like a more generic solution to vendor 
stupidity. I've seen similar formats used by vendors other than Cisco and
Broadsoft.

-Arran

Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS development team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2