VOS3000 CDR File Rotation, VOS3000 Real-Time CDR Forwarding, VOS3000 CDR Query Blackout, VOS3000 CDR Query Date Range, VOS3000 CDR Text File Export, VOS3000 CDR Pipe Format, VOS3000 CDR Billing Mode Codes, VOS3000 CDR End Direction Critical

VOS3000 CDR End Direction Critical Call Termination Party Detection

VOS3000 CDR End Direction Critical Call Termination Party Detection

πŸ“ž Knowing who hung up the call is not just a curiosity β€” it is a critical data point that affects billing disputes, quality analysis, fraud detection, and network performance optimization. The VOS3000 CDR end direction field records exactly which party initiated the call termination: the caller (0), the callee (1), or the VOS3000 server itself (2). This three-code system, documented in the official VOS3000 manual Β§4.4 (page 242), provides the definitive answer to “who ended this call?” β€” and that answer has far-reaching implications for your VoIP business. πŸ”

βš™οΈ Consider the billing dispute scenario: A customer claims they were overcharged because “the call dropped after only a few seconds.” Without the endDirection field, you have no way to prove whether the customer hung up normally, the far end hung up, or the server terminated the call due to a timeout or balance exhaustion. With endDirection = 2 (server), you can explain that the server terminated the call because the prepaid balance was depleted β€” resolving the dispute with evidence. Without it, you are relying on guesswork. πŸ“Š

🎯 This guide provides a comprehensive reference for the VOS3000 CDR end direction field, covering all three codes (0, 1, 2), their meanings, how they interact with other CDR fields like endReason and billingMode, and practical analysis techniques for using end direction data in billing, quality monitoring, and security applications. All definitions are sourced from the official VOS3000 2.1.8.0/2.1.9.07 English manual Β§4.4 (page 242). πŸ“˜

πŸ” What Is VOS3000 CDR End Direction?

πŸ“‹ The VOS3000 CDR end direction (also called “hangup side” in the manual) is Field 7 in the pipe-delimited CDR format. It records which party initiated the termination of the call by sending the SIP BYE message, H.323 EndSessionCommand, or equivalent call teardown signal. This is not about which party originated the call β€” it is specifically about which party ended it.

πŸ“ CDR field location: Position 7 in the pipe-delimited CDR format, between the endReason (Field 6) and callerGatewayId (Field 8) fields, as documented in the VOS3000 manual Β§4.4.

πŸ“‹ Official Manual Definition

πŸ“– The VOS3000 2.1.8.0/2.1.9.07 English manual Β§4.4 (page 242) defines the endDirection field as:

“endDirection β€” Hangup side(0-caller,1-callee,2-serverοΌ‰”

πŸ“ This is the complete and official definition. The three possible values and their meanings are:

CodePartyMeaningSIP Signal
0πŸ”” CallerThe calling party initiated the hangupBYE from caller side
1πŸ“ž CalleeThe called party initiated the hangupBYE from callee side
2πŸ–₯️ ServerThe VOS3000 server initiated the hangupBYE generated by VOS3000

πŸ“Š End Direction Code 0: Caller Hangup

πŸ”” When the VOS3000 CDR end direction is 0, it means the calling party initiated the call termination. In SIP terms, the BYE message originated from the caller’s side of the call leg. This is the most common end direction for normal completed calls β€” the person who made the call decides they are done talking and hangs up.

AttributeDetail
πŸ“Œ Code0
πŸ“ PartyCaller (calling party)
πŸ”„ Typical ScenarioNormal call completion β€” caller hangs up after conversation
πŸ“Š Expected Proportion50–80% of connected calls in most deployments

πŸ“‹ Analysis Implications of Caller Hangup

πŸ’‘ What caller hangup tells you: When endDirection = 0, the call followed a normal pattern β€” the calling party placed the call, the conversation took place, and the caller ended it when finished. This is the expected behavior for the majority of outbound calls. However, if you notice an unusually high percentage of caller hangups with very short hold times (under 3 seconds), it may indicate that callers are reaching the wrong number or encountering audio problems and hanging up immediately.

πŸ“Š Quality correlation: Pair endDirection = 0 with short holdTime values to identify potential audio quality issues. If callers consistently hang up within the first few seconds, there may be a one-way audio problem or incorrect number routing. Cross-reference with the endReason codes to get the full picture β€” a normal SIP 200 OK with endDirection = 0 and holdTime under 2000ms suggests a quick hangup after audio issues rather than a failed call.

πŸ“Š End Direction Code 1: Callee Hangup

πŸ“ž When the VOS3000 CDR end direction is 1, it means the called party initiated the call termination. The BYE message came from the callee’s side. This typically happens when the person who received the call decides to end the conversation.

AttributeDetail
πŸ“Œ Code1
πŸ“ PartyCallee (called party)
πŸ”„ Typical ScenarioCalled party hangs up after conversation ends
πŸ“Š Expected Proportion15–40% of connected calls in most deployments

πŸ“‹ Analysis Implications of Callee Hangup

πŸ’‘ What callee hangup tells you: An endDirection of 1 is perfectly normal for many call scenarios β€” the called party simply ends the conversation. However, a high proportion of callee hangups, especially combined with short hold times, may indicate that the called parties are not expecting the call (possible spam or unsolicited traffic), or that the audio from the caller side is not reaching the callee properly.

πŸ” Wholesale traffic quality indicator: In wholesale VoIP operations, monitoring the ratio of callee hangups to caller hangups on specific routes helps assess traffic quality. A route with a high percentage of callee hangups and short durations may indicate that the terminating carrier’s end users are rejecting or quickly ending calls β€” a sign of potential CLI (Caller Line Identification) issues or unwanted traffic. This data supports decisions about route optimization and carrier selection.

πŸ“Š End Direction Code 2: Server Hangup

πŸ–₯️ When the VOS3000 CDR end direction is 2, it means the VOS3000 server itself initiated the call termination. This is the most operationally significant of the three codes, because it indicates the softswitch actively intervened to end the call β€” and the reasons for that intervention directly impact billing, customer experience, and system health. 🚨

AttributeDetail
πŸ“Œ Code2
πŸ“ PartyServer (VOS3000 softswitch)
πŸ”„ Typical ScenarioServer-initiated call termination for policy, timeout, or balance reasons
πŸ“Š Expected Proportion5–20% of connected calls, depending on prepaid ratio

πŸ“‹ When Does Server Hangup Occur?

πŸ–₯️ There are several important scenarios where VOS3000 terminates a call from the server side, each with different operational implications:

ScenarioDescriptionEnd ReasonImpact
πŸ’° Balance exhaustionPrepaid account runs out of funds during active callVarious (may show session timeout code)Customer may dispute charges
⏱️ Session timer expirySIP session timer expires without successful re-INVITE refresh200 (normal) or 408Call duration capped by timer
πŸ”§ Administrative disconnectOperator manually disconnects the call via VOS3000 client200Immediate call termination
πŸ“‘ No-media timeoutRTP media stream stops flowing for the configured timeout periodVariousDetects dead calls consuming resources
πŸ›‘οΈ Maximum duration limitCall exceeds the configured maximum call duration200Policy-based call length cap
πŸ”„ Gateway failover cleanupServer terminates call during gateway switching or failover process503 or other errorCall may be re-routed

πŸ’‘ Recording server hangups: Whether CDRs for server-initiated hangups are recorded depends on the SERVER_BILLING_RECORD_SERVER_HANG_UP parameter. When this parameter is On, VOS3000 generates CDR records even when the server initiates the hangup, providing a complete audit trail of all call terminations. When Off, server-initiated hangups may not generate CDR records, creating gaps in your billing and operational data. For detailed configuration guidance, see our server hangup CDR recording guide.

πŸ“‹ End Direction and Billing Dispute Resolution

πŸ’° The VOS3000 CDR end direction field is one of the most powerful tools for resolving billing disputes. When a customer challenges a charge, the endDirection code provides objective evidence of what happened during the call:

Dispute ClaimEnd DirectionResolution
“The call dropped after a few seconds”0 (caller hangup)βœ… The caller (customer) hung up normally β€” not a dropped call
“I was disconnected unexpectedly”2 (server hangup)⚠️ Server terminated β€” investigate balance exhaustion or session timeout
“The call was much shorter than billed”1 (callee hangup)βœ… The called party hung up β€” duration matches CDR holdTime
“I never made this call”0 (caller hangup) with specific callerIpπŸ” Verify the callerIp matches the customer’s registered device

πŸ“Š Evidence chain: For maximum dispute resolution effectiveness, combine the endDirection field with other CDR fields. The endReason code tells you why the call ended, the holdTime tells you how long the conversation lasted, the callerIp confirms where the call originated, and the endDirection tells you who terminated the call. Together, these four fields create an unambiguous evidence chain that resolves most billing disputes. For detailed CDR analysis methodology, see our CDR billing discrepancy guide.

πŸ“Š End Direction and Call Quality Analysis

πŸ“ˆ Analyzing end direction patterns across your traffic reveals important quality trends that are not visible from ASR and ACD metrics alone. Here are the key analysis patterns to monitor:

πŸ“‹ End Direction Distribution Analysis

PatternEnd Direction MixIndicatesAction
βœ… Normal distribution60% caller, 30% callee, 10% serverHealthy traffic with normal call patternsNo action needed β€” continue monitoring
⚠️ High server hangupServer hangup over 25%Session timeouts, balance exhaustion, or system issuesCheck session timer and prepaid balance settings
πŸ” Short callee hangupCallee hangup with holdTime under 5sCalled parties rejecting calls β€” possible CLI or spam issueReview caller ID presentation and traffic source
🚨 Short caller hangupCaller hangup with holdTime under 3sOne-way audio or wrong number β€” callers hanging up immediatelyCheck audio quality on affected routes

πŸ“‹ End Direction by Gateway Analysis

πŸ“‘ Segmenting end direction data by gateway (using the callerGatewayId and calleeGatewayId fields) reveals gateway-specific quality issues. A gateway that shows an unusually high percentage of server-initiated hangups (endDirection = 2) may have connectivity problems causing session timer expirations. A gateway with a high proportion of short-duration callee hangups may be routing traffic to low-quality destinations where end users reject the calls. This gateway-level analysis supports data-driven routing decisions and helps you identify which carriers deliver the best call completion quality. For gateway performance monitoring techniques, see our gateway analysis reports guide.

πŸ“‹ End Direction and Session Timer Interaction

⏱️ One of the most important operational interactions is between the VOS3000 CDR end direction and the SIP session timer system. When session timers are enabled, VOS3000 periodically sends re-INVITE messages to refresh the session. If the re-INVITE fails (the endpoint does not respond), VOS3000 terminates the call β€” and the endDirection will be 2 (server). This is a common scenario for calls that “mysteriously drop” after a fixed interval.

Session Timer ScenarioEnd DirectionEnd ReasonResolution
βœ… Re-INVITE succeeds0 or 1 (normal)200 OKCall continues until party hangs up
⚠️ Re-INVITE fails (NAT issue)2 (server)408 or timeoutCheck NAT keepalive settings
πŸ”§ No session timer support2 (server)Session expiryConfigure SS_SIP_NO_TIMER_REINVITE_INTERVAL
πŸ’° Prepaid balance depleted2 (server)200 OK (normal clear)Expected behavior for prepaid accounts

πŸ’‘ Investigating mysterious drops: If customers report calls dropping at consistent intervals (e.g., always at 30 minutes or 2 hours), check the SIP session timer configuration. The session timer interval, combined with the SS_SIP_SESSION_UPDATE_SEGMENT parameter, determines when VOS3000 sends re-INVITE refreshes. If the endpoint does not support session timers and SS_SIP_NO_TIMER_REINVITE_INTERVAL is not configured, VOS3000 may terminate the call after the session timer expires β€” resulting in endDirection = 2.

πŸ›‘οΈ Common End Direction Analysis Problems and Solutions

❌ Problem 1: Excessive Server Hangups (endDirection = 2)

πŸ” Symptom: A high percentage of CDRs show endDirection = 2, indicating the server is terminating many calls.

πŸ’‘ Cause: Multiple factors can cause excessive server hangups: session timer misconfiguration, NAT traversal failures causing re-INVITE timeouts, prepaid accounts frequently running out of balance, or RTP timeout detecting dead media streams.

βœ… Solutions:

  • ⏱️ Review SIP session timer settings β€” ensure SS_SIP_NO_TIMER_REINVITE_INTERVAL provides a safety net for non-timer endpoints
  • 🌐 Check NAT keepalive settings β€” failed re-INVITEs through NAT firewalls are a leading cause of server-initiated hangups
  • πŸ’° Verify prepaid balance thresholds β€” the mid-call balance warning should alert users before their balance is depleted
  • πŸ“‘ Monitor RTP timeout settings that may be too aggressive for legitimate silent periods in calls

❌ Problem 2: Billing Disputes Where Customer Claims Call Dropped

πŸ” Symptom: Customer disputes a charge, claiming the call dropped unexpectedly, but the CDR shows endDirection = 0 (caller hangup) with a substantial holdTime.

πŸ’‘ Cause: The customer may have accidentally ended the call, or their SIP device may have sent a BYE due to a local issue (not a server-side drop). The CDR end direction provides the objective evidence.

βœ… Solutions:

  • πŸ“‹ Present the endDirection = 0 record to the customer as evidence that their device initiated the hangup
  • πŸ” Cross-reference with callerIp to confirm the call originated from the customer’s registered device
  • πŸ“Š Compare the holdTime with the customer’s claim about call duration
  • πŸ“ž For endDirection = 2 cases, explain the server termination reason (balance exhaustion, session timeout, etc.)

❌ Problem 3: Short Callee Hangups Indicating Traffic Quality Issues

πŸ” Symptom: High volume of endDirection = 1 records with very short holdTime values on a specific route or gateway.

πŸ’‘ Cause: The called parties are answering and immediately hanging up. This can indicate wrong-number calls, CLI (Caller Line Identification) not being presented correctly, or the traffic being perceived as spam by the called parties.

βœ… Solutions:

  • πŸ“ž Verify that the caller ID being presented to the called party is correct and recognizable
  • πŸ”§ Check the caller ID management configuration for the affected mapping gateway
  • πŸ“Š Analyze the geographic distribution of short callee hangups to identify specific regions or carriers with quality issues
  • πŸ”„ Consider routing adjustments to avoid low-quality termination carriers

πŸ’‘ End Direction Best Practices

🎯 Follow these best practices to maximize the value of VOS3000 CDR end direction data in your operations:

Best PracticeRecommendationReason
πŸ“‹ Always enable server hangup CDR recordingSet SERVER_BILLING_RECORD_SERVER_HANG_UP = OnπŸ” Complete audit trail of all call terminations
πŸ“Š Monitor end direction distribution weeklyTrack % of codes 0, 1, 2 across all trafficπŸ“ˆ Early detection of quality and configuration issues
πŸ’° Use end direction in billing dispute workflowsInclude endDirection in dispute resolution SOPπŸ›‘οΈ Objective evidence resolves disputes faster
πŸ“‘ Segment by gateway for quality analysisAnalyze end direction per routing gatewayπŸ”§ Data-driven carrier selection and route optimization
⏱️ Correlate endDirection = 2 with session timerMatch server hangups to timer expiry patternsπŸ”§ Identifies NAT and timer configuration problems

❓ Frequently Asked Questions

❓ What does VOS3000 CDR end direction 2 mean?

πŸ–₯️ A VOS3000 CDR end direction of 2 means the VOS3000 server initiated the call termination. This occurs when the softswitch actively ends the call, rather than either endpoint (caller or callee) hanging up. Common reasons include: prepaid account balance exhaustion (the server terminates the call when funds run out), SIP session timer expiry (the server did not receive a successful re-INVITE refresh), administrative disconnect by the operator, maximum call duration limit reached, or RTP media timeout detecting a dead media stream. The endDirection = 2 code is documented in the VOS3000 manual Β§4.4 (page 242) as “server” hangup side.

❓ How do I determine why a server hangup occurred?

πŸ” To determine the specific reason for a server-initiated hangup (endDirection = 2), cross-reference the endDirection field with the endReason field (Field 6) in the same CDR record. The endReason provides the SIP response code or cause code that explains why the call was terminated. For example, endDirection = 2 with endReason = 200 typically indicates a normal server-initiated clear (such as balance exhaustion or maximum duration). EndDirection = 2 with endReason = 408 indicates a timeout. Combining these two fields gives you the complete picture of who ended the call and why.

❓ Does endDirection affect billing calculations?

πŸ’° The endDirection field itself does not directly change billing calculations β€” the holdTime field determines the billable duration regardless of who hung up. However, endDirection has indirect billing implications. When endDirection = 2 (server hangup), the call may have been terminated before the natural conversation end, which can lead to customer disputes. When analyzing billing data, filtering by endDirection helps you understand the nature of your call completions and identify patterns that affect revenue, such as premature server terminations due to balance exhaustion on prepaid accounts.

❓ Can the endDirection value be incorrect?

πŸ”§ In rare cases, the endDirection may not accurately reflect the true termination party. This can happen when a SIP ALG (Application Layer Gateway) or intermediate proxy modifies the BYE message direction, or when a gateway sends a BYE on behalf of an endpoint (making it appear as a callee hangup when the caller actually hung up). If you suspect endDirection inaccuracy, enable SIP debug tracing to capture the actual BYE message flow and verify which IP address sent the termination signal. Check our SIP debug guide for instructions on capturing and analyzing SIP message traces.

❓ How is endDirection different from endReason in VOS3000 CDR?

πŸ“‹ The endDirection field (Field 7) tells you who terminated the call β€” caller (0), callee (1), or server (2). The endReason field (Field 6) tells you why the call was terminated β€” using SIP response codes (200, 486, 503, etc.) or Q.850 cause codes. These two fields answer different questions and must be analyzed together for the complete picture. For example, endDirection = 0 with endReason = 200 means the caller hung up normally. EndDirection = 2 with endReason = 200 means the server terminated the call normally (likely due to balance exhaustion or duration limit). EndDirection = 1 with endReason = 486 means the callee rejected the call with a busy signal.

❓ Should I always record CDRs for server-initiated hangups?

πŸ“ Yes, it is strongly recommended to record CDRs for server-initiated hangups by setting SERVER_BILLING_RECORD_SERVER_HANG_UP = On. Without these records, your CDR data has gaps β€” you lose visibility into calls that the server terminated, which are often the most operationally significant calls (balance exhaustion, session timeouts, administrative actions). These records are essential for billing dispute resolution, quality analysis, and system health monitoring. The zero-duration CDR control parameter (SERVER_BILLING_RECORD_ZERO_HOLD_TIME) serves a different purpose β€” it controls whether failed call attempts are recorded, while SERVER_BILLING_RECORD_SERVER_HANG_UP specifically addresses server-initiated terminations.

πŸ“ž Need Expert Help with VOS3000 CDR End Direction?

πŸ”§ Understanding and analyzing VOS3000 CDR end direction data is essential for billing accuracy, quality monitoring, and operational intelligence. Whether you are investigating server-initiated hangups, resolving billing disputes, or building a call quality dashboard, expert guidance ensures your analysis is accurate and actionable. πŸ“Š

πŸ’¬ WhatsApp: +8801911119966 β€” Get immediate assistance with VOS3000 CDR end direction analysis, billing dispute resolution, and call quality monitoring. Our team specializes in VOS3000 CDR analytics, billing system optimization, and VoIP quality assurance. πŸ”§

πŸ”— Explore related VOS3000 CDR and call quality guides:


πŸ“ž Need Professional VOS3000 Setup Support?

For professional VOS3000 installations and deployment, VOS3000 Server Rental Solution:

πŸ“± WhatsApp: +8801911119966
🌐 Website: www.vos3000.com
🌐 Blog: multahost.com/blog
πŸ“₯ Downloads: VOS3000 Downloads


VOS3000 CDR File Rotation, VOS3000 Real-Time CDR Forwarding, VOS3000 CDR Query Blackout, VOS3000 CDR Query Date Range, VOS3000 CDR Text File Export, VOS3000 CDR Pipe Format, VOS3000 CDR Billing Mode Codes, VOS3000 CDR End Direction CriticalVOS3000 CDR File Rotation, VOS3000 Real-Time CDR Forwarding, VOS3000 CDR Query Blackout, VOS3000 CDR Query Date Range, VOS3000 CDR Text File Export, VOS3000 CDR Pipe Format, VOS3000 CDR Billing Mode Codes, VOS3000 CDR End Direction CriticalVOS3000 CDR File Rotation, VOS3000 Real-Time CDR Forwarding, VOS3000 CDR Query Blackout, VOS3000 CDR Query Date Range, VOS3000 CDR Text File Export, VOS3000 CDR Pipe Format, VOS3000 CDR Billing Mode Codes, VOS3000 CDR End Direction Critical
VOS3000 CDR File Rotation, VOS3000 Real-Time CDR Forwarding, VOS3000 CDR Query Blackout, VOS3000 CDR Query Date Range, VOS3000 CDR Text File Export, VOS3000 CDR Pipe Format, VOS3000 CDR Billing Mode Codes, VOS3000 CDR End Direction Critical

VOS3000 CDR Billing Mode Codes Accurate -1 0 1 3 Reference

VOS3000 CDR Billing Mode Codes Accurate -1 0 1 3 Reference

πŸ’³ Every call detail record in VOS3000 carries a billingMode field that tells you exactly how β€” and whether β€” that call was charged. The four VOS3000 CDR billing mode codes (-1, 0, 1, and 3) are the key to understanding your billing data, detecting revenue leaks, and auditing your call accounting accuracy. Yet many operators treat this field as an afterthought, only discovering its importance when a billing dispute arises or a revenue discrepancy demands investigation. πŸ“Š

βš™οΈ The billingMode field (Field 17 in the pipe-delimited CDR format) determines which type of account was charged for the call. A code of -1 means no billing was applied at all. A code of 0 means the call was billed to a phone number account. A code of 1 means it was billed to a gateway ID. A code of 3 means it was billed to a phone card (calling card). Each code has distinct implications for how the billing engine calculates charges, which rate table is referenced, and how the revenue is attributed in your financial reports. Misunderstanding even one of these codes can lead to incorrect billing analysis and lost revenue. πŸ”

🎯 This guide provides an accurate, manual-verified reference for all four VOS3000 CDR billing mode codes. All code definitions are sourced from the official VOS3000 2.1.8.0/2.1.9.07 English manual Β§4.4 (page 242), with detailed explanations of how each code affects billing calculations, which account types they correspond to, and how to use them in CDR analysis and reporting. πŸ“˜

Table of Contents

πŸ” What Are VOS3000 CDR Billing Mode Codes?

πŸ“‹ The VOS3000 CDR billing mode codes appear in the billingMode field (position 17) of every CDR record in the pipe-delimited text export. They indicate the charge mode β€” the type of billing entity that was used to calculate and record charges for the call. This is distinct from the billing method field (position 16, calleeBilling), which indicates whether the caller or callee is charged. The billing mode tells you what kind of account was charged, while the billing method tells you which party was charged.

πŸ’‘ Why billing mode codes matter:

  • πŸ’° Revenue attribution: Knowing which account type generated revenue helps you track income by business segment (retail phone, wholesale gateway, calling card)
  • πŸ” Fraud detection: An unexpected billing mode code in a CDR may indicate configuration errors or unauthorized access
  • πŸ“Š Reporting accuracy: Billing reports must separate revenue by account type for financial and regulatory purposes
  • πŸ›‘οΈ Audit compliance: Regulators may require documentation of how each call was billed and which account was charged
  • πŸ”§ Troubleshooting: Calls with billingMode = -1 that should have been billed indicate a billing configuration problem

πŸ“ CDR field location: The billingMode field is at position 17 in the VOS3000 pipe-delimited CDR format, as documented in the official manual Β§4.4 (page 242). It appears after the calleeBilling field and before the callerPdd field.

πŸ“Š VOS3000 CDR Billing Mode Code -1: No Billing

🚫 A billingMode of -1 means the call was not billed at all. No charges were calculated, no account was debited, and no billing record was generated for the call β€” although the CDR itself is still recorded for operational and security purposes.

AttributeDetail
πŸ“Œ Code-1
πŸ“ Manual DescriptionNo billing (VOS3000 manual Β§4.4: “bobilling” β€” a typo for “no billing”)
πŸ’° Billing AppliedNone β€” call is completely exempt from charges
πŸ“‹ Account DebitedNo account is debited

πŸ“‹ When Does VOS3000 CDR Billing Mode -1 Occur?

πŸ” There are several scenarios where a call receives a billingMode of -1 in VOS3000:

ScenarioDescriptionExpected?
πŸ›‘οΈ Illegal/unauthorized callsCalls from IP addresses not registered as valid mapping gatewaysβœ… Yes β€” no account to bill
πŸ“ž Free E.164 numbersCalls to numbers listed in SERVER_BILLING_FREE_E164Sβœ… Yes β€” configured as free
🚫 No-CDR free numbersCalls to numbers in SERVER_BILLING_NO_CDR_E164Sβœ… Yes β€” configured to skip billing
⚠️ Unmatched routingCalls that could not be matched to any account or rate table❌ No β€” indicates config error
πŸ”§ System errorsCalls that encountered a billing engine error during processing❌ No β€” requires investigation

🚨 Revenue leak alert: If you find CDR records with billingMode = -1 for calls that should have been billed (normal calls to paying destinations), this indicates a billing configuration problem. The most common cause is a missing rate table entry for the destination number β€” VOS3000 cannot apply billing if it cannot find a matching rate. Check your rate table configuration and ensure all active destinations have valid rates assigned.

πŸ“Š VOS3000 CDR Billing Mode Code 0: Phone Number Billing

πŸ“ž A billingMode of 0 means the call was billed to a phone number account. This is the most common billing mode for retail VoIP operations where individual SIP accounts (each identified by a phone number or extension) are charged for their calls.

AttributeDetail
πŸ“Œ Code0
πŸ“ Manual DescriptionPhone number (VOS3000 manual Β§4.4: “phone number”)
πŸ’° Billing AppliedYes β€” charges calculated and applied to the phone number account
πŸ“‹ Account DebitedIndividual SIP account identified by phone number/extension

πŸ“‹ How Phone Number Billing Works

πŸ”’ When billingMode is 0, the VOS3000 billing engine identifies the calling (or called) party by their phone number or SIP account ID. The charges are applied to that specific account’s balance. The rate table lookup uses the destination number (calleeE164) matched against the account’s assigned rate table. This is the standard billing model for:

  • πŸ“ž Retail SIP accounts: Individual users with their own phone numbers and prepaid/postpaid balances
  • 🏒 Business extensions: PBX extensions that are individually metered and charged
  • πŸ“± Calling card accounts: When the calling card system maps to individual phone number accounts (distinct from phone card billing mode 3)
  • 🏠 Residential VoIP: Home users with per-call billing on their personal SIP account

πŸ’‘ Balance check: For prepaid phone number accounts, VOS3000 checks the account balance before allowing the call. If the balance is insufficient, the call is rejected or limited to the duration that the remaining balance can support. The SERVER_BILLING_PREVENT_OVERDRAFT_ADVANCE_TIME parameter reserves advance time to prevent accounts from going negative during active calls.

πŸ“Š VOS3000 CDR Billing Mode Code 1: Gateway ID Billing

πŸ“‘ A billingMode of 1 means the call was billed to a gateway ID account. This is the dominant billing mode for wholesale VoIP operations where traffic is routed through mapping gateways and routing gateways, and the charges are applied to the gateway’s account rather than to individual phone numbers.

AttributeDetail
πŸ“Œ Code1
πŸ“ Manual DescriptionGateway ID (VOS3000 manual Β§4.4: “gateway ID”)
πŸ’° Billing AppliedYes β€” charges calculated and applied to the gateway account
πŸ“‹ Account DebitedMapping gateway or routing gateway account, identified by gateway ID

πŸ“‹ How Gateway ID Billing Works

🌐 When billingMode is 1, the VOS3000 billing engine attributes the call charge to the gateway through which the traffic passed. This is the standard billing model for wholesale and carrier-grade VoIP operations where traffic volume is high and individual call billing would be impractical. The gateway’s rate table is used for rate lookup, and charges are deducted from the gateway’s account balance.

πŸ“‘ Common scenarios for gateway billing:

  • πŸ”„ Wholesale termination: Carriers sending large volumes of traffic through a gateway and billed by the gateway’s aggregate rates
  • πŸ“ž Origination gateways: Incoming traffic from a PBX or softswitch is billed to the originating mapping gateway
  • πŸ”— Interconnect billing: Traffic exchanged between carriers, billed to the gateway representing the interconnection point
  • 🏒 Enterprise PBX trunking: A business PBX connected via a SIP trunk is billed at the gateway level rather than per extension

πŸ“Š Gateway-level reporting: The billingMode = 1 designation is essential for wholesale traffic analysis. When generating revenue reports, you should filter CDRs by billingMode to separate gateway-billed wholesale revenue from phone-number-billed retail revenue. This separation is critical for understanding your business mix and margins. For more details on wholesale billing analysis, see our CDR analysis and billing guide.

πŸ“Š VOS3000 CDR Billing Mode Code 3: Phone Card Billing

πŸ’³ A billingMode of 3 means the call was billed to a phone card (calling card) account. This applies specifically to calls made through the VOS3000 IVR-based calling card system, where users dial an access number, enter their PIN, and then dial the destination number.

AttributeDetail
πŸ“Œ Code3
πŸ“ Manual DescriptionPhone card (VOS3000 manual Β§4.4: “phone card”)
πŸ’° Billing AppliedYes β€” charges calculated and applied to the calling card account
πŸ“‹ Account DebitedPhone card (calling card) account identified by PIN/card number

πŸ“‹ How Phone Card Billing Works

πŸ’³ When billingMode is 3, the VOS3000 billing engine charges the call to the calling card account that was authenticated through the IVR system. The calling card has its own balance, rate table, and billing rules that are separate from both phone number accounts and gateway accounts. The IVR system plays a balance announcement, authenticates the PIN, and manages call duration based on the card’s remaining balance.

πŸ“‹ Phone card billing specifics:

  • πŸ“ž IVR authentication: The caller dials an access number, enters their PIN via DTMF, and the IVR validates the card
  • πŸ’° Prepaid only: Phone cards are always prepaid β€” the card balance must be sufficient before the call is allowed
  • πŸ“Š Separate rate table: Calling card calls may use a different rate table than regular phone number accounts
  • ⏱️ Duration enforcement: The maximum call duration is calculated based on the card’s remaining balance and the per-minute rate
  • πŸ”Š Balance announcements: The IVR can announce remaining balance and maximum talk time before connecting the call

πŸ”‘ Distinguishing from billingMode 0: Do not confuse phone card billing (mode 3) with phone number billing (mode 0). Even though both involve individual accounts with balances, phone card accounts are accessed through the IVR PIN authentication flow, while phone number accounts are accessed directly via SIP registration. The billing separation ensures that calling card revenue and expenses are tracked independently from retail SIP account revenue.

πŸ“‹ Complete VOS3000 CDR Billing Mode Codes Comparison Table

CodeModeAccount TypeBilling AppliedTypical Use Case
-1🚫 No billingNoneNoIllegal calls, free numbers, unmatched calls
0πŸ“ž Phone numberSIP accountYesRetail VoIP, individual SIP accounts
1πŸ“‘ Gateway IDGateway accountYesWholesale termination, interconnect billing
3πŸ’³ Phone cardCalling card accountYesIVR-based calling card service

πŸ“Š VOS3000 CDR Billing Mode Distribution Analysis

πŸ“ˆ Analyzing the distribution of billing mode codes across your CDR data reveals important patterns about your traffic mix and billing health. Here is what to look for in each mode’s proportion:

Billing ModeHealthy RangeWarning SignAction Required
-1 (No billing)0–5% of total CDRsSudden spike in no-billing recordsInvestigate rate table gaps or illegal call volume
0 (Phone number)Varies by business modelLower than expected for retail operationsVerify SIP account billing configuration
1 (Gateway ID)Varies by business modelGateway-billed calls showing zero revenueCheck gateway rate tables and balances
3 (Phone card)Only if calling card service is activePhone card CDRs without IVR prefixVerify IVR and calling card configuration

πŸ“Š Practical analysis tip: Run a daily query on your CDR data to count the billing mode distribution. If the percentage of mode -1 records suddenly increases, it may indicate a rate table is missing entries for a new destination, or that an attack is generating unauthorized calls. If mode 3 records appear but you do not operate a calling card service, it suggests a configuration error that needs immediate attention. Use our VOS3000 data report guide for setting up automated daily reports. VOS3000 CDR Billing Mode

πŸ”§ Several VOS3000 parameters interact with the billing mode system. Understanding these relationships helps you configure billing correctly and interpret CDR billing mode codes accurately:

ParameterDefaultEffect on Billing Mode
SERVER_BILLING_FREE_E164S(blank)Calls to these numbers incur no charges β€” may result in billingMode = -1
SERVER_BILLING_NO_CDR_E164S(blank)Calls to these numbers skip CDR generation entirely β€” no billingMode recorded
SERVER_BILLING_RECORD_ILLEGAL_CALLOnWhen On, illegal calls generate CDRs with billingMode = -1
SS_CDR_RECORD_ILLEGALOnWhen On, illegal call CDRs (mode -1) are included in text file export
SS_NO_BILLING_TO_PHONEOffWhen On, provides free billing to phone β€” affects billing mode attribution

πŸ’‘ Parameter interaction note: The SERVER_BILLING_FREE_E164S parameter creates a distinct billing behavior from billingMode = -1. When a call matches a free E.164 number, the call is still processed through the billing engine (which may record it with a specific billing mode code), but the calculated charge is zero. This is different from billingMode = -1, which means billing was not applied at all. For details on free number configuration, see our toll-free E164 billing guide. VOS3000 CDR Billing Mode

πŸ›‘οΈ Common VOS3000 CDR Billing Mode Code Problems and Solutions

❌ Problem 1: Revenue Calls Showing billingMode = -1

πŸ” Symptom: Calls that should generate revenue are appearing in CDR records with billingMode = -1 instead of 0 or 1.

πŸ’‘ Cause: The most common cause is a missing rate table entry for the destination. When VOS3000 cannot find a matching rate for the calleeE164 in the account’s rate table, it cannot calculate a charge and assigns billingMode = -1.

βœ… Solutions:

  • πŸ“Š Verify the destination has a valid rate in the appropriate rate table
  • πŸ”§ Check that the account’s rate table assignment is correct
  • πŸ“‹ Ensure prefix settings properly strip routing prefixes before rate lookup β€” see our gateway route prefix billing guide
  • πŸ” Review the CDR billing discrepancy troubleshooting guide for systematic diagnosis

❌ Problem 2: Wrong Billing Mode for Gateway Calls

πŸ” Symptom: Calls through a gateway are being billed to a phone number account (mode 0) instead of the gateway account (mode 1).

πŸ’‘ Cause: The gateway’s billing configuration in the VOS3000 client may be set to bill the calling party’s phone number account rather than the gateway account. This typically happens when the mapping gateway is configured with a specific SIP account instead of billing at the gateway level.

βœ… Solutions:

  • πŸ”§ Review the mapping gateway’s billing settings in VOS3000 client
  • πŸ“‹ Verify the gateway’s rate table and billing account assignment
  • πŸ“ž Check the VOS3000 account billing configuration to ensure proper billing attribution

❌ Problem 3: Unexpected billingMode = 3 Without Calling Card Service

πŸ” Symptom: CDR records show billingMode = 3 (phone card) but no calling card service is deployed on this VOS3000 system.

πŸ’‘ Cause: A SIP account may have been incorrectly configured with phone card billing attributes, or a mapping gateway may be routing calls through the IVR calling card module unintentionally.

βœ… Solutions:

  • πŸ”§ Audit all SIP accounts for unexpected calling card configuration
  • πŸ“‹ Check mapping gateway settings for IVR routing misconfigurations
  • πŸ“Š Filter CDR records by billingMode = 3 and investigate the affected accounts

πŸ’‘ VOS3000 CDR Billing Mode Code Best Practices

🎯 Follow these best practices to ensure accurate billing mode attribution and effective CDR analysis:

Best PracticeRecommendationReason
πŸ“Š Monitor billing mode distribution dailyTrack percentage of each codeπŸ” Early detection of configuration errors and fraud
🚨 Alert on billingMode = -1 spikesSet threshold alerts for no-billing recordsπŸ’° Prevents revenue leaks from rate table gaps
πŸ“‹ Separate revenue reports by billing modeGenerate distinct reports for modes 0, 1, 3πŸ“Š Accurate revenue attribution by business segment
πŸ”§ Validate rate table coverageEnsure all destinations have valid ratesπŸ›‘οΈ Prevents unexpected billingMode = -1 records
πŸ“ Document billing mode usageRecord which account types use which billing modesπŸ“‹ Enables faster troubleshooting and onboarding

❓ Frequently Asked Questions

❓ What does billingMode = -1 mean in VOS3000 CDR?

🚫 A billingMode of -1 in VOS3000 means no billing was applied to the call. The call record exists in the CDR for operational and security purposes, but no account was charged. This occurs for illegal/unauthorized calls from unknown IP addresses, calls to free E.164 numbers configured in SERVER_BILLING_FREE_E164S, and calls that could not be matched to any billing account or rate table. If you are seeing billingMode = -1 for calls that should generate revenue, check your rate table configuration to ensure all active destinations have valid rates. The VOS3000 manual Β§4.4 (page 242) documents this code as “no billing.”

❓ What is the difference between billingMode 0 and billingMode 1?

πŸ“‹ billingMode 0 (phone number) bills the call to an individual SIP account identified by a phone number or extension. This is typical for retail VoIP where each user has their own account with a personal balance and rate table. billingMode 1 (gateway ID) bills the call to a gateway account. This is typical for wholesale VoIP where traffic is billed at the gateway level rather than per individual user. The distinction matters for revenue reporting β€” mode 0 revenue comes from retail accounts, while mode 1 revenue comes from wholesale/interconnect relationships.

❓ Can a call have different billing modes for caller and callee sides?

πŸ”„ No, the billingMode field in the CDR represents a single billing attribution for the entire call. However, the separate calleeBilling field (position 16) does indicate which party is charged: 0 means the caller’s account is billed, and 1 means the callee’s account is billed. These two fields together provide the complete billing picture: calleeBilling tells you which side pays, and billingMode tells you what type of account is charged. For example, calleeBilling = 0 with billingMode = 1 means the caller’s gateway account is charged.

❓ Why do I see billingMode = -1 for legitimate calls?

⚠️ If legitimate, connected calls appear with billingMode = -1, the most likely cause is a missing rate table entry for the destination number. When VOS3000 cannot find a matching rate in the account’s assigned rate table, it cannot calculate charges and assigns no billing mode. Other causes include incorrect gateway route prefix configuration that transforms the destination number into something that does not match any rate table entry, or a misconfigured account that lacks a rate table assignment. Audit your rate tables and prefix settings to resolve these issues.

❓ Is billingMode = 3 only for calling card services?

πŸ’³ Yes, billingMode = 3 is specifically designated for phone card (calling card) billing in the VOS3000 manual Β§4.4. This code only appears when calls are authenticated through the VOS3000 IVR calling card module using a PIN. If you do not operate a calling card service and see this code in your CDRs, it indicates a configuration error where a SIP account or gateway is incorrectly associated with the calling card billing system. Investigate and correct the account configuration to prevent billing misattribution.

❓ How do I filter CDRs by billing mode in VOS3000 client?

πŸ“Š In the VOS3000 client CDR query interface (documented in manual Β§2.7.2), you can filter records by billing mode through the query options. The “Billing mode” filter allows you to select specific modes (Phone, Gateway, Phone card) for display. Note that the client interface uses descriptive labels rather than numeric codes β€” “Phone” corresponds to mode 0, “Gateway” to mode 1, and “Phone card” to mode 3. For no-billing records (mode -1), use the illegal call recording filter or query the text file export directly.

πŸ“ž Need Expert Help with VOS3000 CDR Billing Mode Codes?

πŸ”§ Accurate interpretation of VOS3000 CDR billing mode codes is essential for billing accuracy, revenue protection, and operational intelligence. Whether you are investigating unexpected billingMode values, setting up revenue reports by billing type, or troubleshooting billing discrepancies, expert guidance ensures your analysis is correct and your billing configuration is airtight. πŸ’° VOS3000 CDR Billing Mode

πŸ’¬ WhatsApp: +8801911119966 β€” Get immediate assistance with VOS3000 CDR billing mode analysis, billing configuration, and revenue auditing. Our team specializes in VOS3000 billing system optimization, CDR analytics, and fraud detection. πŸ”§ VOS3000 CDR Billing Mode

πŸ”— Explore related VOS3000 billing and CDR configuration guides: VOS3000 CDR Billing Mode


πŸ“ž Need Professional VOS3000 Setup Support?

For professional VOS3000 installations and deployment, VOS3000 Server Rental Solution:

πŸ“± WhatsApp: +8801911119966
🌐 Website: www.vos3000.com
🌐 Blog: multahost.com/blog
πŸ“₯ Downloads: VOS3000 Downloads


VOS3000 CDR File Rotation, VOS3000 Real-Time CDR Forwarding, VOS3000 CDR Query Blackout, VOS3000 CDR Query Date Range, VOS3000 CDR Text File Export, VOS3000 CDR Pipe Format, VOS3000 CDR Billing Mode Codes, VOS3000 CDR End Direction CriticalVOS3000 CDR File Rotation, VOS3000 Real-Time CDR Forwarding, VOS3000 CDR Query Blackout, VOS3000 CDR Query Date Range, VOS3000 CDR Text File Export, VOS3000 CDR Pipe Format, VOS3000 CDR Billing Mode Codes, VOS3000 CDR End Direction CriticalVOS3000 CDR File Rotation, VOS3000 Real-Time CDR Forwarding, VOS3000 CDR Query Blackout, VOS3000 CDR Query Date Range, VOS3000 CDR Text File Export, VOS3000 CDR Pipe Format, VOS3000 CDR Billing Mode Codes, VOS3000 CDR End Direction Critical