VOS3000 Period Capacity Configuration, VOS3000 Period Dial Plan, VOS3000 RTP Interrupt Detection, VOS3000 Lowest Profit Rate Limit, VOS3000 Max Minute Rate Cap, VOS3000 Sort Lowest Rate Per Second, VOS3000 Check Rate Before Routing, VOS3000 Sort by Lowest Rate, VOS3000 Bilateral Reconciliation, VOS3000 SIP OPTIONS Online Check, VOS3000 T38 Fax Over IP, VOS3000 G729 Annex B Silence, VOS3000 Gateway Group Reserved Lines, VOS3000 Auxiliary Ring Tone

VOS3000 RTP Interrupt Detection Accurate Four-Mode Media Monitoring

VOS3000 RTP Interrupt Detection Accurate Four-Mode Media Monitoring

๐Ÿ“ก When a VoIP call is established and both parties are conversing, the media path is carrying RTP packets in both directions. But what happens when one direction stops โ€” the RTP stream is interrupted while the SIP signaling remains active? The caller hears silence, but the call never hangs up. The VOS3000 RTP interrupt detection feature solves this problem by monitoring RTP packet flow and taking action when media is lost, ensuring that silent zombie calls do not consume gateway resources or confuse billing records. ๐Ÿ”ง

โš™๏ธ According to the VOS3000 V2.1.9.07 Manual ยง2.5.1.1 (page 32), the VOS3000 RTP interrupt detection offers four modes: None (disable detection), Server to Remote (detect audio sent from server to device), Remote to Server (detect audio sent from device to server), and Bidirection (detect both sides โ€” if any one side has no audio, the call will be interrupted). Each mode provides a different level of monitoring granularity, allowing you to choose between passive observation and automatic call termination based on your deployment requirements. The VOS3000 RTP interrupt detection is a per-gateway setting configured in the Additional settings panel under Normal settings. ๐Ÿ“Š

๐ŸŽฏ This guide provides a complete, manual-verified reference for all four VOS3000 RTP interrupt detection modes. All parameter definitions are sourced exclusively from the official VOS3000 V2.1.9.07 Manual ยง2.5.1.1 (page 32). No fabricated values, no guesswork. For expert assistance, contact us on WhatsApp at +8801911119966. ๐Ÿ“˜

๐Ÿ” What Is VOS 3000 RTP Interrupt Detection?

๐Ÿ“‹ The VOS3000 RTP interrupt detection is a per-gateway feature that monitors RTP media packet flow during active calls and takes action when the RTP stream is interrupted. It is configured in the Routing Gateway Additional settings > Normal panel, in the “RTP interrupt detection” dropdown. The VOS3000 RTP interrupt detection requires the media proxy to be enabled for the call, as the softswitch can only observe RTP packets when it is proxying the media stream.

๐Ÿ’ก Key characteristics of RTP Interrupt Detection:

  • ๐Ÿ“ก Configuration location: Routing gateway > Additional settings > Normal > RTP interrupt detection
  • ๐Ÿ“‹ Per-gateway scope: Each routing gateway has its own VOS3000 RTP interrupt detection setting
  • ๐Ÿ”„ Four modes: None, Server to Remote, Remote to Server, Bidirection
  • ๐Ÿ”ง Prerequisite: Media proxy must be enabled (Auto, On, or Must On) for the VOS3000 RTP interrupt detection to function
  • ๐Ÿ“Š Action on detection: The call is interrupted (terminated) when RTP loss is detected in the monitored direction

๐Ÿ“‹ The Four VOS 3000 RTP Interrupt Detection Modes

๐Ÿ“Š The VOS3000 V2.1.9.07 Manual ยง2.5.1.1 (page 32) defines four modes for the VOS3000 RTP interrupt detection. Each mode determines which RTP direction is monitored and what action is taken when an interruption is detected:

ModeDescription (Manual)What Is MonitoredWhen Call Is Interrupted
๐Ÿšซ NoneDisable detectionNo RTP monitoringNever โ€” RTP interruptions are ignored
๐Ÿ“ค Server to RemoteDetect audio sent from server to deviceOutbound RTP: VOS3000 server โ†’ gateway deviceWhen server-to-device RTP stops flowing
๐Ÿ“ฅ Remote to ServerDetect audio sent from device to serverInbound RTP: gateway device โ†’ VOS3000 serverWhen device-to-server RTP stops flowing
๐Ÿ”„ BidirectionDetect both sides, if any one side no audio, the call will be interruptBoth directions simultaneouslyWhen RTP stops in EITHER direction

๐Ÿ’ก Critical manual note: The Bidirection mode description in the VOS3000 V2.1.9.07 Manual is explicit: “if any one side no audio, the call will be interrupt.” This means that losing RTP in just one direction is sufficient to trigger call interruption. This is the most aggressive VOS3000 RTP interrupt detection mode and provides the most comprehensive media monitoring, but it may also terminate calls prematurely in environments where temporary RTP gaps are normal (such as satellite links with variable latency).

๐Ÿ“Š Media Proxy Dependency for RTP Interrupt Detection

๐Ÿ”— The VOS3000 RTP interrupt detection requires the media proxy to be active for the call. Without media proxy, the softswitch does not observe the RTP stream and cannot detect interruptions. The VOS3000 RTP interrupt detection is fundamentally dependent on the media proxy configuration.

Media Proxy ModeRTP Interrupt Detection Effective?Implication for VOS3000 RTP Interrupt Detection
Auto (default)โœ… Yes โ€” when proxy is activatedVOS3000 RTP interrupt detection works for proxied calls; direct-RTP calls bypass monitoring
On / Must Onโœ… Yes โ€” all calls proxiedVOS3000 RTP interrupt detection monitors every call through this gateway
OffโŒ No โ€” no RTP observationVOS3000 RTP interrupt detection has no effect โ€” cannot observe RTP without proxy

๐Ÿ“Š Configuration recommendation: For the VOS3000 RTP interrupt detection to function reliably, set the media proxy to “Auto” or “On” for gateways where media monitoring is required. When media proxy is “Off,” the VOS3000 RTP interrupt detection parameter exists in the configuration but has no functional effect because the softswitch never sees the RTP packets. For comprehensive media proxy setup, see our VOS3000 RTP media guide.

๐Ÿ”„ Direction Monitoring Explained

๐Ÿ“ก Understanding the directional terminology in the VOS3000 RTP interrupt detection is essential for correct configuration. The terms “Server to Remote” and “Remote to Server” refer to the direction of RTP packet flow relative to the VOS3000 softswitch:

DirectionRTP FlowWhat Interruption IndicatesUse Case
๐Ÿ“ค Server to RemoteVOS3000 โ†’ Gateway device (outbound media)The originating side stopped sending audio โ€” caller may have gone silent or network issue on originating sideMonitor whether the calling party’s audio reaches the gateway
๐Ÿ“ฅ Remote to ServerGateway device โ†’ VOS3000 (inbound media)The gateway stopped sending audio โ€” gateway or downstream network issueMonitor whether the gateway’s audio reaches VOS3000
๐Ÿ”„ BidirectionBoth directionsEither side stopped โ€” comprehensive media loss detectionMaximum protection โ€” detects any RTP interruption regardless of direction

๐Ÿ’ก Direction selection tip: Choose “Server to Remote” when you want to detect if the calling party’s audio stops reaching the gateway. Choose “Remote to Server” when you want to detect if the gateway’s audio stops reaching VOS3000. Choose “Bidirection” for comprehensive VOS3000 RTP interrupt detection that catches media loss in either direction. For most production deployments, Bidirection provides the most complete monitoring, but it may be too aggressive for networks with occasional RTP gaps.

๐Ÿ“Š VOS 3000 RTP Interrupt Detection Mode Comparison by Deployment

DeploymentRecommended ModeRationale
๐Ÿข Retail VoIP (reliable networks)BidirectionClean up zombie calls quickly โ€” reliable network means RTP gaps indicate real problems
๐Ÿ”„ Wholesale terminationRemote to ServerFocus on whether the downstream carrier is delivering audio โ€” the most important quality indicator
๐Ÿ“ก Satellite / high-latency linksNone or Server to RemoteAvoid false positives from temporary RTP gaps on unreliable links
๐Ÿ’ณ Calling card / IVR servicesBidirectionZombie calls waste IVR resources and confuse billing โ€” aggressive cleanup is essential
๐Ÿงช Testing / lab environmentNoneDisable VOS3000 RTP interrupt detection during testing to avoid premature call termination

๐Ÿ›ก๏ธ Common VOSS3000 RTP Interrupt Detection Problems and Solutions

โŒ Problem 1: Calls Being Terminated Prematurely

๐Ÿ” Symptom: Active calls with normal conversation are being terminated unexpectedly, with CDR records indicating RTP interrupt detection as the cause.

๐Ÿ’ก Cause: The VOS3000 RTP interrupt detection is set to Bidirection mode on a network with occasional RTP packet gaps. Temporary network congestion or jitter buffers can cause brief RTP interruptions that trigger the detection and terminate the call.

โœ… Solutions:

  • ๐Ÿ”ง Change the VOS3000 RTP interrupt detection to a less aggressive mode โ€” Server to Remote or Remote to Server instead of Bidirection
  • ๐Ÿ“Š If both directions are needed, consider disabling VOS3000 RTP interrupt detection and using monitoring alarms instead for passive observation
  • ๐Ÿ“‹ Investigate network quality issues causing the RTP gaps โ€” resolve the root cause rather than adjusting the detection threshold

โŒ Problem 2: RTP Interrupt Detection Not Working

๐Ÿ” Symptom: The VOS3000 RTP interrupt detection is configured to Server to Remote or Bidirection, but calls with no audio continue without being terminated.

๐Ÿ’ก Cause: The media proxy is not enabled for the affected calls. Without media proxy, VOS3000 cannot observe RTP packets and the VOS3000 RTP interrupt detection has no effect.

โœ… Solutions:

  • ๐Ÿ”ง Verify the media proxy setting for the routing gateway โ€” must be Auto, On, or Must On
  • ๐Ÿ“Š Check if specific calls are bypassing the media proxy due to codec negotiation or NAT configuration
  • ๐Ÿ“‹ Ensure the RTP media proxy is functioning correctly for all calls through this gateway

โŒ Problem 3: One-Way Audio Not Detected

๐Ÿ” Symptom: One-way audio occurs on calls through a gateway with VOS3000 RTP interrupt detection enabled, but the call is not terminated โ€” the detection fails to catch the media loss.

๐Ÿ’ก Cause: The VOS3000 RTP interrupt detection mode is set to monitor only one direction (e.g., Server to Remote), but the audio loss is occurring in the opposite direction (Remote to Server). The unmonitored direction is not checked.

โœ… Solutions:

  • ๐Ÿ”ง Change the VOS3000 RTP interrupt detection to Bidirection mode to monitor both RTP directions
  • ๐Ÿ“Š Analyze CDR records to determine which direction typically loses audio โ€” adjust the VOS3000 RTP interrupt detection mode accordingly
  • ๐Ÿ“‹ Resolve the underlying one-way audio issue rather than relying solely on detection

๐Ÿ’ก VOS 3000 RTP Interrupt Detection Best Practices

Best PracticeRecommendationReason
๐Ÿ“ก Enable media proxy firstSet media proxy to Auto or On before configuring the VOS3000 RTP interrupt detection๐Ÿ”ง VOS3000 RTP interrupt detection cannot function without media proxy observing RTP packets
๐Ÿ”„ Use Bidirection for clean networksEnable Bidirection mode when network quality is reliable๐Ÿ“Š Most comprehensive VOS3000 RTP interrupt detection โ€” catches media loss in either direction
โš ๏ธ Be cautious on unstable linksUse None or single-direction detection on satellite or high-jitter links๐Ÿ“‹ Prevents false-positive call terminations from temporary RTP gaps
๐Ÿ“Š Monitor CDR after enablingCheck call end reasons in CDR after deploying the VOS3000 RTP interrupt detection๐Ÿ“ˆ Verifies detection is working correctly and not causing premature terminations
๐Ÿ“ž Pair with RTP lock-inKeep SS_GATEWAY_SWITCH_STOP_AFTER_RTP_START = On alongside the VOS3000 RTP interrupt detection๐Ÿ›ก๏ธ RTP lock-in prevents switching after media starts; VOS3000 RTP interrupt detection monitors for media loss

๐Ÿ’ฌ Need VOS3000 RTP detection help? WhatsApp +8801911119966

๐Ÿ“‹ VOS3000 RTP Interrupt Detection Quick Decision Table

๐ŸŽฏ Use this decision table to select the correct VOS3000 RTP interrupt detection mode for your deployment scenario:

Your RequirementRecommended ModeReason
I want to monitor for audio loss without disconnecting callsServer to remote or Remote to serverDetects one-way audio and reports without terminating the call
I need to automatically hang up calls with no audioBidirectionDetects loss in both directions and terminates dead calls automatically
My gateway reports false RTP interrupts frequentlyNoneDisables detection to prevent false positives from unreliable gateways

โ“ Frequently Asked Questions

โ“ What is the default VOS 3000 RTP interrupt detection setting?

๐Ÿ”ง The default VOS3000 RTP interrupt detection setting depends on the gateway configuration. For new routing gateways, the default is typically “None” (detection disabled), meaning the softswitch does not monitor RTP packet flow for interruptions. You must explicitly configure the VOS3000 RTP interrupt detection to one of the active modes (Server to Remote, Remote to Server, or Bidirection) to enable media monitoring for that gateway. The VOS3000 RTP interrupt detection is a per-gateway setting, so you can enable different modes on different gateways based on their network characteristics.

โ“ Does VOS3000 RTP interrupt detection work without media proxy?

๐Ÿ“ก No, the VOS3000 RTP interrupt detection requires the media proxy to be active for the call. Without media proxy, VOS3000 does not see the RTP packets flowing between the caller and the gateway, so it cannot detect when the RTP stream is interrupted. The VOS3000 RTP interrupt detection is fundamentally dependent on the media proxy’s ability to observe and relay RTP media packets. If the media proxy is set to “Off,” the VOS3000 RTP interrupt detection parameter exists in the gateway configuration but has no functional effect.

โ“ What is the difference between Bidirection and single-direction detection?

๐Ÿ”„ The key difference is the scope of monitoring. “Server to Remote” only monitors the outbound RTP direction (VOS3000 โ†’ gateway device). “Remote to Server” only monitors the inbound RTP direction (gateway device โ†’ VOS3000). “Bidirection” monitors both directions simultaneously โ€” according to the manual, “if any one side no audio, the call will be interrupt.” The VOS3000 RTP interrupt detection in Bidirection mode provides the most comprehensive monitoring but is also the most aggressive, as it will terminate the call if RTP stops in either direction. Single-direction detection is more tolerant of one-way RTP gaps.

โ“ Will RTP interrupt detection terminate calls during temporary network congestion?

โš ๏ธ Yes, the VOS3000 RTP interrupt detection can terminate calls during temporary network congestion if the RTP gap exceeds the detection threshold. This is why the VOS3000 RTP interrupt detection should be used cautiously on networks with variable quality. For reliable, low-latency networks, Bidirection mode works well. For networks prone to temporary congestion or jitter, consider using “Server to Remote” or “None” mode, and instead rely on ASR ACD analysis and quality monitoring to detect media problems without automatically terminating calls.

โ“ Can I set different RTP interrupt detection modes on different gateways?

๐Ÿ”ง Yes, the VOS3000 RTP interrupt detection is configured per-gateway. Each routing gateway can have its own VOS3000 RTP interrupt detection mode. This means you can set Bidirection mode on a gateway connected to a reliable carrier, Server to Remote on a gateway with occasional upstream issues, and None on a gateway connected through a satellite link. This per-gateway flexibility in the VOS3000 RTP interrupt detection system allows you to tailor media monitoring to the specific network conditions of each gateway.

โ“ How does RTP interrupt detection interact with gateway failover?

๐Ÿ”„ The VOS3000 RTP interrupt detection and gateway failover operate at different levels. The VOS3000 RTP interrupt detection monitors media flow on an established call and terminates it if RTP is lost. Gateway failover (controlled by SS_GATEWAY_SWITCH_LIMIT and related parameters) handles the pre-connect phase where VOS3000 tries alternative gateways when the initial attempt fails. Once a call is connected and RTP is flowing, the VOS3000 RTP interrupt detection takes over to monitor media health. If the VOS3000 RTP interrupt detection terminates the call due to RTP loss, no further failover occurs โ€” the call is ended, not retried. For failover configuration, see our vendor failover setup guide. Need help? Contact us on WhatsApp at +8801911119966. ๐Ÿ“ฑ

๐Ÿ“ž Need Expert Help with VOS 3000 RTP Interrupt Detection?

๐Ÿ”ง Proper VOS3000 RTP interrupt detection configuration is essential for preventing zombie calls, conserving gateway resources, and maintaining accurate billing records. The VOS3000 RTP interrupt detection system with its four modes provides the flexibility to match monitoring intensity to network reliability. Whether you are troubleshooting one-way audio issues, configuring media monitoring for the first time, or balancing detection sensitivity against false positives on unreliable links, expert guidance ensures your VOS3000 RTP interrupt detection delivers the right level of protection. ๐Ÿ“ก

๐Ÿ’ฌ WhatsApp: +8801911119966 โ€” Get immediate assistance with VOS3000 RTP interrupt detection configuration, VOS3000 RTP interrupt detection troubleshooting, media proxy setup, and one-way audio resolution. Our team specializes in VOS3000 call quality management, media monitoring, and carrier-grade VoIP deployment. ๐Ÿ”ง

๐Ÿ”— Explore related VOS3000 media 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 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 Period Capacity Configuration, VOS3000 Period Dial Plan, VOS3000 RTP Interrupt Detection, VOS3000 Lowest Profit Rate Limit, VOS3000 Max Minute Rate Cap, VOS3000 Sort Lowest Rate Per Second, VOS3000 Check Rate Before Routing, VOS3000 Sort by Lowest Rate, VOS3000 Bilateral Reconciliation, VOS3000 SIP OPTIONS Online Check, VOS3000 T38 Fax Over IP, VOS3000 G729 Annex B Silence, VOS3000 Gateway Group Reserved Lines, VOS3000 Auxiliary Ring ToneVOS3000 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 Period Capacity Configuration, VOS3000 Period Dial Plan, VOS3000 RTP Interrupt Detection, VOS3000 Lowest Profit Rate Limit, VOS3000 Max Minute Rate Cap, VOS3000 Sort Lowest Rate Per Second, VOS3000 Check Rate Before Routing, VOS3000 Sort by Lowest Rate, VOS3000 Bilateral Reconciliation, VOS3000 SIP OPTIONS Online Check, VOS3000 T38 Fax Over IP, VOS3000 G729 Annex B Silence, VOS3000 Gateway Group Reserved Lines, VOS3000 Auxiliary Ring ToneVOS3000 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 Period Capacity Configuration, VOS3000 Period Dial Plan, VOS3000 RTP Interrupt Detection, VOS3000 Lowest Profit Rate Limit, VOS3000 Max Minute Rate Cap, VOS3000 Sort Lowest Rate Per Second, VOS3000 Check Rate Before Routing, VOS3000 Sort by Lowest Rate, VOS3000 Bilateral Reconciliation, VOS3000 SIP OPTIONS Online Check, VOS3000 T38 Fax Over IP, VOS3000 G729 Annex B Silence, VOS3000 Gateway Group Reserved Lines, VOS3000 Auxiliary Ring Tone
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