VOS3000 Gateway Switch Limit, VOS3000 RTP Lock-In, VOS3000 Aggressive Gateway Failover, VOS3000 Busy Stop Switch, VOS3000 real-time gateway ASR, VOS3000 ASR Cost Routing, VOS3000 Prefix Mode Extension

VOS3000 Busy Stop Switch Reliable SS_GATEWAY_SWITCH_STOP_AFTER_USER_BUSY

VOS3000 Busy Stop Switch Reliable SS_GATEWAY_SWITCH_STOP_AFTER_USER_BUSY

๐Ÿšซ When a SIP 486 Busy Here response arrives from a gateway in VOS3000, it signals that the called party is genuinely occupied โ€” not that the gateway failed, the route was unreachable, or the call setup timed out. The called person is on another call, and no amount of trying alternative gateways will change that fact. Yet without the VOS3000 busy stop switch parameter, SS_GATEWAY_SWITCH_STOP_AFTER_USER_BUSY, the softswitch might continue switching to other gateways after receiving a busy signal, wasting system resources, inflating CPS load, and generating unnecessary failed CDR records for a call that was never going to complete. ๐Ÿ”ง

โš™๏ธ By default, SS_GATEWAY_SWITCH_STOP_AFTER_USER_BUSY is set to On, which means VOS3000 stops switching gateways immediately when it receives a busy signal (SIP 486 Busy Here or H.323 Release Complete with busy cause code). This is the correct and recommended setting for virtually all deployments because a busy signal indicates a genuine user-level condition, not a network or gateway problem. When the VOS3000 busy stop switch is Off, the softswitch ignores the busy signal and continues trying other gateways, which is wasteful because the called party is busy regardless of which gateway delivers the call. This parameter is independent of the SS_GATEWAY_SWITCH_UNTIL_CONNECT setting โ€” even when aggressive failover mode is enabled, a busy signal still stops the switching process. ๐Ÿ“Š

๐ŸŽฏ This guide provides a complete, manual-verified reference for the SS_GATEWAY_SWITCH_STOP_AFTER_USER_BUSY parameter. All parameter definitions are sourced from the official VOS3000 2.1.9.07 English manual ยง4.3.5.2 (page 236) and the gateway operation documentation, with detailed explanations of why busy stop switching is essential, how it saves resources, and when you might consider the rare scenario of disabling it. ๐Ÿ“˜

๐Ÿ” What Is the VOS3000 Busy Stop Switch?

๐Ÿ“‹ The VOS3000 busy stop switch mechanism is controlled by the system parameter SS_GATEWAY_SWITCH_STOP_AFTER_USER_BUSY, documented in the VOS3000 manual ยง4.3.5.2 (page 236) as “Callee busy stop switch.” The parameter determines whether VOS3000 should stop attempting gateway failover when a busy signal is received from the called party through a gateway.

๐Ÿ’ก Key characteristics of SS_GATEWAY_SWITCH_STOP_AFTER_USER_BUSY:

  • ๐Ÿ”ง Default value: On โ€” busy stop switch is enabled by default, which is the recommended setting
  • ๐Ÿ“ Configuration location: Operation management > Softswitch management > Additional settings > System parameter
  • ๐Ÿ”„ Per-gateway override: Yes โ€” can be set per routing gateway in “Additional settings > Callee busy stop switch”
  • ๐Ÿ“ก Trigger signal: SIP 486 Busy Here or H.323 Release Complete with user-busy cause code
  • ๐Ÿ›ก๏ธ Independence: NOT affected by SS_GATEWAY_SWITCH_UNTIL_CONNECT โ€” busy stop overrides aggressive mode
  • ๐Ÿ“‹ Also configurable per-gateway: Routing gateway > Additional settings > Callee busy stop switch

๐Ÿ“ The critical distinction: A busy signal (486) is fundamentally different from other call failure reasons. A timeout (408) means the gateway or destination did not respond โ€” trying another gateway makes sense. A service unavailable (503) means the gateway itself has a problem โ€” trying another gateway makes sense. But a busy signal (486) means the called person is on another call โ€” trying another gateway will not change the user’s busy status, because the busy condition exists at the endpoint, not at the gateway level. The VOS3000 busy stop switch recognizes this distinction and prevents wasteful switching after a genuine busy condition. Understanding this distinction is fundamental to VOS3000 busy stop switch configuration.

๐Ÿ“Š Why Continuing to Switch After Busy Wastes Resources

๐Ÿ’ฐ When the VOS3000 busy stop switch is disabled (Off), the softswitch treats a busy signal as just another failure reason and continues trying other gateways. This creates a cascade of wasteful activity for every busy call under the VOS3000 busy stop switch Off configuration, as illustrated in the following analysis:

Resource WastedWith Busy Stop OffWith Busy Stop On
๐Ÿ“Š Additional SIP INVITE attemptsN-1 extra INVITEs (N = available gateways)0 โ€” stops immediately on busy
๐Ÿ”„ CPS load per busy callMultiplied by number of gateways tried1 attempt only โ€” minimal CPS impact
๐Ÿ“‹ CDR records generated1 per gateway attempt โ€” all with 486 result1 CDR โ€” clean and accurate
๐Ÿ’พ Database loadNร— CDR inserts per busy call1 CDR insert per busy call
โฑ๏ธ Processing timeMultiple seconds per additional gatewayImmediate โ€” no wasted processing

๐Ÿšจ CPS inflation analysis: Consider a deployment with 5 routing gateways where 20% of calls receive a busy response. With the VOS3000 busy stop switch Off, every busy call generates up to 4 additional INVITE attempts (trying the remaining 4 gateways). At 100 calls per second with 20% busy rate, that is 20 busy calls ร— 4 extra INVITEs = 80 additional CPS load, on top of the normal 100 CPS. This 80% overhead is entirely wasted because none of those additional attempts will succeed โ€” the called party is busy regardless of the gateway. Enabling busy stop switch eliminates this wasted CPS entirely. For CPS capacity planning, see our capacity planning guide.

๐Ÿ“‹ SS_GATEWAY_SWITCH_STOP_AFTER_USER_BUSY Parameter Reference

AttributeDetail
๐Ÿ“Œ Parameter NameSS_GATEWAY_SWITCH_STOP_AFTER_USER_BUSY
๐Ÿ“ Manual DescriptionCallee busy stop switch (VOS3000 2.1.9.07 manual ยง4.3.5.2, page 236)
๐Ÿ”ง Default ValueOn
๐Ÿ“ Configuration PathOperation management > Softswitch management > Additional settings > System parameter
๐Ÿ”„ Per-Gateway OverrideYes โ€” Routing gateway > Additional settings > Callee busy stop switch
๐Ÿ“ก Trigger Signal (SIP)486 Busy Here
๐Ÿ“ก Trigger Signal (H.323)Release Complete with user-busy cause code (17)
๐Ÿ›ก๏ธ IndependenceNOT affected by SS_GATEWAY_SWITCH_UNTIL_CONNECT โ€” overrides aggressive mode

๐Ÿ”„ Busy Stop Switch and Aggressive Failover Independence

๐Ÿ”— One of the most important characteristics of the VOS3000 busy stop switch is its independence from the aggressive failover mode (SS_GATEWAY_SWITCH_UNTIL_CONNECT). The VOS3000 busy stop switch always takes priority over aggressive mode. The VOS3000 manual explicitly documents this independence: “This option is NOT affected by ‘Switch gateway until connect’. When ‘Switch gateway until connect’ is on, if received busy signal, stop switch gateway.”

SWITCH_UNTIL_CONNECTSTOP_AFTER_USER_BUSYBehavior on 486 Busy
OffOnโœ… Stops switching โ€” standard mode with busy protection
OnOnโœ… Stops switching โ€” busy stop overrides aggressive mode
OffOffโš ๏ธ Continues switching โ€” wastes resources on busy calls
OnOff๐Ÿ”ด Continues switching aggressively โ€” maximum waste on busy calls

๐Ÿ’ก Recommended configuration: Always keep SS_GATEWAY_SWITCH_STOP_AFTER_USER_BUSY = On, regardless of your SWITCH_UNTIL_CONNECT setting. The only exception is the extremely rare scenario where different gateways serve different endpoints with the same phone number (such as in a multi-site PBX with shared extensions), and a busy response from one site does not necessarily mean the extension is busy at all sites. Even in this case, the resource waste from continued switching should be carefully weighed against the potential benefit. For more on failover configuration, see our vendor failover setup guide.

๐Ÿ“Š Busy Stop Switch and CDR Recording Impact

๐Ÿ“‹ The VOS3000 busy stop switch directly affects the number and quality of CDR records generated for busy calls. When the VOS3000 busy stop switch is enabled, a single clean CDR is generated with the busy end reason. When disabled, multiple CDR records may be created โ€” one for each gateway that returns a busy response.

CDR AspectBusy Stop OnBusy Stop Off
๐Ÿ“Š CDR records per busy call1 โ€” clean single recordN โ€” one per gateway attempted
๐Ÿ“ Call end reason accuracy486 Busy โ€” accurate and clearMultiple 486 records โ€” confusing for analysis
๐Ÿ’พ Database storage impactMinimal โ€” 1 record per busy callInflated โ€” Nร— records per busy call
๐Ÿ“Š Reporting accuracyAccurate busy call countInflated call count โ€” each busy appears as N calls

๐Ÿ“Š Reporting impact: When the VOS3000 busy stop switch is Off, your CDR reports will show inflated call counts because each busy call generates multiple CDR records. A 486 Busy response from 4 different gateways looks like 4 separate failed calls in the CDR data, even though it was a single call attempt to a single busy endpoint. This distorts your ASR calculation, inflates your failure rate, and makes it difficult to determine the true number of busy calls versus actual call failures. The VOS3000 busy stop switch prevents this distortion and ensures accurate ASR calculations. For CDR analysis best practices, see our CDR analysis and billing guide.

๐Ÿ“‹ Busy Signal vs Other Failure Responses

๐Ÿ” Understanding why the VOS3000 busy stop switch treats 486 Busy differently from other failure responses requires a clear understanding of what each response means and whether trying another gateway could potentially succeed:

SIP ResponseMeaningCan Another Gateway Help?Busy Stop Applies?
486 Busy HereCalled party is on another callโŒ No โ€” user is busy regardless of gatewayโœ… Yes โ€” stops switching
408 Request TimeoutGateway or destination did not respondโœ… Yes โ€” different gateway may reach the destinationโŒ No โ€” not a busy condition
503 Service UnavailableGateway cannot process the callโœ… Yes โ€” another gateway may be operationalโŒ No โ€” not a busy condition
480 Temporarily UnavailableDestination temporarily unreachableโœ… Possibly โ€” different route may workโŒ No โ€” not a busy condition
487 Request TerminatedCall was cancelled or timed outโœ… Yes โ€” may succeed on retryโŒ No โ€” not a busy condition

๐Ÿ’ก Key takeaway: The VOS3000 busy stop switch only applies to the 486 Busy response (and its H.323 equivalent). This selective VOS3000 busy stop switch behavior is what makes the parameter so valuable โ€” it prevents wasteful switching only in the one scenario where switching cannot possibly help, while allowing normal failover for all other failure types. For a complete reference of SIP response codes in VOS3000, see our SIP response codes guide.

๐Ÿ›ก๏ธ Common Busy Stop Switch Problems and Solutions

โŒ Problem 1: Excessive Failed CDR Records for Busy Calls

๐Ÿ” Symptom: CDR records show multiple failed call attempts with 486 Busy result for what should be a single busy call, inflating the total call count and distorting ASR calculations.

๐Ÿ’ก Cause: SS_GATEWAY_SWITCH_STOP_AFTER_USER_BUSY is set to Off, allowing VOS3000 to continue trying other gateways after receiving a 486 Busy response.

โœ… Solutions:

  • ๐Ÿ”ง Set SS_GATEWAY_SWITCH_STOP_AFTER_USER_BUSY to On
  • ๐Ÿ“Š Clean up historical CDR data by filtering for duplicate busy records per call session
  • ๐Ÿ“‹ Verify the per-gateway “Callee busy stop switch” setting is also set to Default or On

โŒ Problem 2: Unusual CPS Spikes During Peak Hours

๐Ÿ” Symptom: CPS load on the VOS3000 softswitch increases disproportionately during peak hours, even though the actual call volume has not increased that much.

๐Ÿ’ก Cause: With busy stop switch disabled, the higher busy rate during peak hours (more people on calls) multiplies the CPS load because each busy call triggers additional gateway attempts. A 30% busy rate with 5 gateways means 30% of calls generate 4ร— extra INVITE traffic.

โœ… Solutions:

  • ๐Ÿ”ง Enable the VOS3000 busy stop switch immediately to eliminate wasted CPS
  • ๐Ÿ“Š Monitor CPS before and after the VOS3000 busy stop switch change to quantify the improvement
  • ๐Ÿ“‹ Review your CPS control settings to ensure proper capacity management

โŒ Problem 3: Distorted ASR Due to Multiple Busy Records

๐Ÿ” Symptom: Your ASR appears artificially low because CDR reports count each gateway attempt as a separate call. A single busy call that tried 4 gateways counts as 4 failed calls in the ASR calculation.

๐Ÿ’ก Cause: Without the busy stop switch, each gateway attempt generates its own CDR. When calculating ASR, the system counts all these records, making it appear that you have many more failed calls than you actually do.

โœ… Solutions:

  • ๐Ÿ”ง Enable SS_GATEWAY_SWITCH_STOP_AFTER_USER_BUSY = On to generate only one CDR per busy call under the VOS3000 busy stop switch
  • ๐Ÿ“Š Adjust your ASR reporting to deduplicate CDR records by call session ID if you cannot change the parameter immediately
  • ๐Ÿ“‹ Review your call end reasons analysis to identify the true busy call rate

๐Ÿ’ก VOS3000 Busy Stop Switch Best Practices

๐ŸŽฏ Follow these best practices for optimal busy stop switch configuration:

Best PracticeRecommendationReason
๐Ÿ”’ Always enable in productionSS_GATEWAY_SWITCH_STOP_AFTER_USER_BUSY = On๐Ÿ›ก๏ธ Prevents wasteful switching on genuine busy signals
๐Ÿ“Š Monitor busy call rateTrack percentage of 486 responses in CDR๐Ÿ“ˆ High busy rate may indicate capacity issues downstream
๐Ÿ”„ Pair with RTP lock-inSS_GATEWAY_SWITCH_STOP_AFTER_RTP_START = On๐Ÿ“ก Two independent stop conditions provide layered protection
๐Ÿ“‹ Set switch limit as safety netSS_GATEWAY_SWITCH_LIMIT = 3โ€“4๐Ÿ”ง Caps total attempts even if busy stop fails
๐Ÿšซ Never disable without justificationOnly disable if you have a documented multi-site PBX use case๐Ÿ“Š Disabling wastes resources and distorts reporting

โ“ Frequently Asked Questions

โ“ What is the default value of SS_GATEWAY_SWITCH_STOP_AFTER_USER_BUSY?

๐Ÿ”ง The default value is On, as documented in the VOS3000 2.1.9.07 manual ยง4.3.5.2 (page 236). This means that by default, VOS3000 stops switching gateways when a busy signal is received. The default of On reflects the correct design principle that a busy signal from the called party is a user-level condition that cannot be resolved by trying a different gateway. Leaving this parameter at its default value is strongly recommended for all production deployments.

โ“ Does the busy stop switch apply to H.323 calls?

๐Ÿ“ก Yes, the VOS3000 busy stop switch applies to both SIP and H.323 calls. For SIP calls, the VOS3000 busy stop switch trigger is a 486 Busy Here response. For H.323 calls, the VOS3000 busy stop switch trigger is a Release Complete message with Q.850 cause code 17 (user busy). The behavior is the same regardless of protocol: when a busy signal is received and the VOS3000 busy stop switch is enabled, VOS3000 stops trying additional gateways. This consistent behavior across protocols ensures that your failover strategy works correctly regardless of which signaling protocol your gateways use.

โ“ What happens if both busy stop and aggressive mode are enabled?

๐Ÿ”„ The busy stop switch takes priority over aggressive mode. The VOS3000 manual explicitly states: “This option is NOT affected by ‘Switch gateway until connect’. When ‘Switch gateway until connect’ is on, if received busy signal, stop switch gateway.” This means that even with aggressive failover enabled (SWITCH_UNTIL_CONNECT = On), a busy signal stops the switching process immediately. The VOS3000 busy stop switch overrides aggressive mode in all cases. The aggressive mode will continue trying gateways for other failure reasons (timeouts, 503 errors, etc.), but it will not continue after a 486 Busy response. This is the correct and expected behavior โ€” the VOS3000 busy stop switch should never be overridden by aggressive mode.

โ“ When would I ever disable the busy stop switch?

โš ๏ธ The only scenario where disabling the VOS3000 busy stop switch might be considered is when you have a multi-site PBX deployment where the same extension number exists at different physical locations, and each location is served by a different gateway. In this case, a busy response from one site’s gateway does not necessarily mean the extension is busy at all sites โ€” the same extension at another location might be available. However, this is an extremely rare deployment scenario, and even in this case, the resource waste from continued switching should be carefully weighed against the potential benefit. For 99% of VOS3000 deployments, the busy stop switch should remain enabled. For help with multi-site configurations, contact us via WhatsApp.

โ“ Does the busy stop switch affect calls that receive 480 Temporarily Unavailable?

๐Ÿ“‹ No, the VOS3000 busy stop switch only applies to 486 Busy Here responses (and the H.323 equivalent). A 480 Temporarily Unavailable response is treated as a normal failure condition that triggers standard failover behavior โ€” VOS3000 will try the next available gateway. The 480 response indicates a temporary condition (such as the destination being unregistered or a Do Not Disturb setting), which could potentially be resolved through a different gateway or route. The busy stop switch is specifically designed for the 486 response because a busy condition at the endpoint cannot be resolved by trying a different gateway. The VOS3000 busy stop switch ensures resources are not wasted on impossible completions.

โ“ How do I verify the busy stop switch is working correctly?

๐Ÿ“Š To verify the VOS3000 busy stop switch is working, call a number that you know will return a 486 Busy response (call a mobile phone that is currently on another call). Check the CDR for that call โ€” there should be exactly one CDR record with a busy end reason, not multiple records from different gateways. If you see multiple CDR records with 486 Busy result for the same call, the VOS3000 busy stop switch is not working correctly. Verify that SS_GATEWAY_SWITCH_STOP_AFTER_USER_BUSY is set to On in system parameters and that the per-gateway “Callee busy stop switch” is not set to Off for the gateways involved. For CDR verification methods, see our CDR analysis guide.

๐Ÿ“ž Need Expert Help with VOS3000 Busy Stop Switch?

๐Ÿ”ง Proper configuration of the VOS3000 busy stop switch is essential for efficient resource utilization, accurate CDR reporting, and correct ASR calculation. The VOS3000 busy stop switch is one of the most impactful failover parameters for operational efficiency. Whether you are troubleshooting inflated CPS load, cleaning up duplicate CDR records, or optimizing your failover strategy, expert guidance ensures your VOS3000 system operates efficiently and your billing data is accurate. ๐Ÿ“Š

๐Ÿ’ฌ WhatsApp: +8801911119966 โ€” Get immediate assistance with VOS3000 busy stop switch configuration, failover optimization, and CDR analysis. Our VOS3000 busy stop switch experts specialize in VOS3000 system tuning, resource optimization, and carrier-grade VoIP deployment. ๐Ÿ”ง

๐Ÿ”— Explore related VOS3000 failover and system configuration 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 Gateway Switch Limit, VOS3000 RTP Lock-In, VOS3000 Aggressive Gateway Failover, VOS3000 Busy Stop Switch, VOS3000 real-time gateway ASR, VOS3000 ASR Cost Routing, VOS3000 Prefix Mode ExtensionVOS3000 Gateway Switch Limit, VOS3000 RTP Lock-In, VOS3000 Aggressive Gateway Failover, VOS3000 Busy Stop Switch, VOS3000 real-time gateway ASR, VOS3000 ASR Cost Routing, VOS3000 Prefix Mode ExtensionVOS3000 Gateway Switch Limit, VOS3000 RTP Lock-In, VOS3000 Aggressive Gateway Failover, VOS3000 Busy Stop Switch, VOS3000 real-time gateway ASR, VOS3000 ASR Cost Routing, VOS3000 Prefix Mode Extension
VOS3000 Gateway Switch Limit, VOS3000 RTP Lock-In, VOS3000 Aggressive Gateway Failover, VOS3000 Busy Stop Switch, VOS3000 real-time gateway ASR, VOS3000 ASR Cost Routing, VOS3000 Prefix Mode Extension

VOS3000 Aggressive Gateway Failover Dynamic SS_GATEWAY_SWITCH_UNTIL_CONNECT

VOS3000 Aggressive Gateway Failover Dynamic SS_GATEWAY_SWITCH_UNTIL_CONNECT

๐Ÿ”„ In normal failover mode, VOS3000 stops trying additional gateways when it encounters certain conditions โ€” the call is ringing, a busy signal is received, or protocol-level stop conditions are met. But what if you want the softswitch to keep trying every available gateway until one actually connects the call? That is exactly what VOS3000 aggressive gateway failover mode does. Enabled by the SS_GATEWAY_SWITCH_UNTIL_CONNECT parameter, this mode instructs VOS3000 to continue switching gateways until it receives a connect signal (SIP 200 OK or H.323 Connect), maximizing the chance of call completion at the potential cost of longer post-dial delay. ๐Ÿ”ง

โš™๏ธ By default, SS_GATEWAY_SWITCH_UNTIL_CONNECT is set to Off, which means VOS3000 uses the standard failover behavior: it stops switching when the call reaches ringing state, receives a busy signal, encounters a no-answer condition, or meets protocol-level stop conditions. When you enable the VOS3000 aggressive gateway failover mode by setting this parameter to On, the softswitch overrides several of these stop conditions and keeps trying gateways until one returns a connect signal. The key difference is that in aggressive mode, even if a gateway returns a 180 Ringing response, VOS3000 may continue trying other gateways if the ringing times out without a 200 OK answer. ๐Ÿ“Š

๐ŸŽฏ This guide provides a complete, manual-verified reference for the SS_GATEWAY_SWITCH_UNTIL_CONNECT parameter. All parameter definitions are sourced from the official VOS3000 2.1.9.07 English manual ยง4.3.5.2 (page 236) and the gateway operation documentation, with detailed explanations of how the VOS3000 aggressive gateway failover works, when it improves ASR, when it hurts PDD, and how the VOS3000 aggressive gateway failover differs from the switch limit parameter. ๐Ÿ“˜

๐Ÿ” What Is VOS3000 Aggressive Gateway Failover?

๐Ÿ“‹ The VOS3000 aggressive gateway failover mode is controlled by the system parameter SS_GATEWAY_SWITCH_UNTIL_CONNECT, documented in the VOS3000 manual ยง4.3.5.2 (page 236) as “Switch Gateway Until Connect.” When enabled, this parameter changes the failover behavior from the standard conservative mode to an aggressive mode that continues attempting gateways until a connect signal is received.

๐Ÿ’ก Key characteristics of SS_GATEWAY_SWITCH_UNTIL_CONNECT:

  • ๐Ÿ”ง Default value: Off โ€” standard failover behavior applies by default
  • ๐Ÿ“ Configuration location: Operation management > Softswitch management > Additional settings > System parameter
  • ๐Ÿ”„ Per-gateway override: Yes โ€” can be set per routing gateway in “Additional settings > Switch gateway until connect”
  • ๐Ÿ“ก Protocol support: Affects both SIP (200 OK) and H.323 (Connect) connect signals
  • ๐Ÿ›ก๏ธ Override priority: Priors to protocol-level stop conditions (Stop switch after OLC, Stop switch after SDP)
  • ๐Ÿ“‹ Limits still apply: SS_GATEWAY_SWITCH_LIMIT, RTP lock-in, and busy stop override aggressive mode

๐Ÿ“Š Aggressive Mode vs Standard Mode Comparison

๐Ÿ”„ Understanding the behavioral difference between aggressive and standard failover modes is essential for making the right VOS3000 aggressive gateway failover configuration decision. The following table compares the two modes across all key failover conditions:

Failover ConditionStandard Mode (Off)Aggressive Mode (On)
๐Ÿ“ž 180 Ringing receivedStops switching โ€” call is ringing at destinationContinues switching until connect or timeout
๐Ÿšซ 486 Busy receivedStops switching โ€” user is busyStops switching โ€” busy stop overrides aggressive mode
๐Ÿ“ก RTP media starts flowingStops switching โ€” audio path establishedStops switching โ€” RTP lock-in overrides aggressive mode
โฑ๏ธ INVITE timeout (no response)Tries next gatewayTries next gateway (same behavior)
๐Ÿ“ž 200 OK / Connect receivedStops switching โ€” call connectedStops switching โ€” call connected (same behavior)
๐Ÿ”„ Switch limit reachedStops switching โ€” limit cap appliesStops switching โ€” limit cap still applies

๐Ÿ’ก Key insight: The primary difference between standard and aggressive mode is how each handles the ringing state. In standard mode, once VOS3000 receives a 180 Ringing response from a gateway, it stops switching because the call appears to be progressing. In aggressive mode, VOS3000 does not consider ringing as a stop condition โ€” it keeps trying other gateways until one actually connects with a 200 OK. This is the core behavioral change that the VOS3000 aggressive gateway failover mode introduces. For operators considering the VOS3000 aggressive gateway failover option, this ringing-state behavior is the key differentiator. For more on SIP call flow states, see our SIP call flow guide.

๐Ÿ“‹ SS_GATEWAY_SWITCH_UNTIL_CONNECT Parameter Reference

AttributeDetail
๐Ÿ“Œ Parameter NameSS_GATEWAY_SWITCH_UNTIL_CONNECT
๐Ÿ“ Manual DescriptionSwitch Gateway Until Connect (VOS3000 2.1.9.07 manual ยง4.3.5.2, page 236)
๐Ÿ”ง Default ValueOff
๐Ÿ“ Configuration PathOperation management > Softswitch management > Additional settings > System parameter
๐Ÿ”„ Per-Gateway OverrideYes โ€” Routing gateway > Additional settings > Switch gateway until connect
๐Ÿ“ก Connect Signal (SIP)200 OK
๐Ÿ“ก Connect Signal (H.323)Connect
๐Ÿ›ก๏ธ Override PriorityPriors to Protocol > Stop switch after OLC and Stop switch after receive SDP

๐Ÿ”„ How Aggressive Failover Differs from Switch Limit

๐Ÿ“Š A common point of confusion is the relationship between the VOS3000 aggressive gateway failover mode (SS_GATEWAY_SWITCH_UNTIL_CONNECT) and the gateway switch limit (SS_GATEWAY_SWITCH_LIMIT). The VOS3000 aggressive gateway failover and switch limit are two independent parameters that control different aspects of VOS3000 aggressive gateway failover behavior, and they work together rather than replacing each other.

AspectSWITCH_UNTIL_CONNECTSWITCH_LIMIT
๐Ÿ“‹ PurposeDefines when to stop switching (only on connect)Defines how many switch attempts are allowed
๐Ÿ”ง DefaultOff (standard mode)None (unlimited attempts)
๐Ÿ“Š Effect on ASRIncreases ASR by trying more gatewaysMay decrease ASR if set too low
โฑ๏ธ Effect on PDDIncreases PDD by extending switching windowDecreases PDD by capping attempts
๐Ÿ”„ InteractionAggressive mode still respects switch limit capSwitch limit caps total attempts regardless of mode

๐Ÿ’ก Recommended combination: For production deployments, the recommended configuration is SS_GATEWAY_SWITCH_UNTIL_CONNECT = On (aggressive mode) combined with SS_GATEWAY_SWITCH_LIMIT = 3โ€“4 (sensible cap). This gives you the best of both worlds: aggressive failover that keeps trying until a connect signal is received, but with a safety cap that prevents runaway switching if all gateways are having problems. Without the switch limit, the VOS3000 aggressive gateway failover mode could try every gateway in your routing table, creating unacceptably long PDD. For more on the switch limit parameter, see our routing optimization guide.

๐Ÿ“Š When Aggressive Mode Improves ASR

๐Ÿ“ˆ The VOS3000 aggressive gateway failover mode can significantly improve your Answer-Seizure Ratio in scenarios where gateways frequently return ringing responses but never complete the call. The VOS3000 aggressive gateway failover is particularly valuable in these deployment scenarios where aggressive mode provides the most ASR benefit:

ScenarioWhy Aggressive HelpsExpected ASR Gain
๐Ÿ”„ Unreliable downstream carriersCarriers that ring but never answer get bypassed5โ€“15% ASR improvement
๐Ÿ“ž Multiple termination providersFastest-connecting provider wins the call3โ€“10% ASR improvement
๐ŸŒ International routes with variable qualityRoutes that ring without answer are quickly skipped10โ€“20% ASR improvement
๐Ÿ”ง New untested gateway routesUnknown quality routes are tried with fallback readyVariable โ€” depends on route quality

๐Ÿ“Š ASR measurement tip: Before and after enabling VOS3000 aggressive gateway failover, measure your ASR over the same time period and traffic volume to quantify the improvement. Use the ASR ACD analysis tools in VOS3000 to track the metric. Pay attention to ASR by destination and by gateway, as aggressive mode may improve ASR for some routes while having no effect on others. Also monitor PDD alongside ASR โ€” the goal is to find the sweet spot where ASR gains outweigh PDD costs.

โฑ๏ธ When Aggressive Mode Hurts PDD

๐Ÿšจ While the VOS3000 aggressive gateway failover mode can improve ASR, it comes with a PDD cost that must be managed. Every additional gateway switch attempt under the VOS3000 aggressive gateway failover mode adds signaling delay before the call connects. In scenarios where the first gateway would have connected the call (just with a slightly longer ring time), aggressive mode wastes time by trying additional gateways unnecessarily.

ScenarioWhy Aggressive HurtsPDD Impact
๐Ÿ“ž Reliable gateways with slow answerGateway would have connected โ€” aggressive mode wastes time on alternates๐Ÿ”ด +5โ€“15 seconds unnecessary delay
๐Ÿข Retail callers expecting fast connectionRetail users are PDD-sensitive and may hang up๐Ÿ”ด Caller abandonment increases
๐Ÿ’ณ Calling card servicesCard users hear silence during switching attempts๐Ÿ”ด Card user frustration and perceived service failure
๐Ÿ“Š High-volume traffic periodsAggressive switching increases CPS load during peak๐Ÿ”ด System overload potential

๐Ÿ’ก Mitigation strategy: Always pair the VOS3000 aggressive gateway failover mode with a reasonable SS_GATEWAY_SWITCH_LIMIT and appropriate SIP timeout settings. The combination of VOS3000 aggressive gateway failover mode + switch limit gives you the ASR benefit while bounding the PDD cost. Additionally, use per-gateway configuration to enable aggressive mode only on the gateways and routes where it provides measurable ASR improvement, rather than enabling it system-wide. For more on PDD optimization, see our SIP call progress timeout guide.

๐Ÿ›ก๏ธ Common Aggressive Failover Problems and Solutions

โŒ Problem 1: Increased PDD Without ASR Improvement

๐Ÿ” Symptom: After enabling SS_GATEWAY_SWITCH_UNTIL_CONNECT, PDD increases significantly but ASR does not improve, suggesting the aggressive switching is not finding additional connected calls.

๐Ÿ’ก Cause: The gateways in the routing pool are all similarly reliable (or all similarly unreliable). Aggressive switching only helps when some gateways connect while others ring without answer. If all gateways behave the same way, switching between them just adds delay without benefit.

โœ… Solutions:

  • ๐Ÿ“Š Analyze CDR data by gateway to identify which gateways connect and which ring without answer
  • ๐Ÿ”ง Use per-gateway aggressive mode โ€” enable only for routes with mixed gateway quality
  • ๐Ÿ“‹ Set SS_GATEWAY_SWITCH_LIMIT to 2โ€“3 to cap the PDD impact

โŒ Problem 2: Double Ringing or Multiple Call Legs

๐Ÿ” Symptom: The called party’s phone rings multiple times or the callee sees multiple incoming calls from the same caller.

๐Ÿ’ก Cause: In aggressive mode, VOS3000 may send INVITE to a second gateway while the first gateway is still ringing the destination. If both gateways reach the same endpoint, the phone rings twice. This is particularly problematic in mobile networks where the same destination may be reachable through multiple gateways.

โœ… Solutions:

  • ๐Ÿ”ง Enable SS_GATEWAY_SWITCH_STOP_AFTER_RTP_START = On to lock in once media flows
  • ๐Ÿ“Š Configure proper gateway prefix settings to avoid duplicate routes โ€” see prefix settings guide
  • ๐Ÿ”„ Reduce the ringing timeout (SS_SIP_TIMEOUT_RINGING) to minimize the overlap window

โŒ Problem 3: CPS Overload with Aggressive Mode

๐Ÿ” Symptom: System CPS (calls per second) increases significantly after enabling aggressive failover, causing performance problems during peak hours.

๐Ÿ’ก Cause: Each failed gateway attempt generates a complete SIP INVITE transaction. In aggressive mode, every call that does not connect on the first attempt generates additional INVITE attempts, multiplying the signaling load.

โœ… Solutions:

  • ๐Ÿ”ง Set SS_GATEWAY_SWITCH_LIMIT to 3โ€“4 to bound the maximum CPS multiplier per call
  • ๐Ÿ“Š Monitor system capacity planning metrics during peak hours
  • ๐Ÿ”„ Consider enabling aggressive mode only during off-peak hours or only for specific routes

๐Ÿ’ก Aggressive Gateway Failover Best Practices

๐ŸŽฏ Follow these best practices to maximize the ASR benefit of VOS3000 aggressive gateway failover while minimizing the PDD cost. Proper VOS3000 aggressive gateway failover deployment requires careful attention to these guidelines:

Best PracticeRecommendationReason
๐Ÿ“Š Always pair with switch limitSet SS_GATEWAY_SWITCH_LIMIT = 3โ€“4๐Ÿ”ง Bounds PDD while preserving ASR benefit
๐Ÿ”’ Keep RTP lock-in enabledSS_GATEWAY_SWITCH_STOP_AFTER_RTP_START = On๐Ÿ›ก๏ธ Prevents one-way audio โ€” overrides aggressive mode
๐Ÿšซ Keep busy stop enabledSS_GATEWAY_SWITCH_STOP_AFTER_USER_BUSY = On๐Ÿ“Š Prevents wasteful switching after genuine busy
๐Ÿ”ง Use per-gateway configurationEnable aggressive mode only on routes that benefit๐Ÿ“‹ Avoids unnecessary PDD on reliable routes
๐Ÿ“Š Measure before and afterCompare ASR and PDD metrics before enabling๐Ÿ“ˆ Data-driven decision making

โ“ Frequently Asked Questions

โ“ What is the default value of SS_GATEWAY_SWITCH_UNTIL_CONNECT?

๐Ÿ”ง The default value is Off, as documented in the VOS3000 2.1.9.07 manual ยง4.3.5.2 (page 236). This means that by default, VOS3000 uses standard failover behavior: it stops switching when the call reaches ringing state, receives a busy signal, or encounters a no-answer condition. The Off default is the conservative choice that prioritizes lower PDD over higher ASR. You should only enable the VOS3000 aggressive gateway failover mode after analyzing your traffic patterns and determining that the ASR improvement justifies the potential PDD increase. The VOS3000 aggressive gateway failover decision should always be data-driven.

โ“ Does aggressive mode override the RTP lock-in stop condition?

๐Ÿ›ก๏ธ No, the VOS3000 manual explicitly states: “This option is NOT affected by ‘Switch gateway until connect’. When ‘Switch gateway until connect’ is on, if received RTP packet, stop switch gateway.” This means that even in aggressive mode, if RTP media starts flowing, VOS3000 stops switching immediately. The RTP lock-in failover (SS_GATEWAY_SWITCH_STOP_AFTER_RTP_START) always takes priority over aggressive mode. This is a critical safety mechanism that prevents one-way audio and ghost calls, regardless of the failover mode you select. For more details, see our RTP media proxy guide.

โ“ Does aggressive mode override the busy stop condition?

๐Ÿšซ No, the VOS3000 manual states: “When ‘Switch gateway until connect’ is on, if received busy signal, stop switch gateway.” The busy stop switch (SS_GATEWAY_SWITCH_STOP_AFTER_USER_BUSY) is independent of the VOS3000 aggressive gateway failover setting. When a 486 Busy Here response is received, VOS3000 stops switching regardless of whether VOS3000 aggressive gateway failover is On or Off. This is because a busy signal indicates the called party is genuinely unavailable โ€” trying other gateways will not change the user’s busy status and would only waste system resources and inflate CPS.

โ“ When should I use aggressive gateway failover?

๐Ÿ“Š You should consider enabling VOS3000 aggressive gateway failover when you have multiple routing gateways for the same destination and some of them consistently ring without connecting. The VOS3000 aggressive gateway failover is particularly valuable for wholesale termination with multiple carrier routes, international traffic with variable quality paths, and scenarios where ASR improvement is more valuable than PDD optimization. You should avoid aggressive mode for retail operations where callers are PDD-sensitive, calling card services where silence during switching frustrates users, and deployments where all gateways have similar quality (no ASR benefit from switching). Always measure ASR and PDD before and after enabling aggressive mode to verify the benefit. Use the gateway analysis reports for data-driven decision making.

โ“ Can I enable aggressive mode for specific gateways only?

๐Ÿ”ง Yes, VOS3000 supports per-gateway configuration of the VOS3000 aggressive gateway failover mode. In the routing gateway’s “Additional settings” panel, you can set “Switch gateway until connect” to On, Off, or Default (which inherits the system parameter value). This per-gateway override allows you to enable aggressive mode only on the gateways and routes where it provides measurable benefit, while keeping standard mode on reliable routes where it would only add unnecessary PDD. This granular control is the recommended approach for production deployments.

โ“ How does aggressive mode affect H.323 calls?

๐Ÿ“ก For H.323 calls, the VOS3000 aggressive gateway failover mode works identically to SIP โ€” the softswitch continues switching gateways until it receives an H.323 Connect message. The H.323 equivalent of SIP 180 Ringing is the Alerting message, and in aggressive mode, receiving an Alerting does not stop the switching process. The softswitch will continue trying other gateways until one returns a Connect message. The same overrides apply under VOS3000 aggressive gateway failover: RTP lock-in and busy stop conditions still take priority over the VOS3000 aggressive gateway failover mode for H.323 calls. For H.323-specific parameters, see the VOS3000 system parameters reference.

๐Ÿ“ž Need Expert Help with VOS3000 Aggressive Gateway Failover?

๐Ÿ”ง Configuring the VOS3000 aggressive gateway failover mode requires careful balancing between call completion rates and post-dial delay performance. The VOS3000 aggressive gateway failover setting is one of the most impactful parameters in your failover strategy. Whether you are evaluating whether aggressive mode will improve your ASR, configuring per-gateway failover settings, or troubleshooting PDD issues after enabling aggressive switching, expert guidance ensures your VOS3000 system achieves the optimal balance for your business requirements. ๐Ÿ“Š

๐Ÿ’ฌ WhatsApp: +8801911119966 โ€” Get immediate assistance with VOS3000 aggressive gateway failover configuration, ASR optimization, and PDD tuning. Our team specializes in VOS3000 failover strategy design, routing quality analysis, and carrier-grade VoIP performance optimization. ๐Ÿ”ง

๐Ÿ”— Explore related VOS3000 failover and routing configuration 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 Gateway Switch Limit, VOS3000 RTP Lock-In, VOS3000 Aggressive Gateway Failover, VOS3000 Busy Stop Switch, VOS3000 real-time gateway ASR, VOS3000 ASR Cost Routing, VOS3000 Prefix Mode ExtensionVOS3000 Gateway Switch Limit, VOS3000 RTP Lock-In, VOS3000 Aggressive Gateway Failover, VOS3000 Busy Stop Switch, VOS3000 real-time gateway ASR, VOS3000 ASR Cost Routing, VOS3000 Prefix Mode ExtensionVOS3000 Gateway Switch Limit, VOS3000 RTP Lock-In, VOS3000 Aggressive Gateway Failover, VOS3000 Busy Stop Switch, VOS3000 real-time gateway ASR, VOS3000 ASR Cost Routing, VOS3000 Prefix Mode Extension
VOS3000 Gateway Switch Limit, VOS3000 RTP Lock-In, VOS3000 Aggressive Gateway Failover, VOS3000 Busy Stop Switch, VOS3000 real-time gateway ASR, VOS3000 ASR Cost Routing, VOS3000 Prefix Mode Extension

VOS3000 RTP Lock-In Failover Robust SS_GATEWAY_SWITCH_STOP_AFTER_RTP_START

VOS3000 RTP Lock-In Failover Robust SS_GATEWAY_SWITCH_STOP_AFTER_RTP_START

๐Ÿ“ก The moment RTP media packets start flowing between a caller and a gateway in VOS3000, the audio path is established and the conversation is live. Switching to a different gateway after that point is one of the most dangerous misconfigurations in VoIP operations โ€” it tears down the established media path, creating one-way audio, ghost calls, and corrupted billing records. The VOS3000 RTP lock-in failover parameter, SS_GATEWAY_SWITCH_STOP_AFTER_RTP_START, is the critical safeguard that prevents this catastrophe by locking the selected gateway once RTP packets are detected. Understanding and correctly configuring this parameter is essential for any production VOS3000 deployment. ๐Ÿ”’

โš™๏ธ By default, SS_GATEWAY_SWITCH_STOP_AFTER_RTP_START is set to On, which means VOS3000 will stop switching gateways as soon as it detects RTP packets flowing through the media proxy. This is the correct and recommended setting for virtually all deployments. When this parameter is Off, VOS3000 may continue trying other gateways even after the audio path is established, which can result in the caller hearing silence while the callee continues speaking into a dead media stream. The VOS3000 RTP lock-in failover mechanism ensures that once audio is flowing, the call stays on the current gateway regardless of other failover conditions. ๐Ÿ›ก๏ธ

๐ŸŽฏ This guide provides a complete, manual-verified reference for the SS_GATEWAY_SWITCH_STOP_AFTER_RTP_START parameter. All parameter definitions are sourced from the official VOS3000 2.1.9.07 English manual ยง4.3.5.2 (page 236) and the gateway settings documentation, with detailed explanations of how RTP lock-in works, why it overrides other failover parameters, and how to troubleshoot one-way audio caused by incorrect settings. ๐Ÿ“˜

๐Ÿ” What Is VOS3000 RTP Lock-In Failover?

๐Ÿ“‹ The VOS3000 RTP lock-in failover mechanism is controlled by the system parameter SS_GATEWAY_SWITCH_STOP_AFTER_RTP_START, documented in the VOS3000 manual ยง4.3.5.2 (page 236) as “Stop Switch Gateway when RTP Start.” The parameter determines whether VOS3000 should stop attempting gateway failover once RTP media packets are detected flowing through the media proxy for a call.

๐Ÿ’ก Key characteristics of SS_GATEWAY_SWITCH_STOP_AFTER_RTP_START:

  • ๐Ÿ”ง Default value: On โ€” RTP lock-in is enabled by default, which is the recommended production setting
  • ๐Ÿ“ Configuration location: Operation management > Softswitch management > Additional settings > System parameter
  • ๐Ÿ“ก Prerequisite: Only effective when media proxy is enabled โ€” RTP detection requires the media proxy to observe RTP packet flow
  • ๐Ÿ”„ Override behavior: Takes priority over “Protocol > Stop switch gateway after olc” and “Stop switch gateway after receive SDP”
  • ๐Ÿ›ก๏ธ Independence: NOT affected by SS_GATEWAY_SWITCH_UNTIL_CONNECT โ€” even aggressive mode stops on RTP
  • ๐Ÿ“‹ Per-gateway override: Can also be configured per routing gateway in “Additional settings > Stop switch gateway when rtp start”

๐Ÿ“ How RTP detection works: When media proxy is enabled for a call, VOS3000 proxies the RTP media stream between the caller and the gateway. The media proxy can detect when RTP packets start flowing from the gateway side. This detection is the trigger for the RTP lock-in โ€” once RTP is observed, the softswitch knows that the audio path is established and that switching gateways would disrupt the conversation.

๐Ÿ“Š Why Switching After RTP Causes One-Way Audio

๐Ÿ”‡ Understanding why the VOS3000 RTP lock-in failover mechanism is so important requires understanding what happens when the VOS3000 RTP lock-in failover safeguard is disabled and a gateway switch occurs after RTP media has started flowing. When VOS3000 decides to switch to a different gateway, it tears down the current call leg and establishes a new one with the next gateway. If RTP was already flowing on the old leg, the audio path is destroyed in the process.

ProblemCauseImpact
๐Ÿ”‡ One-way audioRTP stream torn down on old gateway, new gateway not yet established๐Ÿ”ด Caller or callee hears silence while the other side can still speak
๐Ÿ‘ป Ghost callsOld gateway continues RTP without SIP control channel๐Ÿ”ด Callee continues conversation with no one on the line
๐Ÿ’ฐ Billing corruptionCDR records split across two gateways for one conversation๐Ÿ”ด Double billing or missing billing for partial call segments
๐Ÿ“Š Media resource wasteOld RTP stream not properly terminated on switch๐Ÿ”ด Media proxy port held open, reducing available capacity

๐Ÿšจ The one-way audio cascade: When RTP is flowing and a gateway switch occurs, the SIP signaling is redirected to the new gateway, but the RTP stream on the old gateway may continue for several seconds before timing out. During this window, the callee may still be speaking into the old RTP stream (which goes nowhere), while the new gateway has not yet established its own media path. The result is one-way audio that is extremely confusing for both parties and often leads to immediate call hangup. For more on one-way audio troubleshooting, see our VOS3000 one-way audio fix guide.

๐Ÿ“‹ SS_GATEWAY_SWITCH_STOP_AFTER_RTP_START Parameter Reference

AttributeDetail
๐Ÿ“Œ Parameter NameSS_GATEWAY_SWITCH_STOP_AFTER_RTP_START
๐Ÿ“ Manual DescriptionStop Switch Gateway when RTP Start (VOS3000 2.1.9.07 manual ยง4.3.5.2, page 236)
๐Ÿ”ง Default ValueOn
๐Ÿ“ Configuration PathOperation management > Softswitch management > Additional settings > System parameter
๐Ÿ”„ Per-Gateway OverrideYes โ€” Routing gateway > Additional settings > Stop switch gateway when rtp start
๐Ÿ“ก PrerequisiteMedia proxy must be enabled for RTP detection
๐Ÿ›ก๏ธ PriorityOverrides Protocol-level stop settings; NOT affected by SWITCH_UNTIL_CONNECT

๐Ÿ”„ RTP Lock-In and Its Override Priority

๐Ÿ”— One of the most important aspects of the VOS3000 RTP lock-in failover mechanism is its priority relationship with other failover parameters. The VOS3000 RTP lock-in failover always takes the highest priority in the failover control chain. The VOS3000 manual explicitly states the priority hierarchy, and understanding it is critical for designing a correct failover strategy.

Priority LevelParameter / SettingBehavior
1๏ธโƒฃ HighestSS_GATEWAY_SWITCH_STOP_AFTER_RTP_START (On)Stops ALL switching once RTP detected โ€” overrides everything
2๏ธโƒฃ HighSS_GATEWAY_SWITCH_STOP_AFTER_USER_BUSY (On)Stops switching on 486 Busy โ€” independent of UNTIL_CONNECT
3๏ธโƒฃ MediumProtocol > Stop switch after OLC / Stop switch after SDPPer-protocol stop conditions โ€” overridden by RTP lock-in
4๏ธโƒฃ BaseSS_GATEWAY_SWITCH_UNTIL_CONNECTAggressive mode โ€” still stops on RTP when lock-in is On
5๏ธโƒฃ CeilingSS_GATEWAY_SWITCH_LIMITMaximum attempt cap โ€” still stops on RTP when lock-in is On

๐Ÿ’ก Critical manual note: The VOS3000 2.1.9.07 manual explicitly states: “This option priors to ‘Protocol > Stop switch gateway after olc’ and ‘Stop switch gateway after receive sdp’.” And: “This option is NOT affected by ‘Switch gateway until connect’. When ‘Switch gateway until connect’ is on, if received RTP packet, stop switch gateway.” This means that even when you enable aggressive failover (SWITCH_UNTIL_CONNECT = On), the RTP lock-in still takes effect. Once RTP flows, no more switching โ€” period. This design ensures that audio integrity is never sacrificed for the sake of trying more gateways. For more on the aggressive failover mode, see our VOS3000 call routing guide.

๐Ÿ“Š RTP Lock-In and Media Proxy Dependency

๐Ÿ“ก The VOS3000 RTP lock-in failover mechanism depends on the media proxy being active for the call. Without media proxy, the VOS3000 RTP lock-in failover cannot detect RTP packet flow and therefore cannot enforce the lock-in condition. When media proxy is disabled, VOS3000 does not observe the RTP stream between the caller and gateway, and therefore cannot detect when RTP starts flowing. In this case, the SS_GATEWAY_SWITCH_STOP_AFTER_RTP_START parameter has no effect because the softswitch has no visibility into the media plane.

Media Proxy ModeRTP Lock-In Effective?Implication
Auto (default)โœ… Yes โ€” when proxy is activated for NAT traversalRTP lock-in works for proxied calls; direct RTP calls bypass detection
Always Onโœ… Yes โ€” all calls go through media proxyRTP lock-in protects every call โ€” most secure configuration
OffโŒ No โ€” no RTP observation possibleRTP lock-in parameter has no effect โ€” rely on protocol-level stops only
Behind NAT onlyโœ… Partial โ€” only for NAT-traversed callsDirect-network calls are not protected by RTP lock-in

๐Ÿ”ง Configuration recommendation: For production deployments where call quality is paramount, set the media proxy mode to “Auto” or “Always On” to ensure the VOS3000 RTP lock-in failover mechanism can detect RTP flow and prevent post-media switching. The VOS3000 RTP lock-in failover protection is only as reliable as your media proxy configuration. When media proxy is Off, you must rely on the protocol-level stop conditions (Stop switch after OLC for H.323, Stop switch after SDP for SIP) which are less reliable because they detect signaling state rather than actual media flow. For comprehensive media proxy configuration, see our VOS3000 RTP media guide.

๐Ÿ“‹ Per-Gateway RTP Lock-In Configuration

๐Ÿ”ง In addition to the system-level SS_GATEWAY_SWITCH_STOP_AFTER_RTP_START parameter, VOS3000 allows you to configure VOS3000 RTP lock-in failover behavior on a per-gateway basis through the routing gateway’s Additional settings panel. The per-gateway VOS3000 RTP lock-in failover setting defaults to the system parameter value, but can be overridden for individual gateways.

Setting LevelConfiguration LocationPriority
๐ŸŒ System defaultSoftswitch management > Additional settings > System parameter > SS_GATEWAY_SWITCH_STOP_AFTER_RTP_STARTBase โ€” applies to all gateways without per-gateway override
๐Ÿ“ก Per-gateway overrideRouting gateway > Additional settings > Stop switch gateway when rtp startOverrides system default for this specific gateway

๐Ÿ’ก When to use per-gateway override: Most deployments should keep the system default (On) and not override it per gateway. However, there is one scenario where a per-gateway override might be considered: test gateways that are known to send premature RTP (such as early media before connect) in specific debugging scenarios.

Even in this case, disabling RTP lock-in is risky and should only be done in a controlled lab environment. In production, the VOS3000 RTP lock-in failover should always be enabled for every gateway. Disabling the VOS3000 RTP lock-in failover on any production gateway risks one-way audio whenever failover occurs after media establishment. The VOS3000 RTP lock-in failover should always remain On in production for every gateway. For more on gateway-level settings, see our VOS3000 gateway config FAQ.

๐Ÿ›ก๏ธ Common RTP Lock-In Problems and Solutions

โŒ Problem 1: One-way audio after a gateway switch is the primary symptom of a disabled or malfunctioning VOS3000 RTP lock-in failover.

๐Ÿ” Symptom: Callers report that they can hear the other party but cannot be heard, or vice versa. This typically happens intermittently and may correlate with failover events.

๐Ÿ’ก Cause: SS_GATEWAY_SWITCH_STOP_AFTER_RTP_START is set to Off, allowing VOS3000 to switch gateways after RTP media has started flowing. When the VOS3000 RTP lock-in failover is disabled, the switch occurs, the old media path is torn down but the new one may not be fully established, resulting in one-way audio.

โœ… Solutions:

  • ๐Ÿ”ง Set SS_GATEWAY_SWITCH_STOP_AFTER_RTP_START to On immediately
  • ๐Ÿ“ก Verify media proxy is enabled (Auto or Always On mode)
  • ๐Ÿ“Š Check CDR records for calls with short duration and call end reasons that indicate switching events

โŒ Problem 2: Ghost Calls on Terminating Side

๐Ÿ” Symptom: The callee picks up the phone and starts talking, but the caller is no longer on the line because VOS3000 switched to a different gateway. The callee’s phone shows an active call but there is no audio from the caller side.

๐Ÿ’ก Cause: When VOS3000 switches gateways after RTP has started, the SIP BYE message may not reach the old gateway immediately (or at all), leaving the old media stream active on the terminating side while the originating side has moved to a new gateway.

โœ… Solutions:

  • ๐Ÿ”’ Enable the VOS3000 RTP lock-in failover immediately (SS_GATEWAY_SWITCH_STOP_AFTER_RTP_START = On)
  • ๐Ÿ›ก๏ธ Ensure media proxy properly terminates old RTP streams on any VOS3000 RTP lock-in failover switch event
  • ๐Ÿ“Š Monitor for ghost call patterns using zero-duration CDR analysis

โŒ Problem 3: RTP Lock-In Not Taking Effect

๐Ÿ” Symptom: SS_GATEWAY_SWITCH_STOP_AFTER_RTP_START is set to On, but gateway switching still occurs after RTP starts, causing audio problems.

๐Ÿ’ก Cause: The media proxy is not enabled for the affected calls. Without media proxy, VOS3000 cannot detect RTP packet flow, so the VOS3000 RTP lock-in failover condition never triggers. This commonly happens when media proxy mode is set to “Off” or when specific calls bypass the media proxy due to network configuration.

โœ… Solutions:

  • ๐Ÿ”ง Check SS_MEDIA_PROXY_MODE setting โ€” should be “Auto” or “Always On”
  • ๐Ÿ“Š Verify that the affected calls are actually going through the media proxy
  • ๐Ÿ“ก Review the RTP media proxy configuration for any bypass conditions

๐Ÿ’ก VOS3000 RTP Lock-In Failover Best Practices

๐ŸŽฏ Follow these best practices to ensure robust call quality through proper VOS3000 RTP lock-in failover configuration:

Best PracticeRecommendationReason
๐Ÿ”’ Always enable in productionSS_GATEWAY_SWITCH_STOP_AFTER_RTP_START = On๐Ÿ›ก๏ธ Prevents one-way audio and ghost calls from post-RTP switching
๐Ÿ“ก Enable media proxySet SS_MEDIA_PROXY_MODE to Auto or Always On๐Ÿ”ง RTP lock-in requires media proxy for RTP detection
๐Ÿšซ Never disable for individual gatewaysKeep per-gateway “Stop switch when rtp start” = Default or On๐Ÿ“Š Consistent protection across all routing paths
๐Ÿ“‹ Pair with busy stop switchSS_GATEWAY_SWITCH_STOP_AFTER_USER_BUSY = On๐Ÿ”„ Two independent stop conditions provide layered protection
๐Ÿงช Test before changingOnly modify in lab if you must test Off behavior๐Ÿšจ Disabling RTP lock-in in production causes immediate audio problems

โ“ Frequently Asked Questions

โ“ What is the default value of SS_GATEWAY_SWITCH_STOP_AFTER_RTP_START?

๐Ÿ”ง The default value is On, as documented in the VOS3000 2.1.9.07 manual ยง4.3.5.2 (page 236). This means that by default, VOS3000 will stop switching gateways once RTP media packets are detected flowing through the media proxy. This is the correct and recommended setting for all production deployments. The default of On reflects the VOS3000 design philosophy that audio integrity should never be sacrificed for additional failover attempts. The VOS3000 RTP lock-in failover is a cornerstone of this philosophy.

โ“ Does RTP lock-in work without media proxy?

๐Ÿ“ก No, the VOS3000 RTP lock-in failover mechanism requires the media proxy to be active for the call. Without media proxy, VOS3000 has no visibility into the RTP media stream and cannot detect when RTP starts flowing. In this scenario, SS_GATEWAY_SWITCH_STOP_AFTER_RTP_START has no effect because the detection trigger (RTP packet observation) never fires. If you must run without media proxy, rely on the protocol-level stop conditions instead: “Stop switch gateway after OLC” for H.323 and “Stop switch gateway after receive SDP” for SIP, which detect the signaling indication of media negotiation rather than actual RTP flow. See the RTP media proxy guide for detailed media proxy configuration.

โ“ Does RTP lock-in override SS_GATEWAY_SWITCH_UNTIL_CONNECT?

๐Ÿ”„ Yes, the VOS3000 manual explicitly states: “This option is NOT affected by ‘Switch gateway until connect’. When ‘Switch gateway until connect’ is on, if received RTP packet, stop switch gateway.” This means that even when you enable aggressive failover mode (SWITCH_UNTIL_CONNECT = On), the RTP lock-in still takes priority. The VOS3000 RTP lock-in failover is absolute once RTP media is flowing, the call stays on the current gateway โ€” aggressive mode cannot override the VOS3000 RTP lock-in failover. This is a deliberate safety design to prevent the catastrophic audio problems that would result from switching after media establishment.

โ“ What is the difference between RTP lock-in and SDP stop?

๐Ÿ“‹ RTP lock-in (SS_GATEWAY_SWITCH_STOP_AFTER_RTP_START) detects actual RTP media packets flowing through the media proxy. SDP stop (SS_SIP_STOP_SWITCH_AFTER_SDP) detects the SIP signaling indication that media negotiation has completed (the presence of SDP in a response). RTP lock-in is more reliable because it confirms that media is actually flowing, not just that the signaling has negotiated a media path. The VOS3000 manual states that the VOS3000 RTP lock-in failover “priors to” the protocol-level SDP stop, meaning VOS3000 RTP lock-in failover takes higher priority when both conditions are present. For SIP-specific stop configuration, see our SIP session guide.

โ“ Can I disable RTP lock-in for testing purposes?

๐Ÿงช Technically yes, you can set SS_GATEWAY_SWITCH_STOP_AFTER_RTP_START to Off, but this should only be done in a controlled lab environment for specific testing scenarios. Disabling the VOS3000 RTP lock-in failover in production will cause one-way audio and ghost calls whenever a gateway switch occurs after media establishment. The VOS3000 RTP lock-in failover should never be disabled on live systems. If you need to test failover behavior without RTP lock-in, do so on a dedicated test system with no production traffic, and re-enable it immediately after testing. Never disable this parameter on a production VOS3000 system that handles live calls.

โ“ How do I verify RTP lock-in is working correctly?

๐Ÿ“Š To verify the VOS3000 RTP lock-in failover is working, check the following: (1) Confirm SS_GATEWAY_SWITCH_STOP_AFTER_RTP_START is set to On in system parameters. (2) Verify media proxy mode is Auto or Always On. (3) Place a test call through a gateway and observe the CDR โ€” there should be no gateway switching events after the call is connected and RTP is flowing. (4) Check the softswitch logs for any “switch gateway” events that occur after RTP start โ€” if none are found, the VOS3000 RTP lock-in failover is working correctly. You can also use the VOS3000 debug trace feature for detailed signaling and media analysis.

๐Ÿ“ž Need Expert Help with VOS3000 RTP Lock-In Failover?

๐Ÿ”ง Correct configuration of the VOS3000 RTP lock-in failover parameter is critical for preventing one-way audio, ghost calls, and billing corruption in your VoIP deployment. The VOS3000 RTP lock-in failover mechanism is one of the most important safeguards in the VOS3000 failover system. Whether you are troubleshooting audio problems, configuring media proxy for RTP detection, or designing a failover strategy that protects call quality, expert guidance ensures your VOS3000 system delivers reliable, high-quality voice service. ๐Ÿ“ก

๐Ÿ’ฌ WhatsApp: +8801911119966 โ€” Get immediate assistance with VOS3000 RTP lock-in failover configuration, one-way audio troubleshooting, and media proxy optimization. Our team specializes in VOS3000 call quality assurance, failover design, and carrier-grade VoIP deployment. ๐Ÿ”ง

๐Ÿ”— Explore related VOS3000 failover and media configuration 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 Gateway Switch Limit, VOS3000 RTP Lock-In, VOS3000 Aggressive Gateway Failover, VOS3000 Busy Stop Switch, VOS3000 real-time gateway ASR, VOS3000 ASR Cost Routing, VOS3000 Prefix Mode ExtensionVOS3000 Gateway Switch Limit, VOS3000 RTP Lock-In, VOS3000 Aggressive Gateway Failover, VOS3000 Busy Stop Switch, VOS3000 real-time gateway ASR, VOS3000 ASR Cost Routing, VOS3000 Prefix Mode ExtensionVOS3000 Gateway Switch Limit, VOS3000 RTP Lock-In, VOS3000 Aggressive Gateway Failover, VOS3000 Busy Stop Switch, VOS3000 real-time gateway ASR, VOS3000 ASR Cost Routing, VOS3000 Prefix Mode Extension
VOS3000 Gateway Switch Limit, VOS3000 RTP Lock-In, VOS3000 Aggressive Gateway Failover, VOS3000 Busy Stop Switch, VOS3000 real-time gateway ASR, VOS3000 ASR Cost Routing, VOS3000 Prefix Mode Extension

VOS3000 Gateway Switch Limit Essential SS_GATEWAY_SWITCH_LIMIT Failover Cap

VOS3000 Gateway Switch Limit Essential SS_GATEWAY_SWITCH_LIMIT Failover Cap

๐Ÿ”„ Every time a call fails to connect through one routing gateway in VOS3000, the softswitch can automatically try the next available gateway in the route. This failover mechanism is critical for maintaining high call completion rates, but without a cap on the number of attempts, a single call can cascade through every gateway in your routing table, creating painfully long post-dial delay (PDD) for the caller. The VOS3000 gateway switch limit parameter, SS_GATEWAY_SWITCH_LIMIT, is the essential control that prevents this runaway switching behavior by capping the maximum number of failover attempts per call. ๐Ÿ”ง

โš™๏ธ By default, SS_GATEWAY_SWITCH_LIMIT is set to None, meaning there is no limit on how many gateways VOS3000 will try before giving up on a call. While unlimited switching maximizes the chance of call completion, it comes at a steep cost: each failover attempt adds signaling overhead, increases PDD, inflates calls-per-second (CPS) load on the softswitch, and can generate a cascade of failed CDR records. Setting the VOS3000 gateway switch limit to a specific value forces the softswitch to stop trying after that many attempts, returning a failure response to the caller faster and freeing system resources for other calls. The key is finding the right balance between giving calls enough chances to connect and preventing excessive delay. ๐Ÿ“Š

๐ŸŽฏ This guide provides a complete, manual-verified reference for the SS_GATEWAY_SWITCH_LIMIT parameter. All parameter definitions are sourced from the official VOS3000 2.1.9.07 English manual ยง4.3.5.2 (page 236), with detailed explanations of how the VOS3000 gateway switch limit works, how it interacts with other failover parameters, and practical recommendations for different deployment scenarios. ๐Ÿ“˜

๐Ÿ” What Is the VOS3000 Gateway Switch Limit?

๐Ÿ“‹ The VOS3000 gateway switch limit is defined by the system parameter SS_GATEWAY_SWITCH_LIMIT, documented in the VOS3000 manual ยง4.3.5.2 (page 236) as “Times limit for Routing Gateway Auto-Switch.” This parameter controls the maximum number of times VOS3000 will automatically switch to a different routing gateway when the current gateway fails to deliver a call. Each switch attempt represents one failover cycle: the softswitch selects the next gateway according to the routing rules and sends a new INVITE (for SIP) or Setup (for H.323) to that gateway.

๐Ÿ’ก Key characteristics of SS_GATEWAY_SWITCH_LIMIT:

  • ๐Ÿ”ข Default value: None โ€” unlimited switching attempts per call
  • ๐Ÿ“Š Configuration location: Operation management > Softswitch management > Additional settings > System parameter
  • ๐Ÿ”„ Scope: Applies per call โ€” each new call starts with a fresh switch counter
  • ๐Ÿ“ก Protocol support: Affects both SIP and H.323 gateway switching
  • ๐Ÿ“‹ Interaction: Works alongside SS_GATEWAY_SWITCH_UNTIL_CONNECT, SS_GATEWAY_SWITCH_STOP_AFTER_RTP_START, and SS_GATEWAY_SWITCH_STOP_AFTER_USER_BUSY

๐Ÿ“ Setting the value: When you configure SS_GATEWAY_SWITCH_LIMIT in the VOS3000 client, you set a numeric value representing the maximum number of auto-switch attempts allowed by the VOS3000 gateway switch limit. For example, a value of 3 means VOS3000 will try up to 3 additional gateways after the initial attempt fails, for a total of 4 gateway attempts per call. Setting it to None (or 0, depending on version) removes the limit entirely, allowing unlimited switching until either a gateway connects or all available gateways have been exhausted.

๐Ÿ“Š How Unlimited Switching Causes Long PDD

โฑ๏ธ Post-dial delay (PDD) is the time between when a caller dials a number and when they hear ringback tone. In VOS3000, each gateway failover attempt adds to the PDD because the softswitch must wait for a timeout or rejection from one gateway before trying the next. When the VOS3000 gateway switch limit is set to None, a single call can trigger sequential INVITE attempts to every gateway in the routing table, each consuming several seconds of timeout before moving on.

ScenarioGateways TriedApprox. PDDCaller Experience
Limit = None, 10 gateways all down10 attempts30โ€“60 seconds๐Ÿ”ด Extremely poor โ€” caller hangs up
Limit = 3, gateways down4 attempts (1 + 3)9โ€“15 seconds๐ŸŸก Tolerable โ€” some callers wait
Limit = 2, gateways down3 attempts (1 + 2)6โ€“10 seconds๐ŸŸข Acceptable โ€” fast failure response
Limit = None, 1st gateway succeeds1 attempt1โ€“3 seconds๐ŸŸข Excellent โ€” no failover needed

๐Ÿšจ PDD calculation insight: The approximate PDD for failover is the sum of all SIP INVITE timeouts for each failed attempt. The default SS_SIP_TIMEOUT_INVITE is 10 seconds (VOS3000 manual ยง4.3.5.2, page 231), but the actual time per attempt depends on whether the gateway actively rejects (fast) or simply does not respond (slow timeout). When gateways are truly unreachable, each attempt consumes the full timeout duration, making unlimited switching extremely costly in terms of PDD when the VOS3000 gateway switch limit is not configured. For detailed SIP timeout tuning, see our SIP INVITE timeout guide.

๐Ÿ“‹ SS_GATEWAY_SWITCH_LIMIT Parameter Reference

AttributeDetail
๐Ÿ“Œ Parameter NameSS_GATEWAY_SWITCH_LIMIT
๐Ÿ“ Manual DescriptionTimes limit for Routing Gateway Auto-Switch (VOS3000 2.1.9.07 manual ยง4.3.5.2, page 236)
๐Ÿ”ง Default ValueNone (unlimited switching)
๐Ÿ“ Configuration PathOperation management > Softswitch management > Additional settings > System parameter
๐Ÿ“Š Value RangeNone or positive integer (recommended: 2โ€“5)
๐Ÿ”„ ScopePer call โ€” each call has its own switch counter
๐Ÿ“ก ProtocolSIP and H.323

๐Ÿ”„ How Gateway Switch Limit Interacts with Other Failover Parameters

๐Ÿ”— The VOS3000 gateway switch limit does not operate in isolation โ€” it is one part of a comprehensive failover control system. The VOS3000 gateway switch limit works alongside three other system parameters that control different aspects of failover behavior. Understanding these interactions is critical for designing an effective failover strategy that balances call completion with setup speed.

ParameterDefaultFunctionInteraction with SWITCH_LIMIT
SS_GATEWAY_SWITCH_UNTIL_CONNECTOffEnables aggressive failover until connect signal receivedWhen On, SWITCH_LIMIT still caps total attempts
SS_GATEWAY_SWITCH_STOP_AFTER_RTP_STARTOnStops switching once RTP media starts flowingOverrides SWITCH_LIMIT โ€” stops switching regardless of remaining attempts
SS_GATEWAY_SWITCH_STOP_AFTER_USER_BUSYOnStops switching when 486 Busy receivedOverrides SWITCH_LIMIT โ€” stops switching on busy signal

๐Ÿ’ก Priority hierarchy: The stop conditions (RTP start and user busy) take priority over the switch limit. Even if SS_GATEWAY_SWITCH_LIMIT allows more attempts, if RTP starts flowing or a busy signal is received, VOS3000 stops switching immediately. The VOS3000 gateway switch limit acts as a maximum ceiling โ€” it never forces additional switching, it only prevents excessive switching. For more on the RTP lock-in behavior, see our VOS3000 RTP media guide.

๐ŸŽฏ The optimal VOS3000 gateway switch limit depends on your deployment type, the number of available gateways, and your priority between call completion rate (ASR) and post-dial delay (PDD). Here are practical recommendations based on common VoIP deployment scenarios:

Deployment TypeRecommended LimitReasoning
๐Ÿข Retail VoIP (low PDD critical)2โ€“3Retail callers are impatient โ€” fast failure is better than long silence
๐Ÿ”„ Wholesale termination (ASR critical)3โ€“5Wholesale clients value completion rate over PDD โ€” more attempts improve ASR
๐Ÿ’ณ Calling card service2โ€“3Card users hear silence during switching โ€” limit prevents frustration
๐Ÿ“ก Enterprise SIP trunking3โ€“4Business users tolerate some delay but expect reliable completion
๐Ÿ”— Multi-carrier failover4โ€“6Multiple carriers increase chances โ€” more attempts justified for redundancy
๐Ÿงช Testing / lab environmentNoneUnlimited switching helps discover all routing paths during testing

๐Ÿ“Š ASR vs PDD trade-off: Every additional switch attempt governed by the VOS3000 gateway switch limit improves your Answer-Seizure Ratio (ASR) by giving the call another chance to connect, but each attempt also adds to the PDD. The relationship is not linear โ€” the first 2โ€“3 failover attempts typically yield the largest ASR improvement, while attempts beyond 5 provide diminishing returns because the remaining gateways are often lower-priority routes with poorer quality. For comprehensive ASR analysis methodology, see our VOS3000 ASR ACD analysis guide.

๐Ÿ“‹ Gateway Switch Limit and CDR Impact

๐Ÿ“Š The VOS3000 gateway switch limit directly affects your CDR data. Each gateway attempt governed by the VOS3000 gateway switch limit produces signaling and record-keeping consequences. Each failover attempt that fails generates a CDR record (when SS_CDR_RECORD_NONCONNECT is enabled), and calls that exhaust the switch limit generate a final CDR with the appropriate call end reason. Understanding this CDR impact helps you analyze failover patterns and tune the limit appropriately.

CDR ImpactWith None LimitWith Set Limit (e.g., 3)
Non-connected CDR records per callUp to N (all gateways tried)Up to 3 + 1 (initial attempt + 3 switches)
Database load during gateway outage๐Ÿ”ด Very high โ€” every call generates maximum CDRs๐ŸŸข Controlled โ€” capped CDR generation per call
CPS load on softswitch๐Ÿ”ด High โ€” N INVITE attempts per failed call๐ŸŸข Bounded โ€” predictable maximum attempts per call
Call end reason accuracyLast gateway’s rejection reason recordedLast attempted gateway’s reason, or “switch limit exceeded”

๐Ÿ”ง CDR recording tip: When you enable SS_CDR_RECORD_NONCONNECT (documented in manual ยง4.3.5.2, page 235), VOS3000 records CDRs for calls that never connected โ€” including failover attempts. With an unlimited switch limit, a single call to an unreachable destination could generate dozens of non-connected CDR records, significantly inflating your database. Setting the VOS3000 gateway switch limit prevents this CDR flood by capping the number of failover records per call. For more on CDR configuration, see our CDR analysis and billing guide.

๐Ÿ›ก๏ธ Common Gateway Switch Limit Problems and Solutions

โŒ Problem 1: Excessive PDD with Default None Setting

๐Ÿ” Symptom: Callers experience very long silence (30+ seconds) before hearing ringback or a fast-busy tone, especially when multiple gateways are unavailable.

๐Ÿ’ก Cause: SS_GATEWAY_SWITCH_LIMIT is set to None (default), allowing VOS3000 to try every available gateway sequentially when the VOS3000 gateway switch limit is not configured. Each failed attempt consumes the full INVITE timeout (default 10 seconds), so 5 failed gateways means 50+ seconds of PDD.

โœ… Solutions:

  • ๐Ÿ”ง Set SS_GATEWAY_SWITCH_LIMIT to 3 or 4 โ€” this caps failover attempts while still giving calls reasonable chances under the VOS3000 gateway switch limit
  • โฑ๏ธ Reduce SS_SIP_TIMEOUT_INVITE from 10 to 5 seconds โ€” faster timeout means faster failover between gateways
  • ๐Ÿ“Š Enable vendor failover setup to ensure only healthy gateways are in the routing pool

โŒ Problem 2: Low ASR After Setting Switch Limit Too Low

๐Ÿ” Symptom: After setting SS_GATEWAY_SWITCH_LIMIT to 1 or 2, the Answer-Seizure Ratio drops significantly because calls that would have connected on the 3rd or 4th gateway attempt are now rejected early.

๐Ÿ’ก Cause: The switch limit is too restrictive for the number of available gateways. If you have 5 gateways but the VOS3000 gateway switch limit only allows 2 switch attempts, the softswitch never reaches the gateways that could successfully deliver the call.

โœ… Solutions:

  • ๐Ÿ“Š Analyze CDR data to determine how many switch attempts typically succeed โ€” the limit should be at least 1 more than the highest successful attempt number
  • ๐Ÿ”ง Increase the limit to 3โ€“4 for wholesale deployments where ASR is more valuable than PDD โ€” the VOS3000 gateway switch limit should reflect your traffic priorities
  • ๐Ÿ“ก Use routing optimization to ensure the best gateways are tried first, reducing the need for many switch attempts

โŒ Problem 3: CPS Overload During Gateway Outage

๐Ÿ” Symptom: When one or more gateways go offline, the VOS3000 softswitch experiences high CPU and CPS load because every incoming call triggers maximum failover attempts.

๐Ÿ’ก Cause: With unlimited switching, every failed call generates N INVITE attempts (where N is the number of available gateways), multiplying the signaling load by the number of gateways during outage conditions.

โœ… Solutions:

  • ๐Ÿ”ง Set the VOS3000 gateway switch limit to 2โ€“3 to bound the maximum signaling load per call
  • ๐Ÿ“Š Configure gateway analysis reports with alarm thresholds to detect gateway outages early
  • ๐Ÿ›ก๏ธ Remove failed gateways from the routing pool immediately during outages to prevent wasted switch attempts

๐Ÿ’ก Gateway Switch Limit Best Practices

๐ŸŽฏ Follow these best practices to optimize the VOS3000 gateway switch limit for your specific deployment. Proper VOS3000 gateway switch limit configuration prevents both runaway PDD and premature call rejection:

Best PracticeRecommendationReason
๐Ÿ“Š Never leave default None in productionSet limit to 2โ€“5 based on deployment type๐Ÿ”ง Prevents runaway PDD and CPS overload
๐Ÿ”„ Pair with RTP stop enabledKeep SS_GATEWAY_SWITCH_STOP_AFTER_RTP_START = On๐Ÿ“ก Stops switching once media flows โ€” prevents one-way audio
๐Ÿ“ž Enable busy stop switchKeep SS_GATEWAY_SWITCH_STOP_AFTER_USER_BUSY = On๐Ÿšซ Prevents wasteful switching after genuine busy signal
โฑ๏ธ Tune SIP INVITE timeoutReduce from 10s to 5s for faster failover๐Ÿ“Š Lower PDD per switch attempt without sacrificing reliability
๐Ÿ“‹ Analyze CDR failover patternsReview which attempt number succeeds most often๐Ÿ“Š Data-driven limit setting instead of guessing

โ“ Frequently Asked Questions

โ“ What is the default value of SS_GATEWAY_SWITCH_LIMIT?

๐Ÿ”ง The default value of SS_GATEWAY_SWITCH_LIMIT is None, which means there is no limit on the number of gateway auto-switch attempts per call. This is documented in the VOS3000 2.1.9.07 manual ยง4.3.5.2 (page 236) as “Times limit for Routing Gateway Auto-Switch” with default value “None.” While this maximizes call completion chances, it can cause excessively long PDD when multiple gateways are unreachable. It is strongly recommended to set a specific VOS3000 gateway switch limit (2โ€“5) in production deployments to bound failover behavior and prevent CPS overload during gateway outages.

โ“ Does the gateway switch limit count the initial attempt or only failovers?

๐Ÿ“Š The SS_GATEWAY_SWITCH_LIMIT parameter counts the number of auto-switch attempts, which are the failover attempts after the initial gateway selection. The VOS3000 gateway switch limit counts only these additional attempts, not the initial routing decision. So if you set the limit to 3, VOS3000 will make the initial attempt plus up to 3 additional switch attempts, for a total of 4 gateway tries per call. This interpretation is consistent with the parameter description “Times limit for Routing Gateway Auto-Switch” โ€” the word “auto-switch” refers to the automatic switching between gateways, not the initial routing selection.

โ“ What happens when the switch limit is reached?

๐Ÿšซ When the VOS3000 gateway switch limit is reached and no gateway has successfully connected the call, VOS3000 stops trying additional gateways and returns a failure response to the calling party. The specific SIP response code depends on the last failure reason โ€” it could be 503 Service Unavailable, 408 Request Timeout, or another appropriate code. A CDR record is generated for the call with the appropriate call end reason. The caller hears a fast-busy tone or a failure announcement, depending on your call failed announcement configuration.

โ“ Can I set different switch limits per gateway?

๐Ÿ“‹ No, SS_GATEWAY_SWITCH_LIMIT is a system-level parameter that applies globally to all calls processed by the softswitch. You cannot set different VOS3000 gateway switch limit values per individual gateway. However, you can control failover behavior at the gateway level through the routing gateway’s “Additional settings” panel, which includes per-gateway options like “Switch gateway until connect” and “Stop switch gateway when RTP start” that override the system defaults for that specific gateway. This per-gateway override capability gives you some granularity in controlling failover behavior without needing per-gateway switch limits.

โ“ How does the switch limit interact with SS_GATEWAY_SWITCH_UNTIL_CONNECT?

๐Ÿ”„ SS_GATEWAY_SWITCH_UNTIL_CONNECT enables aggressive failover that keeps trying gateways until one returns a connect signal (SIP 200 OK or H.323 Connect). When this parameter is On, the VOS3000 gateway switch limit still applies โ€” it caps the total number of switch attempts even in aggressive mode. The combination of UNTIL_CONNECT = On and SWITCH_LIMIT = 3 means VOS3000 will aggressively try up to 3 additional gateways, but will stop after that even if no connect signal has been received. This is the recommended combination for production: aggressive mode with a sensible cap. For more on aggressive failover, refer to the VOS3000 system parameters overview.

โ“ Should I change the switch limit when adding more gateways?

๐Ÿ“ก Yes, you should review and potentially increase the VOS3000 gateway switch limit when you add more routing gateways to your system. The general rule is: the limit should be high enough to cover your best gateways plus 1โ€“2 backup attempts, but not so high that it causes unacceptable PDD. If you add 3 new gateways, consider increasing the limit by 1โ€“2 to give calls a chance to reach the new routes. Always monitor PDD and ASR after any change to the VOS3000 gateway switch limit, and use CDR analysis to verify that the additional attempts are actually producing completed calls rather than just adding delay.

๐Ÿ“ž Need Expert Help with VOS3000 Gateway Switch Limit?

๐Ÿ”ง Proper configuration of the VOS3000 gateway switch limit is essential for balancing call completion rates with post-dial delay performance. The VOS3000 gateway switch limit directly impacts both ASR and caller experience. Whether you are troubleshooting excessive PDD, optimizing ASR after changing your switch limit, or designing a failover strategy for a multi-carrier deployment, expert guidance ensures your VOS3000 system delivers the best possible caller experience. ๐Ÿ“Š

๐Ÿ’ฌ WhatsApp: +8801911119966 โ€” Get immediate assistance with VOS3000 gateway switch limit configuration, VOS3000 gateway switch limit tuning, failover optimization, and PDD troubleshooting. Our team specializes in VOS3000 softswitch tuning, routing quality improvement, and carrier-grade failover design. ๐Ÿ”ง

๐Ÿ”— Explore related VOS3000 failover and routing configuration 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 Gateway Switch Limit, VOS3000 RTP Lock-In, VOS3000 Aggressive Gateway Failover, VOS3000 Busy Stop Switch, VOS3000 real-time gateway ASR, VOS3000 ASR Cost Routing, VOS3000 Prefix Mode ExtensionVOS3000 Gateway Switch Limit, VOS3000 RTP Lock-In, VOS3000 Aggressive Gateway Failover, VOS3000 Busy Stop Switch, VOS3000 real-time gateway ASR, VOS3000 ASR Cost Routing, VOS3000 Prefix Mode ExtensionVOS3000 Gateway Switch Limit, VOS3000 RTP Lock-In, VOS3000 Aggressive Gateway Failover, VOS3000 Busy Stop Switch, VOS3000 real-time gateway ASR, VOS3000 ASR Cost Routing, VOS3000 Prefix Mode Extension
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
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 Pipe Format Definitive 18-Field Important Reference Guide

VOS3000 CDR Pipe Format Definitive 18-Field Reference Guide

๐Ÿ“Š Every VOS3000 operator who exports call detail records must understand the VOS3000 CDR pipe format down to the individual field level. The pipe-delimited text file is the universal interface between your softswitch and every external system that consumes call data โ€” billing platforms, fraud detection engines, analytics dashboards, and regulatory compliance archives. A single misinterpreted field can cascade into billing errors, incorrect traffic reports, or failed audits. Yet the official manual provides only a brief field listing, leaving operators to figure out data types, edge cases, and integration mappings on their own. ๐Ÿ”

โš™๏ธ This guide provides a definitive, field-by-field reference of every column in the VOS3000 CDR pipe format. Each field is documented with its position in the pipe-delimited line, data type, example value, special considerations, and how it maps to external billing and analytics systems. All field definitions are sourced from the official VOS3000 2.1.8.0/2.1.9.07 English manual ยง4.4 (pages 241โ€“243), with additional practical guidance based on real-world parsing and integration experience. ๐Ÿ“˜

๐ŸŽฏ Whether you are building a Python CDR parser, configuring a MySQL import pipeline, or integrating VOS3000 with a third-party billing system, this reference eliminates the guesswork from field mapping and data interpretation. Let us walk through every field in the exact order it appears in each CDR line. ๐Ÿ”ง

Table of Contents

๐Ÿ” VOS3000 CDR Pipe Format Overview

๐Ÿ“ When SS_CDR_RECORD_TO_FILE is enabled in VOS3000, the softswitch generates hourly text files in the cdr/ directory. Each file follows the naming convention YYYYMMDDHH.txt, and each line within the file represents one call detail record with fields separated by the pipe character (|, ASCII 124). The format specification is documented in the official VOS3000 manual ยง4.4.

๐Ÿ“‹ CDR Line Format Structure – VOS3000 CDR Pipe

callerE164|calleeE164|startTime|stopTime|holdTime|endReason|
endDirection|callerGatewayId|calleeGatewayId|callerIp|calleeIp|
callerAccessE164|calleeAccessE164|callerToGatewayE164|
calleeToGatewayE164|calleeBilling|billingMode|callerPdd|calleePdd

๐Ÿ“ Field count note: The VOS3000 manual ยง4.4 documents the header line with 18 pipe separators producing 19 columns. The first 17 fields (through billingMode) are the core billing-critical fields present in all CDR records. Fields 18 and 19 (callerPdd and calleePdd) provide Post-Dial Delay metrics that measure call setup timing. Your parsing logic should handle both 17-field and 19-field records for maximum compatibility across VOS3000 versions.

๐Ÿ“Š Complete Field-by-Field Reference – VOS3000 CDR Pipe

๐Ÿ“‹ Below is the definitive reference for every field in the VOS3000 CDR pipe format, in the exact order they appear in each line:

Field 1: callerE164 โ€” The Caller ID ๐Ÿ””

AttributeValue
๐Ÿ“Œ Field Position1 (first field)
๐Ÿ“ Data TypeString (numeric E.164 format)
๐Ÿ“ DescriptionThe caller ID โ€” the originating party’s phone number
๐Ÿ”ข Example12125551234
โš ๏ธ NotesMay differ from callerAccessE164 after prefix transformations

๐Ÿ’ก Practical note: The callerE164 field reflects the caller ID after VOS3000 has applied any configured prefix transformations. This is the number as seen by the billing engine, not necessarily the original incoming number. For the original incoming caller ID before any transformations, refer to Field 12 (callerAccessE164). Understanding this distinction is essential when troubleshooting billing discrepancies.

Field 2: calleeE164 โ€” The Callee ID ๐Ÿ“ž

AttributeValue
๐Ÿ“Œ Field Position2
๐Ÿ“ Data TypeString (numeric E.164 format)
๐Ÿ“ DescriptionThe callee ID โ€” the destination phone number
๐Ÿ”ข Example18005559876
โš ๏ธ NotesThis is the billed destination number after prefix processing

๐Ÿ”‘ Billing relevance: The calleeE164 is the number used by the VOS3000 billing engine to match the call against rate tables. If your prefix settings strip or add digits, the calleeE164 reflects the number after those transformations. This is critical for rate table matching โ€” a calleeE164 of 18005559876 matches a different rate entry than 01118005559876.

Field 3: startTime โ€” Call Begin Time โฐ

AttributeValue
๐Ÿ“Œ Field Position3
๐Ÿ“ Data TypeDatetime string
๐Ÿ“ DescriptionBegin time of the call
๐Ÿ”ข Example2018-12-20 11:20:18
โš ๏ธ NotesFormat is YYYY-MM-DD HH:MM:SS; timezone is server local time

โฑ๏ธ Time zone awareness: The startTime is recorded in the VOS3000 server’s local timezone. If your server is configured in UTC+6 (Bangladesh Standard Time), all timestamps reflect that timezone. When integrating CDR data with systems in different timezones, always account for the offset. The startTime represents when the call was initially received by VOS3000, not when it was answered.

Field 4: stopTime โ€” Call End Time ๐Ÿ›‘

AttributeValue
๐Ÿ“Œ Field Position4
๐Ÿ“ Data TypeDatetime string
๐Ÿ“ DescriptionEnd time of the call
๐Ÿ”ข Example2018-12-20 16:34:09

๐Ÿ“Š Duration calculation: The actual call duration is stored in Field 5 (holdTime), not calculated from startTime and stopTime. The difference between startTime and stopTime includes call setup time, ringing time, and other pre-connection delays. Only holdTime represents the actual conversation duration. The stopTime determines which hourly CDR file the record is written to.

Field 5: holdTime โ€” Call Duration โฑ๏ธ

AttributeValue
๐Ÿ“Œ Field Position5
๐Ÿ“ Data TypeInteger (milliseconds)
๐Ÿ“ DescriptionCall duration in milliseconds
๐Ÿ”ข Example45000 (equals 45 seconds)
๐Ÿšจ Critical NoteValue is in MILLISECONDS, not seconds โ€” a common parsing error

โš ๏ธ The #1 parsing mistake: The holdTime field is recorded in milliseconds, not seconds. A value of 45000 means 45 seconds of conversation, not 45000 seconds. This is the single most common error when integrating VOS3000 CDR data with external billing systems. Always divide holdTime by 1000 before applying per-second or per-minute billing rates. The holdTime is also affected by the SERVER_BILLING_HOLD_TIME_PRECISION parameter, which controls millisecond rounding before billing calculation.

Field 6: endReason โ€” End Reason Code ๐Ÿ“‹

AttributeValue
๐Ÿ“Œ Field Position6
๐Ÿ“ Data TypeString/Integer
๐Ÿ“ DescriptionEnd reason โ€” SIP response code or Q.850 cause code
๐Ÿ”ข Example200 (normal), 486 (busy), 480 (no answer)

๐Ÿ” Interpreting endReason: For SIP calls, the endReason typically contains the SIP response code from the final response message (200 OK, 486 Busy, 480 Temporarily Unavailable, 503 Service Unavailable, etc.). For H.323 calls, it may contain Q.850 cause codes. The endReason field, combined with endDirection, provides the complete picture of why and how a call terminated. For a detailed breakdown of termination codes, see our guide on VOS3000 call termination reasons.

Field 7: endDirection โ€” Hangup Side ๐Ÿ”„

AttributeValue
๐Ÿ“Œ Field Position7
๐Ÿ“ Data TypeInteger (0, 1, or 2)
๐Ÿ“ DescriptionHangup side: 0 = caller, 1 = callee, 2 = server

๐Ÿ”‘ Billing impact: The endDirection tells you who initiated the call termination. A value of 0 means the calling party hung up normally, 1 means the called party hung up, and 2 means the VOS3000 server itself terminated the call (which could indicate a session timeout, account balance exhaustion, or administrative intervention). This field is critical for dispute resolution โ€” see our detailed analysis in the server hangup CDR recording guide.

Fields 8โ€“9: Gateway Identifiers ๐Ÿ“ก

FieldPositionDescriptionExample
callerGatewayId8Calling gateway ID1001
calleeGatewayId9Called gateway ID2003

๐Ÿ“ก Gateway mapping: These fields contain the VOS3000 internal gateway IDs, not the gateway names you see in the client interface. To map these IDs to human-readable gateway names, you need to cross-reference the VOS3000 gateway configuration. The callerGatewayId refers to the mapping gateway (incoming side), while the calleeGatewayId refers to the routing gateway (outgoing side). Understanding this mapping is essential for gateway performance analysis and route optimization.

Fields 10โ€“11: IP Addresses ๐ŸŒ

FieldPositionDescriptionExample
callerIp10Caller IP address192.168.1.100
calleeIp11Callee IP address10.0.0.50

๐Ÿ”’ Security value: The IP address fields are invaluable for security analysis. By tracking callerIp patterns, you can identify traffic from unexpected source IPs that may indicate unauthorized access or SIP scanning attacks. The VOS3000 anti-hack configuration uses IP-level authentication, and these CDR fields provide the audit trail for verifying that authentication is working correctly.

Fields 12โ€“13: Access (Incoming) E164 Numbers ๐Ÿ“ฅ

FieldPositionDescription
callerAccessE16412Incoming caller โ€” the original caller ID as received by VOS3000 before any transformations
calleeAccessE16413Incoming callee โ€” the original destination number as received before transformations

๐Ÿ”„ Why access fields matter: These fields preserve the original phone numbers as they arrived at VOS3000, before any callee rewrite rules, prefix stripping, or number transformations were applied. This is crucial for debugging routing issues โ€” if a call was routed incorrectly because a prefix transformation changed the destination, you can compare calleeAccessE164 (original) with calleeE164 (transformed) to identify exactly where the routing went wrong. For detailed prefix configuration guidance, see our callee rewrite rule guide.

Fields 14โ€“15: Outbound (To Gateway) E164 Numbers ๐Ÿ“ค

FieldPositionHeader NameDescription
callerToGatewayE16414callerToGatewayE164Outbound caller โ€” the caller ID sent to the outgoing gateway
calleeToGatewayE16415calleeToGatewayE164Outbound callee โ€” the destination number sent to the outgoing gateway

๐Ÿ“‹ Naming discrepancy note: The VOS3000 manual ยง4.4 header line labels these fields as callerToGatewayE164 and calleeToGatewayE164, but the field description table in the same section refers to them as “Outbound caller” and “Outbound callee” (callerOutE164 / calleeOutE164). Both names refer to the same data โ€” the phone numbers after all VOS3000 transformations have been applied, as they are sent out to the routing gateway. These outbound fields show the final form of the numbers as seen by the terminating carrier.

Field 16: calleeBilling โ€” Billing Method ๐Ÿ’ฐ

AttributeValue
๐Ÿ“Œ Field Position16
๐Ÿ“ Data TypeInteger (0 or 1)
๐Ÿ“ DescriptionBilling method: 0 = By caller, 1 = By callee

๐Ÿ’ก Understanding billing method: This field indicates which party’s account is charged for the call. A value of 0 means the caller’s account is billed (the standard arrangement for most calls). A value of 1 means the callee’s account is billed, which applies to collect calls, toll-free number calls, or special reverse-charging arrangements. This field works in conjunction with billingMode (Field 17) to determine the complete billing attribution for each call.

Field 17: billingMode โ€” Charge Mode ๐Ÿ’ณ

AttributeValue
๐Ÿ“Œ Field Position17
๐Ÿ“ Data TypeInteger (-1, 0, 1, or 3)
๐Ÿ“ DescriptionCharge mode: -1 = no billing, 0 = phone number, 1 = gateway ID, 3 = phone card

๐Ÿ”‘ Billing mode codes explained: This is one of the most important fields for billing analysis. A billingMode of -1 means the call was not billed at all โ€” this applies to illegal calls, free numbers, and calls that bypass the billing engine. A value of 0 means billing is attributed to a phone number account. A value of 1 means billing is attributed to a gateway ID. A value of 3 means billing is attributed to a phone card (calling card). For a comprehensive breakdown of how each code affects billing calculations, refer to our detailed billing mode codes reference.

Fields 18โ€“19: Post-Dial Delay Metrics โฑ๏ธ

FieldPositionDescription
callerPdd18Time elapsed from call received to call connected (incoming PDD)
calleePdd19Time elapsed from call sent to routing response (outgoing PDD)

๐Ÿ“Š PDD analysis value: Post-Dial Delay is a critical quality-of-service metric. High callerPdd values indicate that calls take too long to connect on the incoming side, which frustrates callers. High calleePdd values indicate slow response from routing gateways, which may point to gateway overload, network latency, or incorrect INVITE timeout configuration. Monitoring PDD trends helps you identify degrading gateway performance before it impacts your ASR.

๐Ÿ“‹ Complete VOS3000 CDR Pipe Format Quick Reference Table

#Field NameTypeDescriptionExample
1callerE164StringThe caller ID12125551234
2calleeE164StringThe callee ID18005559876
3startTimeDatetimeCall begin time2018-12-20 11:20:18
4stopTimeDatetimeCall end time2018-12-20 16:34:09
5holdTimeInteger (ms)Call duration in milliseconds45000
6endReasonString/IntEnd reason code200
7endDirectionIntegerHangup side (0/1/2)0
8callerGatewayIdIntegerCalling gateway1001
9calleeGatewayIdIntegerCalled gateway2003
10callerIpStringCaller IP address192.168.1.100
11calleeIpStringCallee IP address10.0.0.50
12callerAccessE164StringIncoming caller12125551234
13calleeAccessE164StringIncoming callee01118005559876
14callerToGatewayE164StringOutbound caller12125551234
15calleeToGatewayE164StringOutbound callee18005559876
16calleeBillingIntegerBilling method (0/1)0
17billingModeIntegerCharge mode (-1/0/1/3)0
18callerPddIntegerIncoming PDD (ms)3200
19calleePddIntegerOutgoing PDD (ms)1500

๐Ÿ“Š External System Mapping Guide – VOS3000 CDR Pipe

๐Ÿ”— When integrating VOS3000 CDR data with external billing and analytics systems, field names and data types often need to be mapped to the target system’s schema. Here is a reference mapping for common integration targets:

VOS3000 FieldMySQL ColumnCommon Billing LabelTransform Needed
callerE164VARCHAR(32)ANI / Calling NumberNone
calleeE164VARCHAR(32)DNIS / Called NumberNone
startTimeDATETIMECall Start / Setup TimeParse datetime string
holdTimeINTDuration (seconds)โš ๏ธ Divide by 1000
endReasonVARCHAR(16)Release CauseMap to cause code table
endDirectionTINYINTRelease SourceMap 0/1/2 to labels
billingModeTINYINTBilling TypeMap -1/0/1/3 to labels

โ“ Frequently Asked Questions

โ“ How many fields are in the VOS3000 CDR pipe format?

๐Ÿ“‹ The VOS3000 CDR pipe format contains 17 core billing-critical fields (through the billingMode field at position 17) plus 2 Post-Dial Delay fields (callerPdd at position 18 and calleePdd at position 19), for a total of up to 19 fields. The pipe delimiter creates 18 separators for the full 19-column format. Older VOS3000 versions may produce records with only 17 fields (without PDD data). Your parsing code should handle variable field counts gracefully by checking the number of pipe-delimited columns in each line before processing.

โ“ Why is holdTime in milliseconds instead of seconds?

โฑ๏ธ VOS3000 records holdTime in milliseconds to support high-precision billing configurations. The SERVER_BILLING_FEE_PRECISTION and SERVER_BILLING_HOLD_TIME_PRECISION parameters allow billing calculations down to millisecond granularity. While most operators bill in whole seconds or minutes, the millisecond precision in the CDR ensures that no rounding is applied before the data is exported โ€” any rounding happens in the billing engine according to the configured precision parameters. When parsing CDR data, always divide holdTime by 1000 to convert to seconds.

โ“ What is the difference between callerE164 and callerAccessE164?

๐Ÿ”„ callerE164 (Field 1) is the caller ID after VOS3000 has applied all prefix transformations and number manipulations. callerAccessE164 (Field 12) is the original incoming caller ID as it was received by VOS3000 before any transformations. The two values differ when VOS3000’s callee rewrite rules, prefix stripping, or caller ID manipulation features modify the number. Similarly, calleeE164 (Field 2) may differ from calleeAccessE164 (Field 13) when the destination number is transformed before routing.

โ“ What does a billingMode of -1 mean in the CDR?

๐Ÿ’ณ A billingMode of -1 means the call was not billed. This applies to calls that bypass the billing engine entirely, including illegal calls from unauthorized IP addresses, calls to toll-free numbers configured under SERVER_BILLING_FREE_E164S, and calls where the billing system could not determine an account to charge. These records still appear in the CDR export (when SS_CDR_RECORD_ILLEGAL is On) for security auditing purposes, but they carry no billing charge.

โ“ How do I parse VOS3000 CDR files with different field counts?

๐Ÿ”ง The safest approach is to split each CDR line on the pipe character and check the resulting field count before processing. Lines with 17 fields contain core billing data without PDD metrics. Lines with 19 fields include the PDD columns. Always map fields by position (index), not by counting from the end, since new fields are added at the end of the line. Use the field position reference table in this guide to ensure correct mapping regardless of the field count in your specific VOS3000 version.

โ“ Are VOS3000 CDR timestamps in UTC or local time?

โฐ VOS3000 CDR timestamps (startTime and stopTime) are recorded in the server’s local timezone, not UTC. If your server is configured with timezone Asia/Dhaka (UTC+6), all timestamps will be in BST. When integrating CDR data with systems that expect UTC, you must apply the appropriate timezone offset during parsing. Always verify your server’s timezone setting with the date command in SSH before assuming the timezone in your CDR processing logic.

๐Ÿ“ž Need Expert Help with VOS3000 CDR Pipe Format?

๐Ÿ”ง Accurate VOS3000 CDR pipe format parsing is the foundation of every billing integration, analytics pipeline, and compliance archive. A single misinterpreted field โ€” especially the millisecond holdTime or the billing mode codes โ€” can cascade into revenue-impacting billing errors. Whether you are building a CDR parser from scratch, troubleshooting field mapping issues, or integrating VOS3000 with an external billing platform, expert guidance ensures your data pipeline is accurate from day one. ๐Ÿ“Š

๐Ÿ’ฌ WhatsApp: +8801911119966 โ€” Get immediate assistance with VOS3000 CDR pipe format parsing, field mapping, and external system integration. Our team specializes in VOS3000 CDR data extraction, billing system integration, and custom analytics development. ๐Ÿ”ง

๐Ÿ”— Explore related VOS3000 CDR and configuration 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 Text File Export Complete Pipe-Delimited Format Best Guide

VOS3000 CDR Text File Export Complete Pipe-Delimited Format Guide

๐Ÿ“Š Every VoIP operator needs reliable call data โ€” and the VOS3000 CDR text file export is the backbone of billing accuracy, traffic analysis, and regulatory compliance. When enabled, VOS3000 generates pipe-delimited text files containing every call detail record, ready for ingestion by external billing systems, analytics platforms, and fraud detection tools. Yet many operators never configure this powerful feature correctly, leaving critical data trapped inside the VOS3000 database with no external backup or integration path. ๐Ÿ“

โš™๏ธ The two parameters that control this entire process โ€” SS_CDR_RECORD_TO_FILE and SS_CDR_RECORD_NONCONNECT โ€” are straightforward to configure, but their implications for disk space, data completeness, and billing accuracy are often misunderstood. Setting SS_CDR_RECORD_TO_FILE to On creates an hourly CDR text file in the softswitch’s cdr/ directory, while SS_CDR_RECORD_NONCONNECT determines whether zero-duration calls (failed attempts, busy signals, no-answer) are included in that export. The difference between having these records and not having them can mean the difference between catching a fraud pattern early and discovering it weeks too late. ๐Ÿ”

๐ŸŽฏ This guide provides a complete walkthrough of the VOS3000 CDR text file export system: how to enable it, how the pipe-delimited format is structured, how file naming and rotation work, and how to integrate the exported data with external systems. All parameter details are sourced from the official VOS3000 2.1.8.0/2.1.9.07 English manual, ยง4.3.5.1 (page 225) and ยง4.4 (pages 241โ€“243). ๐Ÿ“˜

Table of Contents

๐Ÿ” What Is VOS3000 CDR Text File Export?

๐Ÿ“ The VOS3000 CDR text file export is a softswitch-level feature that writes call detail records to flat text files on the server filesystem. Unlike CDR records stored in the MySQL database โ€” which require the VOS3000 client or web interface to query โ€” text file exports provide a continuous, externally accessible stream of call data that can be consumed by any system capable of parsing pipe-delimited text. ๐Ÿ“‹

๐Ÿ’ก Why text file export matters:

  • ๐Ÿ”„ External billing integration: Feed CDR data directly into third-party billing platforms without database access
  • ๐Ÿ›ก๏ธ Backup redundancy: Maintain a file-based CDR copy independent of the MySQL database
  • ๐Ÿ“Š Analytics pipeline: Pipe-delimited files are easily consumed by Python, Excel, BigQuery, and custom tools
  • ๐Ÿ” Fraud detection: Real-time or near-real-time CDR analysis on exported files catches anomalies faster
  • ๐Ÿ“‹ Regulatory compliance: Many telecom regulators require CDR archival in a portable, non-proprietary format
  • ๐Ÿ”— System migration: Export historical CDR data when migrating to a new billing or CRM system

๐Ÿ“ Parameter location in VOS3000 Client: Operation management โ†’ Softswitch management โ†’ Additional settings โ†’ Softswitch parameter

๐Ÿ“‹ SS_CDR_RECORD_TO_FILE โ€” The Master Switch

๐Ÿ”ง SS_CDR_RECORD_TO_FILE is the primary parameter that enables or disables the entire text file CDR export. When set to On, VOS3000 creates hourly text files containing all CDR records in pipe-delimited format.

AttributeValue
๐Ÿ“Œ Parameter NameSS_CDR_RECORD_TO_FILE
๐Ÿ”ข Default ValueOff
โš™๏ธ Valid ValuesOn / Off
๐Ÿ“ DescriptionSave CDR as TXT (per VOS3000 manual ยง4.3.5.1, page 225)
๐Ÿ“ LocationOperation management โ†’ Softswitch management โ†’ Additional settings โ†’ Softswitch parameter

โš ๏ธ Critical note: This parameter is Off by default. Many VOS3000 deployments run for years without CDR text file export enabled, which means no file-based CDR backup exists. If the MySQL database becomes corrupted or the server experiences a disk failure, all historical CDR data stored only in the database may be lost. Enabling SS_CDR_RECORD_TO_FILE provides a critical safety net.

๐Ÿ“‹ SS_CDR_RECORD_NONCONNECT โ€” Zero-Duration Call Export

๐Ÿ“ž SS_CDR_RECORD_NONCONNECT controls whether non-connected calls โ€” those with zero hold time โ€” are included in the text file export. This includes busy signals, no-answer attempts, failed calls, and other call attempts that never established a two-way audio path.

AttributeValue
๐Ÿ“Œ Parameter NameSS_CDR_RECORD_NONCONNECT
๐Ÿ”ข Default ValueOff
โš™๏ธ Valid ValuesOn / Off
๐Ÿ“ DescriptionWhen saving CDR as TXT, contains CDR which hold time is 0s (per VOS3000 manual ยง4.3.5.1, page 225)
๐Ÿ“ LocationOperation management โ†’ Softswitch management โ†’ Additional settings โ†’ Softswitch parameter

๐Ÿ’ก Why you might want non-connected CDRs: While zero-duration calls generate no revenue, they carry essential operational intelligence. High volumes of busy signals from a specific gateway may indicate capacity problems. Repeated no-answer attempts to a destination could signal a routing misconfiguration. Patterns of failed calls from unauthorized IPs โ€” tracked by SS_CDR_RECORD_ILLEGAL โ€” are often the first sign of toll fraud. Without SS_CDR_RECORD_NONCONNECT enabled, all of this intelligence is excluded from your text file export.

๐Ÿ“ CDR Text File Naming and Storage

๐Ÿ“‚ When SS_CDR_RECORD_TO_FILE is enabled, VOS3000 creates CDR text files in the cdr/ directory under the VOS3000 installation path. The naming convention follows a precise hourly pattern documented in the official manual ยง4.4 (page 241):

๐Ÿ“‹ File Naming Convention

AttributeDetail
๐Ÿ“ FormatYYYYMMDDHH.txt
๐Ÿ“ Directorycdr/ under VOS3000 installation path
โฐ GranularityOne file per hour
๐Ÿ“ Example2013103112.txt contains CDRs ending between 12:00:00 and 12:59:59

๐Ÿ” How the hourly file system works: Each CDR is written to the file corresponding to the hour in which the call ended (stop time). A call that starts at 11:45 and ends at 12:10 will be recorded in the 12:00 hour file, not the 11:00 hour file. This means each file contains a self-contained set of CDRs that can be processed independently without worrying about time-overlap between files.

๐Ÿ“‹ CDR File Rotation and Retention

๐Ÿ”„ VOS3000 manages CDR text file rotation using two server-level parameters that control how long files are retained and how many are kept on disk:

ParameterDefaultRangePurpose
SERVER_CDR_FILE_WRITE_INTERVALNone60โ€“86400 secondsTime interval for creating new CDR files
SERVER_CDR_FILE_WRITE_MAX204810โ€“4096 filesMaximum number of CDR files retained on disk

๐Ÿ“Š Disk space planning: With the default SERVER_CDR_FILE_WRITE_MAX of 2048 files and one file per hour, VOS3000 retains approximately 85 days of CDR text files. For high-traffic systems, monitor disk usage closely โ€” each hourly file can range from a few KB on a low-traffic system to hundreds of MB on a system processing thousands of concurrent calls. To learn more about CDR file rotation and backup strategies, see our guide on VOS3000 CDR analysis and billing.

๐Ÿ“Š Pipe-Delimited CDR Format Overview

๐Ÿ”— Each line in the VOS3000 CDR text file represents one call detail record, with fields separated by the pipe character (|). The format is documented in the official VOS3000 manual ยง4.4 (pages 241โ€“243). Understanding this format is essential for parsing CDR data into external systems.

๐Ÿ“‹ CDR Line Format Structure

callerE164|calleeE164|startTime|stopTime|holdTime|endReason|
endDirection|callerGatewayId|calleeGatewayId|callerIp|calleeIp|
callerAccessE164|calleeAccessE164|callerToGatewayE164|
calleeToGatewayE164|calleeBilling|billingMode|callerPdd|calleePdd

๐Ÿ“ Field count note: The VOS3000 manual ยง4.4 documents the pipe-delimited format with 18 pipe separators, resulting in 19 columns of data. The first 18 fields (through billingMode) are the core CDR fields present in all versions, while the callerPdd and calleePdd fields provide Post-Dial Delay metrics that were added in later revisions of the software.

๐Ÿ“‹ Key CDR Fields at a Glance

#FieldDescriptionExample
1callerE164The caller ID12125551234
2calleeE164The callee ID18005559876
3startTimeCall begin time2018-12-20 11:20:18
4stopTimeCall end time2018-12-20 16:34:09
5holdTimeCall duration in milliseconds45000
6endReasonEnd reason code200
7endDirectionHangup side (0=caller, 1=callee, 2=server)0
17billingModeCharge mode (-1=no billing, 0=phone, 1=gateway, 3=phone card)0

๐Ÿ”‘ Key observations: The holdTime field records call duration in milliseconds, not seconds. This is critical for billing calculations โ€” a holdTime of 45000 means 45 seconds, not 45000 seconds. The endDirection field identifies who terminated the call (caller, callee, or server), which is essential for call termination analysis. The billingMode field determines how the call was charged and whether billing was applied at all.

โš™๏ธ Step-by-Step VOS3000 CDR Text File Export Configuration

๐Ÿ–ฅ๏ธ Follow these steps to enable and configure the VOS3000 CDR text file export on your softswitch:

Step 1: Enable CDR Text File Export ๐Ÿ“

  1. ๐Ÿ” Log in to VOS3000 Client with administrator credentials
  2. ๐Ÿ“Œ Navigate: Operation management โ†’ Softswitch management โ†’ Additional settings โ†’ Softswitch parameter
  3. ๐Ÿ” Locate SS_CDR_RECORD_TO_FILE in the parameter list
  4. โœ๏ธ Change the value from Off to On
  5. ๐Ÿ’พ Click Save to apply the configuration

โš ๏ธ Important: After enabling SS_CDR_RECORD_TO_FILE, VOS3000 will begin writing CDR text files starting from the next hourly interval. Historical CDR data from before the parameter was enabled is not retroactively exported. If you need historical data, use the CDR query interface in the VOS3000 client to export it manually, as described in our CDR analysis guide.

Step 2: Configure Non-Connected Call Recording ๐Ÿ“ž

  1. ๐Ÿ“‹ In the same Softswitch parameter section, locate SS_CDR_RECORD_NONCONNECT
  2. โœ๏ธ Change the value from Off to On if you need zero-duration call records in the export
  3. ๐Ÿ’พ Save the configuration

๐Ÿ’ก Recommendation: Enable SS_CDR_RECORD_NONCONNECT for most deployments. The additional disk space consumed by zero-duration CDRs is minimal compared to the operational value they provide. However, during a DDoS or flood attack, the volume of zero-duration CDRs can spike dramatically. If disk space is a concern during such events, you can temporarily disable this parameter to prevent disk overflow.

Step 3: Configure File Rotation Parameters ๐Ÿ”„

  1. ๐Ÿ“‹ Navigate: Operation management โ†’ Server management โ†’ Server parameter
  2. ๐Ÿ” Review SERVER_CDR_FILE_WRITE_INTERVAL โ€” set the hourly interval for new file creation (default: one file per hour)
  3. ๐Ÿ” Review SERVER_CDR_FILE_WRITE_MAX โ€” set the maximum number of CDR files to retain (default: 2048)
  4. ๐Ÿ’พ Save and restart the VOS3000 service for changes to take effect
ScenarioWRITE_INTERVALWRITE_MAXResult
โœ… Default (most deployments)3600 (1 hour)2048~85 days of CDR files retained
๐Ÿ“Š High-traffic analytics1800 (30 min)4096~85 days with finer granularity
๐Ÿ’พ Low disk space3600 (1 hour)720~30 days of retention
๐Ÿ›ก๏ธ Long-term compliance3600 (1 hour)4096~170 days of retention

๐Ÿ›ก๏ธ Another important softswitch parameter that affects CDR text file content is SS_CDR_RECORD_ILLEGAL. This parameter controls whether CDRs are generated for calls originating from unauthorized IP addresses โ€” calls that VOS3000 rejects as illegal or unauthorized.

AttributeValue
๐Ÿ“Œ Parameter NameSS_CDR_RECORD_ILLEGAL
๐Ÿ”ข Default ValueOn
๐Ÿ“ DescriptionRecord illegal call (per VOS3000 manual ยง4.3.5.1, page 225)

๐Ÿ”’ Unlike SS_CDR_RECORD_NONCONNECT (which defaults to Off), SS_CDR_RECORD_ILLEGAL defaults to On. This means VOS3000 is configured by default to record CDRs for hack attempts and unauthorized call attempts. These records appear in the text file export with a special billing mode code of -1 (no billing), making them easy to filter and analyze separately. For more details on how VOS3000 handles unauthorized calls, see our guide on illegal call detection and prevention.

๐Ÿ› ๏ธ Parsing VOS3000 CDR Text Files for External Systems

๐Ÿ“Š Once the VOS3000 CDR text file export is configured, the next step is integrating the exported data with your external systems. The pipe-delimited format is universally supported by programming languages, databases, and analytics tools.

๐Ÿ“‹ Parsing Methods Comparison

MethodBest ForComplexityReal-Time
๐Ÿ Python scriptCustom analytics, billing importMediumNear-real-time (cron)
๐Ÿ—„๏ธ MySQL LOAD DATADatabase import, reportingLowBatch (hourly)
๐Ÿ“Š Excel/CSV conversionManual review, one-time analysisLowManual
๐Ÿ”„ Logstash/FluentdElasticsearch, SIEM integrationHighNear-real-time

๐Ÿ“‹ Python Parsing Example

import csv

# VOS3000 CDR field names (per manual ยง4.4)
CDR_FIELDS = [
    'callerE164', 'calleeE164', 'startTime', 'stopTime',
    'holdTime', 'endReason', 'endDirection',
    'callerGatewayId', 'calleeGatewayId',
    'callerIp', 'calleeIp',
    'callerAccessE164', 'calleeAccessE164',
    'callerToGatewayE164', 'calleeToGatewayE164',
    'calleeBilling', 'billingMode',
    'callerPdd', 'calleePdd'
]

def parse_cdr_file(filepath):
    """Parse VOS3000 CDR text file into list of dictionaries."""
    records = []
    with open(filepath, 'r') as f:
        reader = csv.reader(f, delimiter='|')
        for row in reader:
            if len(row) >= 17:  # Minimum core fields
                record = dict(zip(CDR_FIELDS[:len(row)], row))
                records.append(record)
    return records

# Usage: Parse a CDR file and filter connected calls
cdr_data = parse_cdr_file('/home/vos3000/cdr/2026042612.txt')
connected = [r for r in cdr_data if int(r.get('holdTime', 0)) > 0]
print(f"Total CDRs: {len(cdr_data)}, Connected: {len(connected)}")

๐Ÿ›ก๏ธ Common VOS3000 CDR Text File Export Problems and Solutions

โš ๏ธ Misconfigurations and misunderstandings about the CDR text file export can lead to data loss, disk space issues, or incomplete records. Here are the most common problems and their solutions:

โŒ Problem 1: No CDR Text Files Being Generated

๐Ÿ” Symptom: The cdr/ directory is empty or does not contain the expected hourly text files.

๐Ÿ’ก Cause: SS_CDR_RECORD_TO_FILE is still set to Off (the default value). Many operators assume CDR files are generated automatically, but this feature must be explicitly enabled.

โœ… Solution:

  • ๐Ÿ”ง Navigate to Softswitch parameter and set SS_CDR_RECORD_TO_FILE = On
  • ๐Ÿ’พ Save the configuration and wait for the next hourly interval
  • ๐Ÿ“ Verify the cdr/ directory exists and has proper write permissions
  • ๐Ÿ“‹ Confirm with the VOS3000 system parameter guide that no other settings are blocking file creation

โŒ Problem 2: Missing Zero-Duration Call Records

๐Ÿ” Symptom: The CDR text files only contain records for connected calls. Failed calls, busy signals, and no-answer attempts are absent.

๐Ÿ’ก Cause: SS_CDR_RECORD_NONCONNECT is set to Off (default), which excludes zero-duration calls from the text file export.

โœ… Solution:

  • ๐Ÿ“ž Set SS_CDR_RECORD_NONCONNECT = On in Softswitch parameter
  • ๐Ÿ“Š Be aware this increases file sizes โ€” monitor disk usage after enabling
  • ๐Ÿ” For fraud detection purposes, this setting is strongly recommended

โŒ Problem 3: Disk Space Exhaustion from CDR Files

๐Ÿ” Symptom: The server runs low on disk space, and the cdr/ directory contains thousands of large CDR text files.

๐Ÿ’ก Cause: SERVER_CDR_FILE_WRITE_MAX is set too high, or an external script is not archiving and cleaning up old CDR files.

โœ… Solution:

  • ๐Ÿ”„ Reduce SERVER_CDR_FILE_WRITE_MAX to a lower value (e.g., 720 for ~30 days)
  • ๐Ÿ“ Implement a cron job to move CDR files older than X days to archive storage
  • ๐Ÿ“Š Monitor disk usage with the VOS3000 disk alarm feature
  • ๐Ÿ’พ Consider compressing older CDR files with gzip to save space

โŒ Problem 4: Parsing Errors Due to Extra Pipe Characters

๐Ÿ” Symptom: External parsing scripts produce incorrect field alignment or data corruption.

๐Ÿ’ก Cause: Caller or callee E164 fields contain unexpected characters, or the number of pipe separators varies between CDR records.

โœ… Solution:

  • ๐Ÿ”ง Use a robust parser that handles variable field counts gracefully
  • ๐Ÿ“‹ Always validate the number of fields per line before processing
  • ๐Ÿ“Š Reference the official VOS3000 manual ยง4.4 (page 241) for the exact field specification

๐Ÿ’ก VOS3000 CDR Text File Export Best Practices

๐ŸŽฏ Follow these best practices to get the most from your VOS3000 CDR text file export configuration:

Best PracticeRecommendationReason
๐Ÿ“ Always enable SS_CDR_RECORD_TO_FILESet to Onโœ… Provides file-based CDR backup independent of MySQL
๐Ÿ“ž Enable SS_CDR_RECORD_NONCONNECTSet to On for most deployments๐Ÿ” Captures failed call data for fraud detection and quality analysis
๐Ÿ”„ Archive CDR files regularlyMove files older than 30 days to archive๐Ÿ’พ Prevents disk space exhaustion on active server
๐Ÿ“Š Validate CDR data dailyCheck record counts and file sizes๐Ÿ›ก๏ธ Early detection of data export problems
๐Ÿ”’ Set proper file permissionsRestrict cdr/ directory access๐Ÿ” CDR files contain sensitive call data and IP addresses
๐Ÿ“ก Consider real-time forwardingUse SERVER_CDR_REAL_TIME_REPORT_SERVERโšก For immediate CDR delivery to external billing systems

๐Ÿ’ก Pro tip: The VOS3000 CDR text file export works best as part of a comprehensive data strategy. Combine the text file export with the VOS3000 billing system for complete revenue tracking, and use the exported data to build custom dashboards that go beyond what the VOS3000 client interface provides. For operators who need real-time CDR delivery rather than hourly file batches, the SERVER_CDR_REAL_TIME_REPORT_SERVER parameter provides an alternative integration path.

๐Ÿ“Š Complete VOS3000 CDR Export Parameter Reference

๐Ÿ“‹ Here is the complete reference table for all parameters related to CDR text file export, sourced from the official VOS3000 2.1.8.0/2.1.9.07 English manual:

ParameterDefaultCategoryPurpose
SS_CDR_RECORD_TO_FILEOffSoftswitchEnable CDR text file export
SS_CDR_RECORD_NONCONNECTOffSoftswitchInclude zero-duration calls in export
SS_CDR_RECORD_ILLEGALOnSoftswitchRecord illegal/unauthorized call CDRs
SERVER_CDR_FILE_WRITE_INTERVALNoneServerCDR file creation interval (60โ€“86400 seconds)
SERVER_CDR_FILE_WRITE_MAX2048ServerMaximum CDR files retained (10โ€“4096)
SERVER_CDR_REAL_TIME_REPORT_SERVER(blank)ServerReal-time CDR forwarding server address
SERVER_QUERY_CDR_DENY_TIME(blank)ServerNo CDR query time (blackout hours)
SERVER_QUERY_CDR_MAX_DAY_INTERVAL31ServerMaximum CDR query date range (days)
SERVER_MAX_CDR_PENDING_LIST_LENGTH100000ServerCDR queue length limit (10000โ€“100000)

โ“ Frequently Asked Questions

โ“ How do I enable VOS3000 CDR text file export?

๐Ÿ“ To enable the VOS3000 CDR text file export, navigate to Operation management โ†’ Softswitch management โ†’ Additional settings โ†’ Softswitch parameter and set SS_CDR_RECORD_TO_FILE to On. This parameter is Off by default, so it must be explicitly enabled. After saving the configuration, VOS3000 will begin creating hourly CDR text files in the cdr/ directory starting from the next hourly interval. The files follow the naming convention YYYYMMDDHH.txt as documented in the VOS3000 manual ยง4.4.

โ“ What is the difference between SS_CDR_RECORD_TO_FILE and SS_CDR_RECORD_NONCONNECT?

๐Ÿ”ง SS_CDR_RECORD_TO_FILE is the master switch that enables CDR text file export entirely. Without it set to On, no CDR text files are created at all. SS_CDR_RECORD_NONCONNECT only takes effect when SS_CDR_RECORD_TO_FILE is already On โ€” it controls whether zero-duration call records (failed calls, busy signals, no-answer attempts) are included in the exported text files. When SS_CDR_RECORD_NONCONNECT is Off, only connected calls with non-zero hold time appear in the export.

โ“ Where are VOS3000 CDR text files stored?

๐Ÿ“‚ VOS3000 CDR text files are stored in the cdr/ directory under the VOS3000 installation path. Each file is named using the format YYYYMMDDHH.txt, where each file contains all CDRs for calls that ended during that specific hour. For example, the file 2026042612.txt contains all CDRs for calls that ended between 12:00:00 and 12:59:59 on April 26, 2026. This file structure is documented in the official VOS3000 manual ยง4.4 (page 241).

โ“ Can I export historical CDR data that was generated before enabling text file export?

๐Ÿ“‹ No, the VOS3000 CDR text file export only generates files for new calls after the feature is enabled. Historical CDR data that was generated while SS_CDR_RECORD_TO_FILE was Off is only available through the VOS3000 client CDR query interface or by querying the MySQL database directly. If you need to export historical data, use the CDR query function in the client and export the results manually. This is why it is strongly recommended to enable SS_CDR_RECORD_TO_FILE from the very first day of deployment.

โ“ How much disk space do VOS3000 CDR text files consume?

๐Ÿ’พ Disk space consumption depends entirely on your call volume. Each CDR record is approximately 200โ€“350 bytes in the pipe-delimited text format. A system processing 100,000 calls per day would generate roughly 25โ€“35 MB of CDR text data per day, or about 1 GB per month. With the default SERVER_CDR_FILE_WRITE_MAX of 2048 files (roughly 85 days of retention), a mid-traffic system would need approximately 3โ€“4 GB of dedicated disk space for CDR files. Always monitor disk usage and configure VOS3000 disk alarms to receive alerts before space runs out.

โ“ What is the pipe delimiter character used in VOS3000 CDR text files?

๐Ÿ”— The VOS3000 CDR text file format uses the vertical bar or pipe character (|, ASCII 124) as the field delimiter. Each line in the file represents one call detail record, with fields separated by pipe characters. This format is widely supported by data processing tools, programming languages (Python, PHP, Perl), database import utilities (MySQL LOAD DATA INFILE), and spreadsheet applications. When parsing, always split on the pipe character and validate the expected field count.

๐Ÿ“ž Need Expert Help with VOS3000 CDR Text File Export?

๐Ÿ”ง Proper VOS3000 CDR text file export configuration ensures your billing data is complete, your audit trail is intact, and your external systems receive the call data they need. Whether you are setting up CDR export for the first time, troubleshooting missing records, or integrating CDR data with an external billing platform, expert guidance saves time and prevents costly data gaps. ๐Ÿ“Š

๐Ÿ’ฌ WhatsApp: +8801911119966 โ€” Get immediate assistance with VOS3000 CDR text file export setup, parsing, and integration. Our team specializes in VOS3000 softswitch configuration, billing system integration, and custom CDR analytics solutions. ๐Ÿ”ง

๐Ÿ”— Learn more about related VOS3000 CDR and billing configurations:


๐Ÿ“ž 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 File Rotation Robust Backup Write Interval Best Configuration

VOS3000 CDR File Rotation Robust Backup Write Interval Configuration

๐Ÿ“‹ Every VoIP operator knows that CDR data is the lifeblood of billing reconciliation โ€” lose your call records, and you lose revenue. The VOS3000 CDR file rotation system, controlled by SERVER_CDR_FILE_WRITE_INTERVAL and SERVER_CDR_FILE_WRITE_MAX, provides a robust backup mechanism that writes call records to text files independently of the primary database. When configured correctly, this ensures you always have a secondary copy of every CDR โ€” even during database outages, server restarts, or unexpected failures. ๐Ÿ›ก๏ธ

โš ๏ธ But misconfigure the rotation parameters, and you risk two catastrophic outcomes: disk overflow from uncontrolled CDR file accumulation, or missing records if the rotation window is too long during peak traffic. The VOS3000 CDR file rotation parameters give you precise control over how frequently backup files are generated and how many are retained โ€” balancing data integrity against disk consumption. This guide covers every detail from the official VOS3000 2.1.9.07 manual, with no fabricated values. ๐Ÿ”ง

๐ŸŽฏ Need help configuring your VOS3000 CDR backup? Contact our team at WhatsApp: +8801911119966 for expert assistance with CDR rotation, billing setup, and complete VOS3000 deployment. ๐Ÿ’ฌ

Table of Contents

๐Ÿ” What Is VOS3000 CDR File Rotation?

๐Ÿ“Š The VOS3000 CDR file rotation system is an additional backup mechanism that writes call detail records to plain text files on the server filesystem. This operates alongside the primary CDR database, providing redundancy and enabling external analytics integration. The system generates pipe-delimited text files in the cdr directory beneath the VOS3000 installation directory, with one file created per configured time interval. ๐Ÿ“

๐Ÿ’ก Why this matters: The backup CDR file system serves several critical purposes:

  • ๐Ÿ›ก๏ธ Disaster recovery: If the database becomes corrupted or unavailable, text files remain intact on disk
  • ๐Ÿ“Š External analytics: Pipe-delimited files are easy to parse with Python, awk, or business intelligence tools
  • ๐Ÿ”„ Regulatory compliance: Many telecom regulators require CDR archival in flat-file format
  • ๐Ÿ’ฐ Billing reconciliation: Compare database CDRs against file CDRs to detect discrepancies
  • ๐Ÿ“ก Real-time monitoring: Some operators tail the CDR files for live traffic visibility

๐Ÿ”‘ Key distinction: The VOS3000 CDR file rotation is a backup mechanism. It does not replace the database CDR storage. The primary CDR records are always written to the database first; the file-based system creates a secondary copy that can be used independently.

โš™๏ธ SERVER_CDR_FILE_WRITE_INTERVAL โ€” The Core Parameter

โฑ๏ธ SERVER_CDR_FILE_WRITE_INTERVAL defines the time interval (in seconds) at which the softswitch creates new CDR text files. Each time this interval elapses, a new file is opened and the previous file is finalized for reading. ๐Ÿ“‹

AttributeValue
๐Ÿ“Œ Parameter NameSERVER_CDR_FILE_WRITE_INTERVAL
๐Ÿ”ข Default ValueNone (not set by default)
๐Ÿ“ UnitSeconds
๐Ÿ“ Range60โ€“86400
๐Ÿ“ DescriptionAdditional write call record file, the new file created time interval (seconds)
๐Ÿ“ LocationOperation management โ†’ Softswitch management โ†’ Additional settings โ†’ Server parameter

๐Ÿ’ก How the interval works: When you set SERVER_CDR_FILE_WRITE_INTERVAL to a value such as 3600 (1 hour), the softswitch creates a new CDR text file every hour. All CDRs whose end time falls within that hour are written to the corresponding file. At the end of the interval, the file is closed and a new one is opened. The file naming convention follows the format YYYYMMDDHH.txt โ€” for example, 2026042612.txt contains all CDRs that ended between 12:00 and 13:00 on April 26, 2026.

๐ŸŽฏ Interval Value Recommendations by Traffic Volume

๐Ÿ“ก The optimal interval depends heavily on your call volume. Higher traffic demands shorter intervals to prevent individual files from becoming too large: ๐Ÿ’ก

Traffic VolumeRecommended IntervalSeconds ValueRationale
๐Ÿ“ž Low (<50 CPS)1 hour3600โœ… Manageable file size; hourly granularity
๐Ÿ“Š Medium (50โ€“200 CPS)30 minutes1800๐Ÿ”ง Prevents oversized files during peaks
๐Ÿ”ฅ High (200+ CPS)15 minutes900๐Ÿ›ก๏ธ Keeps files manageable; easier parsing
โš ๏ธ Extreme (DDoS scenario)5 minutes300๐Ÿšจ Rapid rotation prevents disk fill

โš ๏ธ Important: The minimum allowed value is 60 seconds and the maximum is 86400 seconds (24 hours). Setting the interval below 60 seconds is not supported. If your traffic is so high that even 5-minute files are too large, consider increasing SERVER_CDR_FILE_WRITE_MAX to retain more files, or implementing an external script that periodically archives old files to remote storage.

๐Ÿ“ฆ SERVER_CDR_FILE_WRITE_MAX โ€” Rotation File Count Limit

๐Ÿ“ While SERVER_CDR_FILE_WRITE_INTERVAL controls how often new files are created, SERVER_CDR_FILE_WRITE_MAX controls how many backup CDR files are retained on disk. This parameter prevents uncontrolled disk consumption by automatically deleting the oldest files when the count exceeds the limit. ๐Ÿ—‘๏ธ

AttributeValue
๐Ÿ“Œ Parameter NameSERVER_CDR_FILE_WRITE_MAX
๐Ÿ”ข Default Value2048
๐Ÿ“ UnitNumber of files
๐Ÿ“ Range10โ€“4096
๐Ÿ“ DescriptionAdditional write call record file, the maximum number of reserved file
๐Ÿ“ LocationOperation management โ†’ Softswitch management โ†’ Additional settings โ†’ Server parameter

๐Ÿ”„ How rotation works: When the number of CDR text files exceeds SERVER_CDR_FILE_WRITE_MAX, the oldest files are automatically deleted. This creates a sliding window of retained CDR data โ€” at any given time, you have at most the most recent N files on disk, where N equals SERVER_CDR_FILE_WRITE_MAX.

๐Ÿ“Š Calculating Retention Period from Rotation Parameters

๐Ÿงฎ The total retention period depends on both the write interval and the maximum file count. Here is the formula: ๐Ÿ’ก

๐Ÿ“‹ VOS3000 CDR File Retention Calculation:

Retention Period = SERVER_CDR_FILE_WRITE_INTERVAL ร— SERVER_CDR_FILE_WRITE_MAX

Example 1 (Default Settings):
  Interval = 3600s (1 hour)  ร—  Max Files = 2048
  Retention = 3600 ร— 2048 = 7,372,800 seconds โ‰ˆ 85.3 days

Example 2 (High Traffic):
  Interval = 1800s (30 min)  ร—  Max Files = 2048
  Retention = 1800 ร— 2048 = 3,686,400 seconds โ‰ˆ 42.7 days

Example 3 (Maximum Retention):
  Interval = 86400s (24 hours)  ร—  Max Files = 4096
  Retention = 86400 ร— 4096 = 353,894,400 seconds โ‰ˆ 11.2 years

Example 4 (Short Retention, Frequent Rotation):
  Interval = 300s (5 min)  ร—  Max Files = 2048
  Retention = 300 ร— 2048 = 614,400 seconds โ‰ˆ 7.1 days

โš ๏ธ Critical warning: A shorter interval with the same file count means shorter total retention. If you decrease the interval for performance reasons, you must proportionally increase the file count to maintain the same retention period. Otherwise, you may lose historical CDR backup data faster than expected. ๐Ÿ”ฅ

๐Ÿ–ฅ๏ธ Enabling VOS3000 CDR File Rotation

๐Ÿ”ง The VOS3000 CDR file rotation requires two conditions to be met before it generates backup files: the SS_CDR_RECORD_TO_FILE parameter must be enabled, and the SERVER_CDR_FILE_WRITE_INTERVAL must be set to a valid value. ๐Ÿ“‹

Step 1: Enable CDR Text File Export ๐Ÿ“„

  1. ๐Ÿ” Log in to VOS3000 Client
  2. ๐Ÿ“Œ Navigate: Operation management โ†’ Softswitch management โ†’ Additional settings โ†’ Softswitch parameter
  3. ๐Ÿ” Locate SS_CDR_RECORD_TO_FILE
  4. โœ๏ธ Set value to On
AttributeValue
๐Ÿ“Œ Parameter NameSS_CDR_RECORD_TO_FILE
๐Ÿ”ข Default ValueOff
๐Ÿ“ DescriptionSave CDR as TXT โ€” enables the backup CDR text file system
๐Ÿ“ LocationOperation management โ†’ Softswitch management โ†’ Additional settings โ†’ Softswitch parameter

Step 2: Configure Write Interval โฑ๏ธ

  1. ๐Ÿ“Œ Navigate: Operation management โ†’ Softswitch management โ†’ Additional settings โ†’ Server parameter
  2. ๐Ÿ” Locate SERVER_CDR_FILE_WRITE_INTERVAL
  3. โœ๏ธ Set the desired interval value (60โ€“86400 seconds) based on your traffic volume

Step 3: Configure Maximum File Count ๐Ÿ“

  1. ๐Ÿ” In the same Server parameter section, locate SERVER_CDR_FILE_WRITE_MAX
  2. โœ๏ธ Set the maximum number of files to retain (10โ€“4096, default: 2048)
  3. ๐Ÿ’พ Save and apply the configuration

Step 4: Verify CDR File Generation โœ…

๐Ÿ–ฅ๏ธ After configuration, verify that files are being generated in the CDR directory:

# Check the CDR directory on the VOS3000 server
ls -la /home/vos3000/cdr/

# Expected output โ€” files named by YYYYMMDDHH convention:
# -rw-r--r-- 1 vos3000 vos3000  245120 Apr 26 12:00 2026042612.txt
# -rw-r--r-- 1 vos3000 vos3000  189340 Apr 26 13:00 2026042613.txt
# -rw-r--r-- 1 vos3000 vos3000  312500 Apr 26 14:00 2026042614.txt

# Verify rotation is working โ€” old files should be auto-deleted
# when count exceeds SERVER_CDR_FILE_WRITE_MAX
ls -1 /home/vos3000/cdr/ | wc -l

๐Ÿ“Š For detailed CDR file format information, see our VOS3000 CDR pipe format reference guide.

๐Ÿ”„ VOS3000 CDR File Rotation and Disk Space Management

๐Ÿ’พ One of the most critical aspects of VOS3000 CDR file rotation is managing disk space consumption. Each CDR record written to the text file contains 18 pipe-delimited fields. A typical single CDR line is approximately 200โ€“350 bytes depending on the length of phone numbers, IP addresses, and other variable-length fields. ๐Ÿ“

๐Ÿ“ Estimating Disk Space Requirements

๐Ÿ“Š Use this calculation to estimate your CDR file storage needs: ๐Ÿ’ก

MetricFormulaExample (100 CPS)
CDR lines per hourCPS ร— 3600360,000
File size per hourLines ร— 300 bytes (avg)~108 MB/hour
Daily disk usageFile/hour ร— 24~2.6 GB/day
With 2048 hourly files2048 ร— 108 MB~221 GB total

โš ๏ธ Key insight: At 100 CPS with hourly intervals and the default 2048 file limit, you need approximately 221 GB of disk space for CDR files alone. This does not account for the database, logs, or other system files. Ensure your server has adequate storage, or implement an external archival strategy. For help sizing your VOS3000 server, see our concurrent call load test guide. ๐Ÿ”ง

๐Ÿ›ก๏ธ Common VOS3000 CDR File Rotation Problems and Solutions

โŒ Misconfigured rotation parameters cause a range of issues from missing records to disk overflow. Here are the most common problems and their solutions: ๐Ÿ”

โŒ Problem 1: CDR Files Not Being Generated

๐Ÿ” Symptom: The CDR directory exists but no text files are being created, even though calls are flowing through the system.

๐Ÿ’ก Cause: The most common reason is that SS_CDR_RECORD_TO_FILE is set to Off (default). Without enabling this parameter, the VOS3000 CDR file rotation system is completely inactive regardless of the interval and max file settings.

โœ… Solutions:

  • ๐Ÿ”ง Set SS_CDR_RECORD_TO_FILE to On in Softswitch parameter settings
  • ๐Ÿ“Š Verify SERVER_CDR_FILE_WRITE_INTERVAL is set to a valid value between 60 and 86400
  • ๐Ÿ“ Check that the cdr directory exists beneath the VOS3000 installation directory and has write permissions
  • ๐Ÿ” Check the softswitch logs for any write errors

โŒ Problem 2: Disk Space Exhausting Rapidly

๐Ÿ” Symptom: The server runs out of disk space quickly, and the CDR directory contains a very large number of files.

๐Ÿ’ก Cause: SERVER_CDR_FILE_WRITE_MAX is set too high, or the write interval is very short, causing many small files that collectively consume large amounts of disk space. Alternatively, the automatic file deletion mechanism may not be working correctly.

โœ… Solutions:

  • ๐Ÿ“ Reduce SERVER_CDR_FILE_WRITE_MAX to a value that fits within your available disk space
  • โฑ๏ธ Increase SERVER_CDR_FILE_WRITE_INTERVAL to create fewer, larger files
  • ๐Ÿ”„ Implement an external archival script that moves old CDR files to remote storage (NFS, S3, etc.)
  • ๐Ÿ“Š Monitor disk usage with a cron job that alerts you when usage exceeds 80%

โŒ Problem 3: Historical CDR Files Disappearing Too Quickly

๐Ÿ” Symptom: You need to look up CDR data from 30 days ago, but the oldest available file is only from 10 days ago.

๐Ÿ’ก Cause: The retention period (interval ร— max files) is shorter than your required retention window. This happens when the interval is decreased without proportionally increasing the file count.

โœ… Solutions:

  • ๐Ÿ“ Calculate your required retention: Required Max Files = Required Days ร— 86400 / Interval
  • ๐Ÿ“ฆ Increase SERVER_CDR_FILE_WRITE_MAX to the calculated value (up to 4096 maximum)
  • ๐Ÿ—„๏ธ If you need more than 4096 files, implement external archival before rotation deletes them
  • ๐Ÿ“‹ For detailed CDR querying guidance, see our VOS3000 CDR analysis and billing guide

โŒ Problem 4: Zero-Duration Calls Flooding CDR Files

๐Ÿ” Symptom: CDR text files are much larger than expected, filled with records for calls that never connected (0-second duration).

๐Ÿ’ก Cause: The SS_CDR_RECORD_NONCONNECT parameter is set to On, causing all non-connected calls (failed attempts, busy, no answer) to be included in the text file export along with successful calls.

โœ… Solutions:

  • โš™๏ธ Set SS_CDR_RECORD_NONCONNECT to Off to exclude zero-duration calls from the file export
  • ๐Ÿ“Š Keep it On only if you need failed call data for analytics or fraud detection
  • ๐Ÿ›ก๏ธ During DDoS attacks, set SERVER_BILLING_RECORD_ZERO_HOLD_TIME to Off to prevent database overload โ€” see our DDoS protection guide

๐Ÿ“‹ Complete VOS3000 CDR File Rotation Parameter Reference

๐Ÿ“Š Here is the complete reference table for all parameters related to CDR file rotation, sourced from the official VOS3000 2.1.9.07 manual: ๐Ÿ”ง

ParameterDefaultRangePurpose
SERVER_CDR_FILE_WRITE_INTERVALNone60โ€“86400sTime interval for new CDR file creation
SERVER_CDR_FILE_WRITE_MAX204810โ€“4096Maximum number of CDR files to retain
SS_CDR_RECORD_TO_FILEOffOn/OffEnable/disable CDR text file export
SS_CDR_RECORD_NONCONNECTOffOn/OffInclude non-connected calls (0s) in file export
SS_CDR_RECORD_ILLEGALOnOn/OffRecord illegal calls in CDR files
SERVER_CDR_REAL_TIME_REPORT_SERVERNoneIP:PortForward CDRs to external server in real-time

๐Ÿ“ All server parameters are located at: Navigation โ†’ Operation management โ†’ Softswitch management โ†’ Additional settings โ†’ Server parameter. Softswitch parameters are at the same path under Softswitch parameter.

๐Ÿ’ก VOS3000 CDR File Rotation Best Practices

๐ŸŽฏ Follow these best practices to ensure your VOS3000 CDR file rotation is both reliable and efficient: ๐Ÿ“‹

Best PracticeRecommendationReason
๐Ÿ“Š Calculate retention needsInterval ร— Max Files = Retentionโœ… Ensures you keep enough historical data
๐Ÿ“ Implement external archivalCron job to copy old files to remote storage๐Ÿ›ก๏ธ Prevents data loss when rotation deletes files
โฑ๏ธ Match interval to trafficHigher CPS = shorter interval๐Ÿ”ง Keeps individual file sizes manageable
๐Ÿ’พ Monitor disk spaceAlert at 80% usage threshold๐Ÿšจ Prevents unexpected disk-full outages
๐Ÿ”„ Test recovery regularlyParse backup files monthly to verify integrity๐Ÿ“‹ Confirms files are usable when needed
๐Ÿ” Secure CDR directoryRestrict file permissions to vos3000 user only๐Ÿ›ก๏ธ CDRs contain sensitive billing data

๐Ÿ’ฌ Questions about your VOS3000 CDR file rotation setup? Reach out at WhatsApp: +8801911119966 โ€” our VOS3000 experts can help you optimize rotation settings for your traffic volume and retention requirements. ๐Ÿ“ž

โ“ Frequently Asked Questions

โ“ What is the default value for SERVER_CDR_FILE_WRITE_INTERVAL?

๐Ÿ“‹ The default value for SERVER_CDR_FILE_WRITE_INTERVAL is None (not set). This means that CDR file rotation is not active by default. You must explicitly set a value between 60 and 86400 seconds and enable SS_CDR_RECORD_TO_FILE to On before the system generates backup CDR text files. Without this configuration, CDR records are only stored in the database. ๐Ÿ’ก

โ“ How does VOS3000 CDR file rotation prevent disk overflow?

๐Ÿ›ก๏ธ The VOS3000 CDR file rotation uses SERVER_CDR_FILE_WRITE_MAX to enforce a maximum number of retained files. When the file count exceeds this limit, the oldest files are automatically deleted. For example, with the default value of 2048 and an hourly interval, the system retains approximately 85 days of CDR files. Once the 2049th file is created, the oldest file is removed, maintaining a consistent disk footprint. This sliding window mechanism ensures the CDR directory never grows beyond a predictable size. ๐Ÿ“

โ“ Can I change the VOS3000 CDR file rotation interval without restarting?

๐Ÿ”ง Server parameters in VOS3000 typically take effect after saving and applying the configuration through the VOS3000 Client interface. While some parameters may apply immediately, it is recommended to verify that the new interval is in effect by checking the timestamps of newly created CDR files. If the old interval persists, a softswitch service restart may be required. Always test configuration changes during a maintenance window to avoid any disruption to CDR recording. ๐Ÿ“Š

โ“ What is the relationship between SS_CDR_RECORD_TO_FILE and SERVER_CDR_FILE_WRITE_INTERVAL?

๐Ÿ”— SS_CDR_RECORD_TO_FILE is the master switch that enables or disables the entire CDR text file system. SERVER_CDR_FILE_WRITE_INTERVAL controls the frequency of file creation within that system. If SS_CDR_RECORD_TO_FILE is Off (default), no CDR files are generated regardless of the interval setting. If it is On but the interval is not set (None), the system may not create files properly. Both parameters must be correctly configured for the VOS3000 CDR file rotation to function. ๐ŸŽฏ

โ“ How do I include non-connected calls in the CDR text files?

๐Ÿ“Š By default, SS_CDR_RECORD_NONCONNECT is set to Off, which means only successfully connected calls (calls with duration greater than 0 seconds) are written to the CDR text files. To include failed call attempts, busy calls, and no-answer calls, set SS_CDR_RECORD_NONCONNECT to On. Be aware that enabling this parameter significantly increases the number of CDR records per file, especially during traffic spikes or attack scenarios. For DDoS protection guidance, see our zero duration CDR control guide. โš ๏ธ

โ“ Where are VOS3000 CDR text files stored on the server?

๐Ÿ“ CDR text files are stored in the cdr directory beneath the VOS3000 installation directory. The file naming convention is YYYYMMDDHH.txt, where YYYY is the year, MM is the month, DD is the day, and HH is the hour. Each file contains all CDRs whose end time falls within that time window. For example, 2026042614.txt contains CDRs for calls that ended between 14:00 and 15:00 on April 26, 2026. The files use pipe-delimited format with 18 fields per record โ€” see our CDR pipe format reference for complete field documentation. ๐Ÿ“‹

๐Ÿ“ž Need Expert Help with VOS3000 CDR File Rotation?

๐Ÿ”ง Proper VOS3000 CDR file rotation configuration is essential for ensuring billing data integrity, meeting regulatory retention requirements, and preventing disk overflow disasters. Whether you need to set up CDR backup for the first time, tune rotation parameters for high traffic, or implement an external archival strategy, our VOS3000 experts are here to help. ๐Ÿ›ก๏ธ

๐Ÿ’ฌ Contact us at WhatsApp: +8801911119966 for professional VOS3000 deployment, CDR configuration, and ongoing support. We help VoIP operators worldwide optimize their softswitch performance and billing accuracy. ๐ŸŒ

๐Ÿ“– Explore more VOS3000 guides: CDR analysis and billing, billing system overview, and parameter description reference. ๐Ÿ”—


๐Ÿ“ž 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 Query Date Range Maximum Interval Limit Best Configuration

VOS3000 CDR Query Date Range Maximum Interval Limit Configuration

๐Ÿ“Š A single CDR query spanning 90 days on a high-traffic VOS3000 system can return tens of millions of records โ€” enough to overwhelm the database, exhaust client memory, and freeze the VOS3000 interface for minutes. The VOS3000 CDR query date range limit, controlled by SERVER_QUERY_CDR_MAX_DAY_INTERVAL, prevents this by capping the maximum number of days a user can query in a single CDR search. The default of 31 days is designed to balance operational needs against database performance โ€” but understanding how to work within and around this limit is essential for every VOS3000 operator. โฑ๏ธ

๐Ÿ”ง Whether you are a reseller who needs to pull quarterly reports or an administrator protecting your database from runaway queries, mastering the VOS3000 CDR query date range configuration is critical. This guide covers the parameter details from the official VOS3000 2.1.9.07 manual, practical workarounds for large-range queries, and how this limit works alongside other CDR access controls. ๐Ÿ“‹

๐Ÿ’ฌ Need help optimizing your VOS3000 CDR query performance? Contact our team at WhatsApp: +8801911119966 for expert database tuning and configuration support. ๐Ÿ’ก

Table of Contents

๐Ÿ” What Is VOS3000 CDR Query Date Range Limit?

๐Ÿ“ The VOS3000 CDR query date range limit specifies the maximum number of days a user can include in a single CDR query. When a user attempts to search CDRs with a start and end date that spans more than the configured maximum, the query is rejected with an error message indicating the date range exceeds the allowed limit. ๐Ÿšซ

๐Ÿ’ก Why this limit exists:

  • ๐Ÿ“Š Database performance: Large date range queries scan millions of rows, consuming CPU, memory, and I/O resources on the database server
  • ๐Ÿ–ฅ๏ธ Client stability: Returning millions of CDR records to the VOS3000 Client can cause memory exhaustion and application crashes
  • โฑ๏ธ Query timeout prevention: Long-running queries may time out before completion, wasting resources without returning results
  • ๐Ÿ›ก๏ธ Fair resource sharing: Prevents a single user from monopolizing database resources with an excessively broad query
  • ๐Ÿ“ž Operational continuity: Ensures the VOS3000 system remains responsive for real-time call processing even during heavy CDR analysis

โš™๏ธ SERVER_QUERY_CDR_MAX_DAY_INTERVAL โ€” The Core Parameter

๐Ÿ“ SERVER_QUERY_CDR_MAX_DAY_INTERVAL defines the maximum number of days allowed in a CDR query’s date range. Any query with a date range exceeding this value is automatically rejected. ๐Ÿ“‹

AttributeValue
๐Ÿ“Œ Parameter NameSERVER_QUERY_CDR_MAX_DAY_INTERVAL
๐Ÿ”ข Default Value31
๐Ÿ“ UnitDays
๐Ÿ“ DescriptionMaximum Interval for CDR Inquiry (Day)
๐Ÿ“ LocationOperation management โ†’ Softswitch management โ†’ Additional settings โ†’ Server parameter

๐Ÿ”ง How the 31-day default works: When a user queries CDRs with a date range of, say, January 1 to February 15 (45 days), VOS3000 calculates the interval: 45 days. Since this exceeds the default SERVER_QUERY_CDR_MAX_DAY_INTERVAL of 31, the query is rejected and the user receives an error. The user must then narrow the search to a maximum of 31 days โ€” for example, January 1 to January 31.

๐Ÿ“‹ VOS3000 CDR Query Date Range Limit Examples

๐Ÿ“Š Here are practical examples showing how the limit affects different query scenarios: ๐Ÿ’ก

Query Date RangeDays SpannedDefault Limit (31)Result
Apr 1 โ€“ Apr 1515 daysโœ… Within limitQuery executes normally
Apr 1 โ€“ Apr 3030 daysโœ… Within limitQuery executes normally
Apr 1 โ€“ May 131 daysโœ… Exactly at limitQuery executes (31 โ‰ค 31)
Apr 1 โ€“ May 232 daysโŒ Exceeds limitQuery rejected โ€” reduce date range
Jan 1 โ€“ Mar 3190 daysโŒ Exceeds limitQuery rejected โ€” use incremental approach

๐Ÿ”„ Workarounds for CDR Queries Exceeding the Date Range Limit

๐Ÿ“Š When you need CDR data spanning more than 31 days, there are several approaches to work around the VOS3000 CDR query date range limit without increasing the parameter value and risking database performance: ๐Ÿ’ก

๐Ÿ“‹ Method 1: Incremental Queries (Chunk the Date Range)

๐Ÿ”ข Break your large date range into multiple queries, each within the 31-day limit. For example, to get 90 days of CDR data: ๐Ÿ’ก

๐Ÿ“‹ Incremental CDR Query Strategy (90-day range, 31-day limit):

Query 1: Jan 1 โ€“ Jan 31    (31 days) โœ…
Query 2: Feb 1 โ€“ Feb 28    (28 days) โœ…  
Query 3: Mar 1 โ€“ Mar 31    (31 days) โœ…

Total: 3 queries covering 90 days
Merge results externally (Excel, Python, etc.)

๐Ÿ“Š Advantage: No parameter changes needed; each query is database-friendly. Disadvantage: Requires manual effort to merge multiple result sets. For automated merging, use Python or a spreadsheet tool to combine the CSV exports.

๐Ÿ“ Method 2: CDR Text File Export

๐Ÿ“„ Use the VOS3000 CDR text file system instead of the database query. When SS_CDR_RECORD_TO_FILE is enabled, all CDRs are written to pipe-delimited text files in the cdr directory. These files can be searched, filtered, and analyzed using any text processing tool without any date range restriction. ๐Ÿ“‹

AspectDatabase QueryText File Export
๐Ÿ“… Date range limit31 days (configurable)No limit โ€” read any files on disk
๐Ÿ” Search capabilityRich filtering (account, gateway, etc.)Text processing (grep, awk, Python)
๐Ÿ“Š SpeedFast for targeted queriesSlower for large file scans
๐Ÿ”ง Setup requiredNone โ€” built into VOS3000 ClientEnable SS_CDR_RECORD_TO_FILE + rotation

๐Ÿ’ก For detailed CDR text file setup instructions, see our CDR text file export guide and CDR file rotation guide. ๐Ÿ”—

๐Ÿ“ก Method 3: Real-Time CDR Forwarding to External Analytics

๐ŸŒ If you frequently need large-range CDR analysis, consider forwarding CDRs to an external analytics platform (Elasticsearch, Splunk, custom database) using SERVER_CDR_REAL_TIME_REPORT_SERVER. External platforms typically have no date range restrictions and offer more powerful search and visualization capabilities. For setup instructions, see our real-time CDR forwarding guide. ๐Ÿš€

โš™๏ธ Method 4: Increase the Parameter Value (With Caution)

โš ๏ธ You can increase SERVER_QUERY_CDR_MAX_DAY_INTERVAL beyond 31 days if your database has sufficient resources. However, be aware of the implications: ๐Ÿ’ก

SettingRisk LevelImpact at 100 CPSRecommendation
31 days (default)๐ŸŸข Low~267M records maxโœ… Safe for most deployments
60 days๐ŸŸก Medium~518M records maxโš ๏ธ Only with powerful database server
90 days๐ŸŸ  High~778M records max๐Ÿšจ Risk of query timeouts and client crashes
365 days๐Ÿ”ด Very High~3.15B records maxโŒ Not recommended โ€” use external analytics instead

๐Ÿ–ฅ๏ธ Step-by-Step VOS3000 CDR Query Date Range Configuration

๐Ÿ”ง Follow these steps to configure the CDR query date range limit: ๐Ÿ“‹

Step 1: Configure the Parameter ๐Ÿ“Œ

  1. ๐Ÿ” Log in to VOS3000 Client
  2. ๐Ÿ“Œ Navigate: Operation management โ†’ Softswitch management โ†’ Additional settings โ†’ Server parameter
  3. ๐Ÿ” Locate SERVER_QUERY_CDR_MAX_DAY_INTERVAL
  4. โœ๏ธ Set the desired maximum day interval (default: 31)
  5. ๐Ÿ’พ Save and apply the configuration

Step 2: Verify the Limit โœ…

๐Ÿ“Š After configuration, test the limit by attempting a CDR query that exceeds the configured maximum:

  1. ๐Ÿ“… Open the CDR query window in VOS3000 Client
  2. ๐Ÿ” Set a date range that exceeds the configured limit
  3. โœ… Verify that the query is rejected with a date range error message
  4. ๐Ÿ“‹ Try a query within the limit and confirm it executes successfully

๐Ÿ”— The VOS3000 CDR query date range limit works alongside several other query size parameters that together control database load: ๐Ÿ’ก

ParameterDefaultPurpose
SERVER_QUERY_CDR_MAX_DAY_INTERVAL31Maximum days in CDR query date range
SERVER_QUERY_MAX_ONE_PAGE_SIZE200000Maximum records per page in results
SERVER_QUERY_MAX_SIZE30000000Total data query limit (items)
SERVER_QUERY_ONE_PAGE_SIZE10000Default records per page
SERVER_QUERY_NON_PAGABLE_MAX_LINES100000Non-pagable table max lines per page (1000โ€“200000)

๐Ÿ’ก Practical example: At 100 CPS, a 31-day query could return approximately 267 million records โ€” well above the SERVER_QUERY_MAX_SIZE of 30 million items. This means that even with a 31-day date range, the actual query results may be truncated by the total query size limit. The combination of date range and result size limits provides defense in depth against database overload. ๐Ÿ›ก๏ธ

๐Ÿ›ก๏ธ Common VOS3000 CDR Query Date Range Problems and Solutions

โŒ Problem 1: Reseller Needs Quarterly CDR Report

๐Ÿ” Symptom: A reseller needs to generate a quarterly CDR report (90 days) but the query is rejected.

โœ… Solutions:

  • ๐Ÿ“‹ Use incremental queries: three 31-day queries covering the quarter
  • ๐Ÿ“„ Export CDR text files and process them externally with Python or Excel
  • ๐Ÿ“ก Set up real-time CDR forwarding to an external analytics platform
  • โš™๏ธ Temporarily increase the limit for the specific query (then reduce it back)

โŒ Problem 2: CDR Query Returns Incomplete Results

๐Ÿ” Symptom: A 31-day CDR query returns fewer records than expected.

๐Ÿ’ก Cause: The total result count exceeds SERVER_QUERY_MAX_SIZE (30 million items), causing truncation. Or the query falls within the CDR query blackout window for some hours.

โœ… Solutions:

  • ๐Ÿ“Š Add more specific filters (account, gateway, call type) to reduce result count
  • ๐Ÿ“… Use a narrower date range and merge results
  • ๐Ÿ”ง Check SERVER_QUERY_MAX_SIZE setting if you need larger result sets

โŒ Problem 3: Changing the Limit Does Not Take Effect

๐Ÿ” Symptom: After changing SERVER_QUERY_CDR_MAX_DAY_INTERVAL, queries still fail at the old limit.

โœ… Solutions:

  • ๐Ÿ”„ Re-login to the VOS3000 Client after saving the parameter
  • ๐Ÿ”ง Clear the client cache and restart the application
  • ๐Ÿ“Š Verify the parameter value was saved correctly by re-opening the settings panel

๐Ÿ’ก VOS3000 CDR Query Date Range Best Practices

Best PracticeRecommendationReason
๐Ÿ“Š Keep default 31-day limitDo not increase without careful analysisโœ… Protects database from runaway queries
๐Ÿ“‹ Use incremental queriesChunk large ranges into 31-day segments๐Ÿ”ง No parameter changes; database-friendly
๐Ÿ“„ Leverage text file exportsUse CDR text files for large-range analysis๐Ÿ“Š No date range restriction on file reads
๐Ÿ“ก Forward to external analyticsIntegrate with Elasticsearch/Splunk๐Ÿš€ No limits; powerful visualization
๐Ÿ“ž Add query filtersSpecify account, gateway, or call type๐Ÿ” Reduces result count and query time

๐Ÿ’ฌ Need to optimize your VOS3000 CDR query strategy? Contact us at WhatsApp: +8801911119966 for expert guidance on database performance, CDR export workflows, and external analytics integration. ๐Ÿ“ž

โ“ Frequently Asked Questions

โ“ What is the default value for SERVER_QUERY_CDR_MAX_DAY_INTERVAL?

๐Ÿ“‹ The default value is 31 days. This means that by default, any CDR query in VOS3000 with a date range exceeding 31 days is automatically rejected. The 31-day default covers a typical monthly reporting cycle and provides a reasonable balance between operational needs and database protection. If your business requires larger query ranges, you can increase this value โ€” but consider the performance implications carefully, especially on high-traffic systems. ๐Ÿ”ง

โ“ Can I increase the VOS3000 CDR query date range to 365 days?

โš ๏ธ While SERVER_QUERY_CDR_MAX_DAY_INTERVAL can technically be set to 365 or higher, doing so on a production system with significant call volume is strongly discouraged. At 100 CPS, a 365-day query could attempt to return over 3 billion records โ€” far exceeding the SERVER_QUERY_MAX_SIZE of 30 million items and likely causing query timeouts or client crashes. For annual CDR analysis, use incremental queries, text file exports, or external analytics platforms instead. For CDR text file setup, see our CDR text file export guide. ๐Ÿ“Š

โ“ Does the date range limit apply to the CDR text file export?

๐Ÿ“„ No. The VOS3000 CDR query date range limit only applies to queries made through the VOS3000 Client and web interface (database queries). The CDR text file system writes all records to files on disk without any date range filtering. You can read, search, and analyze these text files using external tools (Python, awk, grep) with no date range restriction whatsoever. This makes the text file system the preferred method for large-range historical CDR analysis. ๐Ÿ”—

โ“ How do I export more than 31 days of CDR data for a reseller?

๐Ÿ“Š You have several options: (1) Use incremental queries โ€” run multiple 31-day queries and merge the results externally, (2) Access the CDR text files on the server directly โ€” they contain all records with no date range limit, (3) Use the real-time CDR forwarding feature to send records to an external analytics platform where larger queries are supported, or (4) Temporarily increase SERVER_QUERY_CDR_MAX_DAY_INTERVAL for the specific query (remember to reduce it back afterward). For the most robust long-term solution, option 3 provides unlimited analytical capability. ๐Ÿ’ก

โ“ Does the VOS3000 CDR query date range limit affect automated reports?

๐Ÿ“‹ The date range limit primarily affects manual CDR queries through the VOS3000 Client interface. Automated reports (configured under Report management) generate based on their own scheduling parameters. However, if an automated report’s date range configuration exceeds the SERVER_QUERY_CDR_MAX_DAY_INTERVAL, it may also be subject to the same restriction. Always verify that your automated report schedules are compatible with the configured date range limit. For more on reporting, see our CDR analysis guide. ๐Ÿ“Š

โ“ What other parameters control CDR query performance?

๐Ÿ”ง Several parameters work together to protect database performance: SERVER_QUERY_CDR_MAX_DAY_INTERVAL (date range limit), SERVER_QUERY_MAX_ONE_PAGE_SIZE (max records per page = 200000), SERVER_QUERY_MAX_SIZE (total query limit = 30M items), SERVER_QUERY_ONE_PAGE_SIZE (default page size = 10000), and SERVER_QUERY_CDR_DENY_TIME (blackout hours). Together, these parameters provide layered protection against heavy queries. For the blackout configuration, see our CDR query blackout guide. ๐Ÿ›ก๏ธ

๐Ÿ“ž Need Expert Help with VOS3000 CDR Query Date Range Configuration?

๐Ÿ”ง Proper VOS3000 CDR query date range configuration protects your database while ensuring your team can access the billing data they need. Whether you need to optimize query performance, set up CDR text file exports for large-range analysis, or integrate with external analytics platforms, our VOS3000 experts are here to help. ๐Ÿ›ก๏ธ

๐Ÿ’ฌ Contact us at WhatsApp: +8801911119966 for professional VOS3000 deployment and optimization services. We serve VoIP operators worldwide with proven solutions for billing, analytics, and system performance. ๐ŸŒ

๐Ÿ“– Explore related guides: CDR query blackout configuration, CDR analysis and billing, and parameter description reference. ๐Ÿ”—


๐Ÿ“ž 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 Query Blackout Secure Deny Time Configuration

VOS3000 CDR Query Blackout Secure Deny Time Configuration

๐Ÿ”’ Imagine this scenario: your billing team is running the end-of-month reconciliation, processing millions of CDR records to generate invoices, when a reseller launches a massive CDR query that consumes database resources and slows the entire billing run to a crawl. The VOS3000 CDR query blackout feature, controlled by SERVER_QUERY_CDR_DENY_TIME, prevents exactly this situation by blocking CDR queries during specified hours โ€” protecting your database during critical billing windows, maintenance periods, and peak processing times. โฑ๏ธ

๐Ÿ“Š The VOS3000 CDR query blackout is a server-level parameter that defines specific hours of the day when CDR queries are denied to all users through the VOS3000 Client and web interface. During these blackout hours, any attempt to query CDR records returns a restriction notice instead of results. This ensures that database resources remain fully available for billing calculations, report generation, and system maintenance without interference from ad-hoc queries. ๐Ÿ›ก๏ธ

๐Ÿ’ฌ Need to configure CDR access policies for your VOS3000 deployment? Contact our experts at WhatsApp: +8801911119966 for professional assistance with billing security and system optimization. ๐Ÿ’ก

๐Ÿ” What Is VOS3000 CDR Query Blackout?

๐Ÿ“‹ The VOS3000 CDR query blackout is a time-based access control mechanism that restricts CDR queries during designated hours. When enabled, users cannot search, view, or export CDR records through the VOS3000 Client or web portal during the configured blackout window. This protects database performance during periods when the system needs maximum resources for internal processing. ๐Ÿšซ

๐Ÿ’ก Why carriers need CDR query blackout:

  • ๐Ÿ’ฐ Billing run protection: Monthly reconciliation processes millions of CDRs โ€” concurrent user queries can cause severe performance degradation
  • ๐Ÿ“Š Report generation: Automated reports require exclusive database access to complete within acceptable timeframes
  • ๐Ÿ”ง Maintenance windows: Database optimization, index rebuilding, and data archival should not compete with query traffic
  • ๐Ÿ›ก๏ธ Data integrity: Prevents partial or inconsistent CDR views during data migration or settlement processing
  • ๐Ÿ“‹ Regulatory compliance: Some jurisdictions require controlled access to CDR data during audit periods

โš™๏ธ SERVER_QUERY_CDR_DENY_TIME โ€” The Core Parameter

๐Ÿ”’ SERVER_QUERY_CDR_DENY_TIME defines the hours during which CDR queries are blocked. The parameter uses a 24-hour clock format, specifying which hours of the day are denied for CDR access. ๐Ÿ“‹

AttributeValue
๐Ÿ“Œ Parameter NameSERVER_QUERY_CDR_DENY_TIME
๐Ÿ”ข Default ValueNone (no blackout by default)
๐Ÿ“ FormatComma-separated hour values (24-hour format)
๐Ÿ“ DescriptionNo CDR Query Time (24 hour) e.g. 18,19,20,21,22,23
๐Ÿ“ LocationOperation management โ†’ Softswitch management โ†’ Additional settings โ†’ Server parameter

๐Ÿ”ง Configuration format: The parameter accepts comma-separated integer values representing the hours of the day (0โ€“23) when CDR queries are blocked. For example, to block CDR queries from 6 PM to midnight, set the value to: 18,19,20,21,22,23. Each value represents one complete hour โ€” setting “18” blocks queries from 18:00:00 to 18:59:59.

๐Ÿ“‹ VOS3000 CDR Query Blackout Configuration Examples

๐Ÿ“Š Here are practical examples showing how to configure the VOS3000 CDR query blackout for different operational scenarios: ๐Ÿ’ก

ScenarioParameter ValueBlackout WindowUse Case
๐Ÿ“ž Evening billing run18,19,20,21,22,236 PM โ€“ Midnight๐Ÿ”’ Monthly reconciliation during off-peak evening hours
๐Ÿ“Š Overnight processing0,1,2,3,4,5Midnight โ€“ 6 AM๐Ÿ”ง Database maintenance and report generation
๐Ÿ’ฐ End-of-day billing22,23,0,110 PM โ€“ 2 AM๐Ÿ“‹ Daily settlement across midnight boundary
๐Ÿ›ก๏ธ All-day restriction0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,2324 hours๐Ÿšจ Complete CDR access lockdown during audits
โœ… No restriction(leave empty)None๐Ÿ“Š Default โ€” CDR queries available 24/7

โš ๏ธ Important note: The blackout hours are specified in the server’s local timezone. If your VOS3000 server is configured in UTC and your billing team works in a different timezone, you must convert the desired blackout window to match the server timezone. For example, if your billing team in Dhaka (UTC+6) wants to block queries from 6 PM to 10 PM local time, and the server is in UTC, the parameter should be set to 12,13,14,15,16 (6 PM UTC+6 = 12 UTC, 10 PM UTC+6 = 16 UTC). ๐ŸŒ

๐Ÿ“‹ Step-by-Step VOS3000 CDR Query Blackout Configuration

๐Ÿ–ฅ๏ธ Follow these steps to configure the CDR query blackout on your VOS3000 system: ๐Ÿ”ง

Step 1: Determine Blackout Window โฑ๏ธ

๐Ÿ“Š Identify the hours when CDR queries should be blocked based on your operational needs:

  • ๐Ÿ“… Billing run schedule: When does your monthly/daily reconciliation run?
  • ๐Ÿ”ง Maintenance windows: When are database optimizations scheduled?
  • ๐Ÿ“Š Report generation: When do automated reports run?
  • ๐ŸŒ Timezone alignment: Convert desired blackout hours to server timezone if different

Step 2: Configure the Parameter ๐Ÿ“Œ

  1. ๐Ÿ” Log in to VOS3000 Client
  2. ๐Ÿ“Œ Navigate: Operation management โ†’ Softswitch management โ†’ Additional settings โ†’ Server parameter
  3. ๐Ÿ” Locate SERVER_QUERY_CDR_DENY_TIME
  4. โœ๏ธ Enter the comma-separated hour values (e.g., 18,19,20,21,22,23)
  5. ๐Ÿ’พ Save and apply the configuration

Step 3: Verify Blackout Enforcement โœ…

๐Ÿ” After configuration, verify that the blackout is working correctly:

  1. ๐Ÿ• Wait until a configured blackout hour
  2. ๐Ÿ“Š Attempt to query CDR records through the VOS3000 Client
  3. โœ… Confirm that the query is denied with a restriction message
  4. ๐Ÿ• After the blackout window ends, verify that CDR queries are restored

๐Ÿ”— The CDR query blackout works alongside several other CDR access control parameters that together form a comprehensive data protection strategy: ๐Ÿ“‹

ParameterDefaultPurposeComplements Blackout?
SERVER_QUERY_CDR_DENY_TIMENoneBlocks CDR queries during specified hours๐Ÿ”‘ Core parameter
SERVER_QUERY_CDR_MAX_DAY_INTERVAL31Limits CDR query date range to 31 days maxโœ… Prevents heavy queries outside blackout
SERVER_QUERY_MAX_ONE_PAGE_SIZE200000Maximum records per page in query resultsโœ… Limits query result size
SERVER_QUERY_MAX_SIZE30000000Total data query limit (items)โœ… Prevents runaway queries
SERVER_QUERY_ONE_PAGE_SIZE10000Default records per pageโœ… Standard pagination control

๐Ÿ’ก Layered protection strategy: For maximum database protection, combine the VOS3000 CDR query blackout with the date range limit (SERVER_QUERY_CDR_MAX_DAY_INTERVAL) and query size limits. The blackout prevents access during critical processing hours, while the date range and size limits prevent excessively heavy queries at any time. This layered approach ensures that even when queries are permitted, they cannot consume excessive resources. For the date range limit configuration, see our CDR query date range guide. ๐Ÿ”—

๐Ÿ›ก๏ธ Common VOS3000 CDR Query Blackout Problems and Solutions

โŒ Misconfigured blackout settings can cause either insufficient protection or unexpected access denial. Here are the most common issues: ๐Ÿ”

โŒ Problem 1: CDR Queries Still Allowed During Blackout Hours

๐Ÿ” Symptom: Users can still query CDR records during the configured blackout hours.

๐Ÿ’ก Cause: The parameter value may contain formatting errors, or the configuration may not have been properly applied after saving.

โœ… Solutions:

  • ๐Ÿ”ง Verify the parameter value uses correct comma-separated format (e.g., 18,19,20 โ€” not 18-20 or 6pm-8pm)
  • ๐Ÿ“Š Ensure there are no spaces in the parameter value
  • ๐Ÿ”„ Re-apply the configuration and restart the softswitch service if necessary
  • ๐Ÿ• Confirm you are testing during the correct hours based on the server timezone

โŒ Problem 2: Blackout Applied in Wrong Timezone

๐Ÿ” Symptom: CDR queries are blocked at unexpected times โ€” not during your intended window.

๐Ÿ’ก Cause: The SERVER_QUERY_CDR_DENY_TIME operates on the server’s system clock timezone, which may differ from your local timezone. If the server is configured in UTC and you specified hours in your local timezone, the blackout window will be offset.

โœ… Solutions:

  • ๐ŸŒ Check the server timezone: date or timedatectl on the VOS3000 Linux server
  • ๐Ÿ”„ Convert your desired blackout hours to the server’s timezone
  • ๐Ÿ“‹ Update the parameter with the corrected hour values
  • ๐Ÿ• Verify by testing a query during the intended blackout window

โŒ Problem 3: Resellers Unable to Access CDRs During Business Hours

๐Ÿ” Symptom: Resellers complain they cannot check their CDRs during normal working hours.

๐Ÿ’ก Cause: The blackout window is set too broadly, covering business hours in addition to billing run periods. This is common when operators set the blackout for the entire evening without narrowing it to the actual billing processing window.

โœ… Solutions:

  • โฑ๏ธ Narrow the blackout window to only the hours when billing runs actually occur
  • ๐Ÿ“Š Schedule billing runs during the lowest-traffic period (typically late night or early morning)
  • ๐Ÿ“‹ Communicate the blackout schedule to all resellers in advance
  • ๐Ÿ”„ If resellers need CDR access, provide them with the CDR text file backup or real-time forwarding as an alternative

โŒ Problem 4: Blackout Not Preventing Heavy Queries Outside Blackout Hours

๐Ÿ” Symptom: Database performance degrades from heavy CDR queries that run outside the blackout window.

๐Ÿ’ก Cause: The VOS3000 CDR query blackout only restricts access during specified hours. Outside those hours, users can still run very large queries that impact performance.

โœ… Solutions:

  • ๐Ÿ“… Set SERVER_QUERY_CDR_MAX_DAY_INTERVAL to limit query date ranges (default: 31 days)
  • ๐Ÿ“ฆ Reduce SERVER_QUERY_MAX_ONE_PAGE_SIZE to limit result set sizes
  • ๐Ÿ“Š Monitor slow queries in the database and identify the heaviest users
  • ๐Ÿ“‹ For more on managing query performance, see our CDR analysis guide

๐Ÿ’ก VOS3000 CDR Query Blackout Best Practices

๐ŸŽฏ Follow these best practices to balance database protection with user access needs: ๐Ÿ“‹

Best PracticeRecommendationReason
๐Ÿ“Š Minimize blackout windowCover only actual billing run hoursโœ… Reduces impact on reseller operations
๐ŸŒ Verify server timezoneConvert blackout hours to server local time๐Ÿ”ง Prevents misaligned blackout windows
๐Ÿ“‹ Communicate scheduleNotify all users of blackout periods๐Ÿ“ž Manages expectations and reduces support tickets
๐Ÿ›ก๏ธ Layer query controlsCombine blackout + date range + size limits๐Ÿ”’ Comprehensive database protection at all times
๐Ÿ”„ Test after changesVerify both denied and allowed periodsโœ… Confirms correct configuration
๐Ÿ“Š Schedule during low trafficAlign billing runs with off-peak hours๐Ÿ“ž Minimizes impact on active users

๐Ÿ’ฌ Questions about configuring VOS3000 CDR access policies? Reach out at WhatsApp: +8801911119966 โ€” our VOS3000 specialists can help you design a comprehensive data protection strategy. ๐Ÿ“ž

โ“ Frequently Asked Questions

โ“ What is the default value for SERVER_QUERY_CDR_DENY_TIME?

๐Ÿ“‹ The default value is None (not configured), which means there is no CDR query blackout โ€” all users can query CDR records at any time. To enable the VOS3000 CDR query blackout, set the parameter to a comma-separated list of hours (0โ€“23) when queries should be blocked. For example, 18,19,20,21,22,23 blocks CDR queries from 6 PM to midnight each day. ๐Ÿ”ง

โ“ Does the VOS3000 CDR query blackout apply to all users?

๐Ÿ”’ Yes. The SERVER_QUERY_CDR_DENY_TIME parameter applies at the server level, which means it blocks CDR queries for all users โ€” including administrators, agents, and resellers. There is no per-user or per-role exemption. During the blackout hours, no one can query CDR records through the VOS3000 Client or web interface. If you need differentiated access control, consider using the VOS3000 Web API with custom application-level access controls. For Web API details, see our VOS3000 Web API account management guide. ๐Ÿ”—

โ“ Can I configure different blackout windows for different days of the week?

๐Ÿ“… No. The VOS3000 CDR query blackout applies the same hours every day. The SERVER_QUERY_CDR_DENY_TIME parameter does not support day-of-week differentiation โ€” if you set 18,19,20, CDR queries are blocked from 6 PM to 9 PM on Monday through Sunday. If you need different schedules for weekdays vs weekends, you would need to manually change the parameter value, or implement a custom automation script that updates the parameter on a schedule. ๐Ÿ”„

โ“ How does the VOS3000 CDR query blackout interact with automated reports?

๐Ÿ“Š The VOS3000 CDR query blackout restricts manual CDR queries through the client and web interfaces. Automated report generation (configured under Navigation โ†’ Report management) may operate independently of the blackout restriction since reports are generated by the system internally rather than through the query interface. However, if automated reports rely on the same query mechanism, they may also be affected. Always test your report generation schedule against the blackout window to ensure reports can complete successfully. For report configuration, see our billing system overview. ๐Ÿ“‹

โ“ What happens when a user tries to query CDRs during the blackout?

๐Ÿšซ When a user attempts to search or view CDR records during the configured blackout hours, the VOS3000 system denies the query and displays a restriction notice. The user is informed that CDR queries are not available during this time period. No partial results are returned. The query does not execute at all โ€” it is blocked before reaching the database, ensuring zero impact on database performance during the blackout window. ๐Ÿ”’

โ“ Can I temporarily disable the blackout for emergency CDR access?

๐Ÿ”ง Yes. To temporarily disable the VOS3000 CDR query blackout, set the SERVER_QUERY_CDR_DENY_TIME parameter to empty (None) and save the configuration. This immediately restores CDR query access for all users. After the emergency access is no longer needed, re-enter the blackout hours and save again. Remember to re-enable the blackout promptly to maintain database protection during billing runs. For help managing VOS3000 parameters, contact our team at WhatsApp: +8801911119966. ๐Ÿ’ฌ

๐Ÿ“ž Need Expert Help with VOS3000 CDR Query Blackout?

๐Ÿ”ง Proper VOS3000 CDR query blackout configuration protects your billing operations from performance disruptions while maintaining appropriate access for your resellers and support team. Whether you need to set up your first blackout window, troubleshoot timezone issues, or design a comprehensive CDR access control strategy, our VOS3000 experts are ready to assist. ๐Ÿ›ก๏ธ

๐Ÿ’ฌ Contact us at WhatsApp: +8801911119966 for professional VOS3000 deployment and configuration support. We help VoIP operators worldwide optimize billing security, database performance, and operational efficiency. ๐ŸŒ

๐Ÿ“– Explore related guides: CDR query date range limit, CDR analysis and billing, and parameter description reference. ๐Ÿ”—


๐Ÿ“ž 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 Real-Time CDR Forwarding Advanced External Server Easy Integration

VOS3000 Real-Time CDR Forwarding Advanced External Server Integration

๐Ÿ“ก In modern VoIP operations, CDR data must reach external systems immediately โ€” not hours later after a batch export. The VOS3000 real-time CDR forwarding feature, powered by SERVER_CDR_REAL_TIME_REPORT_SERVER, pushes every call detail record to an external server the moment a call ends. This enables live billing by external rating engines, instant fraud detection, real-time traffic monitoring, and seamless integration with third-party business intelligence platforms. ๐Ÿš€

โš™๏ธ Without real-time CDR forwarding, operators must rely on scheduled database exports or CDR text file parsing โ€” both of which introduce latency ranging from minutes to hours. For high-value wholesale operations where every second of billing delay impacts cash flow, the VOS3000 real-time CDR forwarding capability is not a luxury โ€” it is a necessity. This guide covers the configuration, use cases, and integration patterns based exclusively on the official VOS3000 2.1.9.07 manual. ๐Ÿ“‹

๐Ÿ’ฌ Need help setting up external CDR integration? Contact our VOS3000 team at WhatsApp: +8801911119966 for expert configuration and deployment assistance. ๐Ÿ’ก

Table of Contents

๐Ÿ” What Is VOS3000 Real-Time CDR Forwarding?

๐Ÿ“Š The VOS3000 real-time CDR forwarding system transmits each completed call detail record to a designated external server immediately after the call ends. Unlike the text file export (which writes CDRs to local files at regular intervals) or the database storage (which requires direct database access), real-time forwarding delivers CDR data over the network to any system that can accept the connection โ€” whether it is a custom billing application, a fraud detection platform, or a data warehouse. ๐ŸŒ

๐Ÿ’ก Key advantages over other CDR access methods:

  • โšก Zero latency: CDRs are forwarded the instant a call completes โ€” no waiting for batch exports
  • ๐Ÿ”— Loose coupling: The external system does not need database access or file system access to VOS3000
  • ๐Ÿ›ก๏ธ Redundancy: Provides a third copy of CDR data (database + text files + external server)
  • ๐Ÿ“Š Real-time analytics: Feed live CDR data into dashboards, monitoring tools, and alerting systems
  • ๐Ÿ’ฐ External billing: Route CDRs to a separate rating engine for specialized billing calculations

โš™๏ธ SERVER_CDR_REAL_TIME_REPORT_SERVER โ€” The Core Parameter

๐Ÿ“ก SERVER_CDR_REAL_TIME_REPORT_SERVER specifies the target server address (IP and port) where VOS3000 forwards CDR records in real-time. This is the single parameter that enables and configures the entire real-time forwarding system. ๐ŸŽฏ

AttributeValue
๐Ÿ“Œ Parameter NameSERVER_CDR_REAL_TIME_REPORT_SERVER
๐Ÿ”ข Default ValueNone (not configured by default)
๐Ÿ“ FormatIP:Port (e.g., 192.168.1.100:5060)
๐Ÿ“ DescriptionAdditional send call record to server address
๐Ÿ“ LocationOperation management โ†’ Softswitch management โ†’ Additional settings โ†’ Server parameter

๐Ÿ”ง Configuration syntax: Set the parameter value to the IP address and port of your external CDR receiving server, separated by a colon. For example, to forward CDRs to a server at IP 10.0.0.50 listening on port 8080, set the value to 10.0.0.50:8080. When this parameter is left empty (default), real-time CDR forwarding is disabled.

๐Ÿ”— Two additional parameters work alongside SERVER_CDR_REAL_TIME_REPORT_SERVER to control the external CDR delivery pipeline: ๐Ÿ’ก

ParameterDefaultRangePurpose
EXTERNAL_SEND_CDROffOn/OffInterface: send CDR โ€” master switch for external CDR delivery
EXTERNAL_MAX_CDR_PENDING_SIZE100001000โ€“100000Queue size for resending CDR when external server is unavailable

โš ๏ธ Important: EXTERNAL_SEND_CDR must be set to On for the real-time CDR forwarding to work. This is the master switch for the entire external CDR interface. Additionally, EXTERNAL_MAX_CDR_PENDING_SIZE defines a buffer queue โ€” if the external server is temporarily unreachable, VOS3000 queues up to this many CDRs for automatic resend when the connection is restored. This prevents CDR loss during network interruptions. ๐Ÿ›ก๏ธ

๐ŸŽฏ VOS3000 Real-Time CDR Forwarding Use Cases

๐ŸŒ The real-time CDR forwarding capability enables a wide range of integration scenarios that are essential for modern VoIP operations: ๐Ÿ“Š

Use CaseExternal SystemBenefit
๐Ÿ’ฐ External billing engineCustom rating/billing applicationReal-time invoice generation; custom rate plans beyond VOS3000
๐Ÿ›ก๏ธ Fraud detectionFraud monitoring platform (e.g., custom SIEM)Instant detection of SIM box, arbitrage, and premium rate fraud
๐Ÿ“Š Traffic analyticsElasticsearch, Splunk, or custom dashboardLive traffic visualization and capacity planning
๐Ÿ”„ CDR reconciliationThird-party reconciliation toolCross-vendor CDR matching for carrier dispute resolution
๐Ÿ“‹ Regulatory complianceLawful interception / CALEA systemImmediate CDR delivery to compliance systems
๐Ÿข Multi-system distributionCDR router/multiplexer applicationOne source feeding multiple downstream systems

๐Ÿ“‹ Step-by-Step VOS3000 Real-Time CDR Forwarding Configuration

๐Ÿ–ฅ๏ธ Follow these steps to configure real-time CDR forwarding on your VOS3000 system: ๐Ÿ”ง

Step 1: Enable External CDR Interface ๐ŸŒ

  1. ๐Ÿ” Log in to VOS3000 Client
  2. ๐Ÿ“Œ Navigate: Operation management โ†’ Softswitch management โ†’ Additional settings โ†’ Server parameter
  3. ๐Ÿ” Locate EXTERNAL_SEND_CDR
  4. โœ๏ธ Set value to On

Step 2: Configure Target Server Address ๐Ÿ“ก

  1. ๐Ÿ” In the same Server parameter section, locate SERVER_CDR_REAL_TIME_REPORT_SERVER
  2. โœ๏ธ Set the value to the IP address and port of your external CDR receiver (e.g., 10.0.0.50:8080)

Step 3: Configure CDR Queue Size ๐Ÿ“ฆ

  1. ๐Ÿ” Locate EXTERNAL_MAX_CDR_PENDING_SIZE
  2. โœ๏ธ Set an appropriate queue size (default: 10000, range: 1000โ€“100000)
  3. ๐Ÿ’พ Save and apply the configuration

Step 4: Verify CDR Forwarding โœ…

๐Ÿ“ก After configuration, verify that CDRs are being forwarded by checking both the VOS3000 side and the external server: ๐Ÿ’ก

๐Ÿ“‹ VOS3000 Real-Time CDR Forwarding Verification:

1. Make a test call through the softswitch
2. On the external server, check for incoming CDR data:
   - Monitor the listening port for connections from VOS3000
   - Verify CDR records are being received after call completion

3. On VOS3000 server, check for forwarding errors:
   - Review softswitch logs for connection failures
   - Monitor the CDR pending queue size

4. If CDRs are not being received:
   - Verify firewall allows traffic from VOS3000 to target IP:Port
   - Confirm the external server application is listening
   - Check that EXTERNAL_SEND_CDR = On
   - Verify SERVER_CDR_REAL_TIME_REPORT_SERVER format (IP:Port)

๐Ÿ”„ CDR Queue and Delivery Guarantee – VOS3000 Real-Time CDR Forwarding

๐Ÿ›ก๏ธ The EXTERNAL_MAX_CDR_PENDING_SIZE parameter plays a critical role in ensuring CDR delivery reliability. When the external server is temporarily unreachable โ€” due to network issues, server maintenance, or application restarts โ€” VOS3000 does not simply discard the CDRs. Instead, it places them in a memory queue for automatic resend once the connection is restored. ๐Ÿ“ฆ

Queue ScenarioBehaviorRecommendation
โœ… External server onlineCDRs forwarded immediately upon call completionNormal operation โ€” no action needed
โš ๏ธ External server temporarily offlineCDRs queued up to EXTERNAL_MAX_CDR_PENDING_SIZESet queue size based on expected downtime duration
๐Ÿšจ Queue full (exceeded limit)Oldest CDRs in queue are discarded to make roomIncrease queue size or fix external server connectivity
๐Ÿ”„ External server restoredQueued CDRs automatically resent in orderVerify CDR ordering on the receiving side

๐Ÿ“ Queue sizing calculation: To determine the appropriate queue size, estimate how many CDRs might accumulate during the longest expected downtime. For example, at 100 CPS with a potential 10-minute server outage: 100 ร— 60 ร— 10 = 60,000 CDRs. Set EXTERNAL_MAX_CDR_PENDING_SIZE to at least 60000 to ensure no data loss. The default of 10000 covers approximately 100 seconds at 100 CPS, which may be insufficient for longer outages. ๐Ÿ“Š

๐Ÿ›ก๏ธ Common VOS3000 Real-Time CDR Forwarding Problems and Solutions

โŒ Misconfigured real-time CDR forwarding causes silent data loss that may go undetected for days. Here are the most common issues and their solutions: ๐Ÿ”

โŒ Problem 1: External Server Not Receiving CDRs

๐Ÿ” Symptom: The external CDR receiver shows no incoming data, even though calls are completing on VOS3000.

๐Ÿ’ก Cause: The most common reasons are: EXTERNAL_SEND_CDR is Off, SERVER_CDR_REAL_TIME_REPORT_SERVER is not configured, or a firewall is blocking the connection.

โœ… Solutions:

  • ๐Ÿ”ง Verify EXTERNAL_SEND_CDR is set to On
  • ๐Ÿ“ก Check that SERVER_CDR_REAL_TIME_REPORT_SERVER contains the correct IP:Port value
  • ๐Ÿ›ก๏ธ Ensure firewall rules allow outbound connections from VOS3000 to the target server
  • ๐Ÿ“‹ Test connectivity from the VOS3000 server: telnet target_ip target_port

โŒ Problem 2: CDRs Arriving Out of Order

๐Ÿ” Symptom: The external system receives CDRs but they are not in chronological order, causing billing calculation errors.

๐Ÿ’ก Cause: During high traffic periods, multiple CDR forwarding threads may deliver records in slightly different order than they were generated. Additionally, if the external server was temporarily unreachable and CDRs were queued, the resend order may not perfectly match the original sequence.

โœ… Solutions:

  • ๐Ÿ“Š Use the startTime field in each CDR record for ordering, not the arrival sequence
  • ๐Ÿ”ง Implement a small buffer window on the receiving side to reorder CDRs before processing
  • ๐Ÿ“‹ For the complete CDR field reference, see our VOS3000 CDR pipe format guide

โŒ Problem 3: CDR Loss During External Server Outages

๐Ÿ” Symptom: After an external server outage, some CDRs are missing from the received data.

๐Ÿ’ก Cause: The CDR queue (EXTERNAL_MAX_CDR_PENDING_SIZE) filled up during the outage, and older CDRs were discarded to make room for new ones.

โœ… Solutions:

  • ๐Ÿ“ฆ Increase EXTERNAL_MAX_CDR_PENDING_SIZE based on your maximum expected downtime
  • ๐Ÿ›ก๏ธ Implement high-availability for the external CDR receiver (redundant servers, load balancer)
  • ๐Ÿ”„ Cross-reference with VOS3000 CDR text files for missing records โ€” see our CDR file rotation guide
  • ๐Ÿ“Š Set up monitoring that alerts you immediately when the queue depth exceeds 50%

โŒ Problem 4: High CPU or Network Usage from CDR Forwarding

๐Ÿ” Symptom: VOS3000 server performance degrades noticeably after enabling real-time CDR forwarding.

๐Ÿ’ก Cause: At very high call volumes, the overhead of opening a network connection and transmitting CDR data for every single call can consume significant CPU and network resources, especially if the external server is slow to respond.

โœ… Solutions:

  • ๐Ÿ“Š Ensure the external CDR receiver can process records as fast as they arrive
  • ๐ŸŒ Use a local network connection (same datacenter) between VOS3000 and the CDR receiver
  • ๐Ÿ”ง Consider implementing a local CDR buffering proxy that batches records before forwarding
  • ๐Ÿ“‹ Monitor VOS3000 system resources to ensure forwarding does not impact call processing

๐Ÿ’ก VOS3000 Real-Time CDR Forwarding Best Practices

๐ŸŽฏ Follow these best practices to ensure reliable and efficient CDR forwarding: ๐Ÿ“‹

Best PracticeRecommendationReason
๐Ÿ›ก๏ธ Use high-availabilityRedundant CDR receiver with failoverPrevents CDR loss during receiver maintenance
๐Ÿ“ฆ Size the queue correctlyCalculate based on max downtime ร— CPSEnsures no CDRs are dropped during outages
๐Ÿ“Š Monitor queue depthAlert when queue exceeds 50% capacityEarly warning of external server problems
๐Ÿ”„ Cross-reference regularlyCompare forwarded CDRs with database records weeklyDetects silent CDR loss or duplication
๐ŸŒ Keep receiver closeSame datacenter or low-latency networkMinimizes forwarding delay and connection failures
๐Ÿ” Secure the connectionUse VPN or TLS tunnel for CDR trafficCDRs contain sensitive billing and subscriber data

๐Ÿ’ฌ Need to integrate VOS3000 with your external billing or fraud detection system? Our team at WhatsApp: +8801911119966 can help you configure real-time CDR forwarding and build the complete data pipeline. ๐Ÿš€

๐Ÿ“Š Complete VOS3000 Real-Time CDR Forwarding Parameter Reference

๐Ÿ“‹ Here is the complete reference table for all parameters related to real-time CDR forwarding, sourced from the official VOS3000 2.1.9.07 manual: ๐Ÿ”ง

ParameterDefaultRangePurpose
SERVER_CDR_REAL_TIME_REPORT_SERVERNoneIP:PortTarget server address for real-time CDR forwarding
EXTERNAL_SEND_CDROffOn/OffMaster switch for external CDR interface
EXTERNAL_MAX_CDR_PENDING_SIZE100001000โ€“100000Queue size for resend when external server is unavailable
EXTERNAL_WEB_SEND_PHONE_ONLINEOffOn/OffInterface: phone online/offline transfer

๐Ÿ“ All server parameters are located at: Navigation โ†’ Operation management โ†’ Softswitch management โ†’ Additional settings โ†’ Server parameter

โ“ Frequently Asked Questions

โ“ What is the default value for SERVER_CDR_REAL_TIME_REPORT_SERVER?

๐Ÿ“‹ The default value is None (not configured). This means VOS3000 real-time CDR forwarding is disabled by default. You must explicitly configure the IP:Port address of your external CDR receiving server and set EXTERNAL_SEND_CDR to On before any CDRs are forwarded. The parameter format is IP:Port โ€” for example, 192.168.1.100:8080 for a server at IP 192.168.1.100 listening on port 8080. ๐Ÿ”ง

โ“ Does VOS3000 real-time CDR forwarding guarantee delivery?

๐Ÿ›ก๏ธ VOS3000 provides a best-effort delivery mechanism with a configurable queue buffer. When the external server is unavailable, CDRs are queued up to the limit specified by EXTERNAL_MAX_CDR_PENDING_SIZE (default: 10000). If the queue fills up, older CDRs are discarded to make room. For guaranteed delivery, implement a high-availability CDR receiver, size the queue appropriately for your maximum expected downtime, and cross-reference with the VOS3000 CDR text file backup system described in our CDR file rotation guide. ๐Ÿ“Š

โ“ Can I forward CDRs to multiple external servers?

๐Ÿ“ก The VOS3000 SERVER_CDR_REAL_TIME_REPORT_SERVER parameter supports a single target address. To distribute CDRs to multiple downstream systems, you have two options: (1) Deploy a CDR multiplexer application at the target address that receives the CDR stream and forwards copies to multiple destinations, or (2) Use a combination of real-time forwarding for immediate processing and CDR text file rotation for batch distribution. The CDR text files can be parsed by multiple independent systems. For complex multi-system integration, contact our team at WhatsApp: +8801911119966. ๐Ÿ”—

โ“ What format are CDRs sent in during real-time forwarding?

๐Ÿ“‹ CDRs forwarded in real-time use the same pipe-delimited format as the text file export, containing all 18 standard fields: callerE164, calleeE164, startTime, stopTime, holdTime, endReason, endDirection, callerGatewayId, calleeGatewayId, callerIp, calleeIp, callerAccessE164, calleeAccessE164, callerToGatewayE164, calleeToGatewayE164, calleeBilling, billingMode, callerPdd, and calleePdd. Each field is separated by a pipe character (|). For the complete field reference, see our VOS3000 CDR pipe format guide. ๐Ÿ“Š

โ“ How do I troubleshoot real-time CDR forwarding connection issues?

๐Ÿ” Start by verifying the basics: (1) Confirm EXTERNAL_SEND_CDR is On, (2) Verify the SERVER_CDR_REAL_TIME_REPORT_SERVER value is correct (IP:Port format), (3) Test network connectivity from the VOS3000 server to the target using telnet or nc, (4) Check firewall rules on both sides, (5) Verify the external application is listening on the specified port, (6) Review VOS3000 softswitch logs for connection error messages, (7) Monitor the EXTERNAL_MAX_CDR_PENDING_SIZE queue depth to detect if CDRs are being queued due to connection failures. For additional troubleshooting, see our VOS3000 debug trace guide. ๐Ÿ”ง

โ“ Does real-time CDR forwarding affect VOS3000 call processing performance?

โšก Under normal conditions, the VOS3000 real-time CDR forwarding has minimal impact on call processing. The forwarding operation occurs after the call has ended, so it does not affect call setup or in-call quality. However, at extremely high call volumes (500+ CPS) or if the external server is slow to respond, the forwarding threads may consume additional CPU and network resources. Best practice is to keep the CDR receiver on the same local network as VOS3000 and ensure it can process records as fast as they arrive. Monitor your gateway analysis reports for any performance anomalies after enabling forwarding. ๐Ÿ“Š

๐Ÿ“ž Need Expert Help with VOS3000 Real-Time CDR Forwarding?

๐Ÿ”ง Whether you are integrating VOS3000 with an external billing engine, setting up a fraud detection pipeline, or building a real-time traffic monitoring dashboard, proper VOS3000 real-time CDR forwarding configuration is the foundation. Our VOS3000 experts can help you design and deploy the complete CDR integration architecture โ€” from softswitch parameters to the receiving application. ๐Ÿ›ก๏ธ

๐Ÿ’ฌ Contact us at WhatsApp: +8801911119966 for professional VOS3000 deployment and CDR integration support. We serve VoIP operators worldwide with proven solutions for billing, fraud prevention, and traffic analytics. ๐ŸŒ

๐Ÿ“– Explore related guides: CDR analysis and billing, billing system overview, and illegal call recording detection. ๐Ÿ”—


๐Ÿ“ž 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