Cisco Unified Border Element (SP Edition) Configuration Guide: Unified Model
Implementing Billing
Downloads: This chapterpdf (PDF - 266.0KB) The complete bookPDF (PDF - 9.9MB) | Feedback

Table of Contents

Implementing Billing on Cisco Unified Border Element (SP Edition)

Contents

Prerequisites for Implementing Billing

Information About Implementing Billing

Integrated Billing Systems

Granular Timestamp Support

Endpoint Information in PacketCable Billing

Restrictions for PacketCable Billing

Performing ISSU for Endpoint Information

Support for Local Cache

Support for Media Information

Restrictions for Support for Media Information

How to Implement Billing

Restrictions for Billing

Configuring Billing

Configuration Examples of Implementing Billing

Support Billing for IP Format

Overview of XML-Based Billing

Restrictions for XML-Based Billing

Configuring XML-Based Billing

Retrieving the XML Billing Records

Managing Disk Space Through Alarms

Managing the Billing Records During RP Failover

MD5 Checksum Support for XML Billing Records File

Selective RADIUS Billing

Configuring Selective RADIUS Billing

Configuration Example of Selective RADIUS Billing

Implementing Billing on Cisco Unified Border Element (SP Edition)

The Cisco Unified Border Element (SP Edition) billing component includes the following core features:

  • Compatibility with existing billing systems—To be able to fit the Cisco Unified Border Element (SP Edition) billing system easily into an existing billing architecture of a provider is an important functional requirement. This requirement entails the use of mechanisms to obtain billing information in a similar fashion to those of the existing mechanisms.
  • Integration with next-generation technologies and solutions—Equally important is the requirement to use next-generation billing technologies, so that service information from Cisco Unified Border Element (SP Edition), softswitches, voicemail, and unified messaging applications, and so on can be collated and billed in a distributed environment.
  • High availability and fault tolerance.
  • Flexible architecture.

The billing component functions as a third-party integrated, distributed Remote Authentication Dial-In User Service (RADIUS)-based call and event logging.

The function of the billing component is:

  • Third-party integrated, distributed Remote Authentication Dial-In User Service (RADIUS)-based call and event logging.

NoteThis feature is supported in the unified model for Cisco IOS XR Software Release 2.4 and later. This feature is supported in the unified model for Cisco IOS XR Software Release 2.4 and later.


Cisco Unified Border Element (SP Edition) was formerly known as Integrated Session Border Controller and may be commonly referred to in this document as the session border controller (SBC).

For a complete description of commands used in this chapter, see Cisco Unified Border Element (SP Edition) Command Reference: Unified Model at http://www.cisco.com/en/US/docs/ios/sbc/command/reference/sbcu_book.html .

For information about all Cisco IOS commands, use the Command Lookup Tool at http://tools.cisco.com/Support/CLILookup or a Cisco IOS master commands list.

Feature History for Implementing Cisco Unified Border Element (SP Edition) Billing

 

Release
Modification

Cisco IOS XE Release 2.4

This feature was introduced on the Cisco IOS XR along with support for the unified model.

Cisco IOS XE Release 2.5

Support for Media Information and Granular Timestamp Support were added on the Cisco ASR 1000 Series Router.

Cisco IOS XE Release 2.6.1

Support for Adjacency Information was added on the Cisco ASR 1000 Series Router.

Cisco IOS XE Release 2.6.2

Support for Endpoint Information was added on the Cisco ASR 1000 Series Router.

Cisco IOS XE Release 3.2.0S

Support for XML based billing method was introduced on the Cisco ASR 1000 Series Router.

Cisco IOS XE Release 3.3S

The Selective RADIUS Billing feature was added on the Cisco ASR 1000 Series Router.

Prerequisites for Implementing Billing

The following prerequisites are required to implement Cisco Unified Border Element (SP Edition) billing:

  • Before implementing interworking billing, Cisco Unified Border Element (SP Edition) must already be configured.
  • To implement billing on the signaling border element (SBE) you must obtain a unique network element ID for the SBE from your network administrator. In addition, you must perform the following task depending on what form of billing you require.

To implement integrated RADIUS-based call logging, you must first configure the RADIUS server and set up the RADIUS network infrastructure.

Information About Implementing Billing

It is critical to understand all Cisco Unified Border Element (SP Edition) billing features and capabilities before performing billing configurations for the Cisco Unified Border Element (SP Edition). The following sections describe Cisco Unified Border Element (SP Edition) billing topologies:

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).

 

Table 36-1 Supported Packet Billing Termination Codes

Code Value
Description

0003

No route to destination

0016

Normal call clearing

0017

User busy

0019

User alerting: No answer

0020

Subscriber absent

0027

Destination out of order

0028

Invalid number format (incomplete address)

0031

Unknown: Call ended during recovery processing

0041

Temporary failure

0042

Switching equipment congestion

0047

Resource unavailable, unspecified

0063

Service or option not available, unspecified

0065

Bearer capability not implemented

0095

Invalid message, unspecified

0097

Message type nonexistent or not implemented

0099

Information element nonexistent or not implemented

0103

Parameter non-existent or not implemented, passed on

0111

Protocol error: Unspecified

0127

Interworking: Unspecified


NoteThe 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). 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.

Endpoint Information in PacketCable Billing

Beginning Cisco Unified Border Element (SP Edition) Release 2.6.2, you can configure SBC to include information—adjacency name or addressing—on endpoints in use for a given call in the PacketCable billing records.

When SBC is not configured to include the endpoint information in the messages, the Signaling_Start messages for both sides of a call contains an MTA_Endpoint_Name attribute that contains the string MTA Endpoint. MTA_Endpoint_Name attribute is not included in Call Answer or Signaling_Stop Event Messages.

If you configure SBC to include the adjacency name, only the names of the endpoint adjacencies are included in the billing records. For example, SIPPB . If you have configured SBC to include the endpoint addressing information, then IP address, port, and transport type are also included in the billing records along with the adjacency name in the following format: IP address , port , transport type , adjacency name . For example, 2.0.0.36,5078,UDP,SIPPB .

If SBC is configured to include the endpoint information:

  • SBC adds the source adjacency name or addressing information, as configured, to the upstream Signaling_Start Event Messages. This information is included in the MTA_Endpoint_Name attribute—replacing the hard-coded string MTA Endpoint. At this point, the downstream Signaling_Start message contains only the hard-coded string—MTA Endpoint.
  • SBC adds the destination adjacency name or addressing information, as configured, to downstream Call_Answer Event Messages. This information is included in the MTA_Endpoint_Name attribute. The upstream Call_Answer message does not contain an MTA_Endpoint_Name attribute.
  • SBC includes both—source and destination—endpoint details in the Signaling_Stop messages; the source adjacency name or addressing information in the upstream message, and the destination adjacency name or addressing information in the downstream message. This ensures that even if a call fails to connect, the billing server still has access to both endpoint details.

Use the [no] cdr endpoint-info {addressing | adjacency} command to configure SBC to include the endpoint information in PacketCable billing.

Use the show sbc sbcname sbe billing instance command to verify whether the SBC is configured to include the endpoint information.

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.

Support for Local Cache

The Cisco ASR 1000 Series Routers have a local disk where records and event messages (EMs)can be stored on a local cache. Local cache support is a significant advantage because call detail records and EMs are not lost when a billing server is unavailable. Use the cache command to configure parameters for storing call detail records and EMs on local disk.

In a typical integrated billing environment, as calls come up and go down, billing records are generated and sent to the RADIUS server. When for any reason the RADIUS server is not reachable or not responding to accounting packets, then the Billing Manager marks the transport as DOWN. As soon as the transport goes down and the local caching path is defined with the cache path command, the billing records are cached locally on the Cisco ASR 1000 Series Router disk. Your router disk may be the hard disk, bootflash or usb0, depending on router configuration. Subsequently, every 10 seconds, the Cisco ASR 1000 Series Router tries to send the cached information to the RADIUS server.

Support for Media Information

Cisco Unified Border Element (SP Edition) supports reporting media information in billing messages. The PacketCable event message (EM) billing interface reports the properties of the media streams associated with a call, including when the media stream begins and ends, the packets and octets transmitted, and lost latency and jitter statistics.

The Support for Media Information feature defines a new proprietary RADIUS Vendor-Specific Attribute that can be carried on the QoS_Commit and QoS_Release PacketCable messages. This attribute added to these billing messages makes stream creation information available to PacketCable billing.

Use the cdr media-info command to add the RADIUS Vendor-Specific Attribute to the billing messages.

The RADIUS Vendor-Specific Attribute contains the following information:

  • Local IP address and port and remote media endpoint IP address and port used in the media stream.
  • Direction of the media stream (send-only, receive-only, send-and-receive, or inactive).
  • Codecs negotiated for that media stream.
  • Bandwidth reserved for the media stream.

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

 

How to Implement Billing

The SBE can perform billing. The key objects to be configured for billing are the long duration checks and the physical location of the cache. You can configure up to eight PacketCable-EM billing instances (indexed 0-7).

Follow the procedure in the “Configuring Billing” section.

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

 

Command or Action
Purpose

Step 1

configure

 

Router# configure

Enables global configuration mode.

Step 2

sbc service-name

 

Router(config)# sbc mysbc

Enters the mode of an SBC service.

Use the service-name argument to define the name of the service.

Step 3

sbe

 

Router(config-sbc)# sbe

Enters the mode of an SBE entity within an SBC service.

Step 4

control address aaa ipv4 IP_address

 

Router(config-sbc-sbe)# control address aaa ipv4 192.168.113.2

Configures an SBE to use a given IPv4 AAA control address when contacting an authentication or billing server. This address is a unique address within the signaling address.

Step 5

radius accounting client-name

 

Router(config-sbc-sbe)# radius accounting set1

Enters the mode for configuring a RADIUS client for accounting purposes.

Step 6

concurrent-requests 0-4000

 

Router(config-sbc-sbe-acc)# concurrent-requests 34

Sets the maximum number of concurrent requests to the RADIUS server. The default value is 250 and the valid range is between 1 and 4000.

Step 7

retry-interval range

 

Router(config-sbc-sbe-acc)# retry-interval 2000

Sets the interval for resending an accounting request to the RADIUS server. The default value is 1200 ms and the valid range is between 10 and 10,000 ms.

Step 8

retry-limit range

 

Router(config-sbc-sbe-acc)# retry-limit 4

Sets the retry interval to the RADIUS server. The default value is 5 and the valid range is between 0 and 9.

Step 9

server server-name

 

Router(config-sbc-sbe-acc)# server Cisco-AR1-PC

Enters the mode for configuring an accounting server within this client.

Step 10

address ipv4 A.B.C.D

 

Router(config-sbc-sbe-acc-ser)# address ipv4 200.200.200.153

Configures the address of an accounting server.

Step 11

priority pri

 

Router(config-sbc-sbe-acc-ser)# priority 2

Configures the priority of the accounting server. The pri argument must be in the range of 1 to 10 (highest to lowest).

Step 12

key key

 

Router(config-sbc-sbe-acc-ser)# key cisco

Configures the RADIUS authentication key or shared secret to be used for this accounting server.

Step 13

port port-number

 

Router(config-sbc-sbe-acc-ser)# port 2009

Configures the port that the RADIUS server will use to receive Access-Request or Accounting-Request packets. The default port is 1813.

Step 14

exit

 

Router(config-sbc-sbe-acc-ser)# exit

Exits the current RADIUS server mode.

Note Repeat Steps 9 to 14 to create multiple RADIUS accounting servers. Only one server is primary; the rest are backup. You would repeat the following commands:

  • server server-name
  • address ipv4 A.B.C.D.
  • priority pri
  • key key
  • port port-num
  • exit

Step 15

activate

 

Router/Admin(config-sbc-sbe-acc)# activate

Activates the RADIUS server.

Step 16

exit

 

Router/Admin(config-sbc-sbe-acc)# exit

Exits the current RADIUS accounting mode.

Note Repeat steps 5 to 16 to create multiple RADIUS accounting clients. You would repeat the following commands:

  • radius accounting client-name
  • concurrent-requests num
  • retry-interval num
  • retry-limit num
  • server server-name
  • address ipv4 A.B.C.D.
  • priority pri
  • key key
  • port port-num
  • exit
  • activate
  • exit

Step 17

billing

 

Router(config-sbc-sbe)# billing

Configures billing policies.

Step 18

cdr endpoint-info addressing

 

Router(config-sbc-sbe-billing)# cdr endpoint-info addressing

Configures billing to include endpoint addressing information.

Step 19

ldr-check {HH MM}

 

Router(config-sbc-sbe-billing)# ldr-check 22 30

Configures the time of day (local time) to run the Long Duration Check (LDR).

Step 20

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

 

Router(config-sbc-sbe-billing)# local-address ipv4 10.20.1.1

Configures the local IPv4 address that appears in the CDR.

Step 21

method packetcable-em

 

Router(config-sbc-sbe-billing)# method packetcable-em

Enables the packet-cable billing method.

Step 22

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

 

Router(config-sbc-sbe-billing)# cache path harddisk:

Configures call detail record caching parameters, including alarm levels, maximum cache size, and cache path location.

Note See Tip after the table for configuring the cache path to a hard disk.

Step 23

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

 

Router(config-sbc-sbe-billing)# packetcable-em 4 transport radius set1

Configures a packet-cable billing instance.

RADIUS-client-name should match the client-name configured with the radius accounting client-name command.

Step 24

batch-size number

 

Router(config-sbc-sbe-billing-packetcable-em)# batch-size 256

Configures the maximum size of a batch when the batch must be set immediately.

Step 25

batch-time number

 

Router(config-sbc-sbe-billing-packetcable-em)# batch-time 22

Configures the maximum number of milliseconds for which any record is held before the batch is sent.

Step 26

attach

 

Router(config-sbc-sbe-billing-packetcable-em)# attach

Activates the billing for a RADIUS client.

Step 27

exit

 

Router(config-sbc-sbe-billing-packetcable-em)# exit

Exits the current mode .

Note Repeat steps 22 to 25 to create multiple billing method instances. You would repeat the following commands:

  • packetcable-em method-index transport radius RADIUS-client-name
  • batch-size number
  • batch-time number
  • attach

Step 28

activate

 

Router(config-sbc-sbe-billing)# activate

Activates the Billing Manager.


Tip If you choose to set the cache path to hard disk, the cache files are created in the root directory. To prevent cluttering up your root directory, we recommend the following 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.


Configuration Examples of Implementing Billing

The following example configures billing and enables caching of call detail records and event messages on the designated hard disk:

Router# configure terminal
Router(config)# sbc mysbc
Router(config-sbc)# sbe
Router(config-sbc-sbe)# control address aaa ipv4 10.10.10.1 vrf default
Router(config-sbc-sbe)# radius accounting mars
Router(config-sbc-sbe-acc)# concurrent-requests 300
Router(config-sbc-sbe-acc)# retry-interval 1000
Router(config-sbc-sbe-acc)# retry-limit 6
Router(config-sbc-sbe-acc)# server moon
Router(config-sbc-sbe-acc-ser)# address ipv4 10.20.1.1
Router(config-sbc-sbe-acc-ser)# priority 4
Router(config-sbc-sbe-acc-ser)# key test
Router(config-sbc-sbe-acc-ser)# port 1820
Router(config-sbc-sbe-acc-ser)# exit
Router(config-sbc-sbe-acc)# activate
Router(config-sbc-sbe-acc)# exit
Router(config-sbc-sbe)# billing
Router(config-sbc-sbe-billing)# ldr-check 22 30
Router(config-sbc-sbe-billing)# local-address ipv4 10.20.1.1
Router(config-sbc-sbe-billing)# method packetcable-em
Router(config-sbc-sbe-billing)# cache path harddisk:
Router(config-sbc-sbe-billing)# packetcable-em 3 transport radius test
Router(config-sbc-sbe-billing-packetcable-em)# batch-size 256
Router(config-sbc-sbe-billing-packetcable-em)# batch-time 22
Router(config-sbc-sbe-billing-packetcable-em)# attach
Router(config-sbc-sbe-billing-packetcable-em)# exit
Router(config-sbc-sbe-billing)# activate
 
 

The following configuration example shows that cache is enabled on the hard disk:

sbc asr
sbe
! - Local radius IP address
control address aaa ipv4 10.1.1.1
 
! - First radius accounting client group
radius accounting ACCT-CLIENT-GROUP-1
! - First radius server
server ACCT-SERVER-1
address ipv4 20.1.1.1
key cisco
activate
 
! - Billing Manager.
billing
local-address ipv4 10.1.1.1
method packetcable-em
cache path harddisk:
! - First billing method.
packetcable-em 0 transport radius ACCT-CLIENT-GROUP-1
local-address ipv4 10.1.1.1
attach
activate

 

The following configuration example shows that four RADIUS servers have been configured in pairs; the second RADIUS server is backing up server 1, the third RADIUS server is backing up server 4, and both pairs of servers are receiving copies of the same records:

sbc asr
sbe
! - Local radius IP address
control address aaa ipv4 10.1.1.1
 
! - First radius accounting client group
radius accounting ACCT-CLIENT-GROUP-1
! - First radius server
server ACCT-SERVER-1
address ipv4 20.1.1.1
key cisco
! - Backup for First radius server
server ACCT-SERVER-2
address ipv4 20.1.1.2
key cisco
activate
 
! - Second radius accounting client group
radius accounting ACCT-CLIENT-GROUP-2
! - Second radius server
server ACCT-SERVER-3
address ipv4 30.1.1.1
key cisco
! - Backup for Second radius server
server ACCT-SERVER-4
address ipv4 30.1.1.2
key cisco
activate
 
! - Billing Manager.
billing
local-address ipv4 10.1.1.1
method packetcable-em
cache path harddisk:
! - First billing method.
packetcable-em 0 transport radius ACCT-CLIENT-GROUP-1
local-address ipv4 10.1.1.1
attach
! - Second billing method for duplicate records.
packetcable-em 1 transport radius ACCT-CLIENT-GROUP-2
local-address ipv4 10.1.1.1
attach
activate
 
The following configuration example shows how to configure endpoint information to capture address information:
 
Router# configure terminal
Router(config)# sbc mySBC
Router(config-sbc)# sbe
Router(config-sbc-sbe)# billing
Router(config-sbc-sbe-billing)# cdr endpoint-info addressing
Router(config-sbc-sbe-billing)# end
Router#
 
The following show command output shows that the billing is configured to include the addressing information of the endpoint:
 
Router# show sbc mySBC sbe billing instance
 
Billing Manager Information:
Local IP address: 172.18.53.179
LDR check time: 0 :0
Method packetcable-em
Method packetcable-li
Admin Status: DOWN
Operation Status: DOWN
Cache path: usb0:billing_cache/
Cache max size: 0 Kilobytes
Cache minor-alarm: 97656 Kilobytes
Cache major-alarm: 488281 Kilobytes
Cache critical-alarm: 976562 Kilobytes
Retry-interval: 20 secs
CDR Media-Info: Not Included
CDR Endpoint-Info: Addressing
 
Billing Methods:
Radius client name: ssss
Instance: 0
Type: PACKET-CABLE
Transport Mechanism Status: DOWN
Active Calls Billed: 0
Local IP Address: 172.18.53.179
Deact-mode: abort
Admin Status: DOWN
Operation Status: DOWN
LDR check time: 0 :0
Batch size: 0
Batch time: 1000 ms

Support Billing for IP Format

Internet is no longer used to transmit only data; it is also used to transmit voice and video. Although the transmission of voice and video through Internet has simplified communication to a large extent, it is very important to understand how voice and video services are being managed and configured.

The PacketCable billing method that is being currently used by the SBC generates call detail record (CDR) in the Bellcore AMA Format (BAF). However, the BAF format is too telephony-specific, and does not contain sufficient provision to support IP-centric logging information. For example, the BAF format does not record session description protocol (SDP) or real-time transport control protocol (RTCP) statistics. Moreover, the PacketCable billing method is not extensible, because of which it is not possible to define extensions to contain these fields.

The XML-based billing method has been selected because it can process IP-centric logging information, It is flexible, and it is commonly used in situations where data must be translated between different platforms, for example, translating billing data from the SBC and the billing server.

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

 

Command or Action
Purpose

Step 1

configure terminal

 

Router# configure terminal

Enters the global configuration mode.

Step 2

sbc service-name

 

Router(config)# sbc mysbc

Enters the mode of an SBC service.

Use the service-name argument to define the name of the service.

Step 3

sbe

 

Router(config-sbc)# sbe

Enters the mode of an SBE entity within an SBC service.

Step 4

billing

 

Router(config-sbc-sbe)# billing

Configures billing policies.

Note There can be only one instance of Billing Manager per SBC. The Billing Manager must be configured to configure billing.

Step 5

method xml

 

Router(config-sbc-sbe-billing)# method xml

Enables the XML billing method.

Step 6

xml method-instance

 

Router(config-sbc-sbe-billing)# xml 1

Configures an XML billing instance. The range of valid values are 0 to 7.

Step 7

cdr path path

 

Router(config-sbc-sbe-billing-xml)# cdr path usb0:cdr

Configures the path to store the CDR billing records. The path must locally point to a directory located either on the flash disk or the hard drive on the Cisco ASR 1000 Series Router.

Step 8

ldr-check hour minutes

 

 

Router(config-sbc-sbe-billing-xml)# ldr-check 23 30

Configures the time for checking long duration records. This is the time when all calls over 24-hours-long are reported.

Step 9

cdr alarm minor 2000 major 1000 critical 500

 

Router(config-sbc-sbe-billing-xml)# cdr alarm minor 2000 major 1000 critical 500

Configures the alarms to be triggered when free disk space that is lower than the configured size is available.

Step 10

flipped-interval 240

 

Router(config-sbc-sbe-billing-xml)# flipped-interval 240

Configures the maximum interval (in seconds) to flip the billing XML file. The default value is 3 minutes.

Step 11

flipped-size 20480

 

Router(config-sbc-sbe-billing-xml)# flipped-size 20480

Configures the maximum size (in kilobytes) to flip the billing XML file. The default value is 10240 kilo bytes (KB).

Step 12

deact-mode quiesce

 

Router(config-sbc-sbe-billing-xml)# deact-mode quiesce

Configures the deactivate mode for the XML billing method.

Step 13

attach

 

Router(config-sbc-sbe-billing-xml)# attach

Activates the billing instance for XML.

Step 14

exit

 

Router(config-sbc-sbe-billing-xml)# exit

Exits the current mode.

Step 15

activate

 

Router(config-sbc-sbe-billing)# activate

Activates the Billing Manager.

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.


NoteThe 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 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

 

Command or Action
Purpose

Step 1

configure terminal

 

Router# configure terminal

Enables global configuration mode.

Step 2

sbc sbc-name

 
Router(config)# sbc mySBC

Creates the SBC service on the SBC, and enters the SBC configuration mode.

Step 3

sbe

 

Router(config-sbc)# sbe

Enters the signaling border element (SBE) function mode of the SBC.

Step 4

cac-policy-set policy-set-id

 

Router(config-sbc-sbe)# cac-policy-set 1

Enters the CAC policy set configuration mode within an SBE entity, creating a new policy set, if necessary:

  • policy-set-id—Integer chosen by a user to identify the policy set. The range is from 1 to 2147483647.

Step 5

cac-table table-name

 

Router(config-sbc-sbe-cacpolicy)# cac-table t1

Enters the CAC table mode for configuration of an admission control table (creating one, if necessary) within the context of an SBE policy set.

  • table-name—Name of the admission control table.

Step 6

table-type { policy-set | limit { list of limit tables }}

 

 

Router(config-sbc-sbe-cacpolicy-cactable)# table-type policy-set

Configures the table type of a CAC Policy table within the context of an SBE policy set.

Step 7

entry entry-id

 

Router(config-sbc-sbe-cacpolicy-cactable)# entry 1

Enters the CAC table entry mode to modify an entry in an admission control table.

  • entry-id—Specifies the table entry.

Step 8

billing filter { enable | disable }

 

Router(config-sbc-sbe-cacpolicy-cactable-entry)# billing filter enable

Specifies whether the billing filter scheme is enabled or disabled.

  • enable —Enables the billing filter.
  • disable —Disables the billing filter.

Step 9

billing methods { xml | packetcable-em }

 

Router(config-sbc-sbe-cacpolicy-cactable-entry)# billing methods xml

 

Specifies the billing methods that are allowed for calls relating to different adjacencies.

  • packetcable-em — Configures the PacketCable billing method for billing.
  • xml —Configures the XML billing method for billing.

Step 10

end

 

Router# end

Enables exit from the CAC table entry configuration mode and entry into the Privileged EXEC mode.

Step 11

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

 

Router# show sbc mySBC sbe cac-policy-set 1 table t1 entry 1

Lists the detailed information for a given entry in a CAC policy table.

 

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

Router# show sbc mySBC sbe cac-policy-set 1 table t1 entry 1
 
SBC Service "mySBC"
CAC Averaging period 1: 60 sec
CAC Averaging period 2: 0 sec
 
CAC Policy Set 1
Active policy set: No
Description:
First CAC table:
First CAC scope: global
 
Table name: t1
Description:
Table type: policy-set
Total call setup failures (due to non-media limits): 0
 
Entry 1
CAC scope:
CAC scope prefix length: 0
Action: Not set
Number of call setup failures (due to non-media limits): 0
……
media bandwidth policing: Degrade
Media policy limit: mp1
IPsec maximum registers: 10
IPsec maximum calls: 5
Billing filter : enable
Billing filter methods: xml

 

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.

cac-policy-set 1
first-cac-scope global
first-cac-table 1
table-type limit adj-group
cac-table 1
entry 1
action next-table 2
billing filter enable
billing methods xml
!
!
cac-table 2
entry 1
match-value ims-adjacencies
action next-table 3
billing filter enable
billing methods xml
billing methods packetcable-em
!
!
cac-table 3
entry 1
match-value special-adj
action cac-complete
billing filter enable
!
!
!