VOS3000 One-Way Audio Fix, VOS3000 MySQL Connection Failed, VOS3000 EMP Start Failed, VOS3000 DDoS Protection, VOS3000 Database Recovery, VOS3000 Call Drop Disconnect , VOS3000 SIP Registration Failed, VOS3000 High CPU Usage

VOS3000 Call Drop Disconnect Proven Troubleshooting Guide

VOS3000 Call Drop Disconnect Proven Troubleshooting Guide ๐Ÿ“ž

Random call drops and disconnects on your VOS3000 softswitch can destroy customer confidence and erode your profit margins. ๐Ÿ˜ž When calls cut off unexpectedly, users blame your service regardless of the actual root cause. A VOS3000 call drop disconnect issue can stem from RTP timeouts, SIP session timer expiry, firewall UDP timeouts, NAT keepalive failures, aggressive failover switching, or upstream provider rejections. This comprehensive guide provides proven diagnostic techniques and solutions for each type of call drop, helping you restore stable, reliable call connections on your VOS3000 platform. ๐Ÿ”ง

Understanding why a VOS3000 call drop disconnect occurs requires analyzing the SIP signaling and RTP media flow for the affected calls. VOS3000 generates detailed CDR (Call Detail Records) that include release cause codes, which tell you exactly why each call ended. By correlating CDR data with network-level diagnostics, you can pinpoint whether the drop is caused by a network issue, a configuration problem, or an upstream provider issue. This guide covers every major cause category with specific diagnostic steps and solutions. ๐Ÿ“‹

Table of Contents

Understanding Call Drop Types in VOS3000 ๐Ÿ“Š

Not all call drops are the same. The VOS3000 call drop disconnect can be categorized by timing (early disconnect vs mid-call), by cause (network timeout vs signaling failure), and by direction (originator disconnect vs terminator disconnect). Understanding the type helps you narrow down the root cause quickly. โฑ๏ธ

Drop TypeTypical DurationSIP MethodRelease CauseCategory
RTP timeoutAfter 30s silenceBYE from VOS3000102 Recovery on timer expiryNetwork
Session timer expiryAfter session intervalBYE from VOS3000102 Recovery on timer expiryConfiguration
Firewall UDP timeoutAfter 2-5 min idleNo BYE (just silence)VariesNetwork
Failover switchRandom, mid-callBYE or CANCEL41 Normal clearing or 487Configuration
Provider rejectionEarly, during setup503 or 48734/38/41Upstream
NAT keepalive lostAfter 1-5 minBYE or silence102Network

RTP Timeout and Media Inactivity ๐Ÿ”‡ (VOS3000 Call Drop Disconnect)

RTP timeout is one of the most common causes of VOS3000 call drop disconnect. When VOS3000 stops receiving RTP packets on an established call, it assumes the media path has failed and terminates the call by sending a SIP BYE. The default RTP timeout in VOS3000 is typically 30 seconds of media inactivity, but this can be configured in system parameters. ๐ŸŽฏ

RTP inactivity can be caused by: the endpoint losing network connectivity, a firewall dropping RTP packets mid-call, NAT pinhole expiry causing one-way RTP that VOS3000 detects as no media, or the endpoint crashing or rebooting during a call. When VOS3000 detects RTP timeout, it sends a BYE with the reason “Recovery on timer expiry” (Q.850 cause code 102). ๐Ÿ“‰

Diagnosing RTP Timeout (VOS3000 Call Drop Disconnect)

Check the CDR for the affected call. If the release cause is 102 (Recovery on timer expiry) and the call duration is between 30-60 seconds, RTP timeout is likely the cause. Verify by capturing RTP traffic during a problem call:

# Monitor RTP flow for a specific call
tcpdump -n -i eth0 host ENDPOINT_IP and udp portrange 10000-60000 -c 100

# If RTP stops flowing before the call ends, you have an RTP timeout
# Check VOS3000 RTP timeout setting in System Parameters

Resolving RTP Timeout (VOS3000 Call Drop Disconnect)

For a VOS3000 call drop disconnect caused by RTP timeout, the fix depends on why RTP stopped flowing. If the issue is NAT pinhole expiry, enable media proxy so RTP flows through VOS3000. If the issue is firewall UDP timeout, increase the UDP timeout on the firewall. If the issue is the endpoint losing connectivity, investigate the endpoint network. You can also increase the RTP timeout value in VOS3000 system parameters, but this is a workaround rather than a fix. ๐Ÿ”ง

Configure the RTP timeout in VOS3000:

System Parameters -> Media -> RTP Timeout
Default: 30 seconds
Recommended: 30-60 seconds (increase only if needed)
RTP Timeout CauseDiagnostic MethodSolution
NAT pinhole expiryRTP stops in one directionEnable media proxy on VOS3000
Firewall UDP timeoutRTP stops after idle periodIncrease firewall UDP timeout
Endpoint network lossBoth RTP directions stopFix endpoint connectivity
Media proxy disabledRTP direct between NAT endpointsEnable media proxy
Port exhaustionNew calls fail, existing calls dropIncrease RTP port range

SIP Session Timer Expiry โฐ (VOS3000 Call Drop Disconnect)

The SIP Session Timer (RFC 4028) is a mechanism to detect when a SIP session has become stale. If the session timer expires without a successful refresh, VOS3000 terminates the call with a BYE. Misconfigured session timers are a common cause of VOS3000 call drop disconnect. ๐Ÿ•

The SIP Session Timer works through re-INVITE or UPDATE messages sent periodically during a call to refresh the session. If VOS3000 sends a re-INVITE for session refresh but does not receive a response (200 OK), the session timer expires and the call is dropped. This can happen when: the session timer interval is too short, the re-INVITE is lost due to network issues, the endpoint does not support session timers, or NAT is interfering with the re-INVITE flow. โš ๏ธ

Diagnosing Session Timer Issues (VOS3000 Call Drop Disconnect)

Capture SIP traffic during a dropped call and look for re-INVITE messages:

# Capture SIP signaling including re-INVITEs
tcpdump -n -i eth0 port 5060 -A -s 0 | grep -E "(INVITE|Session-Expires|Min-SE)"

# Look for re-INVITE messages sent during the call
# Check if 200 OK response is received for the re-INVITE

If you see a re-INVITE from VOS3000 but no 200 OK response, the session timer is expiring because the re-INVITE response is lost. This is a common VOS3000 call drop disconnect scenario. ๐Ÿ“‹

Resolving Session Timer Issues (VOS3000 Call Drop Disconnect)

Adjust the session timer settings in VOS3000. Navigate to System Parameters and configure the session timer interval. The default is typically 1800 seconds (30 minutes), but you can increase it to reduce the frequency of re-INVITEs. Alternatively, you can disable session timers entirely if your endpoints do not support them properly. Learn more about VOS3000 session timer configuration. โฑ๏ธ

VOS3000 Session Timer Configuration:

System Parameters -> SIP -> Session Timer
- Session Expires: 1800 (increase to 3600 if needed)
- Min-SE: 90
- Session Timer Refresher: uac (let the client refresh)

OR disable session timers if endpoints do not support them:
- Session Expires: 0 (disabled)
Session Timer SettingDefaultRecommendedEffect
Session Expires1800 seconds1800-3600 secondsLonger interval means fewer re-INVITEs
Min-SE90 seconds90 secondsMinimum allowed session time
RefresheruacuacClient-initiated refresh
SupportEnabledDisable if not supportedPrevents timer-related drops

Firewall UDP Timeout ๐Ÿงฑ (VOS3000 Call Drop Disconnect)

Stateful firewalls track UDP connections with a timeout value. When no packets are seen on a UDP flow for the timeout duration, the firewall removes the flow entry and silently drops subsequent packets. This causes a VOS3000 call drop disconnect because RTP streams that experience silence (such as when a caller is on mute) will have their firewall entries expire. ๐Ÿ”ฅ

The default UDP timeout on many firewalls is 30-120 seconds. For VoIP calls where silence suppression is enabled, RTP packets may stop flowing during silent periods, causing the firewall to expire the connection. When the caller speaks again, the RTP packets are dropped by the firewall, resulting in one-way audio followed by RTP timeout and call drop. ๐Ÿ˜ค

Diagnosing Firewall UDP Timeout (VOS3000 Call Drop Disconnect)

This issue is characterized by calls that drop after a period of silence (muting) or after a fixed duration. The CDR will show the call ended with RTP timeout. To confirm, temporarily disable the firewall and test. If the drops stop, the firewall UDP timeout is the cause. ๐Ÿ”

# Check Linux conntrack UDP timeout
cat /proc/sys/net/netfilter/nf_conntrack_udp_timeout
cat /proc/sys/net/netfilter/nf_conntrack_udp_timeout_stream

# Default values are typically 30 and 180 seconds
# Increase these for VoIP traffic

Resolving Firewall UDP Timeout (VOS3000 Call Drop Disconnect)

Increase the UDP timeout values on your firewall for the VOS3000 call drop disconnect fix. On Linux with iptables/conntrack:

# Increase conntrack UDP timeouts for VoIP
echo 3600 > /proc/sys/net/netfilter/nf_conntrack_udp_timeout_stream
echo 300 > /proc/sys/net/netfilter/nf_conntrack_udp_timeout

# Make persistent across reboots
echo "net.netfilter.nf_conntrack_udp_timeout_stream = 3600" >> /etc/sysctl.conf
echo "net.netfilter.nf_conntrack_udp_timeout = 300" >> /etc/sysctl.conf
sysctl -p

For hardware firewalls (Cisco ASA, Fortinet, Palo Alto), increase the UDP timeout in the firewall policy or create a dedicated VoIP policy with a longer timeout. A minimum of 3600 seconds (1 hour) is recommended for RTP streams. ๐Ÿ›ก๏ธ

NAT Keepalive Configuration ๐Ÿ’“ (VOS3000 Call Drop Disconnect)

NAT keepalive is essential for maintaining UDP connections through NAT devices. Without keepalive packets, the NAT mapping expires and subsequent packets are dropped. This causes a VOS3000 call drop disconnect when endpoints are behind NAT. The keepalive mechanism sends periodic empty packets to refresh the NAT mapping. ๐Ÿ”„

VOS3000 supports SIP OPTIONS keepalive for SIP trunks and gateways. When enabled, VOS3000 sends periodic OPTIONS requests to the endpoint, and the response refreshes the NAT mapping. For RTP keepalive, VOS3000 can send empty RTP packets (comfort noise) during silent periods to keep the RTP NAT pinholes open. This is configured through the media proxy settings. ๐Ÿ”Š

Configuring NAT Keepalive in VOS3000 (VOS3000 Call Drop Disconnect)

VOS3000 NAT Keepalive Configuration:

1. SIP OPTIONS Keepalive:
   - Navigate to SIP Gateway/Trunk configuration
   - Enable "Heartbeat" or "OPTIONS Keepalive"
   - Set interval: 30 seconds
   - Set retry count: 3

2. RTP Keepalive (via Media Proxy):
   - Enable Media Proxy for the gateway/trunk
   - Configure RTP keepalive interval: 20 seconds
   - This sends empty RTP packets during silence

3. Registration Keepalive:
   - Set SIP registration interval to 60 seconds
   - This refreshes the SIP NAT mapping frequently

By enabling both SIP OPTIONS and RTP keepalive, you prevent NAT mappings from expiring and significantly reduce VOS3000 call drop disconnect incidents. This is especially important for endpoints on residential or mobile networks with aggressive NAT timeouts. ๐Ÿ“ฑ

Keepalive TypeProtocolDefault IntervalRecommendedPrevents
SIP OPTIONSUDP 5060Disabled30 secondsSIP NAT timeout
RTP keepaliveUDP 10000-60000Disabled20 secondsRTP NAT timeout
SIP RegistrationUDP 50603600 seconds60 secondsRegistration NAT timeout

Failover and Aggressive Route Switching ๐Ÿ”„ (VOS3000 Call Drop Disconnect)

VOS3000 supports LCR (Least Cost Routing) with failover, where calls are automatically rerouted to alternative paths when the primary route fails. However, aggressive failover configuration can cause a VOS3000 call drop disconnect when VOS3000 switches routes on established calls rather than just on new call attempts. โšก

Failover-related drops happen when: the ASR (Answer Seizure Ratio) threshold triggers a route switch, the PDD (Post Dial Delay) threshold is exceeded, or the route is marked down based on recent call failures. When VOS3000 switches routes on an in-progress call, it may send a BYE on the current path and attempt to re-establish the call on a new path, which often results in a disconnect. ๐Ÿ”€

Diagnosing Failover Drops (VOS3000 Call Drop Disconnect)

Check the VOS3000 CDR for calls that show a route switch during the call. Look for CDR entries where the call was routed through one gateway initially but then shows a different gateway. Also check the VOS3000 routing log for route switch events. Use our VOS3000 LCR and routing optimization guides for detailed analysis. ๐Ÿ“

# Check VOS3000 routing logs
tail -500 /var/log/vos3000/mbx3000.log | grep -i "route"

# Look for "route change" or "failover" events
# These indicate mid-call route switching

Resolving Failover Drops (VOS3000 Call Drop Disconnect)

Configure VOS3000 failover to only switch routes on new calls, not on established calls. In the LCR and route configuration, set the failover mode to “next route on new call only”. This prevents mid-call route switching that causes VOS3000 call drop disconnect. Also adjust the ASR and ACD thresholds to be less aggressive. Very high ASR thresholds (above 80%) can trigger unnecessary route switches. ๐ŸŽ›๏ธ

For detailed call routing configuration, ensure your route groups are properly set up with appropriate failover priorities. Check our gateway configuration routing mapping guide for correct setup. ๐Ÿ“–

Provider Rejection: 503 and 487 Errors ๐Ÿšซ (VOS3000 Call Drop Disconnect)

Upstream provider rejections are a common external cause of VOS3000 call drop disconnect. When a provider returns a 503 Service Unavailable or 487 Request Terminated response, the call is terminated. Understanding these responses and configuring VOS3000 to handle them gracefully is essential. โ›”

503 Service Unavailable (VOS3000 Call Drop Disconnect)

A 503 response means the provider’s server cannot handle the call at this time. This can be due to provider capacity limits, provider maintenance, or the provider actively rejecting calls from your VOS3000 due to rate limiting. VOS3000 should fail over to the next available route when it receives a 503. ๐Ÿ”„

487 Request Terminated (VOS3000 Call Drop Disconnect)

A 487 response means the call was terminated before completion. This often happens when the caller hangs up before the callee answers, or when a SIP CANCEL is received. However, it can also indicate that the provider is canceling the call due to their own timeout or capacity issues. ๐Ÿ“‰

SIP ErrorMeaningVOS3000 ActionYour Response
503Provider unavailableFailover to next routeVerify provider status, add backup routes
487Request terminatedTerminate call, record CDRCheck if caller or provider initiated cancel
486Busy hereFailover or play busy toneNormal, callee is busy
480Temporarily unavailableFailover to next routeCallee not registered or offline
408Request timeoutFailover to next routeNetwork issue to provider

CDR Analysis for Release Causes ๐Ÿ“‹ (VOS3000 Call Drop Disconnect)

CDR analysis is your most powerful tool for diagnosing VOS3000 call drop disconnect patterns. VOS3000 CDR records include detailed release cause codes based on Q.850 that tell you exactly why each call ended. By analyzing these codes across many calls, you can identify systematic issues. ๐Ÿ“Š

Access CDR data through the VOS3000 web panel under CDR Query or use the CDR analysis billing tools. You can also query the MySQL database directly for advanced analysis. Use the call analysis and report management features for trend identification. ๐Ÿ”Ž

Q.850 CauseNameMeaningAction
16Normal clearingCall ended normally (user hangup)No action needed
17User busyCallee is busyNo action needed
18No user respondingCallee not answeringNo action needed
19No answer from userRinging timeoutCheck ring timeout settings
34No circuit availableProvider has no capacityAdd backup routes
38Network out of orderProvider network failureFailover to backup provider
41Temporary failureProvider temporary issueCheck provider status
102Recovery on timer expirySession/RTP timeoutCheck RTP flow, session timer

Diagnostic Decision Tree ๐ŸŒณ (VOS3000 Call Drop Disconnect)

Follow this decision tree to systematically diagnose any VOS3000 call drop disconnect issue. Start at the top and follow the path that matches your symptoms. ๐Ÿ—บ๏ธ

=============================================
 VOS3000 CALL DROP DISCONNECT DECISION TREE
=============================================

 START: Call Drop Reported
   |
   v
[1] Check CDR Release Cause Code
   |
   +--> 16 (Normal Clearing) --> Likely user hangup, no issue
   +--> 102 (Timer Expiry)   --> Go to STEP 2 (Timeout)
   +--> 34/38 (Network)      --> Go to STEP 3 (Provider)
   +--> 41 (Temp Failure)    --> Go to STEP 3 (Provider)
   +--> Other                --> Go to STEP 4 (Other)
   |
   v
[2] Timeout Analysis
   |
   +--> Call drops at consistent interval?
   |    YES --> SIP Session Timer issue
   |           --> Increase Session-Expires
   |           --> Disable session timer if endpoint lacks support
   |
   +--> Call drops after silence period?
   |    YES --> RTP timeout or Firewall UDP timeout
   |           --> Enable media proxy
   |           --> Increase firewall UDP timeout
   |           --> Enable NAT keepalive
   |
   +--> Call drops randomly?
   |    YES --> Check failover configuration
   |           --> Disable mid-call route switching
   |           --> Review LCR failover settings
   |
   v
[3] Provider Analysis
   |
   +--> Provider returns 503?
   |    YES --> Provider capacity issue
   |           --> Configure failover to backup provider
   |           --> Contact provider about limits
   |
   +--> Provider returns 487?
   |    YES --> Call cancelled by provider
   |           --> Check PDD timeout settings
   |           --> Verify call setup timing
   |
   v
[4] Other Causes
   |
   +--> Check VOS3000 logs for errors
   +--> Verify MySQL connectivity
   +--> Check EMP service status
   +--> Review system resource usage
   +--> Check for DDoS attack indicators
   |
   v
 RESOLVED: Call Stability Restored
=============================================

Preventing Call Drops in VOS3000 ๐Ÿ›ก๏ธ

Prevention is the best strategy for managing VOS3000 call drop disconnect issues. Implement these best practices to minimize call drops on your platform. ๐Ÿ—๏ธ

First, always enable media proxy for endpoints behind NAT. This eliminates the majority of RTP timeout and NAT-related drops. Second, configure appropriate SIP OPTIONS keepalive intervals (30 seconds) for all SIP trunks and gateways. Third, increase firewall UDP timeouts to at least 3600 seconds for RTP traffic. Fourth, configure session timers appropriately and disable them if endpoints do not support them. Fifth, set up proper failover routes with LCR configuration that does not switch routes on established calls. Use our ASR ACD analysis to monitor call quality metrics. ๐Ÿ“ˆ

Regular monitoring using the VOS3000 monitoring tools helps you detect call drop patterns early. Review the gateway analysis reports weekly to identify problematic routes or providers. For comprehensive troubleshooting methodology, refer to our VOS3000 troubleshooting guide 2026 and call end reasons reference. ๐Ÿ“š

Prevention MeasureConfigurationImpact
Enable media proxyPer gateway/trunkEliminates 90% of NAT drops
SIP OPTIONS keepalive30 second intervalPrevents SIP NAT timeout
UDP timeout 3600sFirewall/conntrackPrevents RTP NAT timeout
Session timer tuningSystem ParametersPrevents timer expiry drops
Failover configNo mid-call switchingPrevents failover drops
Backup routesLCR configurationHandles provider failures

Frequently Asked Questions โ“

Why do my VOS3000 calls drop after exactly 30 seconds?

Calls that drop after exactly 30 seconds of silence are typically caused by RTP timeout. VOS3000 has a default RTP inactivity timeout of 30 seconds. When no RTP packets are received for this duration, VOS3000 terminates the call. This usually happens because one direction of the RTP stream is blocked by a firewall or NAT. Enable media proxy and check firewall rules for the RTP port range. โฑ๏ธ

Why do calls drop after 30 minutes on VOS3000?

Calls that consistently drop after 30 minutes are caused by the SIP Session Timer. The default Session-Expires value in VOS3000 is 1800 seconds (30 minutes). If the session refresh (re-INVITE) fails, the call is dropped. Increase the Session-Expires value or disable session timers in System Parameters. Also investigate why the re-INVITE is failing (often a NAT or firewall issue). ๐Ÿ•

How do I increase the UDP timeout for RTP traffic on CentOS?

On CentOS, increase the conntrack UDP timeout by editing /etc/sysctl.conf and adding “net.netfilter.nf_conntrack_udp_timeout_stream = 3600” and “net.netfilter.nf_conntrack_udp_timeout = 300”. Then run “sysctl -p” to apply. For hardware firewalls, consult the firewall documentation for UDP timeout configuration. ๐Ÿงฑ

Can failover cause mid-call drops in VOS3000?

Yes, aggressive failover configuration can cause mid-call drops. If VOS3000 is configured to switch routes on established calls when the ASR drops below a threshold, it may send a BYE on the current call and attempt to reroute. Configure failover to only switch on new call attempts, not on established calls. Check the LCR failover settings in the VOS3000 web panel. ๐Ÿ”„

How do I analyze CDR data for call drop patterns?

Use the VOS3000 web panel CDR Query feature to filter calls by release cause code, gateway, time period, and other criteria. Look for patterns such as: specific gateways with high drop rates, specific time periods with increased drops, specific release cause codes appearing frequently, and calls to specific destinations dropping more often. Export CDR data to CSV for detailed analysis in spreadsheet tools. Use data report features for summary analysis. ๐Ÿ“Š

What is Q.850 cause code 102 in VOS3000?

Q.850 cause code 102 means “Recovery on timer expiry.” In VOS3000, this typically indicates that either the RTP timeout or SIP session timer expired. When you see cause code 102 in CDR, check whether the call duration aligns with your RTP timeout setting (usually 30 seconds of silence) or your session timer interval (default 1800 seconds). This helps you determine which timer is causing the drop. ๐Ÿ”ข

How do I configure SIP OPTIONS keepalive in VOS3000?

In the VOS3000 web panel, navigate to the SIP Gateway or SIP Trunk configuration. Enable the “Heartbeat” or “OPTIONS Keepalive” option. Set the interval to 30 seconds and the retry count to 3. VOS3000 will then send periodic SIP OPTIONS requests to the endpoint. If the endpoint does not respond after the configured retry count, VOS3000 marks the gateway/trunk as unavailable and uses failover routes. ๐Ÿ’“

Need Expert Help? Contact Us ๐Ÿ“ž

If you are still experiencing VOS3000 call drop disconnect issues after following this guide, our team of VOS3000 experts is available to help. We provide professional troubleshooting, optimization, and managed services for VOS3000 platforms of all sizes. ๐Ÿค

WhatsApp: +8801911119966

We offer VOS3000 installation, server rental, anti-hack protection, and comprehensive architecture design. For official VOS3000 software downloads, visit vos3000.com/downloads. ๐Ÿš€


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


VOS3000 One-Way Audio Fix, VOS3000 MySQL Connection Failed, VOS3000 EMP Start Failed, VOS3000 DDoS Protection, VOS3000 Database Recovery, VOS3000 Call Drop Disconnect , VOS3000 SIP Registration Failed, VOS3000 High CPU UsageVOS3000 One-Way Audio Fix, VOS3000 MySQL Connection Failed, VOS3000 EMP Start Failed, VOS3000 DDoS Protection, VOS3000 Database Recovery, VOS3000 Call Drop Disconnect , VOS3000 SIP Registration Failed, VOS3000 High CPU UsageVOS3000 One-Way Audio Fix, VOS3000 MySQL Connection Failed, VOS3000 EMP Start Failed, VOS3000 DDoS Protection, VOS3000 Database Recovery, VOS3000 Call Drop Disconnect , VOS3000 SIP Registration Failed, VOS3000 High CPU Usage
Detecciรณn interrupciรณn RTP VOS3000, Portabilidad numรฉrica LRN VOS3000, Reemplazo razรณn fallida VOS3000, Cรณdigos respuesta SIP CDR VOS3000, Configuraciรณn servidor LRN VOS3000, Precisiรณn decimal tarifas VOS3000

Detecciรณn interrupciรณn RTP VOS3000 Accurate monitoreo de medios en cuatro modos

Detecciรณn interrupciรณn RTP VOS3000 Accurate monitoreo de medios en cuatro modos

La detecciรณn interrupciรณn RTP VOS3000 es uno de los mecanismos mรกs crรญticos del mapping gateway para garantizar la calidad y la eficiencia de las llamadas VoIP en producciรณn. Cuando el flujo RTP (Real-Time Transport Protocol) que transporta el audio de una llamada se interrumpe inesperadamente โ€” por fallas de red, desconexiรณn del gateway o problemas de NAT โ€” la llamada puede quedar en estado zombi sin audio para ninguna de las partes. VOS3000 ofrece cuatro modos de detecciรณn que permiten desde ignorar el problema hasta colgar automรกticamente la llamada afectada, liberando recursos y evitando CDRs con duraciones infladas. ยฟNecesita ayuda con esta configuraciรณn? Contรกctenos por WhatsApp: +8801911119966.

En redes VoIP de alta densidad, especialmente en entornos de wholesale donde miles de llamadas concurrentes atraviesan mรบltiples gateways y operadores, la interrupciรณn del flujo RTP es un evento frecuente. Las llamadas sin audio consumen canales concurrentes, generan CDRs con duraciones que no reflejan comunicaciรณn real y degradan la experiencia del usuario final. Segรบn el manual de administraciรณn del mapping gateway (ยง2.5.1.1, pรกg. 87-89, apartado Media Parameters), VOS3000 proporciona un mecanismo robusto para detectar y responder a estas interrupciones de manera automรกtica segรบn la estrategia que el operador defina para cada gateway de forma independiente.

๐Ÿ“‹ Los Cuatro Modos de Detecciรณn Interrupciรณn RTP

VOS3000 proporciona cuatro modos distintos de detecciรณn, cada uno diseรฑado para un escenario operativo diferente. La selecciรณn del modo se configura de forma independiente para cada mapping gateway, lo que permite aplicar estrategias diferentes segรบn el comportamiento de cada carrier.

๐Ÿ”น Modo๐Ÿ”น Nombre๐Ÿ”น Comportamiento๐Ÿ”น Caso de Uso
0None (Ninguno)No detecta interrupciones RTPEntornos de prueba o trรกfico interno confiable
1Detect Only (Solo Detectar)Detecta pero no realiza ninguna acciรณnMonitoreo estadรญstico interno
2Detect and Report (Detectar e Informar)Detecta y genera alarma visible en NOCMonitoreo activo con notificaciรณn
3Detect and Hang Up (Detectar y Colgar)Detecta y termina la llamada automรกticamenteRecuperaciรณn automรกtica de recursos

๐Ÿ” Modo None โ€” Sin Detecciรณn

Cuando el parรกmetro estรก configurado en modo None, el softswitch ignora completamente las interrupciones del flujo RTP. Si el audio deja de fluir, la llamada permanece activa hasta que una de las partes cuelga o se agota el session timer. Este modo es apropiado para entornos donde las interrupciones son extremadamente raras, como redes internas cerradas con gateways de alta confiabilidad. Detecciรณn Interrupciรณn RTP

โš ๏ธ Advertencia: En modo None, las llamadas sin audio pueden permanecer activas indefinidamente si el session timer no estรก configurado. Esto consume canales concurrentes innecesariamente y genera CDRs con duraciones infladas. Para la mayorรญa de entornos de producciรณn se recomienda al menos el modo Detect and Report. Detecciรณn Interrupciรณn RTP

๐Ÿ”น Aspecto๐Ÿ”น Comportamiento en Modo None
Detecciรณn RTPCompletamente deshabilitada
Llamada sin audioPermanece activa hasta colgar manual o timeout
Impacto en CDRDuraciรณn inflada โ€” se factura tiempo sin comunicaciรณn
Consumo de recursosCanal concurrente ocupado innecesariamente

๐Ÿ“Š Modo Detect Only โ€” Detecciรณn Sin Acciรณn

En el modo Detect Only, VOS3000 monitorea activamente el flujo RTP y detecta cuando se interrumpe, pero no realiza ninguna acciรณn automรกtica. La detecciรณn se registra internamente para fines estadรญsticos y puede utilizarse con las herramientas de monitoreo del sistema para generar reportes de calidad. Este modo es รบtil cuando el operador desea recopilar datos sobre la frecuencia de interrupciones sin afectar las llamadas. Para configuraciรณn de monitoreo avanzado, consulte nuestra guรญa de monitoreo y alarmas.

๐Ÿ”” Modo Detect and Report โ€” Detecciรณn con Notificaciรณn

El modo Detect and Report genera una alarma visible en el sistema de monitoreo del VOS3000 client cuando se detecta una interrupciรณn RTP. Esto permite a los operadores del NOC recibir alertas en tiempo real sobre llamadas afectadas, facilitando la identificaciรณn proactiva de problemas de red. La llamada permanece activa a pesar de la alarma, por lo que las partes pueden reanudar la comunicaciรณn si la interrupciรณn es temporal. Para entender mejor el sistema de alarmas, consulte nuestra guรญa de monitoreo. ยฟNecesita asesorรญa? Escrรญbanos por WhatsApp: +8801911119966.

๐Ÿ”น Modo๐Ÿ”น Detecciรณn๐Ÿ”น Acciรณn Automรกtica๐Ÿ”น Notificaciรณn๐Ÿ”น CDR
NoneNoNingunaNoDuraciรณn inflada
Detect OnlySรญNingunaSolo registro internoDuraciรณn inflada
Detect and ReportSรญNingunaAlarma visible en NOCDuraciรณn inflada
Detect and Hang UpSรญTermina la llamadaCDR registradoDuraciรณn precisa

๐Ÿ“ž Modo Detect and Hang Up โ€” Recuperaciรณn Automรกtica

El modo Detect and Hang Up es la opciรณn mรกs robusta y la mรกs recomendada para entornos de producciรณn de alta densidad. Cuando se detecta una interrupciรณn RTP, VOS3000 termina automรกticamente la llamada enviando un mensaje BYE a ambas partes, liberando canales concurrentes y recursos de medios, y generando un CDR con la duraciรณn real de la comunicaciรณn. Para entender cรณmo estos eventos se registran en los CDRs, consulte nuestra guรญa de anรกlisis de CDR. Para problemas de llamadas sin audio, vea tambiรฉn VOS3000 No Media Hangup.

โš™๏ธ Configuraciรณn Paso a Paso – Detecciรณn Interrupciรณn RTP

Para configurar la detecciรณn interrupciรณn RTP VOS3000 en un mapping gateway, siga estos pasos. La configuraciรณn se realiza de forma independiente para cada gateway. Para mรกs detalles sobre la configuraciรณn de gateways, consulte nuestra guรญa de configuraciรณn de gateways.

๐Ÿ”น Paso๐Ÿ”น Acciรณn๐Ÿ”น Detalle
1Abrir mapping gatewayGateway > Mapping Gateway en el cliente VOS3000
2Localizar RTP Interrupt DetectionSecciรณn Media Parameters, ยง2.5.1.1, pรกg. 87
3Seleccionar modoNone, Detect Only, Detect and Report, o Detect and Hang Up
4Configurar timeout RTPSegundos sin RTP antes de considerar interrupciรณn
5Guardar configuraciรณnAplicar cambios al gateway
6Verificar con pruebasSimular interrupciรณn RTP y verificar comportamiento

๐Ÿ“ˆ Impacto en la Facturaciรณn y Precisiรณn de CDRs

La elecciรณn del modo de detecciรณn tiene un impacto directo en la precisiรณn de los registros de facturaciรณn. Cuando una llamada pierde audio pero permanece activa (modos None, Detect Only o Detect and Report), el CDR continรบa acumulando duraciรณn hasta que la llamada se termina por otro medio. Esto resulta en CDRs con duraciones mayores al tiempo real de comunicaciรณn. El modo Detect and Hang Up resuelve este problema terminando la llamada en el momento de la detecciรณn. Para mรกs informaciรณn, consulte nuestra guรญa del sistema de facturaciรณn.

๐Ÿ”น Escenario๐Ÿ”น Sin Detecciรณn (None)๐Ÿ”น Con Detect and Hang Up
Llamada de 3 min con RTP interrumpido a los 30 segCDR registra 3 minutosCDR registra 30 segundos
Sobrecoste al cliente5x mรกs de lo realFacturaciรณn precisa
Disputa de facturaciรณnProbableMinimizada

๐Ÿ› ๏ธ Soluciรณn de Problemas Comunes – Detecciรณn Interrupciรณn RTP

Los siguientes problemas y soluciones le ayudarรกn a optimizar la configuraciรณn. Para problemas relacionados con audio, consulte nuestra guรญa de soluciรณn de eco y retardo.

๐Ÿ”น Problema๐Ÿ”น Causa Probable๐Ÿ”น Soluciรณn
Llamadas se cortan prematuramenteTimeout RTP demasiado cortoAumentar timeout a 30-60 seg
Llamadas sin audio permanecen activasModo configurado como NoneCambiar a Detect and Hang Up
Falsas detecciones en redes con alta latenciaLatencia variable excede el timeoutAjustar timeout segรบn latencia de red
No se detectan interrupcionesMedia proxy puede enmascarar interrupcionesVerificar configuraciรณn de media proxy
Cortes con codecs con supresiรณn de silencioVAD (G.729 Annex B) no envรญa paquetes en silencioDeshabilitar VAD o aumentar timeout

๐Ÿ”— Recursos Relacionados – Detecciรณn Interrupciรณn RTP en VOS3000

โ“ Preguntas Frecuentes sobre la Detecciรณn Interrupciรณn RTP en VOS3000

ยฟQuรฉ es la detecciรณn interrupciรณn RTP en VOS3000?

Es una funciรณn del mapping gateway de VOS3000 que monitorea el flujo de paquetes RTP durante una llamada activa. Cuando se detecta que los paquetes RTP han dejado de llegar durante un perรญodo configurable, el sistema puede tomar acciones que van desde registrar el evento hasta terminar automรกticamente la llamada. Esta funciรณn estรก documentada en la secciรณn ยง2.5.1.1 (pรกg. 87-89) del manual de administraciรณn y se configura de forma independiente para cada mapping gateway, permitiendo estrategias diferentes segรบn el comportamiento de cada carrier conectado a la plataforma.

ยฟCuรกl es la diferencia entre Detect and Report y Detect and Hang Up?

En modo Detect and Report, VOS3000 detecta la interrupciรณn y genera una alarma visible en el sistema de monitoreo del NOC, pero la llamada permanece activa โ€” las partes pueden seguir sin audio hasta que cuelguen manualmente. En modo Detect and Hang Up, VOS3000 detecta la interrupciรณn y termina inmediatamente la llamada enviando BYE a ambas partes, liberando recursos y generando un CDR con la duraciรณn real. El modo Detect and Hang Up es el recomendado para producciรณn wholesale porque garantiza CDRs precisos y evita el consumo innecesario de canales concurrentes. Detecciรณn Interrupciรณn RTP

ยฟQuรฉ valor de timeout RTP debo configurar?

Un valor tรญpico para entornos de producciรณn es de 30 a 60 segundos โ€” permite tolerar pausas breves en el audio sin generar falsas detecciones, pero es suficientemente corto para identificar interrupciones reales. En redes con alta latencia o enlaces satelitales, puede ser necesario aumentar el timeout a 90 o 120 segundos. El valor รณptimo debe determinarse mediante pruebas en su entorno especรญfico, ajustando segรบn la frecuencia de falsos positivos y la velocidad de detecciรณn deseada.

ยฟPuede la detecciรณn causar cortes de llamadas legรญtimas?

Sรญ, si el timeout RTP estรก configurado con un valor demasiado bajo, las pausas naturales en la conversaciรณn pueden ser detectadas errรณneamente como interrupciones RTP. Esto es mรกs probable cuando se utilizan codecs con supresiรณn de silencio (VAD) como G.729 Annex B, donde los perรญodos de silencio no generan paquetes RTP. Para evitar este problema, asegรบrese de que el timeout sea suficientemente largo (mรญnimo 30 segundos) y considere deshabilitar la supresiรณn de silencio en los gateways cuando utilice el modo Detect and Hang Up.

ยฟCรณmo afecta el media proxy a la detecciรณn de interrupciones RTP?

Cuando el media proxy estรก habilitado, el flujo RTP pasa a travรฉs del servidor VOS3000 en lugar de fluir directamente entre los endpoints. Esto puede facilitar la detecciรณn de interrupciones porque VOS3000 ve los paquetes de ambos lados. Sin embargo, si el media proxy estรก en modo bypass, los paquetes RTP no pasan por el servidor y la detecciรณn puede no funcionar correctamente. Siempre verifique la configuraciรณn del media proxy al implementar esta funciรณn.

ยฟEs recomendable usar el mismo modo para todos los gateways?

No necesariamente. La detecciรณn se configura por mapping gateway, lo que permite usar modos diferentes segรบn el comportamiento de cada carrier. Un gateway con un carrier de alta calidad puede usar Detect and Report para monitoreo pasivo, mientras que un gateway con un carrier propenso a interrupciones puede usar Detect and Hang Up para recuperaciรณn automรกtica. Esta flexibilidad permite optimizar la estrategia de monitoreo para cada interconexiรณn de forma independiente.

๐Ÿš€ Soporte Profesional

La configuraciรณn correcta de la detecciรณn interrupciรณn RTP es fundamental para mantener la calidad del servicio, la precisiรณn de la facturaciรณn y la eficiencia del uso de recursos en su plataforma VoIP. Nuestro equipo de especialistas puede ayudarle a seleccionar e implementar el modo รณptimo para cada gateway. Contรกctenos por WhatsApp: +8801911119966.

Desde la configuraciรณn inicial hasta la optimizaciรณn avanzada de calidad de servicio y monitoreo de alarmas, proporcionamos soporte experto para operadores en Colombia, Perรบ y toda Latinoamรฉrica. Escrรญbanos hoy al +8801911119966 y proteja la calidad de cada llamada en su red.


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


Detecciรณn interrupciรณn RTP VOS3000, Portabilidad numรฉrica LRN VOS3000, Reemplazo razรณn fallida VOS3000, Cรณdigos respuesta SIP CDR VOS3000, Configuraciรณn servidor LRN VOS3000, Precisiรณn decimal tarifas VOS3000Detecciรณn interrupciรณn RTP VOS3000, Portabilidad numรฉrica LRN VOS3000, Reemplazo razรณn fallida VOS3000, Cรณdigos respuesta SIP CDR VOS3000, Configuraciรณn servidor LRN VOS3000, Precisiรณn decimal tarifas VOS3000Detecciรณn interrupciรณn RTP VOS3000, Portabilidad numรฉrica LRN VOS3000, Reemplazo razรณn fallida VOS3000, Cรณdigos respuesta SIP CDR VOS3000, Configuraciรณn servidor LRN VOS3000, Precisiรณn decimal tarifas VOS3000
VOS3000 Authentication Suspend, VOS3000 Registration Flood Protection, VOS3000 No Media Hangup, VOS3000 Max Call Duration Limit, VOS3000 Billing Precision

VOS3000 No Media Hangup: Smart Auto-Disconnect for Ghost Calls Important

VOS3000 No Media Hangup: Smart Auto-Disconnect for Ghost Calls

In wholesale VoIP operations, few problems are as insidious and costly as ghost calls โ€” calls that remain connected in SIP signaling but have no RTP media flowing. These phantom sessions silently consume concurrent call capacity, inflate CDR durations, and generate billing disputes that erode customer trust. The VOS3000 no media hangup feature, configured through the SS_NOMEDIAHANGUPTIME system parameter documented in VOS3000 Manual Section 4.3.5.2, provides a Smart automatic disconnect mechanism that monitors RTP streams and terminates calls when media stops flowing for a configurable period.

This comprehensive guide explains what ghost calls are, how they impact your VoIP business, and how to configure VOS3000 no media hangup to automatically clean up dead call sessions. Whether you are dealing with NAT timeout issues, endpoint crashes, or one-way audio scenarios that leave zombie calls on your server, this guide covers the complete configuration, testing, and troubleshooting process. For professional assistance with VOS3000 ghost call prevention, contact us on WhatsApp at +8801911119966.

What Are Ghost Calls in VoIP?

A ghost call is a VoIP session that remains established in SIP signaling but has no active RTP media stream. The SIP dialog is still valid โ€” the call appears as “answered” and “connected” in the system โ€” but no voice packets are flowing between the endpoints. From the VOS3000 softswitch perspective, the call slot is occupied, the CDR timer is running, and the session counts against your concurrent call limit, but there is no actual voice communication happening.

Ghost calls are particularly dangerous because they are invisible to the caller and callee. Neither party is aware that a call session is still open on the server. The SIP signaling path may have been maintained through keepalive messages or simply because neither side sent a BYE message, while the RTP media path has completely died. The result is a zombie call that wastes resources and corrupts billing data until someone or something terminates it.

Why Ghost Calls Are a Serious Problem

Ghost calls create multiple layers of problems for VoIP operators:

  • Wasted concurrent call capacity: Every ghost call occupies a license slot that could be used for a real call. During network instability events, hundreds of ghost calls can accumulate, exhausting your concurrent call capacity and blocking legitimate traffic
  • Incorrect billing: CDR records show the full duration from answer to disconnect, including the period when no media was flowing. Customers are billed for dead air time, leading to disputes and chargebacks
  • Inflated CDR durations: Ghost calls can last for hours because neither endpoint sends a BYE. CDR records show extremely long call durations with no corresponding voice activity, distorting traffic analytics
  • Billing disputes: When customers analyze their CDRs and find calls lasting hours with no conversation, they dispute the charges. Resolving these disputes consumes time and damages business relationships
  • Resource exhaustion: Each ghost call maintains state in the VOS3000 media relay, consuming memory and processing resources that should be available for active calls

For a deeper understanding of VOS3000 media handling, see our VOS3000 RTP media guide.

How Ghost Calls Occur: Causes and Symptoms

Understanding the root causes of ghost calls is essential for effective prevention. Ghost calls typically occur when the SIP signaling path survives while the RTP media path fails. This section covers the most common causes and their telltale symptoms.

๐Ÿ‘ป Cause๐Ÿ“‹ Description๐Ÿ” Symptom in CDRโš ๏ธ Impact Level
Network connectivity lossInternet link failure between VOS3000 and one endpoint; SIP path via alternate route but RTP direct path brokenCall duration extends far beyond normal; no media packets during outage windowHigh โ€” multiple simultaneous ghost calls during outage
NAT timeoutNAT device drops RTP pinhole mapping due to inactivity; SIP signaling on separate pinhole survivesOne-way audio progressing to no audio; call remains connected indefinitelyMedium โ€” affects specific endpoint pairs behind NAT
Endpoint crash or rebootIP phone, gateway, or softphone crashes without sending SIP BYE or CANCELCDR shows call starting normally then continuing for extended period with no mediaMedium โ€” sporadic occurrence depending on endpoint stability
One-way audio scenarioMedia flows in one direction only; one endpoint sends RTP but the other cannot receive or respondAsymmetric RTP; one direction shows zero packets in captureMedium โ€” common with firewall and NAT misconfigurations
Firewall state table overflowFirewall drops RTP session state due to table overflow; SIP session on different port survivesSudden media loss during peak traffic; call remains in signaling stateHigh โ€” affects many calls simultaneously during peak hours
Codec renegotiation failureRe-INVITE for codec change fails on media path but succeeds on signaling pathCall connected with initial codec, then media stops after re-INVITELow โ€” rare but difficult to diagnose
SIP ALG interferenceRouter SIP ALG modifies SDP in ways that break RTP path while keeping SIP signaling functionalCall answers but no RTP flows from the start; stays connected until timeoutMedium โ€” common with consumer-grade routers

How VOS3000 No Media Hangup Works

The VOS3000 no media hangup feature provides an automatic mechanism to detect and terminate ghost calls. When enabled, VOS3000 continuously monitors the RTP media stream for each active call. If no RTP packets are received for the duration specified by the SS_NOMEDIAHANGUPTIME parameter, VOS3000 automatically sends a SIP BYE message to terminate the call and close the session.

The monitoring process works at the media relay level. When VOS3000 operates in Media Proxy mode, all RTP packets pass through the VOS3000 server. The media relay component tracks RTP packet reception for each active call session. If the RTP stream for a call stops โ€” meaning no RTP packets are received on either the caller or callee media port for the configured timeout period โ€” the system considers the call dead and initiates automatic disconnect by sending a SIP BYE to both endpoints.

This Smart detection mechanism is fundamentally different from the SIP session timer. The session timer operates at the SIP signaling layer and detects when SIP re-INVITE or UPDATE refreshes fail. The no media hangup operates at the RTP media layer and detects when voice packets stop flowing, regardless of whether the SIP signaling path is still alive. For details on the session timer mechanism, see our VOS3000 session timer 32-second drop guide.

The Auto-Disconnect Process Step by Step

When VOS3000 detects that no RTP media has been received for a call within the configured timeout, the following sequence occurs:

  1. RTP monitoring: The VOS3000 media relay continuously tracks RTP packet reception for every active call session
  2. Timeout detection: When no RTP packets are received for SS_NOMEDIAHANGUPTIME seconds on a call, the media relay flags the session as dead
  3. BYE generation: VOS3000 generates a SIP BYE request for the affected call and sends it to both the caller and callee endpoints
  4. Session teardown: The SIP dialog is terminated, media relay ports are released, and the call session state is cleaned up
  5. CDR closure: The CDR record is finalized with the disconnect time and appropriate cause code, recording the actual duration the call remained active
VOS3000 No Media Hangup Detection Flow:

1. Call established (SIP 200 OK received and ACKed)
2. RTP media proxy active โ€” packets flowing in both directions
3. RTP stream stops (no packets received from either endpoint)
4. Timer starts: counting seconds since last RTP packet received
5. Timer reaches SS_NOMEDIAHANGUPTIME seconds โ€” call flagged as ghost
6. VOS3000 sends SIP BYE to both endpoints
7. Call session terminated, media ports released, CDR closed

Key Requirement: Media Proxy mode must be active for RTP monitoring.
Direct media bypass mode does NOT support no media hangup detection.

For help configuring Media Proxy mode to support no media hangup detection, refer to the VOS3000 system parameter documentation or contact your system administrator.

Configuring SS_NOMEDIAHANGUPTIME in VOS3000

The SS_NOMEDIAHANGUPTIME parameter is the core configuration for the VOS3000 no media hangup feature. It defines the number of seconds VOS3000 waits without receiving any RTP packets before automatically disconnecting the call. This parameter is configured in the VOS3000 softswitch system parameters, as documented in VOS3000 Manual Section 4.3.5.2.

To configure SS_NOMEDIAHANGUPTIME, follow these steps:

  1. Log in to VOS3000: Access the VOS3000 client application with an administrator account
  2. Navigate to System Parameters: Go to Operation Management > Softswitch Management > Additional Settings > System Parameter
  3. Locate SS_NOMEDIAHANGUPTIME: Search for the parameter name in the system parameter list
  4. Set the timeout value: Enter the desired number of seconds (see configuration values table below)
  5. Save and apply: Save the parameter change โ€” the setting takes effect for new calls; existing calls use the previous value
โš™๏ธ Parameter Value๐Ÿ“ Behavior๐ŸŽฏ Use Caseโš ๏ธ Consideration
0No media hangup disabled โ€” ghost calls never auto-disconnectedWhen relying entirely on SIP session timer for call cleanupGhost calls will persist indefinitely without session timer
30Disconnect after 30 seconds of no RTP mediaAggressive cleanup for high-capacity systems where every slot countsMay disconnect legitimate calls with long silent periods (hold, mute)
60Disconnect after 60 seconds of no RTP mediaBalanced setting for most wholesale VoIP deploymentsGood balance between cleanup speed and legitimate silence tolerance
90Disconnect after 90 seconds of no RTP mediaConservative setting for environments with frequent short silent periodsGhost calls may persist up to 90 seconds before cleanup
120Disconnect after 120 seconds of no RTP mediaVery conservative; maximum tolerance for silent periodsLong ghost call duration before disconnect; wastes more capacity
180+Extended timeout beyond typical recommendationsSpecial scenarios with very long expected silence (intercom systems, paging)Not recommended for general VoIP; ghost calls linger too long
VOS3000 SS_NOMEDIAHANGUPTIME Configuration:

Navigation: Operation Management > Softswitch Management
            > Additional Settings > System Parameter

Parameter:  SS_NOMEDIAHANGUPTIME
Type:       Integer (seconds)
Default:    0 (disabled)
Recommended: 60 seconds for most wholesale deployments

IMPORTANT:
- Value of 0 disables the feature entirely
- Applies only to new calls after the parameter is saved
- Existing calls continue with the previously active setting
- Media Proxy mode MUST be enabled for this feature to function

Setting the Appropriate Timeout

Choosing the right value for SS_NOMEDIAHANGUPTIME requires balancing two competing concerns. A timeout that is too short risks disconnecting legitimate calls where one or both parties are silent for an extended period โ€” for example, during a hold, mute, or a natural pause in conversation. A timeout that is too long allows ghost calls to waste concurrent call capacity and inflate CDR durations before they are finally cleaned up.

The key insight is that RTP packets are normally sent continuously during a VoIP call, even when the parties are silent. This is because most codecs โ€” including G.711, G.729, and G.723 โ€” generate RTP packets containing silence or comfort noise data. Even when both parties are completely silent, RTP packets continue to flow at the codec’s packetization rate (typically every 20ms or 30ms). The only time RTP stops flowing on a legitimate call is when there is a genuine network or endpoint failure.

However, some codecs and configurations implement silence suppression (also called Voice Activity Detection or VAD), which stops sending RTP packets during silent periods. If your deployment uses VAD-enabled codecs, you must set SS_NOMEDIAHANGUPTIME high enough to accommodate the longest expected silence period. For most deployments without VAD, a 60-second timeout provides an excellent balance between rapid ghost call cleanup and tolerance for legitimate call scenarios.

No Media Hangup vs Session Timer: Critical Differences

VOS3000 provides two separate mechanisms for detecting and cleaning up dead calls: the no media hangup feature and the SIP session timer. Understanding the differences between these two mechanisms is essential for proper configuration and avoiding the common confusion between them.

๐Ÿ“Š Aspect๐Ÿ‘ป No Media Hangupโฑ๏ธ Session Timer
Protocol layerRTP media layerSIP signaling layer
What it monitorsRTP packet reception โ€” whether media is flowingSIP re-INVITE/UPDATE refresh โ€” whether signaling session is alive
Detection methodNo RTP packets received for X secondsSIP session refresh fails (re-INVITE timeout)
Trigger conditionMedia path failure while SIP signaling may still be aliveSIP signaling path failure; both signaling and media are dead
Typical timeout30-120 seconds (configurable via SS_NOMEDIAHANGUPTIME)32 seconds default drop after session refresh failure
ParameterSS_NOMEDIAHANGUPTIMESession-Expires header and Min-SE in SIP messages
Catches ghost calls?Yes โ€” detects calls with dead media but live signalingNo โ€” session timer refresh requires signaling to fail; ghost calls have live signaling
Media Proxy required?Yes โ€” must proxy media to monitor RTPNo โ€” operates purely in SIP signaling layer
Best forDetecting ghost calls where media dies but signaling survivesDetecting total signaling failure where both SIP and RTP are dead

The critical takeaway is that the session timer alone cannot catch ghost calls. When a call becomes a ghost โ€” media is dead but SIP signaling is still alive โ€” the session timer refresh succeeds because the SIP path is functional. Only the no media hangup feature can detect this specific condition because it monitors the RTP stream independently of the SIP signaling state. For complete call cleanup, both mechanisms should be configured together. Learn more about the session timer in our VOS3000 session timer 32-second drop guide.

Media Proxy Mode Interaction with No Media Hangup

The VOS3000 no media hangup feature has a critical dependency on Media Proxy mode. Because the detection mechanism works by monitoring RTP packet reception at the media relay level, the media proxy must be active for each call that you want to monitor. If calls are established in direct media bypass mode โ€” where RTP flows directly between endpoints without passing through the VOS3000 server โ€” the no media hangup feature cannot detect ghost calls because the server never sees the RTP packets.

๐Ÿ”ง Media Mode๐Ÿ‘ป No Media Hangup๐Ÿ“ RTP Visibilityโš ๏ธ Notes
Media Proxy (Relay)โœ… Fully functionalAll RTP packets pass through VOS3000; full monitoring capabilityRecommended mode for ghost call detection
Media Bypass (Direct)โŒ Not functionalRTP flows directly between endpoints; VOS3000 cannot monitor packetsGhost calls will NOT be detected in bypass mode
Mixed Modeโšก Partially functionalOnly proxied calls are monitored; bypassed calls are invisibleInconsistent ghost call detection across your traffic

To ensure complete ghost call detection, configure your VOS3000 system to use Media Proxy mode for all calls. This means setting the appropriate media relay configuration for your gateways and ensuring that calls are not falling through to direct media bypass. The tradeoff is slightly higher server resource consumption, as the media relay must process and forward every RTP packet. However, the benefit of automatic ghost call cleanup far outweighs the marginal increase in CPU and bandwidth usage for most deployments.

For guidance on configuring Media Proxy mode and optimizing server resources, see our VOS3000 RTP media guide and VOS3000 system parameters guide. For hands-on assistance, contact us on WhatsApp at +8801911119966.

Detecting Ghost Calls in CDR: Identifying the Patterns

Even with no media hangup configured, you should regularly audit your CDR records to identify ghost call patterns. Ghost calls leave distinctive signatures in CDR data that can be detected through analysis. Early detection of ghost call patterns helps you identify network issues, endpoint problems, and configuration gaps before they cause significant billing disputes.

๐Ÿ” CDR Pattern๐Ÿ‘ป Indicates๐Ÿ“Š Typical Valuesโœ… Action
Very long duration with zero billed amountGhost call that was eventually cleaned up by no media hangupDuration: 60-300 seconds; Billed: $0.00Verify no media hangup is working; check if timeout is appropriate
Unusually long duration with near-zero billed amountGhost call with minimal media before timeoutDuration: hundreds of seconds; Billed: fractions of a centReduce SS_NOMEDIAHANGUPTIME if too many calls affected
Multiple calls from same endpoint with identical long durationsSystematic endpoint or network issue causing repeated ghost callsDuration: matches SS_NOMEDIAHANGUPTIME value consistentlyInvestigate the specific endpoint; check NAT, firewall, and network path
Calls that end exactly at the no media hangup timeoutNo media hangup is actively cleaning up ghost callsDuration: matches SS_NOMEDIAHANGUPTIME + initial media periodFeature is working correctly; investigate root cause of media loss
Disproportionate ACD (Average Call Duration) for specific routesRoute-level network issues causing ghost callsACD significantly higher than expected for the destinationCheck the vendor/gateway for that route; test media path quality
Spike in concurrent call count without corresponding traffic increaseAccumulating ghost calls during a network eventConcurrent calls near license limit; CDR shows many long-duration callsVerify no media hangup is enabled; check Media Proxy mode is active

Using Current Call Monitor for Real-Time Detection

VOS3000 provides a real-time Current Call monitor that shows all active calls on the system. During a network event, you can use the Current Call monitor to identify ghost calls in real time:

  1. Open Current Call: Navigate to Operation Management > Call Management > Current Call
  2. Sort by duration: Click the duration column to sort calls from longest to shortest
  3. Identify anomalies: Calls with unusually long durations, especially from the same endpoint or gateway, are likely ghost calls
  4. Check media status: If available, observe whether the media relay shows active RTP for each call
  5. Manual disconnect: You can manually disconnect suspected ghost calls from the Current Call interface

Regular monitoring of the Current Call screen helps you identify ghost call patterns early and confirm that your SS_NOMEDIAHANGUPTIME configuration is working effectively.

Different call scenarios have different tolerance levels for silence periods, and the SS_NOMEDIAHANGUPTIME value should be set according to the most sensitive call type in your deployment. The following table provides recommended timeout values based on common VoIP call types and their expected media behavior.

๐Ÿ“ž Call Typeโฑ๏ธ Recommended Timeout๐Ÿ’ก Reasoningโš ๏ธ Risk of Too Short
Wholesale termination30-60 secondsHigh call volume; every slot matters; minimal silence expectedBrief holds during IVR transfer could be disconnected
Retail VoIP60-90 secondsEnd users may mute or hold; need more tolerance for natural silenceUsers on hold may be disconnected unexpectedly
Call center / IVR90-120 secondsIVR menus and queue hold times create extended silence periodsCallers in queue may be dropped while waiting for agent
SIP trunking60 secondsPBX trunk connections; moderate silence tolerance neededPBX hold music should generate RTP; silence may indicate real problem
VAD-enabled endpoints120-180 secondsVoice Activity Detection suppresses RTP during silence; needs longer timeoutNormal silent conversation gaps will trigger disconnect
Emergency services120+ seconds (or disable)Never disconnect emergency calls; silence may be critical situationDisconnecting emergency calls is dangerous and may violate regulations

If your VOS3000 deployment handles multiple call types, set SS_NOMEDIAHANGUPTIME to accommodate the most sensitive call type that requires the longest silence tolerance. Alternatively, consider separating different call types onto different VOS3000 instances or prefixes with different configurations. For guidance on optimizing timeout settings for your specific traffic mix, contact us on WhatsApp at +8801911119966.

Use Case: Preventing Billing Disputes from Ghost Calls

One of the most impactful applications of the VOS3000 no media hangup feature is preventing billing disputes. Consider a scenario common in wholesale VoIP: a carrier routes 10,000 calls per day through a vendor gateway. During a 2-hour network instability event, 200 calls lose their RTP media path but remain connected in SIP signaling. Without no media hangup, these 200 ghost calls persist until the endpoints time out or the session expires โ€” potentially lasting 4-6 hours each.

The CDR records show 200 calls with durations of 4-6 hours each. When the billing system calculates charges based on these CDR durations, the customer is billed for 800-1200 hours of call time that had no actual voice communication. When the customer reviews their invoice and CDR records, they find hundreds of calls with extremely long durations and dispute the entire batch of charges. The dispute resolution process consumes significant staff time, and the carrier often has to issue credits to maintain the business relationship.

With VOS3000 no media hangup configured with SS_NOMEDIAHANGUPTIME set to 60 seconds, each ghost call is detected and terminated within 60 seconds of media loss. The 200 ghost calls generate CDR records showing durations of approximately 60 seconds instead of 4-6 hours. The total billed time is reduced from 800-1200 hours to approximately 3.3 hours, and the customer’s CDR shows reasonable call durations that match actual usage. Billing disputes are minimized, and the carrier’s revenue integrity is maintained.

For a complete understanding of VOS3000 billing and how CDR records are generated, see our VOS3000 billing system guide.

Use Case: Freeing Up Concurrent Call Capacity During Network Issues

Concurrent call capacity is a finite and valuable resource in any VOS3000 deployment. Your VOS3000 license determines the maximum number of simultaneous calls the system can handle, and every ghost call consumes one of these precious slots. During network instability events, ghost calls can accumulate rapidly, potentially exhausting your concurrent call capacity and blocking legitimate traffic.

Consider a VOS3000 system licensed for 2,000 concurrent calls during normal operation. The system typically handles 1,500-1,800 concurrent calls during peak hours, leaving 200-500 slots of headroom. A network event causes media loss on 500 calls, but SIP signaling survives on 400 of them. Without no media hangup, those 400 ghost calls remain connected indefinitely, reducing available capacity to 1,600 slots. When peak hour traffic arrives, the system hits the 2,000-call license limit with 400 ghost calls consuming capacity, and legitimate calls start failing with 503 Service Unavailable.

With VOS3000 no media hangup enabled, those 400 ghost calls are automatically terminated within 60 seconds of media loss. The 400 call slots are immediately freed up and available for legitimate traffic. The system maintains its full capacity for real calls, and the network event passes without any impact on call completion rates. This Smart automatic cleanup ensures that your concurrent call capacity is always available for genuine traffic, not wasted on zombie sessions.

Troubleshooting: Legitimate Calls Being Disconnected

The most common problem encountered with VOS3000 no media hangup is legitimate calls being incorrectly disconnected. This happens when the SS_NOMEDIAHANGUPTIME value is set too low for the actual silence patterns in your call traffic. When legitimate calls are disconnected, users experience unexpected call drops, and the CDR shows the disconnect reason as “no media” rather than a normal call termination.

Symptoms of Incorrect Disconnection

  • Users report unexpected call drops: Callers complain that calls are disconnected during normal conversation, especially during pauses or hold periods
  • CDR shows no media disconnect code: The CDR disconnect reason indicates no media timeout rather than a normal BYE from an endpoint
  • Drops correlate with silence periods: Call drops tend to happen during IVR menus, hold periods, or natural conversation pauses
  • Issue affects specific call types: Only certain routes or endpoints are affected, typically those with VAD enabled or those that generate silence during normal operation

Resolving Incorrect Disconnection

  1. Increase SS_NOMEDIAHANGUPTIME: The most direct solution is to increase the timeout value. If calls are being disconnected at 30 seconds, try 60 seconds. If 60 seconds is too aggressive, try 90 seconds
  2. Check for VAD-enabled endpoints: If any endpoints use Voice Activity Detection, RTP stops during silence. Either disable VAD on those endpoints or increase the timeout to accommodate silence periods
  3. Verify Media Proxy is correctly configured: In rare cases, Media Proxy misconfiguration can cause the server to miss RTP packets that are actually flowing. Verify that the media relay is processing packets correctly using packet capture
  4. Analyze specific affected calls: Use SIP trace and RTP capture to examine the calls being disconnected. Confirm that RTP truly stops before the timeout, or whether the monitoring is incorrectly reporting no media
  5. Consider per-route configuration: If only certain routes or endpoints are affected, consider whether you can isolate those calls and apply different settings

For help diagnosing and resolving no media hangup disconnection issues, see our VOS3000 audio troubleshooting guide or contact us on WhatsApp at +8801911119966.

Configuration and Testing Checklist (VOS3000 no media hangup)

Use this checklist to ensure your VOS3000 no media hangup configuration is complete and working correctly before relying on it in production. Each step should be verified and documented.

โœ… Step๐Ÿ“‹ Action๐Ÿ“ Detailsโš ๏ธ Important
1Verify Media Proxy mode is activeCheck that calls are being proxied, not bypassed, in the media relay configurationNo media hangup does NOT work in bypass mode
2Set SS_NOMEDIAHANGUPTIMENavigate to Softswitch Management > System Parameter and set the timeout value in secondsStart with 60 seconds; adjust based on your call types
3Test with a legitimate callPlace a normal test call and verify it stays connected during normal conversationEnsure the timeout does not affect normal calls
4Test ghost call detectionSimulate a ghost call by establishing a call and then blocking RTP on one endpointCall should disconnect within SS_NOMEDIAHANGUPTIME seconds of RTP loss
5Verify CDR recordsCheck that CDR shows correct disconnect reason for the auto-disconnected callCDR should show no media timeout as the disconnect cause
6Test with hold/mute scenarioPlace a call, put one side on hold, and verify the call stays connectedHold music should generate RTP; if not, timeout may trigger
7Monitor Current Call during peakWatch the Current Call screen during peak hours for ghost call accumulationConcurrent call count should not spike abnormally during network events
8Audit CDR for ghost call patternsAfter 24 hours, review CDR for calls matching ghost call patterns (long duration, zero billing)Ghost call patterns should be eliminated or significantly reduced
9Configure session timer as backupEnsure SIP session timer is also configured for total signaling failure scenariosNo media hangup + session timer = complete call cleanup coverage
10Document configurationRecord SS_NOMEDIAHANGUPTIME value, Media Proxy mode, and session timer settingsEssential for future troubleshooting and configuration audits
VOS3000 No Media Hangup Configuration Summary:

Step 1: Verify Media Proxy mode is active for all call paths
Step 2: Set SS_NOMEDIAHANGUPTIME = 60 (recommended starting value)
Step 3: Save system parameter changes
Step 4: Test with legitimate call โ€” verify no false disconnects
Step 5: Simulate ghost call โ€” verify auto-disconnect works
Step 6: Check CDR records for correct disconnect reason
Step 7: Monitor Current Call during peak hours
Step 8: Audit CDR after 24 hours for ghost call patterns
Step 9: Configure SIP session timer as additional safety net
Step 10: Document all settings for future reference

Both no media hangup AND session timer should be configured
for complete protection against dead calls.

FAQ: VOS3000 No Media Hangup

1. What is no media hangup in VOS3000?

No media hangup is a VOS3000 feature that automatically disconnects calls when the RTP media stream stops flowing. It monitors RTP packet reception for each active call through the media relay. When no RTP packets are received for the duration specified by the SS_NOMEDIAHANGUPTIME parameter, VOS3000 sends a SIP BYE to terminate the call. This Smart mechanism prevents ghost calls โ€” calls that remain connected in SIP signaling but have no active voice media โ€” from wasting concurrent call capacity and corrupting CDR billing records. The feature is documented in VOS3000 Manual Section 4.3.5.2 and requires Media Proxy mode to be active for RTP monitoring.

2. What is the SS_NOMEDIAHANGUPTIME parameter?

SS_NOMEDIAHANGUPTIME is a VOS3000 softswitch system parameter that defines the number of seconds the system waits without receiving any RTP packets before automatically disconnecting a call. The parameter is configured in Operation Management > Softswitch Management > Additional Settings > System Parameter. A value of 0 disables the feature entirely. Common production values range from 30 to 120 seconds, with 60 seconds being the recommended starting point for most wholesale VoIP deployments. The parameter only takes effect for new calls after it is saved; existing calls continue with the previously active value.

3. How do ghost calls affect VoIP billing?

Ghost calls have a direct and damaging impact on VoIP billing accuracy. When a call becomes a ghost โ€” SIP signaling remains connected but RTP media stops โ€” the CDR timer continues to run. The CDR records the full duration from call answer to eventual disconnect, including potentially hours of dead air time. The billing system calculates charges based on these inflated CDR durations, resulting in customers being billed for time when no voice communication was actually happening.

This leads to billing disputes, credit requests, and damaged business relationships. The VOS3000 no media hangup feature addresses this by automatically terminating ghost calls within the configured timeout, keeping CDR durations accurate and proportional to actual media activity. For more on billing accuracy, see our VOS3000 billing system guide.

4. What is the difference between no media hangup and session timer?

No media hangup and the SIP session timer are two distinct call cleanup mechanisms in VOS3000 that operate at different protocol layers and detect different failure conditions. No media hangup operates at the RTP media layer โ€” it monitors whether voice packets are flowing and disconnects calls when media stops. The session timer operates at the SIP signaling layer โ€” it uses periodic SIP re-INVITE or UPDATE messages to verify that the SIP signaling path is alive and disconnects calls when the session refresh fails. The critical difference is that ghost calls typically have live SIP signaling but dead RTP media.

The session timer cannot detect ghost calls because the SIP refresh succeeds, while no media hangup can detect them because it monitors the media stream independently. Both mechanisms should be configured together for complete call cleanup coverage.

5. Why are legitimate calls being disconnected by no media hangup?

Legitimate calls are typically disconnected by the no media hangup feature when the SS_NOMEDIAHANGUPTIME value is set too short for the actual silence patterns in your call traffic. The most common cause is endpoints using Voice Activity Detection (VAD), which stops sending RTP packets during silent periods. If VAD is enabled and a caller pauses for longer than SS_NOMEDIAHANGUPTIME seconds, the system interprets the silence as a dead call and disconnects it.

Other causes include long IVR menu pauses, extended hold times without hold music generating RTP, and network jitter causing temporary RTP gaps. The solution is to increase SS_NOMEDIAHANGUPTIME to a value that accommodates the longest expected legitimate silence period, disable VAD on endpoints, or ensure that hold music and IVR prompts generate continuous RTP output.

6. How do I detect ghost calls in CDR records?

Ghost calls leave distinctive patterns in CDR records that can be identified through analysis. The most obvious indicator is a call with an unusually long duration but a zero or near-zero billed amount โ€” this suggests the call had no actual media flowing. Other patterns include: multiple calls from the same endpoint with identical durations matching the SS_NOMEDIAHANGUPTIME value; calls that end exactly at the no media hangup timeout plus the initial media period; and disproportionate Average Call Duration (ACD) for specific routes compared to expected values. To detect ghost calls systematically, sort your CDR by duration in descending order and review the top results.

Look for calls that are significantly longer than the typical ACD for their destination, especially if they cluster around specific endpoints, gateways, or time periods. For monitoring best practices, see our VOS3000 system parameters guide.

7. Does no media hangup work with media bypass mode in VOS3000?

No, the VOS3000 no media hangup feature does not work when calls are in media bypass (direct) mode. The feature relies on the media relay component to monitor RTP packet reception for each active call. In bypass mode, RTP media flows directly between the two endpoints without passing through the VOS3000 server, so the system has no visibility into whether packets are being exchanged. Without access to the RTP stream, the no media hangup timer cannot detect when media stops flowing.

For this reason, you must configure Media Proxy (relay) mode on your VOS3000 gateways and trunks if you want ghost call detection. In a mixed-mode deployment where some calls use proxy and others use bypass, only the proxied calls benefit from no media hangup protection, while bypassed calls remain vulnerable to ghost call accumulation.

Conclusion – VOS3000 no media hangup

Ghost calls are a persistent threat to VoIP operations, silently consuming concurrent call capacity, inflating CDR durations, and generating billing disputes that erode customer confidence. The VOS3000 no media hangup feature, configured through the SS_NOMEDIAHANGUPTIME system parameter, provides a Smart and effective solution by automatically detecting and terminating calls when RTP media stops flowing.

Key takeaways from this guide:

  • Ghost calls occur when SIP signaling survives but RTP media dies โ€” they are invisible to both parties and persist until explicitly terminated
  • SS_NOMEDIAHANGUPTIME controls the auto-disconnect timeout โ€” set it to 60 seconds for most wholesale deployments; 0 disables the feature
  • Media Proxy mode is required โ€” the feature only works when VOS3000 is proxying RTP media, not in bypass mode
  • No media hangup and session timer serve different purposes โ€” configure both for complete call cleanup coverage
  • Choose your timeout carefully โ€” too short disconnects legitimate calls; too long wastes capacity on ghost calls
  • Monitor CDR patterns regularly โ€” ghost call signatures in CDR data reveal network issues before they cause major problems

By implementing VOS3000 no media hangup with the appropriate timeout for your traffic patterns, you can eliminate ghost calls, protect billing accuracy, and ensure that your concurrent call capacity is always available for genuine voice traffic. For professional VOS3000 configuration and support, visit VOS3000 downloads or contact us on WhatsApp at +8801911119966.


๐Ÿ“ž 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 Authentication Suspend, VOS3000 Registration Flood Protection, VOS3000 No Media Hangup, VOS3000 Max Call Duration Limit, VOS3000 Billing PrecisionVOS3000 Authentication Suspend, VOS3000 Registration Flood Protection, VOS3000 No Media Hangup, VOS3000 Max Call Duration Limit, VOS3000 Billing PrecisionVOS3000 Authentication Suspend, VOS3000 Registration Flood Protection, VOS3000 No Media Hangup, VOS3000 Max Call Duration Limit, VOS3000 Billing Precision