xDR calculation

PortaBilling can collect information about the call via various network elements (e.g., PortaSIP and the media gateway), combine the individual pieces, and produce a single xDR record.

Gateways in the PortaBilling owner network are “trusted” gateways. These gateways MUST be listed in the Nodes directory and be a RADIUS or Diameter client.

Gateways which belong to your customers or vendors should not be created as nodes. Instead, a remote GW which belongs to your customer will be represented in the system as an account.

If the termination GW transmits an accounting record (connection matched), the User-Name must be verified to see if a trusted GW (Node IP=User-Name) is calling. If so, then the billing engine must wait for an accounting record from the trusted GW and use the User-Name from a trusted GW accounting record. If a trusted GW is not found, the call will be charged immediately to an applicable account. If an account is not found, a “security breach” mail alert will be sent.

Billing for telephony services is done based on the information provided by the elements of your VoIP network: gateways, SIP server, and so on. This information is supplied to the billing engine as accounting records. Usually the gateway treats incoming and outgoing calls as two separate entities, e.g., call legs. Each of the call legs produces a separate accounting record, so that, for instance, billing engine receives 4 accounting requests in case of a “classic” VoIP call arriving from PSTN to gateway A, traveling over the Internet to gateway B, and terminating in the PSTN network once again. Of course there must be some way of knowing that these four records are actually part of the same logical call. Therefore, each of them includes a special attribute that carries a unique ID for the call. This ID is used by the billing engine to add the call legs together and is also extremely useful for troubleshooting. For H323 calls, this attribute is called h323-conf-id, while for SIP calls it is call-id (however, for backward compatibility Cisco gateways and PortaSwitch assign a h323-conf-id for every SIP call).

Owners of IP Centrex environments may wish to obtain information about the actions of particular extensions during “complex” calls, i.e. calls that consist of several call legs such as call transfer, call forwarding, etc. For example, you might want to know which extension transferred the call or for how long an operator actually spoke, so that this information can be used in statistics reports.

PortaBilling compliments xDRs for complex PBX calls with auxiliary call details such as:

• Which hunt group a call came from.
• What the last extension ID was that forwarded or transferred the call.
• The actual call duration, i.e. the length of time an operator spoke in the call.
• The caller identity from where the call originated.

All of these details are available on the administrator web interface as part of the xDR history for a customer or their accounts. To browse auxiliary call details, click the Details icon next to the required xDR.

The Voice call details dialog window displays:

• The extension number to which the call was redirected.
• Via – The extension or hunt group number that dispatched the call.
• Call duration – The time during which the owner of the account being billed was occupied.
• Caller extension ID – The extension number where the call originated from.
• Called extension ID – The extension number that accepted the call.
• Calling party identity – The actual caller identity where the call originated from.

Auxiliary call details are created for the following PBX calls:

• Calls to voicemail (direct and missed calls).
• Forwarded/follow-me calls.
• Call pick-up.
• Transferred calls (via blind and attended transfer).

This list is provided out of the box. However, it is easily scalable and in future releases will be extended to cover more call scenarios such as call queues, etc.

The auxiliary call details are defined by the following xDR fields:

• via_hg – Information about the hunt group that dispatched the call.
• via_ext – Information about the last extension ID from where the call was forwarded or transferred.
  These flags appear when a call is processed within the PBX environment.
• media_duration – Information about the actual time the owner of the account to be billed was speaking during the call.
• acli – Information about the actual caller identity within the PBX environment from where the call originated. This identity may differ from the one delivered by the cloud PBX (e.g., the cloud PBX main account or the caller’s phone in case of forwarded calls) and displayed on the device of the called party.

These fields are added to the XDR_Auxiliary_Types table in the database while their values are stored in a separate XDR_Accounts_Aux table. The administrator can retrieve the information by accessing the database and can formulate a statistics report using a third-party application such as the Crystal Report tool. Please refer to the Custom Reports section for details of the custom report creation.

With extended xDRs you receive more sophisticated statistics data which helps you improve the cloud PBX management. The data may also serve as an additional tool for accounting.

When viewing Voice call details in customer and account xDRs, you see two fields: Charged duration and Call duration. What are they and what’s the difference between the two?

Charged duration is the total session duration. It is recorded in the charged_quantity xDR field. PortaBilling uses this value to calculate charges for the corresponding account. (The account to bill for the session is stored in the User-Name attribute).

Call duration is the time the user actually speaks. It is recorded in the media_duration xDR field and is mainly used for statistics purposes.

In direct calls between users, these two field values may be equal. In complex calls such as call transfer, call forwarding, call pickup, and calls that involve an IVR, they may differ. Let’s have a look at some examples:

An external caller Mary calls Bob. Bob has follow-me configured so the call is forwarded to Carol. Mary and Carol speak for 5 minutes. After the call ends, PortaBilling produces the xDRs for the call participants:

Bob is charged for the incoming call from Mary. Since Bob forwarded the call to Carol and was not physically speaking but is the one to pay for this call, his xDR details include:

• charged duration of 5 minutes, and
• call duration of 0 minutes.

Carol is charged for the incoming call from Bob. Her xDR details include:

• charged duration of 5 minutes, and
• call duration of 5 minutes.

Alice calls Bob. After 1 minute of conversation, Bob transfers the call to Carol. Carol answers and Bob is disconnected. Alice and Carol speak for 10 minutes.

After the call is over, PortaBilling produces the xDRs for call participants:

• For Alice: the xDR for the outgoing call to Bob. The xDR has the charge for the whole call, which includes the call to Bob (for 1 minute) and the call to Carol (for 10 minutes). Thus, in xDR details for Alice we see charged duration and call duration equal 11 minutes.
• For Bob: the xDR for the incoming call from Alice. The charged duration and call duration are 1 minute.
• For Bob: the xDR for the redirected call to Carol. The charged duration is 10 minutes (Bob’s account is billed for the transfer) but the call duration is 0, since Bob did not participate in this conversation.
• For Carol: for the incoming call from Alice. The charged duration and call duration are 10 minutes.

Alice calls EasyCall. She dials 12065558899 – the auto-attendant for EasyCall. She presses 1 and is redirected to the Sales queue. After 2 minutes she’s connected to Peter, the sales agent. They speak for 7 minutes. After the call ends, PortaBilling produces these xDRs:

• For Alice – for the outgoing call to Pete. The xDR includes the charged duration and the call duration of 9 minutes (2 minutes for waiting in the queue and 7 minutes for the conversation).
• For the auto-attendant account (12065558899) – for the redirected call from Alice to Pete. The charged duration is 9 minutes because the auto-attendant account is billed for the transfer to Pete. The call duration is 0 because the auto-attendant does not participate in the conversation.
• For Pete – for the incoming call from the auto-attendant. The charged duration and the call duration equal 7 minutes.