2 Call Signaling Accounting Configuration
This section explains SIP and H.323 accounting using the RADIUS Accounting System (RAS).
You can configure the SBC to modify and populate CDRs in specific ways. There are options for how a call proceeds with respect to start/stop/interim records, and the information contained within. This chapter lists features relating to your ability to customize the behavior of call data record population.
Session Accounting
The RAS client can record SIP, H.323, and IWF session activity based on configuration and a CDR. The CDR determines which messages are generated and determines the RADIUS attributes included in the messages. The RAS client must be capable of sending CDRs to any number of RADIUS accounting servers, using the defined hunt, failover, round robin, fewest pending, or fastest server strategies.
The establishment, failed establishment, change, or removal of a session can trigger RADIUS Accounting Request messages. The RAS might also send notification of its status (enabled/disabled). RADIUS Accounting Request messages include the following:
- Start—Session has started.
- Interim-Update—Session parameters have changed.
- Stop—Session has ended.
- Accounting-On—Creation of a new RADIUS client.
- Accounting-Off—RADIUS client has shut down.
Each session might generate Start, Interim-Update, and Stop messages based on the local configuration when the session is initiated. Each Start message tells the RADIUS server that a session has started. Each Interim-Update message changes the session parameters, and may report the session characteristics for the session to that point. Each Stop message informs the RADIUS server that a session has ended and reports session characteristics.
The RAS has the ability to transmit all RADIUS messages related to a session at the end of the session, regardless of which messages are generated and when they are generated. Some customers might choose this option to reduce the likelihood of the RADIUS messages being logged to different servers, or in different log files on the same server.
The RAS always generates a RADIUS Stop message when the session ends, regardless of the session termination cause. The termination cause and the session characteristics are reported.
RADIUS Messages
The following table identifies the relationship between the signaling elements and the RADIUS attributes included in Accounting Request messages to the RADIUS server.
| RADIUS Attribute | Data Element | Message |
|---|---|---|
| NAS IP-Address | IP address of the SIP proxy or the H.323 stack’s call signal address. | Start, Interim-Update, Stop, On, Off |
| NAS Port | SIP proxy port or the H.323 stack’s call signaling RAS port. | Start, Interim-Update, Stop, On, Off |
| NAS Identifier | Value, if any, set in the optional NAS-ID field
for the accounting server that you configure as part of the accounting
configuration. This identifier sets the value that the remote server (the
accounting server) uses to identify the
SBC so that RADIUS
messages can be transmitted.
The remote server to which the accounting configuration will send messages uses at least one of two pieces of information for identification: NAS IP address: always included in the accounting message NAS identifier: configured in the NAS-ID parameter of the accounting server; if configured, the NAS identifier is sent to the remote server This attribute only appears if a value is configured in the NAS-ID field. |
Start, Interim-Update, Stop, On, Off |
| Acct-Session-ID | Either the Call-ID field value of the SIP INVITE message, the callIdentifier of the H.323 message, or RADIUS client information. | Start, Interim-Update, Stop, On, Off |
| Called Station ID | To field value of the SIP INVITE message (a type of message used to initiate a session) or the calledPartyNumber of the H.323 message. | Start, Interim-Update, Stop |
| Calling Station ID | From field value of the SIP INVITE message or the callingPartyNumber of the H.323 message. | Start, Interim-Update, Stop |
| Acct-Terminate-Cause | Reason for session ending (refer to Session Termination session). | Stop, Off |
| Acct-Session-Time | Length of session (time in seconds, or milliseconds if so configured). | Interim-Update, Stop, Off |
Session Termination
Sessions are terminated for reasons that include normal termination, signaling failure, timeout, or network problems. The following table maps RADIUS accounting termination cause codes to network events.
| RADIUS Termination Cause | Event | Message |
|---|---|---|
| User request | SIP BYE message or H.323 | Stop |
| User error | SIP signaling failed to establish session (accompanied by disconnect cause) | Stop |
| NAS request | RADIUS server disabled | Off |
Interim RADIUS Records for Recursive Attempts
When the SBC routes calls, it performs local policy look-ups that can return several next hops, ordered by preference. This can also happen as a results of an LRT lookup, an ENUM query response, or SIP redirect. To set up sessions, the SBC uses—in ordered preference—and recurses through the list if it encounters failures.
You can configure SIP accounting to send RADIUS Interim records when the SBC encounters these failures. The interim message contains: the destination IP address, the disconnect reason, a timestamp for the failure, and the number that was called. This feature is enabled by setting the generate-interim parameter to unsuccessful-attempt. Please refer to Appendix B to view the format of an unsuccessful-attempt interim record.
SIP CDR Stop Time
You can set up your global SIP configuration so the disconnect time reflected in a RADIUS CDR is the time when the SBC receives a BYE. Enabling this parameter also means the disconnect time is defined when the SBC sends a BYE to the UAS and UAC. Otherwise, the the CDR’s value is based on when the 200 OK confirms the BYE.
The applicable RADIUS CDR in this case is the standard RADIUS attribute Acct-Session-Time, number 46.
Media Stop Time VSA in CDRs
An accurate portrayal of a call’s media stop time is important for billing accuracy. Calls are often terminated well after the media has stopped flowing for such reasons as network or equipment peculiarities.
Media Stop Time VSAs
To record the actual media stop time, the Oracle Communications Session Border Controller writes the following four VSAs in CDR Stop Records:
Acme-Flow-Calling-Media-Stop-Time_FS1
Acme-Flow-Called-Media-Stop-Time_FS1
Acme-Flow-Calling-Media-Stop-Time_FS2
Acme-Flow-Called-Media-Stop-Time_FS2These VSAs correspond to:
- calling side’s media stop time - stream 1
- called side’s media stop time - stream 1
- calling side’s media stop time - stream 2
- called side’s media stop time - stream 2
Media Stop Time Calculation
The granularity of the time at which the Oracle Communications Session Border Controller’s checks for media stream idleness, the actual media stop time, as inserted into a CDR is accurate to between 0 and +10 seconds.
- Tc—Time between most recent idleness sample end and end-of-call time
- Tm—2 complete idleness windows
- Te—Time into the idleness window in which the call’s media stopped. This is also the error amount of the recorded media stop time
- Ti—The actual time between the end of media and the end of call
Tm and Tc are known. The Oracle Communications Session Border Controller also knows that the media ended between 20 and 30 seconds, but the actual time, 10- Te into the frame is unknown. Thus, the time recorded in the CDR is quantized up to the end of the media stop frame at 30 seconds. This time, as written to the CDR, must be interpreted with possible error of 0 ≤ Te < 10 seconds.
Media Stop Time during HA Switchover
When a switchover occurs between media stop time and end of call, the media stop time written to the CDR is the failover time.
Millisecond Granularity for CDRs
Some accounting features require greater precision. The attribute acct-session-time can be configured to be in milliseconds.
The RADIUS attribute acct-session-time uses seconds as its default. You can set this to a millisecond granularity in the account-config configuration element using the option millisecond-duration. This option setting is required for the RADIUS CDR display, Diameter RF accounting and locally-generated CDR comma separated value (CSV) files behaviors.
Note:
Changing to millisecond granularity violates RFC 2866.SIP Call Tear Down Due to Media Guard Timer Expiration
When a SIP call is torn down by the SBC due to media timers expiring, the following standard and VSA attributes and their corresponding values will appear in the CDR stop message together:
Table 2-1 Media Guard Timer Expiration in CDR
| CDR Attribute | Value | Explanation |
|---|---|---|
| Acct-Terminate-Cause | Idle-Timeout | This standard RADIUS AVP indicates the call was ended due to a timer expiring. |
| h323-disconnect-cause | "6" | This VSA AVP indicates the call was ended due to a timeout. |
| Acme-Disconnect-Initiator | 3 | This VSA AVP indicates the call disconnect was initiated internally from the SBC, and not from an endpoint or due to an unknown reason. |
Set Accounting Message Generation
You set the account configuration parameters to define high level accounting information. After setting initial parameters in the account-config, you must create one or more accounting-servers that define the systems where RADIUS accounting CDRs are sent.
To configure the account configuration:
Enhanced Stop CDR Reporting for Exceeded Ingress Session Constraints
The SIP enhanced-cdr option enables consistent generation of RADIUS Stop records on both ingress and egress paths. With enhanced-cdr enabled, RADIUS Stop records are generated in response to any ingress path rejection of a dialog creating SIP INVITE request. The contents of RADIUS Stop records are also written to the local CDR files (if enabled).
Use the following command syntax to enable consistent generation of RADIUS Stop records.
ORACLE(sip-config)# options +enhanced-cdr
ORACLE(sip-config)#In legacy releases there was an inconsistency in the generation of RADIUS Stop records when calls are rejected for exceeding configured session ingress or egress constraints. On the egress path, legacy releases rejected such calls with a 503 (Service Unavailable) response and the generation of a RADIUS STOP record. On the ingress path, however, while calls were rejected with a 503 response, RADIUS Stop records were not generated.
Including P-Visited Network Identifier and History-Info Headers in CDRs
You can configure the SBC to add fully compliant P-Visited Network Identifier (PVNI) and History-Info (HI) headers in CDRs. You configure this by adding the pcscf-cdr-compliance option to the account-config, specifying whether you want to include PVNI (PVNI-pref), HI (HI-pref), or both. The behavior is dependent on the type of call, including Mobile Terminating (MT) and Mobile Originating (MO), information provided by SIP, and whether you are also using an S8HR profile.
The PVNI and HI fields in CDRs may or may not contain data. When configured, the SBC performs processes to determine whether or not to add:
- P-Visited-Network-ID to the applicable CDR field
- History-Info to the applicable CDR field
You configure the pcscf-cdr-compliance in the applicable account-config to use these processes within your environment.
ORACLE# configure terminal
ORACLE(configure)# session-router
ORACLE(session-router)# account-config
ORACLE(account-config)# select
ORACLE(account-config)# options +pcscf-cdr-compliance=PVNI-prefIf you save and activate this configuration, the SBC enables PVNI CDR population for MT calls. To configure for both PVNI and HI headers, configure the option with both values separated by a comma and enclosed in quotes.
ORACLE(account-config)# options +pcscf-cdr-compliance="PVNI-pref,HI-pref"Support for P-Visited-Network-ID Field
For MT calls, the access SBC, deployed as an A-SBC, inserts the PVNI header in CDRs based on the called party registration cache entry (MCC/MNC). If the Called party registration cache does not have a PVNI value, the A-SBC inserts the network-id value from the access side (egress realm) sip-interface configuration as the PVNI into CDRs.
For both MO and MT and when you configure it to add PVNI to CDRs, the A-SBC checks for an s8hr-profile in the same interface:
- If there is an S8HR profile on the access
sip-interface:
- If the SBC receives an MCC/MNC from the Rx server, it creates the PVNI header using the called party registration cache entry (MCC/MNC) and adds it to the CDR.
- If the SBC does not
receive an MCC/MNC, It checks whether there is a
network-id value on the access side
sip-interface:
- If so, the SBC creates the PVNI using that network-id value.
- If not, the SBC uses the
local-mccmnc value as the PVNI, and
adds it to CDR.
Note:
If you have not configured the local-mccmnc value in your S8HR profile, the SBC uses the default, which is 999999.
- If there is not an S8HR profile on the access sip-interface, the SBC checks whether there is a network-id value on the access side sip-interface. If so, the SBC uses the network-id value as the PVNI, and adds it to CDR.
- If both the S8HR and the egress (access)
network-id are not configured, the SBC checks whether the initial
INVITE/MESSAGE comes from a trusted endpoint and contains a PVNI:
- If so, the SBC relays the PVNI and add to CDR.
- If not, the SBC leaves the PVNI field empty.
When you have set the pcscf-cdr-compliance option to include PVNI, and the SBC is acting as an I-SBC handling MO/MT calls, the SBC uses the following sequence for populating the CDR field:
- If configured, uses the network-id on the ingress sip-interface as PVNI.
- If populated and from a trusted endpoint, uses the PVNI from the initial INVITE.
- Leaves the PVNI field empty.
Note:
This behavior applies to the INVITE or any Re-INVITE.Support for History-Info Field
For MO calls, if you have configured the HI option in the account-config, SBC uses the History-Info(s) received in the initial INVITE replies, including those with 181, 180 or 200 status-codes. The SBC populates the CDR with the last provisional (>100) or final (200) response containing History-Info(s). If History-Info is not available in provisional or final replies, the SBC leaves the History-Info in the CDR empty.
For MT calls, SBC extracts History-Info header(s) from the initial INVITE and adds them to the CDR. If History-Info is not available in the initial INVITE, the SBC leaves the HI field empty.
If there are multiple History-Info headers in the initial INVITE, the SBC concatenates all the history-info headers values, and without exceeding the default or configured CDR field size, adds them to the CDR.
- HI-1 - 100 characters
- HI-2 - 100 characters
- HI-3 - 100 characters
By default, the maximum CDR field size is 246. In this case, the SBC includes the first two History-Info headers in their entirety, and truncates HI-3.
Consider the presence of the following HI headers:
- History-Info: <sip:bob@example.com>;index=1
- History-Info: <sip:office@example.com>;index=1.2;mp=1
- History-Info: <sip:office@192.0.2.5>;index=1.2.1;rc=1.2
The SBC populates the History-Info CDR as follows
<sip:bob@example.com>;index=1, <sip:office@example.com>;index=1.2;mp=1, <sip:office@192.0.2.5>;index= 1.2.1;rc=1.2Including the Reason-Header AVP in CDRs
You can configure the SBC to include reason header AVPs in diameter STOP and EVENT CDRs within the context of a configured account-config. When configured, the SBC does this for both cause information it receives from another device and for cause information the system generates itself. To do this, you enable the add-reason-header parameter in the sip-config. When enabled, the SBC includes the Reason-Header AVP in Diameter Accounting Request (ACRs) for Accounting-Record-Type [STOP/EVENT] CDRs per spec 3GPP TS 32.299 V13.5.0 for both in-dialog and out-of-dialog messages. This is in addition to the parameter's other functions, including adding the SIP reason header to BYE, CANCEL, and SIP Error Responses (4xx, 5xx, 6xx). You can customize the text used in reason headers using the local-error parameters in the local-response-map that you apply to your target traffic.
The system checks incoming BYE, CANCEL, and SIP Error Responses (4xx, 5xx, 6xx) for reason headers to propagate using either default or customized messaging you have specified in your local response map. These headers would be presented as Q.850 cause and text information. If the incoming message does not include reason headers, the SBC does not insert a reason header AVP in the ACR or a reason header in the ensuing signaling. If it receives multiple reason-headers, the system adds them all in both AVP and the signaling. If the SBC does not have a customized or default mapping for a SIP error code, it maps that code to the q850CauseTypeInternalError (47).
In addition to reason header propagation, the SBC generates reason headers based on issues it identifies itself. These would usually be 6xx responses. For these situations, the SBC also includes the reason-header AVP for CDRs and SIP error messages for egress. The system uses the default or customized messaging configured in the local-response-map for its own reason headers.
Note:
The SBC never uses SIP cause and text to construct its own reason headers. instead adding the q850 cause and text. It does, however, make the content of Reason-Header AVP the same as that of received SIP Reason: header.To create reason headers, the SBC concatenates the q.850-cause and q.850-reason. A formatted example of a SIP reason-header follows.
Q.850;cause=16;text="Call Terminated"See Configure Reason and Cause Mapping for SIP-SIP Calls for instructions on configuring a local-response-map, including the local-error parameters and the add-reason-header parameter.
Default Reason Header Information
When you enable the add-reason-header in the sip-config without having configured a local-response-map, the SBC adds reason information to responses and CDRs using default q.850 reason-text and q.850 cause-codes. An example of default text for the 488 message code is "Not Acceptable here". The SBC includes all error code enumerations in the local-error listing within the local-response-map. Default values are presented below.
| SIP Error Codes | Integer Value | Q850 Cause Codes | Integer Value |
|---|---|---|---|
| RESP_STATUS_MOVED | 301 | q850CauseTypeNumberChanged | 22 |
| RESP_STATUS_BAD | 400 | q850CauseTypeInternalError | 47 |
| RESP_STATUS_UNAUTH | 401 | q850CauseTypeIncomingBarred | 55 |
| RESP_STATUS_PAY_REQ | 402 | q850CauseTypeIncomingBarred | 55 |
| RESP_STATUS_FORBIDDEN | 403 | q850CauseTypeIncomingBarred | 55 |
| RESP_STATUS_NOT_FOUND | 404 | q850CauseTypeDestUnreachable | 3 |
| RESP_STATUS_NOT_ALLOW | 405 | q850CauseTypeIncomingBarred | 55 |
| RESP_STATUS_NOT_ACCEPT | 406 | q850CauseTypeIncomingBarred | 55 |
| RESP_STATUS_AUTH_REQ | 407 | q850CauseTypeIncomingBarred | 55 |
| RESP_STATUS_REQ_TMO | 408 | q850CauseTypeNoUserResponding | 18 |
| RESP_STATUS_CONFLICT | 409 | q850CauseTypeInternalError | 47 |
| RESP_STATUS_GONE | 410 | q850CauseTypeNumberChanged | 22 |
| RESP_STATUS_LEN_REQ | 411 | q850CauseTypeInternalError | 47 |
| RESP_STATUS_TOO_BIG | 413 | q850CauseTypeInvalidMessageRecv | 95 |
| RESP_STATUS_URI_TOO_BIG | 414 | q850CauseTypeInvalidMessageRecv | 95 |
| RESP_STATUS_MEDIA | 415 | q850CauseTypeMediaNegFailure | 65 |
| RESP_STATUS_BAD_EXT | 420 | q850CauseTypeInvalidMessageRecv | 95 |
| RESP_STATUS_TMP_UNAVAIL | 480 | q850CauseTypeNouserAnswer | 19 |
| RESP_STATUS_NO_EXIST | 481 | q850CauseTypeInternalError | 47 |
| RESP_STATUS_LOOP | 482 | q850CauseTypeInternalError | 47 |
| RESP_STATUS_TOOMNY_HOPS | 483 | q850CauseTypeExchangeRoutingError | 25 |
| RESP_STATUS_ADDR_INCMPL | 484 | q850CauseTypeInvalidNumberFormat | 28 |
| RESP_STATUS_AMBIGUOUS | 485 | q850CauseTypeInternalError | 47 |
| RESP_STATUS_BUSY_HERE | 486 | q850CauseTypeUserBusy | 17 |
| RESP_STATUS_CANCELLED | 487 | q850CauseTypeInternalError | 47 |
| RESP_STATUS_NOT_HERE | 488 | q850CauseTypeMediaNegFailure | 65 |
| RESP_STATUS_INT_ERR | 500 | q850CauseTypeInternalError | 47 |
| RESP_STATUS_NOT_IMPL | 501 | q850CauseTypeFacilityRejected | 29 |
| RESP_STATUS_BAD_GTWY | 502 | q850CauseTypeDestOutofOrder | 27 |
| RESP_STATUS_SVC_UNAVAIL | 503 | q850CauseTypeInternalError | 47 |
| RESP_STATUS_GTWY_TMO | 504 | q850CauseTypeTimeout | 102 |
| RESP_STATUS_BAD_VER | 505 | q850CauseTypeInvalidMessageRecv | 95 |
| RESP_STATUS_BUSY | 600 | q850CauseTypeUserBusy | 17 |
| RESP_STATUS_DECLINE | 603 | q850CauseTypeCallRejected | 21 |
| RESP_STATUS_DONT_EXIST | 604 | q850CauseTypeDestUnreachable | 3 |
| RESP_STATUS_NOTACCEPT | 606 | q850CauseTypeInternalError | 47 |
Changing Default Reason Text
You configure the Q850 cause code using the entries configuration in the local-response-map table for SIP Error Codes. You configure Q850 cause codes corresponding to each local error one at a time. The example configuration below sets the Q850 cause code and reason text corresponding to the locally generated SIP error 488.
ORACLE# sh running-config local-response-map
local-response-map
entries
local-error not-acceptable-here-488
sip-status 488
q850-cause 65
sip-reason
q850-reason Not Acceptable HereAssume the SBC generates a 488. Using the entries configuration above, to specify the Q850 cause code. The SBC would construct the SIP Reason Header using the q850-cause and q850-reason.
The resulting message would be:
Reason: Q.850;cause=65;text="Not Acceptable Here"Similarly, for 5xx, 6xx as per the Q850 cause code and reason text configured in local-response-map, SBC constructs the reason header using these values.
ORACLE# sh running-config local-response-map
local-response-map
entries
local-error sip-locally-generated-bye
sip-status
q850-cause 16
sip-reason
q850-reason Bye Call TerminatedThe resulting message would be:
Reason: Q.850;cause=16;text="Bye Call Terminated"If you do not configure the message, the default resulting message would be:
Reason: Q.850;cause=16;text="Call Terminated"Per Realm Accounting Control
You can enable or disable accounting control for specific ingress realms using the accounting-enable parameter. This parameter is enabled by default.
The SBC’s SIP and H.323 tasks check whether this parameter is set to enabled or disabled, and sends records on that basis.
Note:
This realm configuration does not trigger accounting of MESSAGE and REGISTER traffic.Egress Realm Accounting Option
You can also set the force-realm-accounting option in the sip-config to ensure the SBC performs accounting based on this configuration on the egress realm.
For session accounting, the SBC checks the realm accounting configuration on both the ingress and egress realms. If the accounting configuration is enabled on either realm, and you have enabled the sip-config option, the SBC performs accounting for that session. If you have not enabled the sip-config option, the SBC only performs accounting for calls at the ingress realms that have accounting enabled.
This option also causes the SBC to perform accounting for REGISTER and MESSAGE requests. For this purpose, the SBC first checks whether you have configured the sip-config option. If set, the SBC checks the realm accounting configuration on the ingress and egress realms. If you have configured realm accounting configuration on either realm, the SBC performs accounting on these messages.
The syntax for this option follows.
ORACLE(sip-config)# options + force-realm-accountingBoth the force-realm-accounting option and the accounting-enable parameter are RTC supported.
RADIUS CDR Content Control
CDRs can be cusomized to limit their size as generated. The SBC’s RADIUS accounting provides a detailed set of records that can contain, for example, multiple media flow descriptions for forked calls that can contain multiple sets of media and QoS attributes. While the level of detail might be required for some networks, in others the large CDRs generated to reflect that level of granularity can cause issues for the application receiving the records.
You can control the size of the RADIUS CDRs your SBC produces:
- Duplicate RADIUS attribute prevention—Using this feature, you can configure the SBC to send only one set of RADIUS attributes in CDR for a forked call. (When a forked SIP INVITE contains media information, media and QoS attributes can potentially be duplicated.)
- RADIUS attribute selection—You can set a list of the Oracle VSAs you want
included in a RADIUS CDR, and the SBC will exclude the others from
the record; standard attributes are always included. You specify attributes using their
unique identifier in a comma-delimited list, and you can list them in any order.
However, entering an invalid range disables this feature.
The SBC excludes attributes from the records in which they are already defined. If an attributes only appears in a Stop record, then it will be deleted from Stop records.
Configuring Specific RADIUS Attributes for CDR Inclusion
You enter the list of VSAs that you want included as a comma-delimited list. There are special entry types you can use in the comma-delimited list to set ranges and make entries easier:
- X- — Where X is a VSA identifier, the SBC will include all attributes with an identifier equal to or greater than X.
- -X — Where X is a VSA identifier, the SBC will include all attributes with an identifier equal to or less than X.
- - — Use the minus sign (-) alone when you want to turn off attribute selection, including all VSAs in the CDR.
To enter a list of RADIUS attributes to include in a CDR:
Custom RADIUS CDR VSAs for SIP
This section describes these additions to the SBC’s RADIUS accounting capabilities for customizing your call detail records (CDRs):
- Generating CDRs with call detail information from a SIP message—The SBC 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 SBC to provide terminating trunk-group and trunk-context data even when the SBC 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 SBC 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 SBC 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 SBC 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 SBC ignores the visual separators when comparing it against a match value. Furthermore, the SBC 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 manipulation-string parameter for a realm, SIP session agent, or SIP interface. Then, you reference it as the $MANIP_STRING variable.
When a message arrives, the SBC 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 SBC populates messages matching a session agent using the $MANIP_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.
Configure 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 SBC 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 SBC 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 SBC 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 SBC 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 SBC 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.