Cisco Unified Border Element (SP Edition) Configuration Guide: Unified Model

Integrated Billing Systems

Integrated billing is achieved through the PacketCable Event Messages architecture (Figure 36-1 shows the PacketCable 1.5 Event Messages Specification; PKT-SP-EM1.5-I01-050128) where the Cisco Unified Border Element (SP Edition) is integrated into this architecture. As shown, the billing server and softswitch both support PacketCable Event Messages.

ISP-A in Figure 36-1 shows Cisco Unified Border Element (SP Edition) operating in a unified model where the billing system is being deployed as a distributed billing system consisting of three billing servers. Cisco Unified Border Element (SP Edition) can be configured to send to these servers in a range of ways, such as to all three simultaneously, or to use one primary and two backups.

In the unified model, the system operates as follows:

• Cisco Unified Border Element (SP Edition) produces event messages (EMs). These event messages are for billable or other interesting events, such as call start, call end, and media-type changes.
• Cisco Unified Border Element (SP Edition) and other elements of the system, which produces EMs, sends them in real time (or batched up for network efficiency) using the RADIUS protocol to the billing server.
• Billing server collates EMs into call detail records (CDRs). For an example of a CDR, see “Example for Event Messages from Cisco Unified Border Element (SP Edition) to RADIUS Billing Server” section.
• Cisco Unified Border Element (SP Edition) supports local caching of records and event messages in the Cisco ASR 1000 Series Router’s local disk in the event that none of the RADIUS servers are reachable.
• Cisco Unified Border Element (SP Edition) supports multiple RADIUS servers, for example, you can define multiple servers under a single client.

Note that ISP-B in Figure 36-1 shows Cisco Unified Border Element (SP Edition) operating in a distributed model where the billing system is being deployed using a single billing server and a softswitch.

Table 36-1 shows the packet billing termination codes that are supported by Cisco Unified Border Element (SP Edition).

Note The PacketCable 1.5 Event Messages Specification discusses sending the identifying information (the BCID and FEID) on the outgoing INVITE and responding SDP so that correlation can be done between the two sets of billing data. Cisco Unified Border Element (SP Edition) does not support this mechanism for intra-domain or inter-domain transmission. The billing server must perform the correlation using an alternative method (for example, using the telephone numbers dialed and the time of the call).

Granular Timestamp Support

Cisco Unified Border Element (SP Edition) Billing Manager maintains a granular timestamp that billing methods can use to query the current time. The granular timestamp provides a precision of 100 milliseconds. This precision is sufficient for all billing requirements without having an impact on performance.

By default, the granular timestamp is set to the maximum of 100 milliseconds.

Restrictions for PacketCable Billing

H.323 is supported for PacketCable billing, but with some limitations. One such limitation is that

no H.323 signalling address is present in PacketCable billing.

Performing ISSU for Endpoint Information

When performing ISSU to upgrade SBC from Release 2.6.1 to Release 2.6.2, if adjacency information (cdr adj-info) is provisioned for Release 2.6.1, then the corresponding endpoint-info adjacency (cdr endpoint-info adjacency) option is provisioned and the functionality is maintained.

When performing ISSU to downgrade SBC from Release 2.6.2 to Release 2.6.1, if endpoint adjacency information (cdr endpoint-info adjacency) is provisioned for Release 2.6.2, then the corresponding adjacency (cdr adj-info) option is provisioned and the functionality is maintained. If endpoint addressing information (cdr endpoint-info addressing) is provisioned for Release 2.6.2, no provisioning happens in Release 2.6.1.

Restrictions for Support for Media Information

The restriction for Support for Media Information are the following:

If an endpoint is behind a NAT, then the endpoint IP address cannot be obtained from the Session Description Protocol (SDP). It is instead auto detected after the endpoint sends media packets. This means that the remote address and port may not be known at the point that the gate is committed. Therefore, this information is not available on the Media_Session_Desc attribute that is sent on the QoS_Commit PacketCable message. Instead, a zero address is specified.

In particular, in a normal call setup and teardown when an endpoint is behind a NAT, there is no remote address or port in the Media_Session_Desc sent on the QoS_Commit message. The correct remote address and port is in the Media_Session_Desc sent in the QoS_Release message.

The only case in which Cisco Unified Border Element (SP Edition) would never report a remote address and port is when the call ends before any media packets have been sent and therefore the remote address is never learned by the media forwarding component on the network processing unit.

Figure 36-1 shows the PacketCable 1.5 Event Messages Specification (PKT-SP-EM1.5-I01-050128).

Figure 36-1 Integrated Billing Deployment

Restrictions for Billing

The restrictions for configuring billing are:

• You may not modify any billing configuration items if billing is active.
• You may only modify batch-time and batch-size when a method or the billing is active. All other commands are not allowed. However, those are blocked when more than one method exists.
• You may not modify ldr-check at billing level if any methods have been defined.
• You may not remove a RADIUS accounting client if it is currently assigned to a billing method.
• You must define a RADIUS accounting client before it is selected in a billing method.
• You can assign a RADIUS accounting client only to a single billing method.
• You cannot remove the billing when it is active or when methods are configured.
• You may not remove the method packetcable command while a packetcable-em configuration is in place.
• H.323 is supported for billing, but with some limitations. One such limitation is that no H.323 signalling address is present in billing instances.

Configuring Billing

This task defines how to configure billing configurations.

SUMMARY STEPS

1. configure

2. sbc service-name

3. sbe

4. control address aaa ipv4 IP_address

5. radius accounting client-name

6. concurrent-requests num

7. retry-interval num

8. retry-limit num

9. server server-name

10. address ipv4 A.B.C.D.

11. priority pri

12. key key

13. port port-num

14. exit

15. activate

16. exit

17. billing

18. cdr endpoint-info addressing

19. ldr-check { HH MM }

20. local-address ipv4 { A.B.C.D. }

21. method packetcable-em

22. cache [ path {WORD} | alarm [critical VAL] [major VAL] [minor VAL] | max-size {0-4194303}]

23. packetcable-em method-index transport radius RADIUS-client-name

24. batch-size number

25. batch-time number

26. attach

27. exit

28. activate

DETAILED STEPS

1. Make a directory on the disk to store billing records. For example: mkdir harddisk:billcache

2. Configure the cache path to point to this directory. For example, the following command configures the cache path to point to the directory billcache:

cache path harddisk:/billcache/

Note The trailing forward slash / is mandatory in the cache path configuration.

Overview of XML-Based Billing

The XML-based billing method is used to generate a set of XML records, each of which gives a complete description of a call. For each call, there is an XML record. In the XM billing method, the billing events are generated and stored in the Billing Manager. Only after the call is complete, the Billing Manager writes the complete CDR on the disk. The XML billing method stores the billing records using the local file daemon. The XML billing records are stored locally in the path configured using the command-line interface (CLI).

When a call begins, the SBC starts recording the billable events pertaining to that call. After the call is completed, the SBC stops recording, and collates the events into a single CDR. The format of the CDR is a proprietary XML format, which can be analyzed and post-processed with standard XML parser tools. The CDR is appended to a local file. Critical, major, and minor alarms for notifying administrator for increase in file-size upon exceeding the configured threshold value is configured using the cdr alarm command. This enables the administrator to free up disk space before the disk gets full and the old billing information gets overwritten by the new billing information.

For more information on XML billing schema, see Appendix 1, —$paratext>— .

Restrictions for XML-Based Billing

Following are restrictions for XML-based Billing:

• A maximum of only one XML billing instance can be configured.
• Each billing method configuration (under billing) consumes memory. A billing method should not be configured, unless at least one instance of the corresponding method is also configured.
• The no method xml command fails if an instance of the corresponding method is configured.
• Compression of the billing records is not supported.
• H.323 is supported for XML billing, but with some limitations. One such limitation is that no H.323 signalling address is present in XML billing instances.

Configuring XML-Based Billing

The following section provides configuration details for the XML billing method, the local path to store the CDR records, threshold values, and for configuring other parameters:

SUMMARY STEPS

1. configure terminal

2. sbc sbcname

3. sbe

4. billing

5. method xml

6. xml xmlinstance

7. cdr path path

8. ldr-check hour:min

9. cdr alarm minor 2000 major 1000 critical 500

10. flipped-interval 240

11. flipped-size 20480

12. deact-mode quiesce

13. attach

14. exit

15. activate

DETAILED STEPS

Retrieving the XML Billing Records

Because the CDR billing records are stored locally on the Cisco ASR 1000 Series Router, it is recommended that the XML billing records are copied to another system regularly. The SBC stores the XML file under the CDR path configured using the CLI. The XML file is flipped after exceeding the fixed size or interval configured. The default file size is 10 MB, and, the default interval is 3 minutes. Copying the billing records from the local disk to remote machine everyday and removing the old billing records from the local disk is therefore recommended. For security reasons, the file should be copied using a secure transport method such as SCP or HTTPS.

Managing Disk Space Through Alarms

The XML billing CDR records are stored on the disk by the file daemon. If there are too many calls in the system can quickly fill a disk. It is therefore important to put an automated management system in place to ensure that sufficient disk space is permanently available. An automated system uses file transfer protocol (FTP) to regularly copy the CDR files to an appropriate server, and deletes the files from the local disk.

If free disk space is lower than what is configured, the SBC generates an alarm, requesting the administrator to free up the disk space by removing the CDRs. The SBC continues to accept calls until more disk space is available. To prevent unbilling of active calls due to lack of disk space, it is recommended that minor, major, and critical alarms to be configured regularly notify the administrator to free up disk space when the free disk space threshold size is exceeded.

Managing the Billing Records During RP Failover

It is important to consider various scenarios that might need attention to retain the billing records. One such scenario is managing the billing records during route processor (RP) failover from active to standby. The SBC billing architecture is designed such that billing records are not lost in case of failover to standby RP. The architecture makes certain assumptions on the infrastructure, and those assumptions should be implemented and verified.

The Billing Manager generates transient billing control block, with billing data. The primary SBC replicates these blocks to the standby SBC. In case of a failover, the call state and billing state are available on the standby, and are designed to continue the call and bill it.

In XMl-based billing, before the failover, the Billing Manager stores the XML billing records in the local disk (via the file daemon interface). When failover occurs, the file daemon flushes the billing records in cache buffer into hard disk. The file daemon writes the records in the local disk belonging to the new active RP.

Note The CDR path for storing the XML billing records must be defined earlier on the new, active RP. If the CDR path is not defined, the billing records will not be written to the hard disk. If the CDR path is not defined, create it by executing the cdr path path command from the config-sbc-sbe-billing-xml command mode.

The old billing records that are present on the new standby RP can be copied to a remote machine using the copy stby-harddisk: <destination path> command.

MD5 Checksum Support for XML Billing Records File

The XML billing records that are stored locally are copied to a remote machine. To ensure that the billing records copied to the destination remote machine are the same as the one existing locally, MD5 checksum support has been implemented on the XML billing records file. A checksum is a form of mechanism that ensures that the file is downloaded properly. The MD5 checksum support is used to provide the XML billing record file integrity check, when the XML billing record is copied from a local storage to a remote server.

When an old XML billing record file is closed, SBC computes and generates the MD5 checksum for the old XML billing record file. The checksum value is stored in the MD5 checksum log file. If size of the log file is more than 2 MB, the MD5 value is switched to another log file to write. There are two log files, md5checksum1.log and md5checksum2.log. The log files are located under the CDR path configured under the SBC SBE billing XML instance.

Selective RADIUS Billing

The billing methods supported by the SBC are:

• XML billing—Billing records are written in a proprietary XML format to disk.
• PacketCable billing—RADIUS messages are sent to RADIUS servers.

Prior to Cisco IOS XE Release 3.3S, all calls have the billing records generated for all the active billing methods. However, the customer that has a RADIUS server of limited capacity cannot generate billing records for calls for a subset of all adjacencies. From Cisco IOS XE Release 3.3S, the Selective RADIUS Billing feature provides the function to select billing methods for calls relating to different adjacencies.

The billing method or methods used for calls can be selected at a per-adjacency scope and the user can also choose to not use the billing method for a specific adjacency.

Configuring Selective RADIUS Billing

This task configures the Selective RADIUS Billing feature.

SUMMARY STEPS

1. configure terminal

2. sbc sbc-name

3. sbe

4. cac-policy-set policy-set-id

5. cac-table table-name

6. table-type policy-set

7. entry entry-id

8. billing filter { enable | disable }

9. billing methods { xml | packetcable-em }

10. end

11. show sbc sbc-name sbe cac-policy-set id table name entry id

DETAILED STEPS

The following example displays the partial output of the show sbc sbe cac-policy-set table entry command that lists the billing filter information:

Configuration Example of Selective RADIUS Billing

The following example configures all calls billed using XML billing, all calls on an adjacency in the IMS-adjacencies group are configured to be billed using XML and PacketCable-em billing, however, all calls on a special-adj adjacency are configured for not being billed at all.