The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
The following sections describe billing and its many aspects. It is critical to understand all Cisco Unified Border Element (SP Edition) billing features and capabilities before performing billing configurations.
Integrated billing is achieved through the PacketCable Event Messages architecture (see the PacketCable 1.5 Event Messages Specification; PKT-SP-EM1.5-I01-050128) as exemplified in Figure 37-1 where Cisco Unified Border Element (SP Edition) is integrated into this architecture. As shown, the billing server supports PacketCable Event Messages.
Cisco Unified Border Element (SP Edition) on the Cisco ASR 1000 Series Routers supports remote billing in the unified mode. Remote billing is call billing that is integrated with a third-party accounting server.
Figure 37-1 shows Cisco Unified Border Element (SP Edition) operating in a unified model where the billing system is being deployed with 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.
Figure 37-1 Integrated Billing Deployment
The system operates as follows:
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).
The generated event messages, as described in the “Event Messages Set Overview” section are sent using the RADIUS protocol to a preconfigured set of billing servers. Before getting into the actual detail of the event messages, review the event message transmission considerations described in the following sections:
Billing servers are configured at start-up, in SETs:
Each event message is sent to the entire collection of sets, but to only one machine within each set.
Figure 37-2 shows the multiple server support.
Figure 37-2 Multiple Server Support
Because of the inefficiency of the RADIUS protocol, the SBE collates event messages into batches and sends them using a single RADIUS message to alleviate the burden on the transport mechanism.
Batching is possible only on a per-set basis. The batch size is not configurable, but is determined by the load on the billing component.
This section specifies the set of event messages supported by Cisco Unified Border Element (SP Edition):
The following table lists supported call event messages.
The following table lists event messages that are non-call-related, out-of-band event messages.
|
|
Sent when changes of more than 200 ms occur in the time; also sent for daylight savings changes, and so on. |
The following table lists the event messages that are not supported.
This section specifies the supported event messages and the attributes sent for each one.
This message is sent when signaling starts for a call; that is, when Cisco Unified Border Element (SP Edition) has ascertained that the destination is routable and the originating endpoint is allowed to make the call (that is, after the SLA has been checked).
The following table lists the attributes sent with this message.
The following table lists the attributes not sent with this message.
|
|
Ported-In billing not supported [transparent to Cisco Unified Border Element (SP Edition)]. |
|
This message is generated when the SBE has reserved bandwidth (QoS) on the network through the DBE.
If this reserved bandwidth changes, this message (along with the partner QoS_Commit message) is generated anew.
Note If the SBE is managing multiple gates, this message is generated only for the gates to and from each MTA endpoint (and not the internal gates). There are no optional attributes not sent on this message.
The following table lists the attributes sent with this message.
This message indicates the earliest point at which non-early two-way media is established.
The SBE sends the message to the billing servers when it is notified that the called party has gone off-hook; that is, that they have answered the call.
The following table lists the attributes sent with this message.
The following table lists the attributes not sent with this message.
This message is sent by the SBE when the gate bandwidth is committed. This message is only sent if a QoS_Reserve has been previously sent.
The following table lists the attributes sent with this message.
The following table lists the attributes not sent with this message.
|
|
Information is sent on the QoS_Reserve message and not duplicated on this message |
The following table lists the structure of the Total_Bandwidth attribute (attribute ID 253).
|
|
|
|
The total bandwidth in use by the streams described in this QoS_Commit message. |
The following table lists the structure of the Media_Session_Desc attribute (attribute ID 254).
This message is generated by the SBE when 2-way media flow terminates—when sending a 200 OK response to a BYE from either party.
Usually, this message immediately precedes QoS_Release and Signaling_Stop.
This message is only sent if a Call_Answer has previously been sent.
The following table lists the attributes sent with this message.
|
|
This message is generated by the SBE when the reserved bandwidth has been released; that is, the gate on the DBE has been closed.
The following table lists the attributes sent with this message.
This message is not sent if we have not sent a Signaling_Start for this call.
The following table lists the attributes sent with this message.
The following table lists the attributes not sent with this message.
|
|
The FEID of the terminating network element. Cisco Unified Border Element (SP Edition) does not transmit this between network elements. |
When a call is terminated on the DBE (that is, the gate is closed), statistics are returned to the SBE. On receipt of these statistics, this message is generated.
When media QoS is renegotiated, the gate is closed and re-opened. In this case, statistics are logged for the first gate when it closes, and for the second gate when it closes (at the end of the call).
There may be multiple gates for each Media. The statistics are aggregated and result in only one Media_Statistics message per billing leg.
The following table lists the attributes sent with this message.
|
|
This message is generated once a day, at a pre-configured time.
At the preconfigured time, the SBE audits the active calls, and determines which calls (if any) have been active for more than 24 hours. For each call satisfying this condition, a Media_Alive message is generated.
The following table lists the attributes sent with this message.
|
|
This message is generated by the SBE either on its own behalf, or on the behalf of the DBE, when either the DBE or SBE experiences a time change of more than 200 ms (discounting slew adjustments via Network Time Protocol (NTP)). This includes step adjustments, manual time settings changes and daylight savings time adjustments.
The following table lists the attributes sent with this message.
|
|
Billing requires the following generic configuration:
If integrated mode is specified, then the following configuration information is required:
Integrated mode requires the RADIUS client component of Cisco Unified Border Element (SP Edition). This has configuration requirements (such as the sets of billing servers). Each of these sets also has a state, which depends on the existence or absence of the event message cache file for that set. The administrator may change this state. The state may be disabled, active, failed, or resending.
The billing component is administered using the Cisco Unified Border Element (SP Edition) command-line interface. See the applicable billing commands in 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.
Alarms are tripped differently, based on how billing has been integrated, as described in the following table.
The Cisco Unified Border Element (SP Edition) billing system is fault tolerant on the following two levels:
During a failover to a backup system, warm failover mechanisms are supported. In the case of warm failover:
During the failover to a cold, non-dedicated backup, some billing data is lost in the transition from the old, failed system to the new server. The number of billing records completely lost during this transition is less than 10,000 per failover. However, in such a situation, consider the following possibilities:
This section contains the following examples:
This example shows two requests from the SBC to the RADIUS server for a single placed call.
The first RADIUS event message has messages related to call setup:
The second RADIUS event message has messages related to call teardown:
The following example shows the requests from the SBC to RADIUS server where SBC is configured to include the endpoint adjacency name in billing records:
The following example shows requests from the SBC to RADIUS server where SBC is configured to include endpoint addressing information in billing records:
The PacketCable 1.5 Event Messages Specification mandates that the billing messages are sent using the RADIUS protocol and IPSec for security.
Note In ACE SBC Release 3.0.00, only the RADIUS security mechanism, based on its own Request Authenticator, is supported.