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. ๐
Table of Contents
๐ 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.
| Problem | Cause | Impact |
|---|---|---|
| ๐ One-way audio | RTP stream torn down on old gateway, new gateway not yet established | ๐ด Caller or callee hears silence while the other side can still speak |
| ๐ป Ghost calls | Old gateway continues RTP without SIP control channel | ๐ด Callee continues conversation with no one on the line |
| ๐ฐ Billing corruption | CDR records split across two gateways for one conversation | ๐ด Double billing or missing billing for partial call segments |
| ๐ Media resource waste | Old 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
| Attribute | Detail |
|---|---|
| ๐ Parameter Name | SS_GATEWAY_SWITCH_STOP_AFTER_RTP_START |
| ๐ Manual Description | Stop Switch Gateway when RTP Start (VOS3000 2.1.9.07 manual ยง4.3.5.2, page 236) |
| ๐ง Default Value | On |
| ๐ Configuration Path | Operation management > Softswitch management > Additional settings > System parameter |
| ๐ Per-Gateway Override | Yes โ Routing gateway > Additional settings > Stop switch gateway when rtp start |
| ๐ก Prerequisite | Media proxy must be enabled for RTP detection |
| ๐ก๏ธ Priority | Overrides 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 Level | Parameter / Setting | Behavior |
|---|---|---|
| 1๏ธโฃ Highest | SS_GATEWAY_SWITCH_STOP_AFTER_RTP_START (On) | Stops ALL switching once RTP detected โ overrides everything |
| 2๏ธโฃ High | SS_GATEWAY_SWITCH_STOP_AFTER_USER_BUSY (On) | Stops switching on 486 Busy โ independent of UNTIL_CONNECT |
| 3๏ธโฃ Medium | Protocol > Stop switch after OLC / Stop switch after SDP | Per-protocol stop conditions โ overridden by RTP lock-in |
| 4๏ธโฃ Base | SS_GATEWAY_SWITCH_UNTIL_CONNECT | Aggressive mode โ still stops on RTP when lock-in is On |
| 5๏ธโฃ Ceiling | SS_GATEWAY_SWITCH_LIMIT | Maximum 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 Mode | RTP Lock-In Effective? | Implication |
|---|---|---|
| Auto (default) | โ Yes โ when proxy is activated for NAT traversal | RTP lock-in works for proxied calls; direct RTP calls bypass detection |
| Always On | โ Yes โ all calls go through media proxy | RTP lock-in protects every call โ most secure configuration |
| Off | โ No โ no RTP observation possible | RTP lock-in parameter has no effect โ rely on protocol-level stops only |
| Behind NAT only | โ Partial โ only for NAT-traversed calls | Direct-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 Level | Configuration Location | Priority |
|---|---|---|
| ๐ System default | Softswitch management > Additional settings > System parameter > SS_GATEWAY_SWITCH_STOP_AFTER_RTP_START | Base โ applies to all gateways without per-gateway override |
| ๐ก Per-gateway override | Routing gateway > Additional settings > Stop switch gateway when rtp start | Overrides 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 Practice | Recommendation | Reason |
|---|---|---|
| ๐ Always enable in production | SS_GATEWAY_SWITCH_STOP_AFTER_RTP_START = On | ๐ก๏ธ Prevents one-way audio and ghost calls from post-RTP switching |
| ๐ก Enable media proxy | Set SS_MEDIA_PROXY_MODE to Auto or Always On | ๐ง RTP lock-in requires media proxy for RTP detection |
| ๐ซ Never disable for individual gateways | Keep per-gateway “Stop switch when rtp start” = Default or On | ๐ Consistent protection across all routing paths |
| ๐ Pair with busy stop switch | SS_GATEWAY_SWITCH_STOP_AFTER_USER_BUSY = On | ๐ Two independent stop conditions provide layered protection |
| ๐งช Test before changing | Only 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:
- VOS3000 RTP Media โ Complete media proxy and RTP configuration guide
- VOS3000 One-Way Audio Fix โ Troubleshooting one-way audio problems
- VOS3000 Vendor Failover Setup โ Complete failover configuration guide
- VOS3000 Gateway Configuration Routing Mapping โ Gateway routing and mapping setup
- VOS3000 Echo Delay Fix โ Solving echo and delay problems
- VOS3000 System Parameters โ Complete system parameter 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
![]() | ![]() | ![]() |


