Custom RADIUS CDR VSAs for SIP
This section describes these additions to the OCSBC’s RADIUS accounting capabilities for customizing your call detail records (CDRs):
- Generating CDRs with call detail information from a SIP message—The OCSBC reserves a set of vender-specific attributes (VSAs) and then populates them according to your header manipulation (HMR) configuration
- Generating CDRs with trunk group information—You can enable your OCSBC to provide terminating trunk-group and trunk-context data even when the OCSBC is not performing trunk-group routing.
Both support using the CSV file for RADIUS records, which you can either save locally or push to a defined FTP server.
About User-Defined VSAs for SIP Calls
The OCSBC reserves VSAs 200-229 for you to define for use with SIP calls. These VSAs should never be used for other purposes, and their use should never conflict with the need to add new VSAs in the future. Because this leaves a significant number of VSAs unused, there is still ample space for any new VSAs that might be required.
Since RADIUS START records are created on session initiation, their content cannot be updated. However, the content for INTERIM and STOP records can be.
To configure user-defined VSAs for a SIP call, you use HMR. For example, when you set up HMR correctly, the OCSBC reports originating or terminating country codes in CDRs in whatever format they appear in the SIP username field. The HMR rules you configure uses the SIP header name P-Acme-VSA, adding it to the SIP header from any part of the SIP message. Then the OCSBC searches for the P-Acme-VSA header, generates a VSA for it, and then includes that VSA in the CDR for the call.
You can include multiple custom VSAs per CDR by adding the corresponding number of rules; in essence, you add in the header as many times as required.
HMR Adaptations
The following HMR element rule types support user-defined VSA for SIP calls:
- uri-user-only—The uri-user-only element rule type represents the URI username without the URI user parameters. You can perform these actions for the uri-user-only type: store, replaces, delete, and add. This means, for example, that you can add a username string to SIP or TEL URI without having any impact on other parameters.
- uri-phone-number-only—The uri-phone-number-only applies when all rules are met. It refers to the user part of the SIP/TEL URI without the user parameters when the user qualifies for the BNF shown here:
uri-phone-number-only = [+]1*(phone-digit / dtmf-digit / pause-character) phone-digit = DIGIT / visual-separator DIGIT = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" visual-separator = "-" / "." / "(" / ")" dtnf-digit = "*" / "#" / "A" / "B" / "C" / "D" pause-character = "p" / "w"Once the URI user part qualifies as a uri-phone-number-only based on this BNF, the OCSBC ignores the visual separators when comparing it against a match value. Furthermore, the OCSBC performs on or using the uri-phone-number-only after the excluding the visual separators.
But anew value being added as a uri-phone-number-only or replacing a uri-phone-number-only does not have to match the BNF noted above. That is, you can use the uri-phone-number-only type knowing that:
- The action only occurs if the URI username matches the BNF defined here.
- Even so, you can also replace the uri-phone-number-only with one that does not match—using the same rule.
HMR String Variable
HMR supports the use of a string variable that you can use to populate headers and elements. You set this value in the hmr-string parameter for a realm, SIP session agent, or SIP interface. Then, you reference it as the $HMR_STRING variable.
When a message arrives, the OCSBC matches the string you provision to the closest session agent, realm, or SIP interface. The precedence for matching is in this order: session agent, realm, and then SIP interface. For example, the OCSBC populates messages matching a session agent using the $HMR_STRING variable, but it leaves the value empty for session agents that do not match.
You can use the string variable, for instance, for values specific to realms and session agents such as country code values when the regular expression pattern used to match a country code fails to do so.
ACLI Instructions and Examples User-Defined VSAs
This section shows you how to configure user-defined VSAs for SIP calls. It also contains subsections with configuration examples so you can see how this feature is put to use.
This section also shows you two configuration examples for this feature.
To create a header manipulation rule that generates user-defined VSAs for SIP calls:
The first example shows you how to generate custom VSA for the To and From headers in SIP messages.
- VSA 200 contains the header value from the SIP From header.
- VSA 220 contains the header value from the SIP To header.
sip-manipulation namecustom VSA1 description header-rule name storeFrom header-name from action store comparison-type pattern-rule match-value .* msg-type request new-value methods INVITE header-rule name storeTo header-name to action store comparison-type pattern-rule match-value .* msg-type request new-value methods INVITE header-rule name generateVSA200 header-name P-Acme-VSA action add comparison-type case-sensitive match-value msg-type any new-value 200:+$storeFrom.$0 methods INVITE header-rule name generateVSA220 header-name P-Acme-VSA action add comparison-type case-sensitive match-value msg-type any new-value 220:+$storeTo.$0 methods INVITE
The second example shows you how to configure HMR to generate VSA 225, which contains the customer P_From header when it is present. When that header is not present, the rule instructs the OCSBC to include the header value from the SIP From header for VSA 225.
sip-manipulation
name customVSA1
description
header-rule
name storePfrom
header-name P_From
action store
comparison-type pattern-rule
match-value .*
msg-type request
new-value
methods INVITE
header-rule
name storeFrom
header-name from
action store
comparison-type pattern-rule
match-value .*
msg-type request
new-value
methods INVITE
header-rule
name generateVSA225_1
header-name P-Acme-VSA
action add
comparison-type case-sensitive
match-value
msg-type request
new-value 225:+$storeFrom.$0
methods INVITE
header-rule
name generateVSA225_2
header-name P-Acme-VSA
action manipulate
comparison-type pattern-rule
match-value $storePfrom
msg-type request
new-value
methods INVITE
element-rule
name one
parameter-name
type header-value
action delete-element
match-val-type any
comparison-type pattern-rule
match-value ^225.*
new-value
element-rule
name two
parameter-name
type header-value
action add
match-val-type any
comparison-type case-sensitive
match-value
new-value 225:+$storePfrom.$0Trunk-Group VSA Generation
You can force the OCSBC to generate VSAs related to trunk groups even when you are not using the trunk group feature. With the force-report-trunk-info parameter turned on in the session router configuration:
- The OCSBC reports terminating trunk group and trunk-context information even though it has not perform trunk-group routing.
The appropriate VSAs report the terminating trunk-group (VSA 65) and trunk context (VSA 67) with the information of the matching ingress session agent and realm of the originator.
- The OCSBC reports the terminating trunk-group (VSA 66) and trunk context (VSA 68) as the received trunk group and context from the call’s SIP REQUEST message. If the SIP message has none, then the OCSBC uses the information from the matching egress session agent (or egress realm, when available) and next-hop realm.
Note that information is reported after HMR processing—meaning that header manipulation has been performed on the message information reported.