VOS3000 SIP Authentication Retry, VOS3000 SIP Early Hangup, VOS3000 SIP Session Timer Refresh, VOS3000 Non-Timer Endpoint Safety, VOS3000 SIP NAT Keepalive, VOS3000 SIP Resend Interval, VOS3000 SIP INVITE Timeout, VOS3000 SIP Call Progress Timeout, VOS3000 SIP Outbound Registration Parameters, VOS3000 SIP Privacy Header, VOS3000 SIP Routing Gateway Contact, VOS3000 SIP Publish Expire, VOS3000 SIP Display From, VOS3000 SIP Send Unregister

VOS3000 SIP NAT Keep Alive: Complete Configuration Best Practices

VOS3000 SIP NAT Keep Alive: Complete Configuration Best Practices ๐Ÿ“ž๐Ÿ”„๐Ÿ›ก๏ธ

Are your VoIP endpoints losing registration behind NAT firewalls? ๐Ÿ“ฑ๐Ÿ”ฅ One-way audio, dropped calls, and unreachable devices are classic symptoms of NAT binding expiration. The VOS3000 SIP NAT keep alive mechanism solves this by sending periodic UDP heartbeat messages that maintain the NAT pinhole open, ensuring your SIP devices stay reachable at all times. โš™๏ธ๐Ÿ“ก

In this comprehensive guide, we break down every VOS3000 SIP NAT keep alive parameter โ€” from message content and sending period to interval and quantity per cycle โ€” so you can configure heartbeat settings with precision and eliminate NAT-related registration failures. ๐Ÿ”งโœ…

Table of Contents

What Is VOS3000 SIP NAT Keep Alive? ๐ŸŒ๐Ÿ”’

Network Address Translation (NAT) creates temporary port mappings (pinholes) for outbound connections. When a SIP device behind NAT registers with VOS3000, the NAT firewall opens a pinhole for the response. However, if no traffic passes through this pinhole for a period exceeding the NAT’s UDP timeout (often 30โ€“120 seconds on consumer routers), the mapping is destroyed. โŒ๐Ÿ“ก

When the pinhole closes:

  • ๐Ÿ“ž VOS3000 cannot reach the device for inbound calls
  • ๐Ÿ”‡ One-way audio or no audio at all
  • ๐Ÿ“‹ Registration appears active but the device is unreachable
  • ๐Ÿ”„ Call failures and frustrated users

The VOS3000 SIP NAT keep alive feature addresses this by having the server proactively send UDP heartbeat messages to registered NAT devices at regular intervals, keeping the NAT mapping alive. ๐Ÿ’ก๐Ÿ›ก๏ธ This is especially critical when devices do not support SIP REGISTER retransmission for keeping their NAT bindings open.

As documented in the VOS3000 2.1.9.07 manual, when a device does not support REGISTER keeping, VOS3000 can send UDP messages to keep the NAT channel active. ๐Ÿ”‘๐Ÿ–ฅ๏ธ

VOS3000 SIP NAT Keep Alive Parameters Overview ๐Ÿ“Šโš™๏ธ

There are four core SIP parameters that control the NAT keep alive behavior in VOS3000. All of these are configured under Navigation > Operation management > Softswitch management > Additional settings > SIP parameter. ๐Ÿ–ฅ๏ธ๐Ÿ”ง

Parameter ๐Ÿ“‹Default ValueDescription ๐Ÿ“
SS_SIP_NAT_KEEP_ALIVE_MESSAGEHELLOContent of NAT Keep Message
SS_SIP_NAT_KEEP_ALIVE_PERIOD30NAT Keep Message’s Period (seconds)
SS_SIP_NAT_KEEP_ALIVE_SEND_INTERVAL500NAT Keep Message’s Send Interval (milliseconds)
SS_SIP_NAT_KEEP_ALIVE_SEND_ONE_TIME3000NAT Keep Message’s Quantity per Time

SS_SIP_NAT_KEEP_ALIVE_MESSAGE โ€” Heartbeat Content ๐Ÿ”๐Ÿ’ฌ

The SS_SIP_NAT_KEEP_ALIVE_MESSAGE parameter defines the content of the UDP heartbeat message that VOS3000 sends to NAT devices. By default, this is set to HELLO. ๐Ÿ“ก๐Ÿ”‘

How SS_SIP_NAT_KEEP_ALIVE_MESSAGE Works โš™๏ธ

According to the official VOS3000 manual:

  • โœ… If set (e.g., “HELLO”): VOS3000 sends heartbeat messages with the configured content to each registered NAT device
  • โŒ If not set (empty): The server will not send any heartbeat messages, and NAT bindings may expire

This is the master switch for the entire NAT keep alive feature. Without a value configured, none of the other three parameters have any effect. ๐Ÿ”‘โš ๏ธ

Setting ๐Ÿ“‹Behavior ๐Ÿ”„Use Case ๐ŸŽฏ
Empty (not set)No heartbeat sent ๐ŸšซDevices use REGISTER for keep-alive
HELLO (default)Sends “HELLO” as UDP payload โœ…Standard NAT traversal for most endpoints
Custom stringSends custom content ๐Ÿ’กVendor-specific device requirements

โš ๏ธ Important: The heartbeat message content is sent as a raw UDP payload โ€” it is NOT a SIP message. Some devices may expect a specific string format. Always verify compatibility with your endpoint vendor. ๐Ÿ“๐Ÿ”ง

SS_SIP_NAT_KEEP_ALIVE_PERIOD โ€” Heartbeat Cycle โฑ๏ธ๐Ÿ”„

The SS_SIP_NAT_KEEP_ALIVE_PERIOD parameter controls how often VOS3000 completes a full cycle of sending heartbeat messages to all registered NAT devices. The default is 30 seconds, with a valid range of 10โ€“86400 seconds. ๐Ÿ“Š๐Ÿ•

Understanding the Period Cycle ๐Ÿ”„

Within each period, VOS3000 iterates through all registered NAT devices and sends heartbeat messages. The system uses the SS_SIP_NAT_KEEP_ALIVE_SEND_INTERVAL and SS_SIP_NAT_KEEP_ALIVE_SEND_ONE_TIME parameters to control pacing within the cycle. ๐ŸŽฏโš™๏ธ

Critical manual note: When UDP heartbeat messages of all NAT devices cannot be sent within this cycle, the system will resend from the beginning when the cycle arrives โ€” which may cause some devices to miss heartbeat messages. โš ๏ธ๐Ÿ“ž

Period Value โฑ๏ธNAT Timeout Coverage ๐Ÿ”’Server Load ๐Ÿ’ปBest For ๐ŸŽฏ
10 secondsAggressive ๐Ÿ›ก๏ธHigh โฌ†๏ธStrict NAT firewalls (30s UDP timeout)
30 seconds (default)Standard โœ…Moderate โžก๏ธMost deployments, balanced approach
60 secondsRelaxed ๐Ÿ”“Low โฌ‡๏ธLenient NAT, fewer endpoints
300 secondsMinimal ๐Ÿ“‰Very Low โฌ‡๏ธโฌ‡๏ธEnterprise NAT with long timeouts
86400 seconds (max)None โŒNegligibleEffectively disables keep alive (not recommended)

Period Sizing Formula ๐Ÿ“๐Ÿ’ก

To ensure every device receives a heartbeat within each period, use this calculation:

Required Period (seconds) โ‰ฅ (Total NAT Devices ร— SS_SIP_NAT_KEEP_ALIVE_SEND_ONE_TIME) ร— (SS_SIP_NAT_KEEP_ALIVE_SEND_INTERVAL / 1000)

Example with 1000 NAT devices:
= 1000 ร— 3000 ร— (500 / 1000)
= 1,500,000 seconds โ†’ NOT feasible in one cycle!

This means with large deployments, not all devices can be serviced in a single 30-second period.
The system restarts from the beginning when the period elapses,
so some devices at the end of the list may miss heartbeats.
โš ๏ธ Scale your parameters accordingly!

SS_SIP_NAT_KEEP_ALIVE_SEND_INTERVAL โ€” Message Pacing ๐Ÿ•๐Ÿ“ก

The SS_SIP_NAT_KEEP_ALIVE_SEND_INTERVAL parameter sets the delay between consecutive heartbeat messages during the sending cycle. The default is 500 milliseconds. โš™๏ธ๐Ÿ”„

Why Send Interval Matters ๐Ÿ”‘

VOS3000 must send heartbeats to potentially thousands of NAT devices. Sending them all simultaneously would flood the network and consume excessive CPU. The send interval spaces out transmissions to prevent burst congestion. ๐Ÿ“Š๐Ÿ’ก

Interval (ms) โฑ๏ธMessages/Second ๐Ÿ“คNetwork Impact ๐ŸŒUse Case ๐ŸŽฏ
100 ms10 msg/secHigher burst ๐Ÿ“ˆLow device count, fast network
500 ms (default)2 msg/secBalanced โœ…Standard deployments
1000 ms1 msg/secGentle ๐Ÿ“‰High device count, constrained bandwidth

SS_SIP_NAT_KEEP_ALIVE_SEND_ONE_TIME โ€” Quantity Per Device ๐Ÿ”ข๐Ÿ“ก

The SS_SIP_NAT_KEEP_ALIVE_SEND_ONE_TIME parameter determines how many heartbeat messages VOS3000 sends to each NAT device per cycle. The default is 3000. ๐Ÿ”„โš™๏ธ

Understanding Quantity Per Time ๐ŸŽฏ

This parameter works in conjunction with the send interval to control the pacing of messages within a single period cycle. With a default of 3000 messages per device, VOS3000 sends multiple heartbeats to each device within the period to ensure reliability. ๐Ÿ“กโœ…

Parameter ๐Ÿ”งDefaultUnitEffect on Performance ๐Ÿ’ป
SS_SIP_NAT_KEEP_ALIVE_SEND_ONE_TIME3000MessagesHigher = more redundancy but more bandwidth ๐Ÿ”ผ
SS_SIP_NAT_KEEP_ALIVE_SEND_INTERVAL500MillisecondsHigher = slower sending rate ๐Ÿ”ฝ
SS_SIP_NAT_KEEP_ALIVE_PERIOD30SecondsShorter = more frequent cycles ๐Ÿ”

The NAT keep alive feature does not operate in isolation. Several related system parameters work together to ensure seamless NAT traversal. Understanding these relationships is essential for a well-tuned VOS3000 SIP NAT keep alive deployment. ๐Ÿ”ง๐Ÿ“‹

Parameter ๐Ÿ“‹DefaultPurpose ๐ŸŽฏRelationship to Keep Alive ๐Ÿ”„
SS_ENDPOINT_EXPIRE300 / 3600Terminal registration expiry timeKeep alive period should be shorter than expiry ๐Ÿ”‘
SS_ENDPOINT_NAT_EXPIRE300NAT terminal registration expiry timeCritical: Keep alive must beat this timer ๐Ÿšจ
SS_MEDIA_PROXY_BEHIND_NATOnForward RTP for NAT terminalsComplements keep alive for audio path ๐Ÿ“ž

The SS_ENDPOINT_NAT_EXPIRE parameter (default 300 seconds) is particularly important. Your VOS3000 SIP NAT keep alive period (default 30 seconds) must always be shorter than the NAT expiry time, ensuring the NAT binding is refreshed well before the registration times out. โฑ๏ธโœ… If the keep alive period exceeds the NAT expiry, devices will be deregistered before the next heartbeat arrives. โŒ๐Ÿ”ฅ

For more details on registration handling, see our guide on VOS3000 SIP Registration. ๐Ÿ“‹๐Ÿ“ž

VOS3000 SIP NAT Keep Alive Configuration Walkthrough ๐Ÿ–ฅ๏ธ๐Ÿ”ง

Configuring NAT keep alive in VOS3000 is straightforward. Follow these steps to access and set the parameters: ๐Ÿ“โœ…

Step-by-Step Configuration ๐Ÿ“‹

  1. ๐Ÿ–ฅ๏ธ Open the VOS3000 Client application
  2. ๐Ÿ“‚ Navigate to Operation management > Softswitch management
  3. โš™๏ธ Click on Additional settings
  4. ๐Ÿ“‹ Select the SIP parameter tab
  5. ๐Ÿ” Find and configure the following parameters:
# NAT Keep Alive Configuration in VOS3000 Client
# Location: Operation management > Softswitch management > Additional settings > SIP parameter

SS_SIP_NAT_KEEP_ALIVE_MESSAGE = HELLO
SS_SIP_NAT_KEEP_ALIVE_PERIOD = 30
SS_SIP_NAT_KEEP_ALIVE_SEND_INTERVAL = 500
SS_SIP_NAT_KEEP_ALIVE_SEND_ONE_TIME = 3000

# Related parameters to verify:
SS_ENDPOINT_NAT_EXPIRE = 300
SS_MEDIA_PROXY_BEHIND_NAT = On

โœ… Best Practice: After modifying any SIP parameter, apply the changes and monitor the system for at least 15 minutes. Use the SIP debug guide to verify heartbeat messages are being sent and received correctly. ๐Ÿ”ง๐Ÿ“ก

Different deployment scenarios call for different parameter tuning. Here are recommended configurations based on common use cases: ๐Ÿ’ก๐Ÿ”ง

Scenario ๐Ÿ MESSAGE ๐Ÿ’ฌPERIOD โฑ๏ธINTERVAL (ms)QUANTITY ๐Ÿ”ข
Small office (<50 devices)HELLO205003000
Medium deployment (50โ€“500)HELLO305003000
Large deployment (500+)HELLO305001500
Strict NAT / Carrier-gradeHELLO152003000
Constrained bandwidthHELLO3010001000

NAT Keep Alive Message Flow Diagram ๐Ÿ”„๐Ÿ“ก

The following text diagram illustrates how the VOS3000 SIP NAT keep alive mechanism operates within a single period cycle: ๐Ÿ“Š๐Ÿ”‘

โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
โ”‚                  VOS3000 NAT Keep Alive Flow                       โ”‚
โ”œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ค
โ”‚                                                                     โ”‚
โ”‚  Period Cycle (30 seconds default)                                  โ”‚
โ”‚  โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•                                  โ”‚
โ”‚                                                                     โ”‚
โ”‚  โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”    REGISTER     โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”                     โ”‚
โ”‚  โ”‚  SIP Phoneโ”‚ โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ–บโ”‚   VOS3000    โ”‚                     โ”‚
โ”‚  โ”‚ (Behind   โ”‚                โ”‚   Softswitch  โ”‚                     โ”‚
โ”‚  โ”‚  NAT)    โ”‚โ—„โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€ โ”‚              โ”‚                     โ”‚
โ”‚  โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜    200 OK       โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜                     โ”‚
โ”‚       โ”‚                              โ”‚                              โ”‚
โ”‚       โ”‚     NAT Firewall             โ”‚                              โ”‚
โ”‚       โ”‚   โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”            โ”‚                              โ”‚
โ”‚       โ”‚   โ”‚  Pinhole    โ”‚            โ”‚                              โ”‚
โ”‚       โ”‚   โ”‚  Created โœ… โ”‚            โ”‚                              โ”‚
โ”‚       โ”‚   โ””โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”˜            โ”‚                              โ”‚
โ”‚       โ”‚         โ”‚                    โ”‚                              โ”‚
โ”‚       โ”‚  โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ–ผโ”€โ”€โ”€โ”€โ”€โ”€โ”            โ”‚                              โ”‚
โ”‚       โ”‚  โ”‚ UDP Timeout  โ”‚            โ”‚                              โ”‚
โ”‚       โ”‚  โ”‚ Approaching  โ”‚โ—„โ”€โ”€โ”€ โ”€โ”€โ”€โ”€โ”€โ”€โ”‚  HELLO (heartbeat)           โ”‚
โ”‚       โ”‚  โ”‚ โฑ๏ธ 30s       โ”‚            โ”‚  at SS_SIP_NAT_KEEP_ALIVE_   โ”‚
โ”‚       โ”‚  โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”˜            โ”‚  PERIOD intervals             โ”‚
โ”‚       โ”‚         โ”‚                    โ”‚                              โ”‚
โ”‚       โ”‚  โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ–ผโ”€โ”€โ”€โ”€โ”€โ”€โ”            โ”‚                              โ”‚
โ”‚       โ”‚  โ”‚ Pinhole      โ”‚โ—„โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€ โ”‚  HELLO โ†’ Pinhole Refreshed โœ… โ”‚
โ”‚       โ”‚  โ”‚ Refreshed โœ… โ”‚            โ”‚                              โ”‚
โ”‚       โ”‚  โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜            โ”‚                              โ”‚
โ”‚       โ”‚                              โ”‚                              โ”‚
โ”‚       โ”‚  If NO keep alive:           โ”‚                              โ”‚
โ”‚       โ”‚  โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”            โ”‚                              โ”‚
โ”‚       โ”‚  โ”‚ Pinhole       โ”‚            โ”‚                              โ”‚
โ”‚       โ”‚  โ”‚ EXPIRED โŒ    โ”‚            โ”‚                              โ”‚
โ”‚       โ”‚  โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜            โ”‚                              โ”‚
โ”‚       โ”‚         โ”‚                    โ”‚                              โ”‚
โ”‚       โ”‚    โ”Œโ”€โ”€โ”€โ”€โ–ผโ”€โ”€โ”€โ”€โ”               โ”‚                              โ”‚
โ”‚       โ”‚    โ”‚ INBOUND  โ”‚โ”€โ”€โ”€โ”€ X โ”€โ”€โ”€โ”€โ”€โ”€โ–บโ”‚  Call FAILS - Unreachable! โŒโ”‚
โ”‚       โ”‚    โ”‚ CALL     โ”‚               โ”‚                              โ”‚
โ”‚       โ”‚    โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜               โ”‚                              โ”‚
โ”‚                                                                     โ”‚
โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜

Troubleshooting VOS3000 SIP NAT Keep Alive Issues ๐Ÿ”งโš ๏ธ

Even with proper configuration, NAT keep alive issues can arise. Here are common problems and their solutions: ๐Ÿ”๐Ÿ“ž

Common Problems and Solutions ๐Ÿ› ๏ธ

Problem โŒLikely Cause ๐Ÿ”Solution โœ…
Devices unregister randomlyKeep alive period too long for NAT timeoutReduce SS_SIP_NAT_KEEP_ALIVE_PERIOD to 15โ€“20 seconds ๐Ÿ”ฝ
One-way audio on callsNAT pinhole expired for media, SS_MEDIA_PROXY_BEHIND_NAT offEnable media proxy; verify keep alive is active ๐Ÿ“ž
High CPU on VOS3000 serverSEND_ONE_TIME too high with many devicesReduce SEND_ONE_TIME or increase SEND_INTERVAL ๐Ÿ“‰
Some devices never receive heartbeatsPeriod cycle too short for all devicesIncrease PERIOD or reduce SEND_ONE_TIME per device โฑ๏ธ
No heartbeats sent at allSS_SIP_NAT_KEEP_ALIVE_MESSAGE is emptySet MESSAGE to “HELLO” or a custom string โœ…

For deeper troubleshooting of SIP-related issues, refer to our comprehensive VOS3000 troubleshooting guide. ๐Ÿ”ง๐Ÿ“‹ Also check our guide on SIP ALG problems and VoIP NAT troubleshooting for firewall-related issues. ๐Ÿ”ฅ๐Ÿ›ก๏ธ

VOS3000 SIP NAT Keep Alive vs Device REGISTER ๐Ÿ”„๐Ÿ“ž

Understanding the relationship between NAT keep alive and SIP REGISTER is critical. The VOS3000 manual clearly explains when each mechanism is appropriate: ๐Ÿ“‹๐Ÿ’ก

In normal device registration, the registration is maintained by the device’s own REGISTER refresh messages. These REGISTER messages also keep the NAT pinhole open naturally. However, when a device does not support REGISTER keeping, VOS3000 must step in with server-side UDP heartbeat messages. ๐Ÿ”‘๐Ÿ–ฅ๏ธ

Aspect ๐Ÿ“‹Device REGISTER ๐Ÿ“ฑServer NAT Keep Alive ๐Ÿ–ฅ๏ธ
Initiated byEndpoint device ๐Ÿ”ตVOS3000 server ๐ŸŸข
Message typeSIP REGISTERUDP payload (e.g., “HELLO”)
NAT pinhole refreshYes โœ… (outbound from device)Yes โœ… (inbound from server to NAT pinhole)
Registration refreshYes โœ…No โŒ (only keeps NAT pinhole)
When to useDevices with REGISTER supportDevices without REGISTER keep-alive

Learn more about SIP authentication mechanisms in our VOS3000 SIP authentication guide. ๐Ÿ”๐Ÿ“ž

Best Practices for VOS3000 SIP NAT Keep Alive ๐Ÿ†โœ…

Follow these proven best practices to get the most from your VOS3000 SIP NAT keep alive configuration: ๐Ÿ’ก๐Ÿ”ง

  1. ๐Ÿ”‘ Always set MESSAGE โ€” An empty MESSAGE field disables the entire feature. Use “HELLO” unless your device requires a specific string
  2. โฑ๏ธ Keep PERIOD shorter than NAT timeout โ€” Most consumer NAT firewalls have a 30โ€“60 second UDP timeout. Set your period to 15โ€“30 seconds
  3. ๐Ÿ“ Size for your deployment โ€” With many devices, reduce SEND_ONE_TIME or increase SEND_INTERVAL to prevent CPU overload
  4. ๐Ÿ›ก๏ธ Enable media proxy โ€” Keep SS_MEDIA_PROXY_BEHIND_NAT = On to ensure RTP media streams traverse NAT correctly
  5. ๐Ÿ“Š Monitor endpoint expiry โ€” Ensure SS_SIP_NAT_KEEP_ALIVE_PERIOD is well under SS_ENDPOINT_NAT_EXPIRE (default 300 seconds)
  6. ๐Ÿ“‹ Test with SIP debug โ€” Use the SIP debug tools to verify heartbeat delivery
  7. ๐Ÿ”’ Check firewall rules โ€” Ensure VOS3000 firewall permits outbound UDP heartbeats to registered device IPs

Need help configuring VOS3000 for your specific NAT scenario? Contact us on WhatsApp at +8801911119966 ๐Ÿ“ฑ๐Ÿ’ฌ โ€” our team can help you optimize your VOS3000 SIP NAT keep alive settings for any deployment size. ๐Ÿ›ก๏ธ๐Ÿ“ž

FAQ: VOS3000 SIP NAT Keep Alive โ“๐Ÿ“ž

What happens if I leave SS_SIP_NAT_KEEP_ALIVE_MESSAGE empty? ๐Ÿ“‹

If the SS_SIP_NAT_KEEP_ALIVE_MESSAGE parameter is not set (empty), VOS3000 will not send any heartbeat messages to NAT devices. This means NAT pinholes may expire, causing devices to become unreachable for inbound calls. โŒ๐Ÿ”ฅ Always set this to “HELLO” or a custom string to enable the feature. โœ…

What is the best SS_SIP_NAT_KEEP_ALIVE_PERIOD value for strict NAT? โฑ๏ธ

For strict NAT firewalls with short UDP timeouts (30 seconds or less), set SS_SIP_NAT_KEEP_ALIVE_PERIOD to 15 seconds. This ensures the heartbeat arrives well before the NAT pinhole expires. ๐Ÿ›ก๏ธ๐Ÿ”‘ For standard deployments, the default 30 seconds works well. โœ…

Can VOS3000 NAT keep alive replace SIP REGISTER? ๐Ÿ”„

No. The NAT keep alive mechanism only keeps the NAT pinhole (UDP port mapping) open. It does not refresh the SIP registration itself. Devices that support REGISTER should continue using it for registration renewal. NAT keep alive is specifically for devices that do not support REGISTER-based keep-alive. ๐Ÿ“ž๐Ÿ“‹

How do I know if my VOS3000 SIP NAT keep alive is working? ๐Ÿ”

Use the VOS3000 SIP debug tools or Wireshark to capture UDP traffic from the VOS3000 server to your registered NAT devices. You should see “HELLO” (or your configured message) being sent at the configured period interval. ๐Ÿ“ก๐Ÿ“Š Also check that devices remain registered without unexpected deregistration events. โœ…

Why are some devices missing heartbeat messages? โš ๏ธ

When there are too many NAT devices for VOS3000 to service within a single period cycle, some devices at the end of the iteration may not receive a heartbeat. The system restarts from the beginning when the cycle arrives. To fix this, increase SS_SIP_NAT_KEEP_ALIVE_PERIOD or reduce SS_SIP_NAT_KEEP_ALIVE_SEND_ONE_TIME. ๐Ÿ”ง๐Ÿ“ˆ

Should I change SS_SIP_NAT_KEEP_ALIVE_SEND_INTERVAL from the default? ๐Ÿ•

In most deployments, the default 500 ms interval is well-balanced. Increase to 1000 ms if you have bandwidth constraints or a very large number of devices. Decrease to 200 ms only for small deployments with strict timing requirements. โš™๏ธ๐Ÿ’ก Always monitor server CPU after making changes. ๐Ÿ“Š

What is the relationship between SS_ENDPOINT_NAT_EXPIRE and keep alive period? ๐Ÿ”—

SS_ENDPOINT_NAT_EXPIRE (default 300 seconds) defines how long a NAT device’s registration remains valid. The keep alive period (default 30 seconds) must always be significantly shorter than this value. A good rule of thumb: keep alive period should be at most 1/5 of the NAT expire time. โฑ๏ธโœ… If keep alive period exceeds NAT expire, devices will be deregistered before the next heartbeat cycle. โŒ๐Ÿ”ฅ

Need expert assistance with your VOS3000 deployment? ๐Ÿ“ž๐Ÿ’ฌ Reach out on WhatsApp at +8801911119966 โ€” we provide professional VOS3000 configuration, NAT troubleshooting, and VoIP optimization services worldwide. ๐ŸŒ๐Ÿ›ก๏ธโš™๏ธ


๐Ÿ“ž 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 SIP Authentication Retry, VOS3000 SIP Early Hangup, VOS3000 SIP Session Timer Refresh, VOS3000 Non-Timer Endpoint Safety, VOS3000 SIP NAT KeepaliveVOS3000 SIP Authentication Retry, VOS3000 SIP Early Hangup, VOS3000 SIP Session Timer Refresh, VOS3000 Non-Timer Endpoint Safety, VOS3000 SIP NAT KeepaliveVOS3000 SIP Authentication Retry, VOS3000 SIP Early Hangup, VOS3000 SIP Session Timer Refresh, VOS3000 Non-Timer Endpoint Safety, VOS3000 SIP NAT Keepalive
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
VOS3000 SIP Debug with Wireshark, VOS3000 Outbound SIP Registration, VOS3000 Scaling High Traffic, VOS3000 Protect Route, VOS3000 Caller Number Pool

VOS3000 SIP Debug: Best Essential Wireshark and Log Analysis Guide

VOS3000 SIP Debug: Essential Wireshark and Log Analysis Guide

Diagnosing VoIP call failures without a proper VOS3000 SIP debug workflow is like searching for a needle in a haystack while blindfolded. Most VOS3000 operators rely on guesswork when calls fail, randomly changing gateway settings, firewall rules, and system parameters until something works. This approach wastes hours, creates instability, and often introduces new problems while attempting to fix the original one. The professional method involves systematically capturing and analyzing SIP signaling traffic using Wireshark alongside VOS3000 native debug trace tools, then correlating the results with CDR termination reasons to pinpoint the exact root cause of any call failure.

This guide teaches you the complete VOS3000 SIP debug methodology: from enabling VOS3000’s built-in Debug Trace function, to capturing traffic with tcpdump on CentOS 7, to analyzing SIP call flows in Wireshark, and finally correlating everything with CDR records. Every technique described here is based on real VOS3000 features documented in the official VOS3000 V2.1.9.07 Manual. For professional assistance with VOS3000 troubleshooting, contact us on WhatsApp at +8801911119966.

VOS3000 SIP Debug: Built-in Debug Trace Tool

Before reaching for Wireshark, you should understand VOS3000’s native Debug Trace functionality, which provides SIP message logging directly from the softswitch without any external tools. This feature is documented in VOS3000 Manual Section 2.5.3 and provides real-time visibility into SIP signaling exchanged between VOS3000 and all connected gateways.

Enabling VOS3000 SIP Debug Trace

To activate the debug trace in VOS3000, navigate to Operation Management > Debug Trace in the VOS3000 client. The Debug Trace interface allows you to capture two types of traces:

  • SIP Trace: Captures all SIP signaling messages including INVITE, 200 OK, ACK, BYE, CANCEL, REGISTER, and OPTIONS messages with full headers and timestamps
  • Registration Trace: Captures specifically the SIP REGISTER messages exchanged between mapping gateways and VOS3000, useful for diagnosing registration failures and authentication problems

When you enable SIP Trace, VOS3000 displays every SIP message in real time with precise timestamps, the source and destination IP addresses, and the complete message headers including Via, From, To, Call-ID, Contact, and SDP content. This immediate visibility into signaling flow makes it possible to identify configuration problems such as incorrect Contact headers, mismatched IP addresses in SDP, or missing authentication credentials without needing any packet capture tools.

Reading VOS3000 Debug Trace Output

The debug trace output shows SIP messages in chronological order with millisecond timestamps. Each message is displayed with its direction (sent or received), the remote IP address, and the complete SIP message content. When analyzing the trace, pay close attention to the following elements that commonly reveal the root cause of call failures:

๐Ÿ“‹ Trace Element๐Ÿ” What to Look Forโš ๏ธ Common Problem
Via headerCorrect IP and port in received/rportNAT mangling changes real IP
Contact headerReachable IP and portPrivate IP in Contact (NAT issue)
SDP c= lineCorrect media IP addressWrong IP causes one-way audio
SDP m= lineCodec and port match expectationsCodec mismatch or blocked port
Session-ExpiresTimer values and refresher32-second drop from timer mismatch
Response timeDelay between INVITE and 100/180Slow response indicates network issue

Capturing VOS3000 Traffic with tcpdump on CentOS 7

While VOS3000 Debug Trace shows signaling content, it does not capture RTP media streams or provide the advanced filtering and analysis capabilities of Wireshark. For comprehensive VOS3000 SIP debug, you need to capture raw network packets using tcpdump on your CentOS 7 server, then analyze them in Wireshark on your workstation. This combined approach gives you complete visibility into both signaling and media paths.

Essential tcpdump Commands for VOS3000

The following tcpdump commands capture different aspects of VOS3000 traffic. Run these commands via SSH on your VOS3000 server:

# Capture SIP signaling only (port 5060 UDP and TCP)
tcpdump -i eth0 -w /tmp/sip-capture.pcap port 5060

# Capture SIP + RTP for a specific gateway IP
tcpdump -i eth0 -w /tmp/gateway-debug.pcap host 192.168.1.100

# Capture all traffic on SIP port with full packet size
tcpdump -i eth0 -s 0 -w /tmp/full-sip-capture.pcap udp port 5060 or tcp port 5060

# Capture SIP signaling for a specific phone number (filter in Wireshark later)
tcpdump -i eth0 -s 0 -w /tmp/number-debug.pcap port 5060

# Capture RTP media streams (port range 10000-20000)
tcpdump -i eth0 -w /tmp/rtp-capture.pcap udp portrange 10000-20000

# Combined SIP and RTP capture for complete analysis
tcpdump -i eth0 -s 0 -w /tmp/complete-debug.pcap \
  port 5060 or udp portrange 10000-20000

# Limit capture duration to 60 seconds
timeout 60 tcpdump -i eth0 -s 0 -w /tmp/timed-capture.pcap port 5060

After capturing, transfer the .pcap file to your workstation using SCP or SFTP, then open it in Wireshark for analysis. For detailed network configuration, refer to our CentOS 7 kernel tuning guide.

๐ŸŽฏ Debug Scenario๐Ÿ’ป tcpdump Command๐Ÿ“ Captures
SIP signaling onlytcpdump -i eth0 -w file.pcap port 5060INVITE, 200 OK, BYE, REGISTER
Single gatewaytcpdump -i eth0 -w file.pcap host GW_IPAll traffic to/from gateway
RTP media onlytcpdump -i eth0 -w file.pcap udp portrange 10000-20000Audio media packets
Complete analysistcpdump -i eth0 -s 0 -w file.pcap port 5060 or udp portrange 10000-20000Signaling + media

VOS3000 SIP Debug with Wireshark Filters

Wireshark provides powerful display filters that allow you to isolate specific SIP messages, response codes, and call flows from a packet capture. Mastering these filters is essential for efficient VOS3000 SIP debug analysis. The following filters are the most useful for diagnosing VOS3000 call failures.

Essential Wireshark SIP Filters

Open your captured .pcap file in Wireshark and apply these display filters to isolate specific traffic:

# Show only SIP protocol messages
sip

# Show SIP and RTP together
sip || rtp

# Show only SIP INVITE messages
sip.Method == "INVITE"

# Show specific SIP response codes
sip.Status-Code == 503
sip.Status-Code == 408
sip.Status-Code == 403
sip.Status-Code == 480

# Show all SIP error responses (4xx, 5xx, 6xx)
sip.Status-Code >= 400

# Show BYE and CANCEL messages (call termination)
sip.Method == "BYE" || sip.Method == "CANCEL"

# Show REGISTER messages
sip.Method == "REGISTER"

# Filter by specific Call-ID (replace with actual Call-ID)
sip.Call-ID contains "abc123"

# Filter by specific phone number in SIP URI
sip.to contains "8801911119966"

# Show Session Timer related messages
sip.Session-Expires exists

Analyzing SIP Call Flow in Wireshark

A normal VOS3000 SIP call flow follows this sequence: INVITE, 100 Trying, 180 Ringing (or 183 Session Progress), 200 OK, ACK, and eventually BYE and 200 OK. When you analyze a VOS3000 SIP debug capture, the first step is to verify that this complete message flow occurs. Any deviation from this sequence indicates a specific problem.

๐Ÿ“ก SIP Messageโœ… Expectedโš ๏ธ If Missing/Abnormal
INVITESent by VOS3000 to gatewayNot sent = routing problem
100 TryingReceived from gatewayNot received = firewall or offline
180 RingingDestination is alertingSkipped = fast answer or error
200 OKCall answered with SDPError code instead = check code
ACKConfirms call establishedMissing = call not confirmed
BYENormal call terminationUnexpected BYE = check reason

Use Wireshark’s built-in Telephony > VoIP Calls feature to visualize the complete SIP call flow as a diagram. This shows all messages in sequence with timing, making it easy to spot anomalies. For detailed SIP call flow reference, see our VOS3000 SIP call flow guide.

VOS3000 SIP Debug: Diagnosing One-Way Audio

One-way audio is one of the most frustrating VoIP problems because the call connects successfully but only one party can hear the other. The root cause is almost always an incorrect IP address in the SDP (Session Description Protocol) content of the SIP messages, which tells the remote endpoint where to send RTP media packets. When VOS3000 or the gateway advertises a private or incorrect IP in the SDP c= line, media packets are sent to an unreachable address.

SDP Analysis for One-Way Audio

To diagnose one-way audio using VOS3000 SIP debug, capture the SIP signaling during a call and examine the SDP content in both the INVITE and the 200 OK messages. Look specifically at the c= (connection) line and the m= (media) line in the SDP:

# SDP in INVITE from VOS3000 to gateway:
v=0
o=- 123456 1 IN IP4 10.0.0.5      โ† Check: Is this the real server IP?
s=-
c=IN IP4 10.0.0.5                   โ† CRITICAL: RTP goes here
t=0 0
m=audio 12345 RTP/AVP 0 8 18       โ† RTP port and codec list
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000

# If c= shows 10.0.0.5 but real IP is 203.0.113.50,
# RTP media will be sent to 10.0.0.5 (unreachable) = ONE-WAY AUDIO

When the SDP c= line contains a private IP address (10.x.x.x, 172.16-31.x.x, 192.168.x.x) but the VOS3000 server has a public IP, the remote gateway sends RTP to the private IP, which is unreachable from the internet. This results in the gateway hearing audio from VOS3000 (because VOS3000 can reach the gateway’s correct IP), but VOS3000 never receives the return RTP stream. The fix involves configuring the correct Local IP setting in VOS3000 gateway configuration, enabling media proxy mode, or adjusting NAT-related settings in the gateway’s Additional Settings. For more audio troubleshooting, see our VOS3000 echo delay and audio fix guide.

VOS3000 SIP Debug: Diagnosing 32-Second Call Drops

The 32-second call drop is a notorious issue in VOS3000 deployments where calls disconnect exactly 32 seconds after connecting. This problem is caused by Session Timer negotiation failure. When one side proposes a Session-Expires value that the other side does not support or refuses, the session timer expires after the minimum period, causing the call to drop. This is documented in VOS3000 Manual Section 4.3.5.2 with the SS_SESSION_TIMER parameters.

Analyzing Session Timer in Wireshark

To diagnose this issue, filter your Wireshark capture for Session-Expires headers and examine the negotiation between VOS3000 and the gateway:

โš™๏ธ Parameter๐Ÿ“‹ Default๐Ÿ“ Purpose๐Ÿ› ๏ธ Fix
SS_SESSION_TIMER1800 (30 min)Session timer durationSet to 0 to disable
SS_SESSION_TIMER_MIN_SE90Minimum session expiresLower to 32 or disable timer
SS_SESSION_TIMER_REFRESHER0 (UAC)Who sends refreshMatch with gateway setting

In Wireshark, search for “Session-Expires” in the SIP messages. If you see the gateway responding with a 422 Interval Too Brief containing a Min-SE value that is larger than VOS3000’s proposed Session-Expires, or if the gateway rejects the session timer entirely, the call will drop at the minimum timer expiry. The quickest fix is to set SS_SESSION_TIMER to 0 in VOS3000 softswitch parameters, which disables the session timer entirely. For detailed session timer troubleshooting, see our session timer 32-second drop guide.

VOS3000 SIP Debug: Correlating CDR with Packet Captures

The most powerful VOS3000 SIP debug technique combines packet capture analysis with CDR record examination. CDR records show you the outcome (termination reason, duration, gateway used), while packet captures show you the signaling path that led to that outcome. By correlating the two, you can trace any call failure from symptom to root cause with complete certainty.

Correlation Method

Follow these steps to correlate VOS3000 CDR records with Wireshark captures for effective debugging:

  1. Start packet capture: Run tcpdump on the VOS3000 server before reproducing the issue
  2. Make test call: Place a call that exhibits the problem
  3. Stop capture: Stop tcpdump after the call fails
  4. Find CDR record: In VOS3000, query the CDR for the test call using Data Query > CDR Query
  5. Note the Call-ID: Record the call timestamp and caller/callee numbers
  6. Filter in Wireshark: Open the capture and filter by the called number or timestamp range
  7. Analyze the flow: Compare the SIP message sequence with the CDR termination reason
๐Ÿ“‹ CDR Termination Reason๐Ÿ” What to Find in Wireshark๐Ÿ› ๏ธ Root Cause
NoAvailableRouterNo INVITE sent to any gatewayNo matching prefix configured
InviteTimeout (408)INVITE sent, no response receivedFirewall, wrong IP, or offline gateway
AllGatewayBusy (503)INVITEs sent, 503 or no 200 OK from anyAll gateways at capacity or disabled
Session timeoutBYE after exactly 32 secondsSession Timer negotiation failure
Normal releaseBYE from caller or calleeNormal hangup (not a problem)
No media timeoutNo RTP packets in one directionSDP IP mismatch or blocked RTP

For a complete reference of CDR termination reasons and their meanings, see our VOS3000 call end reasons guide.

VOS3000 SIP Debug: DTMF Failure Analysis

DTMF (Dual-Tone Multi-Frequency) failures occur when keypad presses during a call are not transmitted correctly to the remote end. This causes problems with IVR systems, voicemail navigation, and automated phone menus. VOS3000 supports multiple DTMF transmission methods, and mismatches between the mapping gateway, VOS3000, and routing gateway cause DTMF to fail silently.

Diagnosing DTMF in Wireshark

To debug DTMF issues, capture both SIP signaling and RTP media during a call where DTMF is being sent. Then analyze the capture for DTMF events using these Wireshark filters:

# Show RTP events (RFC 2833 DTMF)
rtp.event

# Show SIP INFO messages containing DTMF
sip.Method == "INFO" && sip contains "Signal"

# Show all RTP streams for codec analysis
rtp.stream

VOS3000 supports three DTMF modes documented in VOS3000 Manual Section 2.5.1.1: RFC 2833 (in-band RTP events), SIP INFO (out-of-band signaling), and Inband (audio tones). When the mapping gateway sends DTMF via RFC 2833 but the routing gateway expects SIP INFO, the DTMF digits are lost during translation. The fix involves ensuring consistent DTMF mode configuration across all gateways, or enabling VOS3000’s DTMF mode conversion feature in the gateway Additional Settings. For complete DTMF configuration, see our VOS3000 transcoding and DTMF guide.

๐Ÿ“ก DTMF Mode๐Ÿ” Wireshark Evidenceโš ๏ธ Common Failure
RFC 2833RTP event packets (payload 101)Missing payload type in SDP
SIP INFOSIP INFO messages with SignalGateway ignores INFO messages
InbandAudio tones visible in RTP streamG729 compression destroys tones

VOS3000 SIP Debug Best Practices

Following a consistent debug methodology reduces troubleshooting time and improves accuracy. These best practices ensure your VOS3000 SIP debug sessions are productive and efficient.

Debug Workflow Checklist

Every time you need to debug a VOS3000 call issue, follow this structured workflow to avoid missing critical information:

  • Step 1: Define the problem precisely. Note the exact symptom: one-way audio, 32-second drop, 503 error, no ringback, DTMF not working, or registration failure
  • Step 2: Start packet capture first. Always begin tcpdump before reproducing the issue so you capture the complete message flow
  • Step 3: Make a test call. Use a consistent test number and document the exact timestamp
  • Step 4: Stop capture and find CDR. Stop tcpdump, then locate the exact CDR record for your test call
  • Step 5: Analyze in Wireshark. Open the capture, filter by your test call, and trace the complete SIP message flow
  • Step 6: Correlate CDR reason with packet evidence. Match the CDR termination reason to the specific SIP messages that caused it
  • Step 7: Apply targeted fix. Based on your analysis, make the specific configuration change needed
  • Step 8: Verify the fix. Repeat the test to confirm the issue is resolved

This systematic approach eliminates guesswork and ensures you fix the actual root cause rather than applying temporary workarounds. For professional VOS3000 troubleshooting assistance, contact us on WhatsApp at +8801911119966.

๐ŸŽฏ Problem๐Ÿ” First Check๐Ÿ› ๏ธ Wireshark Filter๐Ÿ“ Likely Cause
One-way audioSDP c= line IPsip || rtpNAT/SDP IP mismatch
32-second dropSession-Expires headersip.Session-ExpiresTimer negotiation failure
503 errorGateway status and prefixsip.Status-Code == 503No available gateway
408 timeoutFirewall and IP configsip.Status-Code == 408Network unreachable
DTMF not workingDTMF mode on gatewaysrtp.eventDTMF mode mismatch
Registration failureCredentials and IPsip.Method == “REGISTER”Wrong password or NAT

Frequently Asked Questions About VOS3000 SIP Debug

How do I enable VOS3000 SIP debug trace?

Navigate to Operation Management > Debug Trace in the VOS3000 client, then click Enable for SIP Trace or Registration Trace. The trace displays real-time SIP messages with full headers and timestamps. Note that enabling debug trace for extended periods on high-traffic servers may impact performance, so disable it after capturing the needed data.

What is the best tcpdump command for VOS3000 SIP debug?

The most useful command for comprehensive debugging is: tcpdump -i eth0 -s 0 -w /tmp/debug.pcap port 5060 or udp portrange 10000-20000. This captures both SIP signaling and RTP media streams. Use the -s 0 flag to capture full packet size, and always specify the correct network interface with -i. For professional help, contact us on WhatsApp at +8801911119966.

How do I diagnose one-way audio in VOS3000 using Wireshark?

Capture SIP signaling during the call, then examine the SDP content in the INVITE and 200 OK messages. Look at the c=IN IP4 line in the SDP. If this IP address is a private address (10.x, 172.16-31.x, 192.168.x) but the server uses a public IP, RTP media is being sent to the wrong address. Fix by configuring the correct Local IP in VOS3000 gateway settings or enabling media proxy mode.

Why do VOS3000 calls drop exactly at 32 seconds?

This is caused by Session Timer negotiation failure. When VOS3000 and the remote gateway cannot agree on session timer parameters, the call drops at the minimum session timer expiry. Check Wireshark for Session-Expires headers and 422 Interval Too Brief responses. The quickest fix is to set SS_SESSION_TIMER to 0 in VOS3000 softswitch parameters to disable session timer entirely.

How do I check DTMF problems in VOS3000?

Capture both SIP and RTP during a call where DTMF is sent. In Wireshark, filter for rtp.event to see RFC 2833 DTMF events, or sip.Method == “INFO” for SIP INFO DTMF. If you see DTMF in one format but the receiving gateway expects a different format, enable DTMF mode conversion in VOS3000 gateway Additional Settings. The most reliable configuration is RFC 2833 on both mapping and routing gateways.

Can I use VOS3000 Debug Trace instead of Wireshark?

VOS3000 Debug Trace shows SIP signaling content but does not capture RTP media streams, provide advanced filtering, or visualize call flows. It is useful for quick checks of SIP headers and message sequences. For comprehensive analysis including one-way audio diagnosis, DTMF debugging, and media path verification, Wireshark with packet capture is necessary. Use both tools together for the most effective debugging workflow.

Get Professional VOS3000 SIP Debug Help

If you are struggling with persistent call failures, one-way audio, or unexplained errors in your VOS3000 deployment, professional debugging assistance can save you hours of frustration and lost revenue. Our team has extensive experience analyzing VOS3000 packet captures, correlating CDR records, and identifying root causes quickly.

Contact us on WhatsApp: +8801911119966

We offer complete VOS3000 troubleshooting services including remote packet capture analysis, CDR investigation, configuration optimization, and permanent error resolution. Whether you need help with a specific call failure or ongoing monitoring and support, we can help ensure your platform operates reliably.


๐Ÿ“ž 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 SIP Debug with Wireshark, VOS3000 Outbound SIP Registration, VOS3000 Scaling High Traffic, VOS3000 Protect Route, VOS3000 Caller Number PoolVOS3000 SIP Debug with Wireshark, VOS3000 Outbound SIP Registration, VOS3000 Scaling High Traffic, VOS3000 Protect Route, VOS3000 Caller Number PoolVOS3000 SIP Debug with Wireshark, VOS3000 Outbound SIP Registration, VOS3000 Scaling High Traffic, VOS3000 Protect Route, VOS3000 Caller Number Pool
VOS3000 RTP Media & Audio Troubleshooting Guide โ€“ Fix One Way Audio and No Sound

VOS3000 RTP Media & Audio Troubleshooting โ€“ Easily Fix One Way Audio and No Sound

VOS3000 RTP Media & Audio Troubleshooting Guide โ€“ Fix One Way Audio and No Sound

Audio problems are one of the most common technical issues in VoIP systems. Operators using the VOS3000 softswitch sometimes experience problems such as one way audio, no sound after call connection or intermittent voice quality issues.

Most of these problems are related to RTP media flow, NAT configuration, codec negotiation or firewall restrictions.

This guide explains how RTP media works in VOS3000 and how to troubleshoot common audio problems in VoIP deployments.

Most of Time this solved by Try Media Proxy “On/Off” at Routing Gateway, VOS3000 do Signaling – so mostly one way audio not depend on VOS3000 but still try Media Proxy On/Off, at least any of that will work for no audio or one way audio.

๐Ÿ“ฑ WhatsApp Support
+8801911119966


Understanding RTP Media in VOS3000 (VOS3000 RTP Media)

In VoIP communication, SIP protocol is used for signaling while RTP (Real-Time Transport Protocol) carries the actual audio packets.

The call process typically works like this:

  1. SIP signaling establishes the call
  2. Endpoints negotiate codecs
  3. RTP ports are exchanged
  4. Voice packets flow between endpoints

Once a call is connected through the VOS3000 routing engine, RTP streams transmit the audio between the caller and the destination network.

Understanding the VOS3000 SIP call routing process can help diagnose media problems.

VOS3000 SIP Call Flow Explained


Common Audio Problems in VOS3000

VoIP operators frequently encounter several types of audio issues.

The most common problems include:

  • One way audio
  • No audio after call connection
  • Delayed audio packets
  • Audio dropping during calls
  • Codec incompatibility

These issues usually occur because RTP packets are blocked or misconfigured somewhere in the network path.


One Way Audio Problem (VOS3000 RTP Media)

One way audio occurs when one side of the call can hear the other party but the reverse direction has no audio.

This usually happens due to:

  • NAT configuration problems
  • Firewall blocking RTP ports
  • Incorrect gateway IP configuration

In many VoIP networks, SIP signaling works correctly but RTP packets cannot reach the destination endpoint.


Firewall Blocking RTP Ports

Firewalls can block RTP traffic if the necessary ports are not opened.

Most VoIP deployments require a range of UDP ports for RTP media streams.

If these ports are restricted, the call may connect but no audio will pass between endpoints.

Network administrators should verify:

  • RTP port range configuration
  • UDP port access rules
  • firewall NAT behavior

NAT Configuration Problems (VOS3000 RTP Media)

NAT (Network Address Translation) is another major cause of audio problems in VoIP networks.

When devices are located behind routers, the public IP address may differ from the internal address used in SIP signaling.

If NAT traversal is not handled properly, RTP packets may be sent to incorrect IP addresses.

This leads to:

  • one way audio
  • delayed voice packets
  • call disconnection

Codec Mismatch Issues (VOS3000 RTP Media)

Codec negotiation happens during SIP call setup. If both endpoints cannot agree on a common codec, audio transmission may fail.

Typical codecs used in VoIP networks include:

  • G711
  • G729
  • G723

Operators should ensure that the codec configuration is compatible between the originating gateway and the termination carrier.


Gateway Audio Problems

Sometimes audio problems originate from the gateway or carrier network rather than the VOS3000 server itself.

Possible causes include:

  • carrier codec restrictions
  • incorrect SIP header formatting
  • gateway media routing errors

Proper gateway configuration and routing policies can help reduce these issues.

VOS3000 SIP Trunk Configuration Guide


Monitoring Audio Quality

VOS3000 provides monitoring tools that allow operators to evaluate call performance and identify routing problems.

Important quality metrics include:

  • ASR โ€“ Answer Seizure Ratio
  • ACD โ€“ Average Call Duration
  • Call failure rate
  • gateway traffic reports

Operators can analyze these metrics to determine whether issues originate from routing, carrier networks or local infrastructure.

VOS3000 Error Codes and Troubleshooting


Best Practices to Avoid Audio Issues

To maintain stable VoIP service, operators should follow several best practices.

  • Allow RTP UDP ports in firewall rules
  • verify NAT configuration
  • ensure compatible codecs between gateways
  • monitor call quality statistics regularly
  • test carrier routes frequently

Proper network configuration significantly reduces VoIP audio issues.


Official VOS3000 Resources

VOS3000 Official Manuals and Downloads

VOS3000 Client Software Download


FAQ โ€“ VOS3000 Audio Troubleshooting

Why does one way audio happen in VoIP calls?

One way audio usually occurs when RTP packets are blocked by firewalls or incorrect NAT configuration.

Does VOS3000 control RTP media directly?

VOS3000 handles SIP signaling and routing, while RTP media streams normally flow between endpoints or gateways.

How can I fix no audio after call connection?

Check firewall rules, verify RTP port configuration and ensure that both endpoints support the same codecs.

Where can I download VOS3000 manuals?

Download VOS3000 Manuals


Need VOS3000 Server or Support?

If you need VOS3000 hosting, routing configuration or VoIP deployment assistance, you can contact us.

๐Ÿ“ž Need Call Center Setup Support?

For professional VOS3000 call center configuration and deployment:

๐Ÿ“ฑ WhatsApp: +8801911119966
๐ŸŒ Website: www.vos3000.com
๐ŸŒ Blog: multahost.com/blog
๐Ÿ“ฅ Downloads: VOS3000 Downloads


VOS3000-Offer, VOS3000 Price, VOS3000 rent, VOS3000 Hosting, VOS3000 installation, VOS3000 CentOS, VOS3000 Hosted, VOS3000 21907, VOS3000 Web, VOS3000 Softswitch, VOS3000 Keygen, VOS3000 Login, VOS3000 API, VOS3000 Anti Hack, VOS3000 21907, VOS3000 21907 Feature, VOS3000 2.1.6.00, client VOS3000, VOS3000 Server, VOS3000 Gateway, VOS3000 Server getting restarted, VOS3000 Installation, VOS3000 Server, VOS3000 SoftSwitch, VOS3000 Switch, VOS3000, VOS3000 Pricem VOS3000 Web, VOS3000 API, VOS3000 Rent, VOS3000 Manual, VOS3000 Downloads, VOS3000 VoIP, VOS3000 Carrier Switch, VOS3000, VOS3000 Login, VOS3000 Monitoring, VOS3000 Performance Metrics, VOS3000 Call Routing, VOS3000 Security, VOS3000 Web Manager, VOS3000 Versions, VOS3000 BillingVOS3000 Monitoring,VOS3000 Capacity, VOS3000 Billing System, VOS3000 License, Mobile Apps for VOS3000, VOS3000 Mobile Apps, Mobile Apps, VOS3000 Apps, Android VOS3000, VOS3000 in IOS, Manual for VOS3000, VOS3000 Manual, Manual VOS3000, Reference Manual VOS3000, User Manual VOS3000, CentOS7 Installation for VOS3000, Multiple IP License in VOS3000, VOS3000 License, License in VOS3000, vos installation, VOS3000 Hosting, Hosting VOS3000, VOS3000 Server Rent, VOS3000 Client Download, VOS3000 error codes, VOS3000 vs Asterisk, VOS3000 call center, best voip softswitch, vos3000 routing, vos3000 vicidial auto dialer, vos3000 sip trunk configuration, VOS3000 ASR ACD Analysis, VOS3000 Codec G729 Transcoding, VOS3000 IVR Balance Query, VOS3000 DTMF Modes, VOS3000 Gateway Analysis Reports, VOS3000 RTP Media, VOS3000 SIP Call FlowVOS3000-Offer, VOS3000 Price, VOS3000 rent, VOS3000 Hosting, VOS3000 installation, VOS3000 CentOS, VOS3000 Hosted, VOS3000 21907, VOS3000 Web, VOS3000 Softswitch, VOS3000 Keygen, VOS3000 Login, VOS3000 API, VOS3000 Anti Hack, VOS3000 21907, VOS3000 21907 Feature, VOS3000 2.1.6.00, client VOS3000, VOS3000 Server, VOS3000 Gateway, VOS3000 Server getting restarted, VOS3000 Installation, VOS3000 Server, VOS3000 SoftSwitch, VOS3000 Switch, VOS3000, VOS3000 Pricem VOS3000 Web, VOS3000 API, VOS3000 Rent, VOS3000 Manual, VOS3000 Downloads, VOS3000 VoIP, VOS3000 Carrier Switch, VOS3000, VOS3000 Login, VOS3000 Monitoring, VOS3000 Performance Metrics, VOS3000 Call Routing, VOS3000 Security, VOS3000 Web Manager, VOS3000 Versions, VOS3000 BillingVOS3000 Monitoring,VOS3000 Capacity, VOS3000 Billing System, VOS3000 License, Mobile Apps for VOS3000, VOS3000 Mobile Apps, Mobile Apps, VOS3000 Apps, Android VOS3000, VOS3000 in IOS, Manual for VOS3000, VOS3000 Manual, Manual VOS3000, Reference Manual VOS3000, User Manual VOS3000, CentOS7 Installation for VOS3000, Multiple IP License in VOS3000, VOS3000 License, License in VOS3000, vos installation, VOS3000 Hosting, Hosting VOS3000, VOS3000 Server Rent, VOS3000 Client Download, VOS3000 error codes, VOS3000 vs Asterisk, VOS3000 call center, best voip softswitch, vos3000 routing, vos3000 vicidial auto dialer, vos3000 sip trunk configuration, VOS3000 ASR ACD Analysis, VOS3000 Codec G729 Transcoding, VOS3000 IVR Balance Query, VOS3000 DTMF Modes, VOS3000 Gateway Analysis Reports, VOS3000 RTP Media, VOS3000 SIP Call FlowVOS3000-Offer, VOS3000 Price, VOS3000 rent, VOS3000 Hosting, VOS3000 installation, VOS3000 CentOS, VOS3000 Hosted, VOS3000 21907, VOS3000 Web, VOS3000 Softswitch, VOS3000 Keygen, VOS3000 Login, VOS3000 API, VOS3000 Anti Hack, VOS3000 21907, VOS3000 21907 Feature, VOS3000 2.1.6.00, client VOS3000, VOS3000 Server, VOS3000 Gateway, VOS3000 Server getting restarted, VOS3000 Installation, VOS3000 Server, VOS3000 SoftSwitch, VOS3000 Switch, VOS3000, VOS3000 Pricem VOS3000 Web, VOS3000 API, VOS3000 Rent, VOS3000 Manual, VOS3000 Downloads, VOS3000 VoIP, VOS3000 Carrier Switch, VOS3000, VOS3000 Login, VOS3000 Monitoring, VOS3000 Performance Metrics, VOS3000 Call Routing, VOS3000 Security, VOS3000 Web Manager, VOS3000 Versions, VOS3000 BillingVOS3000 Monitoring,VOS3000 Capacity, VOS3000 Billing System, VOS3000 License, Mobile Apps for VOS3000, VOS3000 Mobile Apps, Mobile Apps, VOS3000 Apps, Android VOS3000, VOS3000 in IOS, Manual for VOS3000, VOS3000 Manual, Manual VOS3000, Reference Manual VOS3000, User Manual VOS3000, CentOS7 Installation for VOS3000, Multiple IP License in VOS3000, VOS3000 License, License in VOS3000, vos installation, VOS3000 Hosting, Hosting VOS3000, VOS3000 Server Rent, VOS3000 Client Download, VOS3000 error codes, VOS3000 vs Asterisk, VOS3000 call center, best voip softswitch, vos3000 routing, vos3000 vicidial auto dialer, vos3000 sip trunk configuration, VOS3000 ASR ACD Analysis, VOS3000 Codec G729 Transcoding, VOS3000 IVR Balance Query, VOS3000 DTMF Modes, VOS3000 Gateway Analysis Reports, VOS3000 RTP Media, VOS3000 SIP Call Flow