除了恶意欺诈之外，透支还可能源于客户忘记充值、付款延迟、或者对自身通话量的误判。无论原因如何，最终的结果都是运营商承担了本不该承担的财务风险。VOS 3000通过系统层面的自动阻断机制，可以在余额到达临界值时立即停止服务，将损失降到最低。同时，CPS（Calls Per Second）限速功能可以防止恶意突发流量，即使在账户尚未触发余额阻断之前，也能限制异常高的话务量，提供双重保障。
VOS 3000 负余额阻断不仅能防止透支，还可以通过CPS（Calls Per Second）限速来防止恶意突发流量。在VoIP运营中，有一种常见的攻击方式是短时间内发起大量并发呼叫，这不仅会消耗系统资源，还可能在余额阻断机制生效之前就产生大量通话费用。通过在Mapping Gateway上配置Rate Limit（速率限制），您可以控制每个网关每秒允许的最大呼叫数，有效遏制突发流量攻击。
是的，CPS限速设置过低会拒绝正常的呼叫请求，导致客户体验下降。CPS（Calls Per Second）限制的是每秒允许的新呼叫建立数量，而不是同时在线的通话数。如果客户在正常业务中偶尔会出现突发性的呼叫（例如呼叫中心在特定时段集中外呼），而CPS设置过低，这些正常呼叫也会被拒绝。因此，建议将CPS限速值设置为客户正常峰值话务量的1.5-2倍，既留出足够的余量应对正常突发，又能有效阻止异常的超大流量攻击。同时，建议结合VOS3000计费系统中的话务统计功能，定期分析客户的实际CPS使用情况，动态调整限速参数。
# 停止VOS3000所有服务（在旧服务器上执行）
service vos3000d stop
service mbx3000d stop
service voipagent stop
# 验证服务已完全停止
ps aux | grep vos3000
ps aux | grep mbx3000
# 确认MySQL仍在运行（导出需要）
service mysqld status
VOS 3000的License授权文件绑定在服务器的IP地址和MAC地址上，因此VOS3000 服务器迁移到新IP地址的服务器后，必须重新申请License。不能简单复制旧服务器的License文件——它们在新IP上将无法生效。您需要联系VOS 3000官方支持申请License转移，提供以下信息以加快处理速度：
🔒 所需信息
📝 详细说明
💡 备注
原License密钥
当前服务器上的License字符串
位于/etc/vos3000/license文件
旧服务器IP地址
License当前绑定的IP地址
旧服务器公网IP
新服务器IP地址
新CentOS 7服务器的IP地址
必须为静态永久IP
订单号/购买凭证
原始购买订单号或发票编号
License所有权证明
新服务器MAC地址
新服务器网卡MAC地址
运行命令：ip link show
注册邮箱
原始License购买时使用的邮箱
用于身份验证
# 获取新服务器IP地址
ip addr show | grep "inet " | grep -v 127.0.0.1
# 获取新服务器MAC地址
ip link show | grep ether
# 检查当前License状态
cd /opt/vos3000/
./licenseinfo.sh
# 收到新License后上传到指定目录
# 然后重启VOS3000服务使其生效
# 启动VOS3000所有服务
service mysqld start
service vos3000d start
service mbx3000d start
service voipagent start
# 验证服务运行状态
service vos3000d status
service mbx3000d status
service voipagent status
# 检查日志是否有错误
tail -f /var/log/vos3000/vos3000.log
tail -f /var/log/vos3000/mbx3000.log
VOS3000 Transcoding: Codec Converter Configuration Guide for VoIP
Configuring VOS3000 transcoding correctly is one of the most critical steps in building a reliable VoIP platform that can interconnect diverse networks and endpoints. When the caller and callee use incompatible voice codecs, calls simply cannot connect — or they connect with no audio, one-way audio, or severely degraded voice quality. According to the VOS3000 Transcode Module documentation (Section 1.1, Page 1), “When caller and callee voice codecs are incompatible, transcoding function can be used to make them compatible.” This single statement captures the entire purpose and value of VOS3000 transcoding: bridging the codec gap between different VoIP networks, devices, and service providers.
The reality of VoIP operations is that you will frequently encounter situations where your customers (calling side) support one set of codecs while your vendors (called side) support a different set. For example, a retail SIP customer may only support PCMA (G711a), while your termination vendor only accepts G729 calls. Without VOS3000 transcoding enabled and properly configured, these calls will fail every time — costing you revenue and frustrating your customers. The VOS3000 transcode module solves this problem by converting the voice stream from one codec to another in real time, ensuring both ends can communicate regardless of their native codec support.
This comprehensive guide covers every aspect of VOS3000 transcoding configuration, from the basic codec settings on mapping and routing gateways to advanced DTMF handling during transcoding and G729 negotiation modes. All information is based on the official VOS3000 Transcode Module documentation and the VOS3000 V2.1.9.07 Manual. For expert assistance with your transcoding configuration, contact us on WhatsApp at +8801911119966.
Table of Contents
Understanding VOS3000 Transcoding Fundamentals
Before diving into configuration, it is essential to understand what VOS3000 transcoding does, when it is needed, and how it interacts with other VOS3000 features like media proxy and DTMF handling. Many VOS3000 operators struggle with transcoding because they configure it without understanding the underlying concepts, leading to misconfigurations that cause audio problems instead of solving them.
What Is VOS3000 Transcoding?
Transcoding in VOS3000 refers to the real-time conversion of a voice media stream from one codec format to another. When a call passes through VOS3000 with media proxy enabled, the softswitch sits in the media path between the caller and callee. This position allows VOS3000 to receive audio in one codec from the caller, decode it, re-encode it in a different codec, and send it to the callee — all in real time with minimal latency. The VOS3000 Transcode Module documentation confirms this process in Section 1.1 (Page 1): “When caller and callee voice codecs are incompatible, transcoding function can be used to make them compatible.”
The key requirement for VOS3000 transcoding to work is that media proxy must be enabled. Without media proxy, VOS3000 does not intercept the RTP media stream and therefore cannot perform codec conversion. The RTP flows directly between endpoints, and both endpoints must share at least one common codec for the call to succeed.
When VOS3000 Transcoding Is Required
VOS3000 transcoding is required in several common VoIP scenarios. Understanding these scenarios helps you determine when to enable codec conversion and how to configure it properly:
Different codec support between customer and vendor: Your customer’s SIP device only supports PCMA (G711a) and PCMU (G711u), but your termination vendor only accepts G729 calls. Without transcoding, every call between this customer and vendor will fail with a codec negotiation error
Bandwidth optimization: You want to use G729 on the vendor side to save bandwidth on your WAN link, while customers connect with G711 over their local network where bandwidth is not a concern
Multi-vendor routing: Different vendors support different codecs, and you need VOS3000 to adapt the codec for each vendor automatically
Legacy device interconnection: Older SIP phones or gateways may only support G711, while modern networks use G729 or G723 for efficiency
Mobile VoIP applications: Mobile SIP clients often prefer G729 for lower bandwidth usage, while the called party may be on a traditional G711 landline
📞 Scenario
🔵 Caller Codec
🟢 Callee Codec
🔄 Transcoding Needed
Retail SIP phone → G729 vendor
PCMA (G711a)
G729
✅ Yes — PCMA → G729
Mobile app → Landline gateway
G729
PCMA (G711a)
✅ Yes — G729 → PCMA
SIP phone → SIP phone (same codec)
PCMA
PCMA
❌ No — codecs match
G723 gateway → G729 vendor
G723
G729
✅ Yes — G723 → G729
G711 → G711 vendor
PCMU (G711u)
PCMA (G711a)
⚠️ Maybe — depends on device support
VOS3000 Transcoding Resource Considerations
VOS3000 transcoding is a CPU-intensive operation because it requires real-time decoding and re-encoding of voice streams. Each transcoded call consumes significantly more server resources than a simple pass-through call. The impact depends on which codecs are involved: transcoding between G711 and G729 is more CPU-intensive than transcoding between G711 variants. When planning your VOS3000 deployment, factor in the expected percentage of transcoded calls and ensure your server has sufficient CPU capacity. For load testing guidance, see our VOS3000 concurrent call load test guide.
Where to Configure VOS3000 Transcoding Codec Settings
The VOS3000 transcoding codec settings are located in the Additional Settings section of both mapping gateways (customer side) and routing gateways (vendor side). According to the VOS3000 Transcode Module documentation (Section 1.2, Page 1), the codec configuration is found at: Business Management > Routing Gateway/Mapping Gateway > Additional Settings > Codec. This same path is referenced in the VOS3000 Manual Section 2.5.1.1 (Page 32, 47) which describes the codec settings under Additional Settings > Codec > H323/SIP.
Understanding this configuration location is critical because the transcoding behavior is controlled independently on each gateway. The mapping gateway codec settings determine how VOS3000 handles the codec on the caller (customer) side, while the routing gateway codec settings determine the codec handling on the callee (vendor) side. Both sides must be configured correctly for VOS3000 transcoding to function as intended.
Navigating to Codec Settings
To access the VOS3000 transcoding codec settings, follow these steps for each gateway type:
For Mapping Gateway (Customer Side):
Navigate to Business Management > Mapping Gateway
Double-click the mapping gateway you want to configure
Click the Additional Settings tab
Select the Codec sub-tab
Configure the SIP and/or H323 codec settings as needed
For Routing Gateway (Vendor Side):
Navigate to Business Management > Routing Gateway
Double-click the routing gateway you want to configure
Click the Additional Settings tab
Select the Codec sub-tab
Configure the SIP and/or H323 codec settings as needed
For mapping gateways, the path is Business Management > Mapping Gateway > Additional Settings > Codec > H323/SIP (referenced in VOS3000 Transcode Module Section 1.2 and VOS3000 Manual Section 2.5.1.1, Page 32). For routing gateways, the path is Business Management > Routing Gateway > Additional Settings > Codec > H323/SIP (referenced in VOS3000 Transcode Module Section 1.2 and VOS3000 Manual Section 2.5.1.1, Page 47). Both paths lead to the same codec configuration interface, but the settings you apply on each gateway type control different sides of the call.
The VOS3000 transcoding codec configuration provides two primary settings that control how the softswitch handles codec negotiation and conversion: “Softswitch specified” and “Allow codec conversion.” Understanding the exact behavior of each option is essential for correct VOS3000 transcoding configuration.
Softswitch Specified Codec Setting
According to the VOS3000 Transcode Module documentation (Section 1.2, Page 1), the “Softswitch specified” option means that both the caller and callee use the codec specified by the softswitch. When this option is selected, VOS3000 dictates the codec to be used on that gateway side, regardless of what codecs the far-end device supports or negotiates in SDP.
The practical impact of the “Softswitch specified” setting is significant:
On the mapping gateway (caller side): Selecting “Softswitch specified” with a specific codec (e.g., PCMA) forces VOS3000 to use PCMA when communicating with the customer’s device, even if the customer’s device offers G729 in its SDP
On the routing gateway (callee side): Selecting “Softswitch specified” with a specific codec (e.g., G729) forces VOS3000 to use G729 when sending media to the vendor, even if the vendor’s SDP also offers PCMA
Combined effect: When both sides use “Softswitch specified” with different codecs, VOS3000 transcoding is automatically activated to convert between the two specified codecs
This is the most common and recommended configuration for VOS3000 transcoding because it gives you precise control over which codec is used on each side of the call.
Allow Codec Conversion Setting
The “Allow codec conversion” checkbox is the second critical setting for VOS3000 transcoding. According to the VOS3000 Transcode Module documentation (Section 1.2, Page 1), “When caller and callee codecs are inconsistent, use codec conversion to convert to far-end supported voice codec.” This setting explicitly permits VOS3000 to perform real-time codec conversion when the codecs on the two sides of the call do not match.
The “Allow codec conversion” checkbox must be checked on both the mapping gateway and the routing gateway for full transcoding support. The behavior is as follows:
Checked on mapping gateway: VOS3000 is allowed to convert the codec on the caller (customer) side to match what the callee (vendor) requires
Checked on routing gateway: VOS3000 is allowed to convert the codec on the callee (vendor) side to match what the caller (customer) is sending
Unchecked on either side: VOS3000 will not perform codec conversion on that side, which may result in call failure if the codecs are incompatible
The combination of “Softswitch specified” and “Allow codec conversion” creates a complete VOS3000 transcoding configuration that ensures calls succeed even when the caller and callee have no common codecs.
⚙️ Setting
📝 Description
🎯 Purpose
📋 When to Use
Softswitch specified
VOS dictates the codec used on this gateway side
Force a specific codec regardless of SDP negotiation
When you need precise codec control for transcoding
Allow codec conversion
Permits VOS to convert between incompatible codecs
Enable real-time codec transcoding
When caller and callee codecs differ
Auto negotiation
VOS negotiates the codec based on SDP offer/answer
Let endpoints agree on a common codec
When both sides share common codecs
VOS3000 Transcoding Function Scenario: Step-by-Step
The VOS3000 Transcode Module documentation (Section 1.3, Pages 2-3) provides a detailed application scenario that demonstrates exactly how VOS3000 transcoding works in practice. This scenario is the most important configuration example to understand because it shows the complete flow of a transcoded call from start to finish.
Scenario: Caller Supports PCMA Only, Callee Supports G729 Only
In this scenario, the caller (customer connected through a mapping gateway) only supports the PCMA codec (G711a), while the callee (vendor connected through a routing gateway) only supports G729. Without VOS3000 transcoding, this call would fail because the two endpoints have no common codec. With VOS3000 transcoding properly configured, the call succeeds because VOS3000 converts the voice stream from PCMA to G729 in real time.
According to the VOS3000 Transcode Module documentation (Section 1.3, Pages 2-3), the configuration steps are:
Step 1: Configure the Mapping Gateway (Caller Side)
Navigate to Business Management > Mapping Gateway
Double-click the mapping gateway used by the caller
Go to Additional Settings > Codec
Check the “Allow codec conversion” checkbox
Select “Softswitch specified codec PCMA”
Save the configuration
By checking “Allow codec conversion” and selecting “Softswitch specified codec PCMA” on the mapping gateway, you are telling VOS3000 to force the use of PCMA when communicating with the caller, and to allow VOS3000 to convert this codec to whatever the callee requires.
Step 2: Configure the Routing Gateway (Callee Side)
Navigate to Business Management > Routing Gateway
Double-click the routing gateway used for the callee
Go to Additional Settings > Codec
Check the “Allow codec conversion” checkbox
Select “Softswitch specified codec G729”
Save the configuration
By checking “Allow codec conversion” and selecting “Softswitch specified codec G729” on the routing gateway, you are telling VOS3000 to force the use of G729 when communicating with the vendor, and to allow VOS3000 to convert the incoming PCMA stream to G729 before sending it to the vendor.
🔧 Configuration Step
👤 Mapping Gateway (Caller)
🏢 Routing Gateway (Callee)
📝 Result
Allow codec conversion
✅ Checked
✅ Checked
VOS3000 can transcode between sides
Softswitch specified codec
PCMA (G711a)
G729
Different codecs on each side → transcoding active
Media proxy
On / Auto
On / Auto
VOS3000 intercepts RTP for transcoding
Call flow
Caller → PCMA → VOS3000
VOS3000 → G729 → Vendor
✅ Call succeeds with real-time transcoding
How the Call Flow Works During VOS3000 Transcoding
Understanding the complete call flow during VOS3000 transcoding helps you troubleshoot issues and design your transcoding architecture correctly. Here is what happens at each stage of the call:
Call initiation: The caller sends a SIP INVITE to VOS3000 with PCMA in the SDP codec list
Codec selection on mapping gateway: VOS3000, using the “Softswitch specified codec PCMA” setting on the mapping gateway, responds to the caller with PCMA as the selected codec, regardless of what other codecs the caller offered
Call routing: VOS3000 routes the call to the appropriate routing gateway based on the dial plan and LCR configuration
Codec selection on routing gateway: VOS3000, using the “Softswitch specified codec G729” setting on the routing gateway, sends a SIP INVITE to the vendor with only G729 in the SDP, forcing the vendor to use G729
Media path established: The caller sends RTP audio in PCMA format to VOS3000. VOS3000 decodes the PCMA audio, re-encodes it as G729, and sends the G729 audio to the vendor. In the reverse direction, the vendor sends G729 audio to VOS3000, which decodes it and re-encodes as PCMA for the caller
Two-way audio: Both parties hear each other clearly because VOS3000 transcoding handles the codec conversion in both directions simultaneously
This bidirectional real-time codec conversion is the core function of VOS3000 transcoding. The process is seamless to both parties — neither the caller nor the callee is aware that their voice is being decoded, converted, and re-encoded by VOS3000 in the middle.
VOS3000 Transcoding: Auto Negotiation vs Softswitch Specified
The VOS3000 Manual Section 2.5.1.1 (Page 32, 47) describes two primary codec selection modes available in the Additional Settings > Codec > H323/SIP configuration: Auto negotiation and Softswitch specified. Choosing the correct mode for each gateway is critical for VOS3000 transcoding to work properly.
Auto Negotiation Mode
In Auto negotiation mode, VOS3000 allows the endpoints to negotiate the codec through the standard SDP offer/answer mechanism. VOS3000 does not force a specific codec; instead, it facilitates the negotiation between the caller and callee to find a mutually supported codec. If both endpoints share at least one common codec, Auto negotiation will select it and no transcoding is needed.
Auto negotiation is appropriate when:
Both endpoints share common codecs: If your customers and vendors both support G711 and G729, Auto negotiation will select the best common codec without requiring transcoding
You want to minimize server load: Auto negotiation avoids transcoding when possible, reducing CPU consumption on your VOS3000 server
Simple deployments: When all your gateways and endpoints use the same codecs, Auto negotiation is the simplest configuration
However, Auto negotiation fails when the caller and callee have no common codecs. In this case, VOS3000 cannot complete the SDP negotiation and the call will fail with a codec mismatch error. This is exactly when you need to switch from Auto negotiation to Softswitch specified with “Allow codec conversion” enabled.
Softswitch Specified Mode
In Softswitch specified mode, VOS3000 dictates which codec is used on each side of the call. As described in the VOS3000 Transcode Module documentation (Section 1.2, Page 1), “Softswitch specified: Both caller and callee use softswitch specified codec.” This mode gives you complete control over the codec selection on each gateway, independent of what the endpoints negotiate or offer in SDP.
Softswitch specified mode is required when:
Caller and callee have no common codecs: You must force different codecs on each side and rely on VOS3000 transcoding to bridge the gap
You need to control bandwidth usage: Forcing G729 on the vendor side reduces bandwidth consumption, even if both sides support G711
A specific codec is required by a gateway: Some SIP gateways only work correctly with a specific codec, and you need to force it regardless of the endpoint’s SDP offer
📋 Feature
🔄 Auto Negotiation
🖥️ Softswitch Specified
Codec selection
Endpoints negotiate via SDP
VOS3000 forces specific codec
Transcoding needed
Only if no common codec found
Yes, when different codecs on each side
Server CPU load
Lower (no transcoding usually)
Higher (active transcoding)
Call success rate
Fails if no common codec
Always succeeds with proper config
Best for
Same codec on both sides
Different codecs on each side
Bandwidth control
Limited control
Full control (force G729 for bandwidth)
VOS3000 Transcoding G729 Negotiation Modes
When configuring VOS3000 transcoding with the G729 codec, you must understand the G729 negotiation modes available in VOS3000. According to the VOS3000 Manual Section 2.5.1.1 (Page 32, 47), the G729 codec has multiple variants and VOS3000 supports several negotiation modes for handling them.
G729 Variants and Their Differences
The G729 codec family includes several variants, the most important being:
G729: The original G729 codec (also known as G729A annex), providing 8 kbps voice compression
G729a: A lower-complexity version of G729 with slightly reduced voice quality but significantly lower CPU requirements. The “a” stands for “annex A”
G729b: G729 with Voice Activity Detection (VAD) and Comfort Noise Generation (CNG), which reduces bandwidth during silence periods
G729ab: Combination of G729a (low complexity) and G729b (VAD/CNG)
While all G729 variants use the same basic encoding algorithm and are largely interoperable, some SIP devices are strict about which variant they accept. If a device advertises only G729a in its SDP but VOS3000 sends G729, the call may fail even though the audio encoding is compatible. The G729 negotiation modes in VOS3000 solve this problem by controlling how VOS3000 advertises and handles G729 variants.
G729 Negotiation Mode Options
VOS3000 provides four G729 negotiation modes, as referenced in the VOS3000 Manual (Section 2.5.1.1, Page 32, 47):
Auto: VOS3000 automatically selects the G729 variant based on the remote endpoint’s SDP offer. If the endpoint offers G729, VOS3000 responds with G729. If the endpoint offers G729a, VOS3000 responds with G729a. This is the recommended setting for maximum compatibility
G729: VOS3000 always uses G729 regardless of what the remote endpoint offers. Use this when you need to force G729 for compatibility with gateways that only accept this variant
G729a: VOS3000 always uses G729a regardless of the remote endpoint’s offer. Use this when you need the lower-complexity variant for CPU savings on high-capacity transcoding
G729&G729a: VOS3000 offers both G729 and G729a in the SDP, allowing the remote endpoint to choose which variant to use. This provides maximum compatibility by supporting both variants simultaneously
⚙️ Mode
📝 Behavior
🎯 Best For
⚠️ Consideration
Auto
Matches remote endpoint’s G729 variant
General use (recommended default)
May not work with some strict gateways
G729
Forces G729 variant only
Gateways requiring G729 specifically
Higher CPU than G729a
G729a
Forces G729a (low complexity) variant
High-capacity transcoding servers
Slightly lower voice quality
G729&G729a
Offers both G729 and G729a in SDP
Maximum compatibility
Larger SDP payload, may confuse some devices
Choosing the Right G729 Negotiation Mode for VOS3000 Transcoding
For most VOS3000 transcoding deployments, the Auto G729 negotiation mode is the best choice because it automatically adapts to the remote endpoint’s G729 variant, minimizing compatibility issues. However, if you encounter G729 codec negotiation failures where calls fail with codec mismatch errors even though both sides claim to support G729, try switching to G729&G729a mode, which offers both variants in the SDP and allows the remote endpoint to select the one it supports.
If your VOS3000 server handles a large number of concurrent transcoded calls and CPU utilization is a concern, consider using G729a mode, which uses less CPU per call due to its lower algorithmic complexity. The voice quality difference between G729 and G729a is minimal and typically imperceptible to callers.
VOS3000 Transcoding and DTMF Handling
DTMF (Dual-Tone Multi-Frequency) handling is a critical consideration when configuring VOS3000 transcoding. When VOS3000 performs transcoding, it sits in the media path and processes all RTP packets, including DTMF signals. The VOS3000 Transcode Module documentation (Section 2, Pages 5-6) provides detailed information about how DTMF is handled during transcoding, and understanding these behaviors is essential for ensuring that IVR systems, calling card platforms, and PIN authentication work correctly with transcoded calls.
DTMF Transport Methods in VOS3000 Transcoding
VOS3000 supports three DTMF transport methods, each with different behavior during transcoding:
SIP INFO: According to the VOS3000 Transcode Module documentation (Section 2.2, Page 5), “SIP INFO belongs to independent signaling, where key presses are carried in separate signaling messages.” SIP INFO DTMF signals travel in the SIP signaling channel, completely separate from the RTP media stream. This means SIP INFO DTMF is unaffected by codec conversion because it does not travel in the media path.
RFC2833: According to the VOS3000 Transcode Module documentation (Section 2.3, Page 5), “RFC2833 is identified in SDP by a=rtpmap:101 telephone-event/8000, and key presses are carried in separate RTP packets.” RFC2833 transmits DTMF as special RTP events within the media stream, identified by a specific payload type. The SDP attribute a=rtpmap:101 telephone-event/8000 advertises RFC2833 support and specifies the payload type number (commonly 101).
Inband: According to the VOS3000 Transcode Module documentation (Section 2.4, Page 5), “Inband key presses are carried in the RTP as a continuous segment of voice.” Inband DTMF embeds the DTMF tones as actual audio in the RTP voice stream. This is the most problematic method for VOS3000 transcoding because the DTMF tones are compressed along with the voice audio, which can distort them beyond recognition — especially when transcoding between G711 and G729.
RFC2833 Payload Configuration for VOS3000 Transcoding
The RFC2833 payload value is a critical setting for VOS3000 transcoding when DTMF is transported via RFC2833. According to the VOS3000 Transcode Module documentation, only RFC2833 has a Payload value setting. The payload number (typically 101) identifies the RTP payload type used for telephone-event packets. When configuring VOS3000 transcoding, ensure that the RFC2833 payload value matches on both sides of the call, or that VOS3000 is correctly translating the payload type during transcoding.
The SDP for RFC2833 includes the following attribute:
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
In this example, payload type 101 is used for telephone-event, and keys 0-16 are supported (digits 0-9, *, #, and additional keys A-D). When media proxy is enabled during VOS3000 transcoding, VOS3000 controls the payload type and key range sent to each side.
Use Peer RFC2833 Ability Setting
The “Use peer RFC2833 ability” setting controls how VOS3000 advertises RFC2833 support in the SDP during VOS3000 transcoding. According to the VOS3000 Transcode Module documentation (Section 2.5, Page 6):
When checked: If the peer (far end) sends RFC2833 capability in its SDP, VOS3000 will also advertise RFC2833 to the other side. If the peer does not send RFC2833, VOS3000 will not advertise it either. This follows the peer’s capability transparently
When unchecked: If the peer sends RFC2833 capability, VOS3000 sends RFC2833 to the far end normally. If the peer does not send RFC2833, VOS3000 auto-generates the SDP field to include RFC2833 capability, regardless of what the peer supports. This forces RFC2833 on the far end even when the original peer did not offer it
For VOS3000 transcoding deployments where you want to ensure RFC2833 DTMF works reliably on both sides, unchecking “Use peer RFC2833 ability” is often the better choice because it guarantees that VOS3000 advertises RFC2833 in SDP to both endpoints, enabling proper DTMF relay during transcoding.
📞 DTMF Method
🔄 Transcoding Impact
✅ Reliability
📋 Recommendation
SIP INFO
No impact (signaling channel, not media)
High — independent of codec
Good for transcoded calls
RFC2833
VOS terminates and regenerates DTMF events
High — VOS controls payload
✅ Recommended for transcoded calls
Inband
DTMF tones distorted by codec compression
Low — unreliable with G729
❌ Avoid for transcoded calls
VOS3000 Transcoding DTMF Behavior with Media Proxy
The VOS3000 Transcode Module documentation (Section 2.6, Page 6) provides critical details about how DTMF is handled when media proxy is enabled or disabled during VOS3000 transcoding. This is one of the most important aspects of transcoding configuration because incorrect DTMF handling can cause IVR failures, PIN entry problems, and other issues that directly impact your customers.
DTMF with Media Proxy Enabled (Required for VOS3000 Transcoding)
When media proxy is enabled — which is required for VOS3000 transcoding — VOS3000 fully intercepts and processes all RTP media streams, including DTMF signals. According to the VOS3000 Transcode Module documentation (Section 2.6, Page 6), “If media forwarding is enabled, the RFC2833 payload and 0-16 key support type received from the far-end SDP is terminated by VOS, and VOS integrates and sends the values set in VOS DTMF configuration to the peer end.”
This means that with media proxy on during VOS3000 transcoding:
RFC2833 is terminated and regenerated: VOS3000 receives the RFC2833 DTMF events from one side, terminates them, and then generates new RFC2833 DTMF events on the other side using the payload value and key range configured in VOS3000’s DTMF settings
DTMF conversion is possible: VOS3000 can convert DTMF from one method to another (e.g., SIP INFO on the caller side to RFC2833 on the callee side)
Payload type is controlled by VOS3000: The RFC2833 payload type number sent to each endpoint is determined by VOS3000, not passed through from the remote side
Key support range is controlled: VOS3000 sends DTMF key support 0-16 (digits 0-9, *, #, A-D) as configured in the DTMF settings
DTMF Without Media Proxy (Passthrough Mode)
When media proxy is disabled, VOS3000 does not intercept the RTP stream and DTMF signals pass through directly between endpoints. According to the VOS3000 Transcode Module documentation (Section 2.6, Page 6), without media proxy, “RFC2833 passthrough” is the behavior — DTMF events travel directly from the caller to the callee without modification.
However, without media proxy, VOS3000 transcoding cannot function because VOS3000 does not have access to the media stream to perform codec conversion. This means passthrough mode and transcoding are mutually exclusive — if you need VOS3000 transcoding, media proxy must be enabled, and VOS3000 will actively handle DTMF as described above.
⚙️ Aspect
🔵 Media Proxy ON (Transcoding)
⚪ Media Proxy OFF (Passthrough)
VOS3000 transcoding
✅ Active — codec conversion works
❌ Not possible — no media access
RFC2833 DTMF
Terminated and regenerated by VOS
Direct passthrough
RFC2833 payload type
VOS controls payload value sent to each side
Original payload passed through
DTMF method conversion
✅ Possible (e.g., Inband → RFC2833)
❌ Not possible
Inband DTMF detection
✅ VOS can detect and convert
❌ Cannot intercept
SIP INFO DTMF
Unaffected (signaling channel)
Unaffected (signaling channel)
Important VOS3000 Transcoding DTMF Notes and Edge Cases
The VOS3000 Transcode Module documentation (Section 2.6, Page 6) includes several important notes about DTMF behavior during transcoding that are critical for avoiding common problems. These edge cases frequently cause confusion and support issues, so understanding them thoroughly is essential.
Dual DTMF Method Handling
According to the VOS3000 Transcode Module documentation, “When the far-end sends both SIP INFO and RFC2833, VOS will only recognize the first detected key press type.” This means that if a device sends DTMF using both SIP INFO and RFC2833 simultaneously (which some devices do), VOS3000 locks onto whichever method it detects first and ignores the other for the remainder of that call. This first-detected-type locking mechanism prevents duplicate DTMF digits but can cause issues if the far-end switches DTMF methods mid-call.
Inband to SIP INFO/RFC2833 Conversion
The VOS3000 Transcode Module documentation states: “If Inband is received but far-end uses SIP INFO/RFC2833, VOS can only identify and pass through, then send additional SIP INFO/RFC2833.” This means VOS3000 can detect Inband DTMF in the incoming RTP stream and then generate the corresponding SIP INFO or RFC2833 DTMF on the outgoing side. However, this conversion requires media proxy to be enabled and is not 100% reliable because Inband DTMF detection depends on audio quality and codec type.
RFC2833/SIP INFO to Inband Conversion
When the situation is reversed, the VOS3000 Transcode Module documentation explains: “If peer sends RFC2833/SIP INFO but far-end uses Inband, the RFC2833/SIP INFO is discarded and converted to Inband.” VOS3000 discards the incoming RFC2833 or SIP INFO DTMF and instead generates Inband DTMF tones in the outgoing RTP audio stream. This conversion is less common but may be necessary when connecting to legacy PBX systems or analog gateways that only understand Inband DTMF.
Key Range and Payload Control with Media Proxy
As stated in the VOS3000 Transcode Module documentation, “With media proxy on: RFC2833 payload and 0-16 key support terminated by VOS, VOS sends configured DTMF values.” This means VOS3000 takes full control of the RFC2833 parameters on both sides of the transcoded call. The payload type number and the supported key range (0-16) advertised in the SDP are determined by VOS3000’s configuration, not by what the original endpoint offered. This ensures consistency and prevents payload type mismatches that could cause DTMF failures.
These DTMF edge cases highlight the importance of understanding VOS3000 transcoding behavior in detail. The key takeaways are: (1) VOS3000 locks to the first detected DTMF type when multiple methods are received simultaneously; (2) Inband to SIP INFO/RFC2833 conversion is partial and may not be fully reliable; (3) RFC2833/SIP INFO to Inband conversion is full and reliable with media proxy; (4) With media proxy on, VOS3000 has full control over RFC2833 payload type and key range; (5) Without media proxy, RFC2833 passthrough is the only option and transcoding is not possible.
This section provides a complete, step-by-step walkthrough for configuring VOS3000 transcoding in a real-world scenario. The example uses the most common transcoding situation: a customer who only supports G711 (PCMA) connecting through a vendor that only accepts G729.
Prerequisites for VOS3000 Transcoding
Before configuring VOS3000 transcoding, ensure the following prerequisites are met:
VOS3000 transcode module is installed: The transcode module must be installed and licensed on your VOS3000 server. Without it, codec conversion options will not be available in the gateway configuration
Media proxy is enabled: VOS3000 transcoding requires media proxy to intercept and process the RTP media stream. Verify that media proxy is set to “Auto” or “On” on both the mapping gateway and routing gateway
Sufficient server CPU capacity: Each transcoded call consumes more CPU than a pass-through call. Monitor your server’s CPU utilization and ensure you have headroom for the expected number of concurrent transcoded calls
Proper DTMF configuration: If your calls involve IVR or DTMF-dependent features, configure DTMF settings correctly on both gateways before enabling transcoding
Step 1: Configure Mapping Gateway Codec for VOS3000 Transcoding
Access the mapping gateway configuration for the customer who will be sending calls:
Navigate to Business Management > Mapping Gateway
Double-click the target mapping gateway
Click the Additional Settings tab
Select the Codec sub-tab
Under the SIP section:
Set codec mode to “Softswitch specified”
Select PCMA as the softswitch specified codec
Check “Allow codec conversion”
Set media proxy to Auto or On
Click Save
Step 2: Configure Routing Gateway Codec for VOS3000 Transcoding
Access the routing gateway configuration for the vendor who will be receiving calls:
Navigate to Business Management > Routing Gateway
Double-click the target routing gateway
Click the Additional Settings tab
Select the Codec sub-tab
Under the SIP section:
Set codec mode to “Softswitch specified”
Select G729 as the softswitch specified codec
Set G729 negotiation mode to Auto
Check “Allow codec conversion”
Set media proxy to Auto or On
Click Save
Step 3: Configure DTMF for VOS3000 Transcoding
On both the mapping gateway and routing gateway, configure the DTMF settings to ensure DTMF works correctly during transcoding:
In the same Additional Settings tab, select the Protocol sub-tab (or DTMF sub-tab depending on your VOS3000 version)
Set DTMF receive to All (accepts all DTMF methods)
Set DTMF send (SIP) to Auto or RFC2833
Set RFC2833 Payload to 101 (default)
Uncheck “Use peer RFC2833 ability” if you want VOS3000 to always advertise RFC2833 regardless of the peer’s capability (recommended for transcoding)
Click Save
Step 4: Test VOS3000 Transcoding
After completing the configuration, test the transcoding with actual calls:
Use a SIP softphone configured with only PCMA codec to place a test call
The call should route through the mapping gateway (PCMA side) to the routing gateway (G729 side)
Verify two-way audio by speaking and confirming the other party can hear you
Test DTMF by pressing keypad buttons during the call and verifying they are received on the far end
Check the VOS3000 Current Call view to verify that the caller is using PCMA and the callee is using G729
Review CDR records after the call to confirm the codec information is recorded correctly
VOS3000 transcoding problems typically manifest as no audio, one-way audio, or DTMF failures. This section covers the most common issues and their solutions.
Issue 1: No Audio After Enabling VOS3000 Transcoding
If you enable VOS3000 transcoding but calls have no audio at all, the most common causes are:
Media proxy not enabled: VOS3000 transcoding requires media proxy to be active. Check that both the mapping gateway and routing gateway have media proxy set to “Auto” or “On”
Transcode module not installed: Without the transcode module installed and licensed, VOS3000 cannot perform codec conversion even if the settings are configured. Verify the transcode module is active in your VOS3000 installation
Firewall blocking RTP: Check that your server’s firewall allows RTP traffic on the configured media port range. For firewall configuration guidance, see our VOS3000 extended firewall configuration guide
Incorrect codec selection: Verify that the “Softswitch specified codec” on each gateway matches a codec that the endpoint actually supports. If you specify G729 on the mapping gateway but the customer’s SIP phone does not support G729, the call will fail
Issue 2: One-Way Audio with VOS3000 Transcoding
One-way audio during VOS3000 transcoding means that one party can hear the other but not vice versa. This typically indicates an asymmetric configuration issue:
Codec conversion only enabled on one side: If “Allow codec conversion” is checked on the mapping gateway but not the routing gateway, transcoding may only work in one direction. Ensure both sides have “Allow codec conversion” checked
NAT/routing issue on one side: The RTP stream from VOS3000 to one endpoint may be blocked by a NAT or firewall. This is not a transcoding issue but a network issue that must be resolved separately
Asymmetric media proxy: If media proxy is enabled on one gateway but not the other, the RTP path may be incomplete. Enable media proxy on both gateways for VOS3000 transcoding
Issue 3: DTMF Not Working During VOS3000 Transcoding
DTMF failures during transcoded calls are common and usually caused by DTMF method mismatches or incorrect payload configuration:
Inband DTMF with G729: If the DTMF method is set to Inband but the transcoded call uses G729 on one side, DTMF tones will be distorted by the codec compression. Switch to RFC2833 or SIP INFO for reliable DTMF during VOS3000 transcoding
Payload mismatch: If the RFC2833 payload value configured in VOS3000 does not match what the endpoint expects, DTMF events will not be recognized. Verify the payload value matches the SDP negotiation
“Use peer RFC2833 ability” misconfigured: If this setting is checked and the peer does not advertise RFC2833 support, VOS3000 will not advertise RFC2833 to the other side, causing DTMF to fail. Try unchecking this option so VOS3000 always advertises RFC2833
Media proxy disabled or transcode module not installed
Enable media proxy; verify transcode module
One-way audio
Asymmetric codec conversion or NAT issue
Check “Allow codec conversion” on both sides; verify RTP routing
DTMF not working
Inband DTMF with G729, or payload mismatch
Use RFC2833; match payload value with SDP
Call fails immediately
Softswitch specified codec not supported by endpoint
Use a codec that the endpoint supports
Poor voice quality
High CPU utilization from too many transcoded calls
Reduce concurrent transcoded calls or upgrade server
G729 negotiation failure
G729 variant mismatch (G729 vs G729a)
Try G729&G729a negotiation mode
Best Practices for VOS3000 Transcoding Configuration
Following these best practices will help you configure VOS3000 transcoding correctly and avoid common problems that affect call quality and reliability.
1. Minimize Transcoding When Possible
VOS3000 transcoding consumes significant server CPU resources and introduces a small amount of latency and potential voice quality degradation. Always prefer direct codec passthrough when both endpoints share a common codec. Only enable VOS3000 transcoding when there is a genuine codec incompatibility that prevents calls from connecting. Use Auto negotiation as the default codec mode, and switch to Softswitch specified with Allow codec conversion only when you need to force different codecs on each side.
2. Use RFC2833 for DTMF with VOS3000 Transcoding
RFC2833 is the most reliable DTMF method for VOS3000 transcoding because it is carried in separate RTP packets that VOS3000 can terminate and regenerate without quality loss. SIP INFO is also reliable since it travels in the signaling channel, but it may not be supported by all devices. Avoid Inband DTMF with transcoded calls because codec compression distorts the DTMF tones, especially with G729.
3. Monitor CPU Utilization
VOS3000 transcoding is CPU-intensive. Monitor your server’s CPU utilization regularly, especially during peak call volumes. If CPU utilization consistently exceeds 70-80%, consider upgrading your server hardware or reducing the number of concurrent transcoded calls. Use the VOS3000 system monitoring tools to track resource usage in real time.
4. Configure G729 Negotiation Mode Correctly
For maximum compatibility with diverse gateways and SIP devices, use the Auto G729 negotiation mode. If you encounter G729-specific negotiation failures, switch to G729&G729a mode to offer both variants. Only use the strict G729 or G729a modes when you have a specific reason to force one variant.
5. Always Enable Media Proxy for VOS3000 Transcoding
VOS3000 transcoding cannot function without media proxy. Always verify that media proxy is set to Auto or On on both the mapping gateway and routing gateway before enabling codec conversion. If media proxy is set to Off, VOS3000 will not intercept the RTP stream and cannot perform codec conversion.
6. Test After Every Configuration Change
Always test with actual calls after making any VOS3000 transcoding configuration change. Verify two-way audio, DTMF functionality, and call completion. Use the Current Call view to confirm that the correct codecs are being used on each side. For testing methodology, see our VOS3000 call testing guide.
By following these six best practices — minimizing unnecessary transcoding, using RFC2833 for DTMF, monitoring CPU utilization, configuring the correct G729 negotiation mode, always enabling media proxy, and testing after every change — you can ensure that your VOS3000 transcoding deployment delivers reliable, high-quality voice calls while efficiently utilizing your server resources.
VOS3000 Transcoding vs No Transcoding: Decision Guide
Not every VOS3000 deployment needs transcoding. In some cases, enabling VOS3000 transcoding unnecessarily can waste server resources and introduce quality issues. Use this decision guide to determine whether VOS3000 transcoding is needed for your deployment.
When VOS3000 Transcoding Is Required
Your customers and vendors have no common codecs (e.g., customer only G711, vendor only G729)
You need to optimize bandwidth by using G729 on one side while keeping G711 on the other
You are interconnecting networks with different codec requirements
You need to force a specific codec on a gateway for compatibility reasons
You are connecting legacy SIP devices that only support G711 to modern G729-based networks
When VOS3000 Transcoding Is Not Required
All your customers and vendors share common codecs (Auto negotiation will select the best match)
You have low server CPU capacity and cannot afford the overhead of transcoding
Your traffic volume is high enough that transcoding CPU cost would be prohibitive
Both endpoints can natively agree on a codec without softswitch intervention
In summary: if your customers and vendors share common codecs, use Auto negotiation without transcoding. If they have no common codecs (e.g., customer G711 only, vendor G729 only), enable Softswitch specified with Allow codec conversion. For bandwidth optimization, force G729 on the WAN side and G711 on the LAN side. For G723 to G729 scenarios, use Softswitch G723 on the gateway side and G729 on the vendor side.
Frequently Asked Questions About VOS3000 Transcoding
❓ What is VOS3000 transcoding and when do I need it?
VOS3000 transcoding is the real-time conversion of voice media streams between different codecs (e.g., PCMA to G729). You need it when your caller and callee have incompatible codecs — for example, when a customer only supports G711 but your termination vendor only accepts G729. Without transcoding, these calls would fail due to codec mismatch. According to the VOS3000 Transcode Module documentation (Section 1.1), “When caller and callee voice codecs are incompatible, transcoding function can be used to make them compatible.”
❓ Where do I configure VOS3000 transcoding codec settings?
VOS3000 transcoding codec settings are located in the Additional Settings > Codec section of both mapping gateways and routing gateways. Navigate to Business Management > Routing Gateway/Mapping Gateway > Additional Settings > Codec, as documented in the VOS3000 Transcode Module documentation (Section 1.2, Page 1) and the VOS3000 Manual Section 2.5.1.1 (Pages 32, 47). You must configure both the mapping gateway (caller side) and routing gateway (callee side) for transcoding to work correctly.
❓ Does VOS3000 transcoding work without media proxy?
No. VOS3000 transcoding requires media proxy to be enabled because the softswitch must intercept the RTP media stream to decode and re-encode the audio in a different codec. Without media proxy, RTP flows directly between endpoints and VOS3000 cannot perform codec conversion. Always set media proxy to Auto or On on both gateways when enabling VOS3000 transcoding.
❓ What is the difference between Softswitch specified and Auto negotiation?
Auto negotiation allows endpoints to negotiate a common codec through the standard SDP offer/answer mechanism, with no transcoding needed if both sides share a codec. Softswitch specified forces VOS3000 to use a specific codec on each gateway side, regardless of what the endpoints offer. When you use Softswitch specified with different codecs on each side, VOS3000 transcoding is activated to bridge the codec gap. Use Auto negotiation when both sides share common codecs, and Softswitch specified when they do not.
❓ How does DTMF work during VOS3000 transcoding?
During VOS3000 transcoding with media proxy enabled, VOS3000 terminates all incoming DTMF signals (RFC2833, SIP INFO, or Inband) from one side and regenerates them on the other side according to the DTMF send settings configured for that gateway. RFC2833 is the recommended DTMF method for transcoded calls because VOS3000 can reliably terminate and regenerate the telephone-event packets. Inband DTMF should be avoided with G729 transcoding because codec compression distorts the DTMF tones.
❓ Why is my G729 transcoded call failing with a codec error?
G729 codec errors during VOS3000 transcoding are usually caused by G729 variant mismatches. Some devices only accept G729 while others only accept G729a, even though they are largely compatible. Try changing the G729 negotiation mode on the routing gateway to “G729&G729a” which offers both variants in the SDP, giving the remote endpoint the choice. If that does not resolve the issue, check that the vendor actually supports G729 and that the transcode module is properly installed and licensed.
❓ How much CPU does VOS3000 transcoding use?
VOS3000 transcoding is CPU-intensive, with each transcoded call consuming significantly more CPU than a pass-through call. The exact CPU usage depends on the codecs involved and the server hardware. G729 transcoding is more CPU-intensive than G711-to-G711 transcoding. Monitor your server’s CPU utilization during peak hours and ensure you have sufficient capacity. If CPU exceeds 80%, consider upgrading your server or reducing the number of concurrent transcoded calls. For load testing, see our VOS3000 concurrent call load test guide.
❓ Can I get professional help configuring VOS3000 transcoding?
Absolutely. Our VOS3000 specialists have extensive experience configuring transcoding for VoIP deployments of all sizes. We can help you determine when transcoding is needed, configure codec conversion on both mapping and routing gateways, optimize DTMF settings for transcoded calls, and troubleshoot any transcoding issues. Contact us on WhatsApp at +8801911119966 for expert assistance with your VOS3000 transcoding configuration.
Get Expert Help with VOS3000 Transcoding Configuration
VOS3000 transcoding is a powerful feature that enables your VoIP platform to interconnect diverse networks and endpoints, but it must be configured correctly to deliver reliable call quality. Misconfigured transcoding can cause no audio, one-way audio, DTMF failures, and excessive CPU load — all of which directly impact your customers’ experience and your business revenue.
Whether you are setting up VOS3000 transcoding for the first time, troubleshooting an existing configuration, or planning a large-scale deployment with multiple codec conversions, our team can help. We provide complete VOS3000 transcoding configuration services including codec analysis, gateway configuration, DTMF optimization, and performance tuning.
📱 Contact us on WhatsApp: +8801911119966
Our VOS3000 experts are available to help you configure transcoding for any scenario — from simple PCMA to G729 conversion to complex multi-codec deployments. We can also assist with server capacity planning to ensure your hardware can handle the transcoding load. For faster troubleshooting of any VOS3000 issue, see our VOS3000 easy troubleshoot guide.
📞 Need Professional VOS3000 Setup Support?
For professional VOS3000 installations and deployment, VOS3000 Server Rental Solution:
Welcome to the ultimate guide on VOS3000 agent account configuration and reseller authorization management. If you’re running a VoIP wholesale or retail business using VOS3000, understanding how agent accounts work is absolutely critical for scaling your operations, delegating responsibilities, and building a profitable multi-level reseller network.
The VOS3000 agent account system is one of the most powerful features in the VOS3000 softswitch platform. It allows administrators to create hierarchical account structures where parent accounts (agents) can manage their own sub-accounts, handle payments, configure gateways, and even create sub-agents — all without needing direct admin intervention for every task.
In this comprehensive guide, we’ll walk through every aspect of the VOS3000 agent account system — from basic setup to advanced authorization management, sub-account filtering, number section limitations, and real-world deployment scenarios. Whether you’re a system administrator, a VoIP operator, or a reseller yourself, this guide has everything you need.
A VOS3000 agent account is a specialized account type within the VOS3000 softswitch that has the authority to manage other accounts beneath it — known as sub-accounts. Unlike ordinary accounts that simply originate or terminate calls, an agent account acts as a managerial entity that can create, modify, delete, and control its subordinate accounts.
According to the VOS3000 User Manual (Section 2.4.3, Page 22):
“Agent accounts differ from ordinary accounts in that there are accounts belonging to agent accounts. Once an account becomes an agent account, it will appear in the navigation tree.”
This means that the moment an account has sub-accounts assigned to it, VOS3000 automatically recognizes it as an agent account. The system then provides additional management capabilities and UI elements (like the navigation tree entry) that are not available for ordinary accounts.
💡 Why VOS3000 Agent Accounts Matter for Your Business
In the VoIP industry, the VOS3000 agent account system is the backbone of reseller operations. Here’s why it matters:
🔑 Delegation of Control: System admins don’t need to manage every single end-user account. Agent accounts can handle their own sub-account management.
💰 Revenue Distribution: Each agent manages their own payment collection, making multi-level billing seamless.
📊 Scalability: As your business grows from 10 customers to 10,000, the agent hierarchy keeps everything organized.
🛡️ Security: Agent accounts can only manipulate their own sub-accounts, ensuring data isolation and security.
⚡ Efficiency: Agents can perform routine operations (adding phones, making payments) without waiting for admin approval.
The VOS3000 agent account system is specifically designed to “facilitate agent development” (VOS3000 Manual, Section 2.4.5, Page 24), meaning it provides the tools resellers need to grow their business independently while the platform maintains overall control.
⚖️ Agent Account vs. Ordinary Account: Key Differences
Understanding the distinction between ordinary and agent accounts in VOS3000 is fundamental to proper system configuration. Let’s examine the critical differences:
🔄 Feature
👤 Ordinary Account
🏢 VOS3000 Agent Account
Sub-Accounts
❌ Cannot have sub-accounts
✅ Can manage sub-accounts
Navigation Tree
❌ Not visible in navigation tree
✅ Appears in navigation tree
Account Management
❌ Cannot add/modify/delete accounts
✅ Can manage sub-accounts (with authorization)
Payment Control
❌ No payment authority
✅ Can process payments for sub-accounts
Gateway Management
❌ No gateway access
✅ Can add/modify gateways (with authorization)
Phone Card Operations
❌ Cannot manage phone cards
✅ Can add/delete/modify phone cards
Account Category
“Account” (non-editable)
“Agent” (non-editable)
Scope of Control
Own account only
Own account + all sub-accounts
As shown in the table above, the VOS3000 agent account transforms a simple calling account into a management powerhouse. The key insight from the VOS3000 manual (Section 2.4.2, Page 16) is that the account category field is non-editable — it’s automatically determined by the system based on whether the account has sub-accounts or not.
⚙️ How VOS3000 Agent Accounts Work
The VOS3000 agent account system operates on a hierarchical principle. Let’s break down the core mechanics:
🔄 Automatic Agent Promotion
One of the most important concepts in VOS3000 is that agent status is automatically assigned. When you create an account and assign sub-accounts to it (by setting the Agent ID field on those sub-accounts), the parent account automatically becomes an agent account. The VOS3000 manual (Section 2.4.2, Page 16) states:
“When an account has sub accounts, it automatically becomes an agent.”
This means you don’t need to manually flip a switch to create an agent account — the system handles this dynamically based on the account relationships you establish.
🔗 The Agent ID Field
Every account in VOS3000 has an Agent ID field. This field specifies the parent account (the agent) to which this account belongs. Key rules:
📌 The Agent ID must reference an existing account in the system
📌 The parent account must exist before you can assign it as an Agent ID
📌 An account without an Agent ID is a top-level account (or a standalone account)
📌 When an account is created by an agent, it must be designated to an agent account (VOS3000 Manual, Section 2.4.5, Page 25)
The Agent ID relationship forms the backbone of the entire VOS3000 agent account hierarchy and determines the chain of command within your reseller network.
🛡️ Scope of Manipulation
A critical security feature of the VOS3000 agent account system is that an agent account can only manipulate its own sub-accounts (VOS3000 Manual, Section 2.4.5, Page 25). This means:
🔒 Agent A cannot see or modify Agent B’s sub-accounts
🔒 Each agent’s scope is strictly limited to their own hierarchy
🔒 Even sub-agents created by an agent fall under that agent’s control
🔒 Only system administrators have access to all accounts
This design ensures complete isolation between different resellers using the same VOS3000 platform — a fundamental requirement for multi-tenant VoIP operations.
📝 Step-by-Step: Creating a VOS3000 Agent Account
Creating a VOS3000 agent account involves several steps. Let’s walk through the complete process:
Step 1: Create the Parent Account
First, you need to create the account that will become the agent. Navigate to the Account Management section in VOS3000:
🖥️ Log in to VOS3000 with administrator credentials
📋 Navigate to Account Management (Section 2.4.2, Page 16)
➕ Click Add to create a new account
📝 Fill in the required account details
💾 Save the account
Step 2: Assign Sub-Accounts to the Agent
To transform the ordinary account into a VOS3000 agent account, you need to assign sub-accounts:
👤 Create a new account (or edit an existing one)
🔗 In the Agent ID field, enter the account ID of the parent account
✅ The parent account must already exist in the system
💾 Save the sub-account
🔄 The parent account automatically becomes an agent account
Step 3: Verify Agent Account Status
After assigning sub-accounts, verify that the account has been promoted to agent status:
🔍 Check the Account Category field — it should now display “Agent”
🌲 Look for the account in the navigation tree — it should now appear there
📂 Double-click the agent account to open the Sub Account Management interface
Step 4: Configure Authorizations
Now configure what operations the VOS3000 agent account can perform. This is covered in detail in the Authorization Management section below.
The complete workflow can be summarized in this configuration checklist:
🔢 Step
📋 Action
✅ Verification
1
Create parent account
Account appears in account list
2
Create sub-account with Agent ID
Agent ID field populated correctly
3
Verify agent promotion
Category shows “Agent”, appears in navigation tree
4
Configure authorizations
Permissions enabled as needed
5
Set number section limitations
Prefix restrictions applied
6
Test agent operations
Agent can perform authorized tasks
📂 Sub-Account Management in VOS3000
Once an account becomes a VOS3000 agent account, it gains access to the Sub-Account Management interface. This is where agents can view, manage, and control all accounts under their jurisdiction.
🔑 Accessing Sub-Account Management
According to the VOS3000 manual (Section 2.4.3, Page 22):
“Double-click the agent account to open ‘Sub account management’.”
This simple action opens a dedicated management interface for that specific agent’s sub-accounts. From here, the agent can perform all authorized operations on their sub-accounts.
🔍 Direct vs. All Sub-Account Filter
The Sub-Account Management interface provides two important filter options (VOS3000 Manual, Section 2.4.3, Page 22):
🔎 Filter
📋 Description
📌 Use Case
Direct
Shows only the immediate (first-level) sub-accounts
Quick view of directly managed accounts
All
Shows all sub-accounts including sub-sub-accounts (nested)
Complete hierarchical view of entire agent tree
The distinction between “Direct” and “All” is especially important in multi-level reseller scenarios. When an agent creates a sub-agent (who in turn has their own sub-accounts), the “Direct” filter shows only the immediate children, while “All” reveals the entire hierarchy beneath that agent.
⚡ Sub-Account Operations
From the Sub-Account Management interface, authorized agents can perform the following operations on their sub-accounts:
➕ Add new sub-accounts — Create new customer or sub-agent accounts
✏️ Modify sub-accounts — Update account settings, rates, and configurations
🗑️ Delete sub-accounts — Remove accounts that are no longer needed
📞 Add/delete/modify phones — Manage phone numbers for sub-accounts
💰 Process payments — Add credit/balance for sub-accounts
Each of these operations requires the corresponding authorization to be enabled for the VOS3000 agent account, which we’ll cover in the next section.
🔐 VOS3000 Agent Authorization Management
Authorization management is the heart of the VOS3000 agent account system. It determines exactly what operations an agent can and cannot perform. The VOS3000 manual (Section 2.4.5, Pages 24-25) provides a comprehensive list of authorizations that can be granted to agent accounts.
🛡️ Why Authorization Management Matters
Proper authorization configuration is essential because:
🔒 Security: Prevents unauthorized operations that could disrupt service or cause financial loss
🎯 Role-Based Access: Different agents may need different levels of control based on their business role
📈 Business Control: Administrators can limit what agents can do to maintain oversight
⚖️ Compliance: Ensures agents operate within the boundaries defined by the platform operator
🔄 Flexibility: Authorization can be adjusted as business relationships evolve
As stated in the VOS3000 manual (Section 2.4.5, Page 24):
“This function facilitates agent development. Agent user can have agent-typed account in system. Admins can create accounts limiting rights.”
This means the system administrator retains ultimate control — they decide which authorizations each VOS3000 agent account receives, enabling a fine-grained approach to permission management.
📋 Complete Authorization List
The following table lists all available authorizations for VOS3000 agent accounts as documented in the VOS3000 User Manual (Section 2.4.5, Pages 24-25):
🔢 #
🔐 Authorization
📋 Description
⚠️ Risk Level
1
Add/delete/modify account
Create new sub-accounts, remove existing ones, or modify account details
🔴 High
2
Add/delete/modify phone
Manage phone number assignments for sub-accounts
🟡 Medium
3
Add/delete/modify phone card
Manage calling card configurations for prepaid services
🟡 Medium
4
Add/delete gateway
Create or remove SIP gateways/trunk endpoints
🔴 High
5
Modify gateway information
Update gateway settings such as IP, port, codec, and protocol
🔴 High
6
Modify gateway capacity
Adjust concurrent call capacity limits on gateways
🟡 Medium
7
Payment for this account
Process payments/credit top-ups for the agent’s own account
🔴 High
8
Payment for sub accounts
Process payments/credit top-ups for all sub-accounts
🔴 High
Each authorization can be independently enabled or disabled for each VOS3000 agent account, giving administrators precise control over what each agent can do.
🔍 Detailed Breakdown of Authorization Types
Let’s examine each authorization type in detail to understand exactly what they enable and when you should grant them.
1️⃣ Add/Delete/Modify Account Authorization
This is the most fundamental authorization for a VOS3000 agent account. It allows the agent to:
➕ Add: Create new sub-accounts under the agent’s hierarchy
🗑️ Delete: Remove existing sub-accounts that are no longer needed
✏️ Modify: Edit sub-account settings including rates, codecs, prefixes, and more
When to grant: This authorization should be granted to any agent who needs to manage their own customer base. Without this, the agent cannot independently onboard new customers or modify existing ones.
Important note: As stated in the VOS3000 manual (Section 2.4.5, Page 25):
“Accounts created by agent must be designated to an agent account.”
This means every account created by an agent is automatically linked back to that agent — they cannot create “orphan” accounts that exist outside the agent hierarchy.
2️⃣ Add/Delete/Modify Phone Authorization
This authorization allows the VOS3000 agent account to manage phone numbers for sub-accounts:
📞 Add: Assign new phone numbers to sub-accounts
🗑️ Delete: Remove phone numbers from sub-accounts
✏️ Modify: Update phone number settings and configurations
When to grant: Essential for agents who manage DID numbers or need to assign specific caller IDs to their sub-accounts. Particularly important for retail VoIP resellers.
3️⃣ Add/Delete/Modify Phone Card Authorization
Phone card management is crucial for prepaid calling card businesses:
💳 Add: Create new calling card batches
🗑️ Delete: Remove calling card configurations
✏️ Modify: Update calling card rates and settings
When to grant: Only for agents who specifically operate calling card services. This authorization should be withheld from agents who don’t need calling card functionality.
4️⃣ Add/Delete Gateway Authorization
Gateway management is one of the highest-risk authorizations:
🌐 Add: Create new SIP gateways or trunk endpoints for sub-accounts
🗑️ Delete: Remove existing gateway configurations
When to grant: Only for trusted agents who need to configure their own SIP trunks or gateway endpoints. Most resellers do not need this authorization — the administrator typically manages gateway configurations centrally.
This authorization allows updating existing gateway settings:
🔧 IP Address: Change the gateway IP address
🔌 Port: Modify the SIP signaling port
🎵 Codec: Update the supported codec list
📡 Protocol: Change SIP protocol settings
📝 Prefix: Modify dial prefix configurations
When to grant: For agents who manage their own SIP infrastructure and need to update gateway parameters when their network changes. This is a high-risk authorization that should be carefully controlled.
6️⃣ Modify Gateway Capacity Authorization
This authorization controls the ability to adjust gateway concurrent call limits:
📊 Increase capacity: Allow more simultaneous calls through a gateway
📉 Decrease capacity: Reduce the number of simultaneous calls
When to grant: Useful for agents who need to manage their own bandwidth allocation. For instance, a reseller might need to increase capacity during peak hours and reduce it during off-peak times.
7️⃣ Payment for This Account Authorization
This authorization allows the VOS3000 agent account to process payments (credit top-ups) for its own account:
💰 Add balance: Increase the account’s calling credit
📋 View payment history: Track all payment transactions
When to grant: This is typically granted to agents who operate on a prepaid model and need to manage their own balance. However, in most wholesale setups, the administrator manages top-ups centrally, so this authorization is often disabled.
8️⃣ Payment for Sub Accounts Authorization
This is perhaps the most business-critical authorization for resellers:
💰 Top up sub-accounts: Add credit to customer accounts
📊 Manage sub-account balances: Distribute credit across multiple sub-accounts
📋 Track payments: Monitor all payment activities in the sub-account hierarchy
When to grant: Essential for any VOS3000 agent account that operates as a reseller. Without this, the agent cannot manage their customers’ balances, which is a core reseller function.
The following authorization matrix shows recommended configurations for different agent types:
🔐 Authorization
🛒 Retail Reseller
🏭 Wholesale Agent
💳 Calling Card Agent
🌐 SIP Trunk Provider
Add/delete/modify account
✅
✅
✅
✅
Add/delete/modify phone
✅
❌
❌
✅
Add/delete/modify phone card
❌
❌
✅
❌
Add/delete gateway
❌
✅
❌
✅
Modify gateway information
❌
✅
❌
✅
Modify gateway capacity
❌
✅
❌
✅
Payment for this account
✅
❌
✅
✅
Payment for sub accounts
✅
✅
✅
✅
📵 Number Section Limitation for Agent Accounts
The Number Section Limitation feature (VOS3000 Manual, Section 2.4.6, Page 26) allows administrators to restrict the phone number prefixes that a VOS3000 agent account (and its sub-accounts) can use. This is a powerful tool for controlling call routing and preventing unauthorized destination access.
🔧 How Number Section Limitation Works
Number Section Limitation works by defining allowed or blocked phone number prefixes for specific accounts:
📱 Prefix-based filtering: Controls which number prefixes (e.g., country codes, area codes) the account can dial
🔄 Inherited by sub-accounts: Sub-accounts inherit the limitations of their parent agent account
🛡️ Security layer: Prevents agents from routing calls to unauthorized or expensive destinations
📊 Business control: Allows platform operators to segment destination access by agent tier
The VOS3000 agent account system supports two CTD (Call Type Definition) billing models, as documented in the VOS3000 manual (Section 2.4.2, Page 16):
📊 Standard CTD Billing Model
The Standard billing model is the default and most commonly used model in VOS3000:
📞 Per-minute billing: Calls are billed based on duration
🔄 Rating by destination: Different rates apply to different destinations
💰 Prepaid/Postpaid: Supports both payment models
📋 CDR-based: All billing is calculated from Call Detail Records
🔄 Flow CTD Billing Model
The Flow billing model is specifically designed for callback business operations (VOS3000 Manual, Section 2.4.2, Page 16):
📲 Callback-oriented: Designed for callback service providers
🔗 Two-leg billing: Handles the unique billing requirements of callback calls
🌐 DID integration: Works with DID-based callback triggers
📊 Specialized CDR processing: Different CDR handling for callback scenarios
📋 Feature
📊 Standard Model
🔄 Flow Model
Primary Use Case
Standard VoIP calling
Callback business
Billing Method
Per-minute by destination
Two-leg callback billing
CDR Processing
Single CDR per call
Separate CDRs for each leg
Complexity
Simple
Moderate
Recommendation
Default choice for most deployments
Only for callback operations
When configuring a VOS3000 agent account, choose the Standard model unless you specifically operate a callback business. The Flow model introduces additional complexity that is unnecessary for standard wholesale or retail VoIP operations.
🏗️ Multi-Level Reseller Hierarchy
One of the most powerful aspects of the VOS3000 agent account system is the ability to create multi-level reseller hierarchies. The VOS3000 manual (Section 2.4.5, Page 25) confirms that “Agent can create sub-accounts for sub-agents”, enabling a tree-like organizational structure.
🌳 Understanding the Hierarchy Structure
In a VOS3000 deployment, the account hierarchy typically looks like this:
🏢 System Administrator (Admin)
├── 🏭 Master Agent (VOS3000 Agent Account - Level 1)
│ ├── 🛒 Sub-Agent A (VOS3000 Agent Account - Level 2)
│ │ ├── 👤 End Customer 1
│ │ ├── 👤 End Customer 2
│ │ └── 👤 End Customer 3
│ ├── 🛒 Sub-Agent B (VOS3000 Agent Account - Level 2)
│ │ ├── 👤 End Customer 4
│ │ └── 🛒 Sub-Sub-Agent (Level 3)
│ │ ├── 👤 End Customer 5
│ │ └── 👤 End Customer 6
│ └── 👤 Direct Customer 1
├── 🏭 Master Agent 2 (VOS3000 Agent Account - Level 1)
│ ├── 👤 Direct Customer 7
│ └── 👤 Direct Customer 8
└── 👤 Standalone Customer (No agent hierarchy)
📏 Key Hierarchy Rules
The VOS3000 agent account hierarchy follows strict rules that maintain order and security:
🔗 Agent ID Chain: Every account (except top-level) must have an Agent ID pointing to its parent
🔒 Scope Limitation: An agent can only manipulate accounts within its own hierarchy
📋 Authorization Inheritance: Sub-agents can only have authorizations that are a subset of their parent’s authorizations
📐 Mandatory Designation: Accounts created by agents must be designated to an agent account
🌲 Navigation Tree: Each agent account appears in the navigation tree with its sub-accounts organized beneath it
🌍 Real-World Hierarchy Example
Consider a VoIP operator based in Bangladesh who serves the South Asian market. Their VOS3000 agent account hierarchy might look like this:
🏢 Level
📋 Account Name
🔗 Agent ID
📋 Category
🔐 Key Authorizations
Admin
System Admin
N/A
Admin
All authorizations
Level 1
BD-Wholesale-Agent
Admin
Agent
All except gateway management
Level 2
Dhaka-Retail-Sub
BD-Wholesale-Agent
Agent
Account, Phone, Payment (sub)
Level 3
Customer-001
Dhaka-Retail-Sub
Account
N/A (end user)
This hierarchical structure enables each level to operate independently within their authorized scope while maintaining overall system integrity.
🌲 Agent Account Navigation Tree
A key visual indicator of a VOS3000 agent account is its appearance in the navigation tree. The VOS3000 manual (Section 2.4.3, Page 22) explicitly states that once an account becomes an agent, “it will appear in the navigation tree.”
🖥️ Navigation Tree Features
The navigation tree provides several important capabilities:
📂 Hierarchical View: Visual representation of the agent-sub-account relationship
🖱️ Quick Access: Double-click an agent account to open Sub-Account Management
🔍 Filter Options: Toggle between “Direct” and “All” views for sub-account display
📊 Real-time Updates: The tree updates dynamically as sub-accounts are added or removed
💡 Using the Navigation Tree Effectively
For administrators managing large numbers of VOS3000 agent accounts, the navigation tree is an essential tool. Here are some tips:
🏷️ Use descriptive account names: Name agent accounts clearly to identify them in the tree (e.g., “Agent-BD-Wholesale” instead of “A001”)
🔍 Use the “Direct” filter for quick access: When you only need to work with immediate sub-accounts, the “Direct” filter reduces visual clutter
🌐 Use “All” for audit purposes: When auditing an agent’s entire hierarchy, switch to “All” to see the complete sub-account tree
📐 Keep hierarchy depth reasonable: While VOS3000 supports multi-level hierarchies, keeping it to 2-3 levels makes the navigation tree more manageable
✅ Best Practices for VOS3000 Agent Account Management
Based on extensive experience with VOS3000 deployments, here are the best practices for managing VOS3000 agent accounts effectively:
🛡️ Security Best Practices
🔐 Principle of Least Privilege: Only grant the minimum authorizations an agent needs to perform their business functions. Don’t give gateway management access to retail resellers.
🔒 Regular Authorization Audits: Periodically review agent authorizations to ensure they still align with business needs. Remove any authorizations that are no longer required.
📱 Apply Number Section Limitations: Always configure prefix restrictions for agents to prevent unauthorized destination routing.
📊 Monitor Payment Activities: Keep a close eye on payment authorizations, especially for high-volume agents. Consider disabling “Payment for this account” for agents who should only process sub-account payments.
🔄 Use Strong Passwords: Ensure all agent accounts use strong, unique passwords and change them regularly.
⚙️ Operational Best Practices
📋 Document Your Hierarchy: Maintain a clear diagram of your agent hierarchy. This helps with troubleshooting and onboarding new team members.
🏷️ Naming Conventions: Use consistent naming conventions for agent accounts. For example: “[Region]-[Type]-[Name]” like “BD-Wholesale-AcmeTel”.
📊 Regular Balance Reviews: Monitor agent account balances to ensure they have sufficient credit for their operations. Set up alerts for low-balance situations.
🔄 Test Before Deployment: Always test new agent configurations in a non-production environment before deploying to your live system.
📋 Backup Configurations: Regularly backup your VOS3000 configuration, including agent account settings and authorizations.
💰 Business Best Practices
📈 Tier-Based Authorization: Create different authorization profiles for different agent tiers (e.g., Silver, Gold, Platinum) with progressively more capabilities.
🔄 Sub-Agent Approval Process: Implement an approval process before allowing agents to create sub-agents, preventing uncontrolled hierarchy growth.
🛡️ Prepaid Vendor Routing: Configure call routing to only pass calls to vendors with positive balance. Learn more in our article on prepaid vendor call routing in VOS3000.
⚠️ Common Mistakes and How to Avoid Them
When working with VOS3000 agent accounts, administrators often make these common mistakes:
❌ Mistake 1: Granting All Authorizations by Default
One of the most dangerous mistakes is giving every agent all available authorizations. This creates unnecessary security risks and can lead to accidental misconfigurations.
Solution: Follow the principle of least privilege. Start with minimal authorizations and add more only when there’s a documented business need.
❌ Mistake 2: Not Using Number Section Limitations
Without Number Section Limitations, agents can route calls to any destination, potentially resulting in unexpected costs or fraud.
Solution: Always configure Number Section Limitations for every VOS3000 agent account. Review and update them regularly. For fraud prevention, also consider the VOS3000 extended firewall configuration.
❌ Mistake 3: Creating Overly Deep Hierarchies
While VOS3000 supports multi-level agent hierarchies, creating too many levels makes management complex and can impact system performance.
Solution: Limit your hierarchy to 2-3 levels. If you need more levels, consider flattening the structure by creating separate top-level agents instead.
❌ Mistake 4: Ignoring the “Direct” vs. “All” Filter
Many administrators don’t realize the importance of the “Direct” and “All” filter in Sub-Account Management. Using the wrong filter can lead to confusion about the scope of an agent’s hierarchy.
Solution: Use “Direct” for day-to-day management and “All” for auditing and comprehensive reviews.
❌ Mistake 5: Not Setting Agent ID Correctly
Setting the wrong Agent ID can break the hierarchy chain and lead to accounts being managed by the wrong agent.
Solution: Always double-check the Agent ID field when creating sub-accounts. The parent account must exist before you can reference it as an Agent ID. Remember: “The Account id of its parent account. Parent account must exist” (VOS3000 Manual, Section 2.4.2, Page 16).
❌ Mistake 6: Choosing the Wrong CTD Billing Model
Selecting the Flow billing model when you’re not running a callback business introduces unnecessary complexity.
Solution: Use the Standard CTD billing model unless you specifically operate callback services.
🔧 Troubleshooting Agent Account Issues
When issues arise with your VOS3000 agent account setup, here are the most common problems and their solutions:
⚠️ Problem
🔍 Likely Cause
✅ Solution
Account doesn’t appear in navigation tree
Account has no sub-accounts assigned
Create at least one sub-account with this account as Agent ID
Agent cannot add sub-accounts
“Add/delete/modify account” authorization not granted
Enable the account management authorization in Authorization Management
Agent cannot process payments
Payment authorization not enabled
Enable “Payment for sub accounts” and/or “Payment for this account”
Sub-account shows wrong agent
Agent ID was set incorrectly during creation
Modify the sub-account and correct the Agent ID field
Agent can see other agents’ sub-accounts
System configuration issue
Verify account scope settings; agent should only manipulate its own sub-accounts
Account category won’t change to “Agent”
No sub-accounts assigned yet
Account category is auto-determined; assign sub-accounts to promote to Agent
Q1: How do I convert an ordinary account to a VOS3000 agent account?
A: You don’t need to manually convert an account. In VOS3000, agent status is automatically assigned when an account has sub-accounts. Simply create a sub-account and set its Agent ID to the ordinary account’s ID. The ordinary account will automatically become a VOS3000 agent account and appear in the navigation tree. As the manual states (Section 2.4.2, Page 16): “When an account has sub accounts, it automatically becomes an agent.”
Q2: Can a VOS3000 agent account create sub-agents (agents under agents)?
A: Yes! The VOS3000 manual (Section 2.4.5, Page 25) explicitly states that “Agent can create sub-accounts for sub-agents.” This means an agent can create sub-accounts that are themselves agents, building a multi-level reseller hierarchy. Each sub-agent can then manage their own set of sub-accounts, enabling complex business structures.
Q3: What happens if I delete a VOS3000 agent account that has sub-accounts?
A: Deleting a VOS3000 agent account that has active sub-accounts requires careful handling. You should first reassign or delete all sub-accounts before removing the parent agent account. Always check the “All” filter in Sub-Account Management to see the complete hierarchy before proceeding with deletion. It’s recommended to back up your configuration before making such changes.
Q4: Can I restrict an agent to only certain call destinations?
A: Absolutely. Use the Number Section Limitation feature (VOS3000 Manual, Section 2.4.6, Page 26) to restrict the phone prefixes that an agent’s sub-accounts can dial. This is essential for preventing agents from routing calls to expensive or unauthorized destinations. Each agent can have different prefix restrictions based on their business agreement.
Q5: What is the difference between “Direct” and “All” sub-account filters?
A: The “Direct” filter shows only the immediate (first-level) sub-accounts directly under the VOS3000 agent account. The “All” filter shows the entire hierarchy, including sub-sub-accounts and sub-agents’ sub-accounts. Use “Direct” for day-to-day management and “All” for comprehensive auditing. This feature is documented in Section 2.4.3, Page 22 of the VOS3000 manual.
Q6: Should I use the Standard or Flow CTD billing model for my agent account?
A: Use the Standard CTD billing model for regular VoIP calling (wholesale or retail). Use the Flow model only if you specifically operate a callback business. The Flow model is designed for two-leg callback billing scenarios and introduces unnecessary complexity for standard operations. The VOS3000 manual (Section 2.4.2, Page 16) confirms that the Flow model is specifically “for callback business.”
Q7: Can an agent account modify another agent’s sub-accounts?
A: No. A fundamental security principle of the VOS3000 agent account system is that “Agent account can only manipulate its sub accounts” (VOS3000 Manual, Section 2.4.5, Page 25). Agent A cannot see, modify, or interact with Agent B’s sub-accounts. This isolation ensures that different resellers on the same platform operate independently and securely.
Q8: How do I configure gateway access for a VOS3000 agent account?
A: Gateway access requires three authorizations to be enabled: “Add/delete gateway,” “Modify gateway information,” and “Modify gateway capacity.” Enable these authorizations only for agents who need to manage their own SIP infrastructure. For most retail resellers, gateway management should remain with the system administrator. Only grant gateway authorizations to trusted wholesale or SIP trunk provider agents.
📚 Related Resources
Expand your VOS3000 knowledge with these related guides from our blog:
Need help setting up your VOS3000 agent account system or configuring reseller authorization management? Our team of VOS3000 experts is ready to assist you with:
🔧 Agent Account Setup: Complete configuration of your agent hierarchy and authorization structure
🔐 Security Hardening: Implement best-practice authorization controls and number section limitations
📊 Billing Configuration: Set up CTD billing models and rate cards for your agent network
🛡️ Fraud Prevention: Configure firewall rules and monitoring to protect your platform
🔄 Migration Support: Migrate existing accounts to a proper agent hierarchy
Whether you’re setting up your first VOS3000 agent account or managing a complex multi-level reseller network, we’re here to help. Don’t let configuration challenges slow down your business — reach out today!
📖 This guide is based on the VOS3000 User Manual V2.1.9.07. All page references and feature descriptions are sourced from the official documentation. For the latest software updates, visit vos3000.com/downloads.php.
Published on multahost.com/blog — Your trusted source for VOS3000 tutorials, configuration guides, and VoIP business insights. Need expert help? Contact us on WhatsApp at +8801911119966.
📞 Need Professional VOS3000 Setup Support?
For professional VOS3000 installations and deployment, VOS3000 Server Rental Solution:
VOS3000 Web Manager: Complete Mobile and Web Interface Guide
Managing a VoIP softswitch used to mean being tied to a desktop computer with a dedicated client application installed. Those days are over. The VOS3000 Web Manager transforms how VoIP operators interact with their switch by providing a fully functional web-based interface accessible from any browser — including smartphones and tablets. Whether you are commuting, traveling, or simply away from your desk, the VOS3000 Web Manager ensures that critical switch data and management functions are always at your fingertips.
The VOS3000 Web Manager is not a stripped-down version of the desktop client. It is a purpose-built web portal designed to deliver the most essential monitoring and management capabilities in a responsive, mobile-friendly format. From real-time concurrency dashboards to customer and vendor management, from CDR lookups to alarm monitoring, the VOS3000 Web Manager covers every aspect of daily VoIP operations that matter most to operators on the move.
In this comprehensive guide, we will walk through every feature of the VOS3000 Web Manager as documented in the official VOS3000 Web Manager PDF (Sections 4.1 through 4.10). You will learn how to access the portal, navigate the dashboard, manage accounts, review call records, monitor system health, and much more. By the end of this article, you will have complete mastery of the VOS3000 Web Manager and be able to run your VoIP operations from virtually anywhere.
Table of Contents
What Is VOS 3000 Web Manager and Why It Matters
The VOS 3000 Web Manager is the built-in web interface component of the VOS3000 VoIP softswitch platform. It allows administrators and operators to access key switch functions through a standard web browser without requiring the VOS3000 desktop client. According to the VOS3000 Web Manager manual (Section 1.1), the web interface is designed to provide “convenient and efficient management of the VOS3000 system through a browser-based interface.”
For VoIP businesses that operate across time zones or have teams working remotely, the VOS3000 Web Manager is an indispensable tool. Instead of requiring every operator to install the Java-based desktop client on a Windows machine, the web manager enables instant access from any device with a browser. This includes iPhones, Android phones, iPads, MacBooks, Linux desktops, and Chromebooks. The implications for operational flexibility are enormous.
Consider a scenario where an alarm triggers at 2 AM. With the VOS3000 Web Manager, you do not need to rush to a computer with the desktop client installed. You can simply open your phone’s browser, log into the web manager, check the alarm details, review recent CDR, and take corrective action — all from the comfort of your bed. This level of accessibility is what makes the VOS3000 Web Manager a game-changer for VoIP operations.
Accessing the VOS3000 Web Manager is straightforward and requires no additional software installation. The web interface runs directly on the VOS3000 server and is accessible via a standard HTTP URL. According to the VOS3000 Web Manager manual (Section 4.1), the access format is simple and consistent across all VOS3000 deployments.
Access URL Format
The VOS3000 Web Manager is accessed using the following URL pattern:
http://YOUR_SERVER_IP:PORT/manage
For example, if your VOS3000 server IP address is 192.168.1.100 and the web manager port is 80, you would navigate to:
http://192.168.1.100:80/manage
Replace YOUR_SERVER_IP with the actual IP address of your VOS3000 server and PORT with the configured web service port. The default port may vary depending on your VOS3000 installation configuration. If you are unsure about the port, consult your system administrator or check the VOS3000 server configuration files.
Login Credentials
One of the most convenient aspects of the VOS3000 Web Manager is that it uses the exact same login credentials as the VOS3000 desktop client. There is no separate account setup required. As stated in the VOS3000 Web Manager manual (Section 4.1), “the web manager uses the same username and password as the VOS3000 client.” This means you can log in immediately with your existing operator or administrator credentials.
📱 Parameter
⚙️ Details
📝 Notes
Access URL
http://IP:PORT/manage
Replace IP and PORT with your server details
Username
Same as VOS3000 client
No separate account needed
Password
Same as VOS3000 client
Synchronized with desktop credentials
Protocol
HTTP
HTTPS if SSL configured on server
Browser Support
Chrome, Safari, Firefox, Edge
Mobile and desktop browsers supported
Mobile Access
iPhone, Android, iPad
Responsive design adapts to screen size
It is important to note that the VOS3000 Web Manager relies on the web service component running on the VOS3000 server. If the web service is not running, you will not be able to access the web manager. Ensure that the VOS3000 web service is started and listening on the correct port before attempting to access the web interface. You can verify this by checking the service status on your VOS3000 server.
VOS 3000 Web Manager Homepage Dashboard
Once you successfully log into the VOS3000 Web Manager, you are greeted by the homepage dashboard — a comprehensive overview of your VoIP system’s real-time status. The dashboard is the central hub of the VOS3 000 Web Manager and provides at-a-glance visibility into the most critical operational metrics. According to the VOS 3000 Web Manager manual (Section 4.2), the homepage displays several key data points that are essential for daily monitoring.
Real-Time Concurrency Monitoring
The first and most prominent metric on the VOS3000 Web Manager dashboard is real-time concurrency. This shows the number of simultaneous calls currently active on your VOS3000 system. Concurrency is a vital metric because it directly reflects the current load on your switch. If concurrency approaches your license limits or server capacity, you need to take action — either by upgrading your license, adding server resources, or optimizing routing.
The VOS3000 Web Manager updates the concurrency count in real-time, giving you an accurate snapshot of current call volume at any moment. This is particularly useful during peak traffic hours when you need to closely monitor system load. The real-time nature of this data means you can watch concurrency rise and fall as traffic patterns change throughout the day.
Online Statistics Overview
Beyond concurrency, the VOS 3000 Web Manager dashboard displays several critical online statistics. According to the VOSS 3000 Web Manager manual (Section 4.2), these include:
Online Phone: The number of phone endpoints currently registered and online on the system. This metric helps you understand how many customer devices are actively connected.
Online Mapping: The number of mapping gateways currently active. Mapping gateways are the SIP trunks or gateway connections that route calls through your VOS3000 system.
Online Routing: The number of routing gateways currently online and available for call routing. This tells you how many vendor paths are currently reachable.
These three statistics together paint a complete picture of your system’s connectivity health. If the number of online routing gateways drops unexpectedly, it could indicate network issues or vendor outages that need immediate attention. The VOS3000 Web Manager makes these metrics immediately visible, enabling rapid response to connectivity problems.
Today’s Financial Summary
One of the most valuable features of the VOS3000 Web Manager dashboard is the financial summary section. This area displays today’s key financial metrics at a glance, allowing operators to monitor business performance in real-time without generating separate reports. The financial metrics shown in the VOS3000 Web Manager include:
💰 Metric
📊 Description
🎯 Importance
Today’s Income
Total revenue generated from customer calls today
Primary revenue tracking metric
Today’s Profit
Net profit after deducting vendor costs from income
Key profitability indicator
Today’s Consumption
Total vendor costs for routing calls today
Cost tracking for vendor management
Today’s Cost
Operational cost breakdown for today
Detailed cost analysis metric
Having these financial metrics on the VOS3000 Web Manager homepage means you can check your business performance with a single glance at your phone. No need to log into the desktop client, navigate to reports, and generate a financial summary. The VOS3000 Web Manager puts this information front and center, making it easy to stay on top of your VoIP business performance throughout the day.
Performance Overview in VOS 3000 Web Manager
Beyond the homepage dashboard, the VOS 3000 Web Manager provides a dedicated performance overview section. According to the VOS 3000 Web Manager manual (Section 4.3), this section displays both system resource metrics and VoIP quality indicators, giving operators a comprehensive view of system health and call quality.
System Resource Monitoring
The VOS 3000 Web Manager performance overview includes real-time monitoring of critical server resources. These metrics are essential for ensuring that your VOS3000 server has sufficient capacity to handle current and projected call volumes. The system resource metrics available in the VOS3000 Web Manager include:
CPU Usage: Displays the current processor utilization percentage. High CPU usage can indicate that the server is under heavy load, which may affect call processing performance.
RAM Usage: Shows the current memory utilization. Memory exhaustion can lead to system instability and call processing failures.
Disk Usage: Indicates the percentage of disk space currently in use. Running out of disk space can cause CDR recording failures and system crashes.
Monitoring these resources through the VOS3000 Web Manager allows you to proactively address capacity issues before they impact service quality. For example, if you notice CPU usage consistently above 80%, you can plan for server upgrades or load balancing before performance degrades to the point of affecting live calls.
VoIP Quality Metrics
In addition to system resources, the VOS3000 Web Manager performance overview displays critical VoIP quality metrics that directly impact call quality and customer satisfaction. These metrics are updated in real-time and provide immediate visibility into the health of your VoIP traffic. According to the VOS3000 Web Manager manual (Section 4.3), the quality metrics include:
📶 Metric
🧠 Full Name
🎯 Optimal Range
⚠️ Alert Threshold
ASR
Answer-Seizure Ratio
40-60%
Below 20%
ACD
Average Call Duration
3-8 minutes
Below 30 seconds
PDD
Post Dial Delay
1-3 seconds
Above 5 seconds
The ASR (Answer-Seizure Ratio) is perhaps the most important VoIP quality metric displayed in the VOS3000 Web Manager. It represents the percentage of call attempts that result in a successful connection. A low ASR can indicate problems with routing, vendor quality, or dial plan configuration. Monitoring ASR through the VOS3000 Web Manager enables operators to quickly identify and address quality issues.
ACD (Average Call Duration) helps you understand typical call patterns. Abnormally short ACD values may indicate call setup failures, while unusually long ACD might suggest audio issues where calls are not properly disconnecting. The VOS3000 Web Manager presents this data in an easily digestible format that makes pattern recognition simple.
PDD (Post Dial Delay) measures the time between when a caller dials and when they hear ringback tone. High PDD values create a poor user experience, as callers perceive long delays as a sign of system problems. The VOS3000 Web Manager allows you to monitor PDD in real-time, enabling quick identification of routing paths with excessive delays.
One of the most powerful capabilities of the VOS3000 Web Manager is the ability to add and manage customer accounts directly from a mobile browser. According to the VOS3000 Web Manager manual (Section 4.4), the web interface provides streamlined customer creation functionality that allows operators to onboard new customers quickly without needing the desktop client.
Customer Creation Process
The VOS3000 Web Manager simplifies customer creation by focusing on the essential configuration elements needed to get a new customer up and running. The process involves two primary components:
1. Mapping Gateway Configuration: The mapping gateway defines how the VOS3000 system identifies and routes calls from the customer. In the VOS3000 Web Manager, you configure the mapping gateway by specifying the customer’s SIP signaling IP address or prefix. This tells the VOS3000 system which incoming calls belong to this customer.
2. Phone Number Assignment: After configuring the mapping gateway, you assign phone numbers or number ranges to the customer. The VOS3000 Web Manager allows you to specify the phone numbers that this customer is authorized to send calls from, ensuring proper identification and billing.
Here is a typical workflow for adding a customer through the VOS3000 Web Manager:
Step 1: Log into VOS3000 Web Manager
Step 2: Navigate to Customer Management section
Step 3: Click "Add Customer"
Step 4: Enter customer name and basic information
Step 5: Configure Mapping Gateway (SIP IP/Prefix)
Step 6: Assign Phone Numbers
Step 7: Set billing rate and credit limit
Step 8: Save and activate the customer
🔧 Configuration Item
📝 Required
📋 Description
Customer Name
Yes
Unique identifier for the customer account
Mapping Gateway IP
Yes
SIP signaling IP of the customer gateway
Phone Number
Yes
Caller ID numbers assigned to the customer
Billing Rate
Yes
Rate plan applied to customer calls
Credit Limit
Recommended
Maximum credit allowed before call blocking
Codec Preference
Optional
Preferred voice codec for this customer
Concurrent Call Limit
Recommended
Maximum simultaneous calls allowed
The VOS3000 Web Manager mobile interface is designed for efficiency. Rather than presenting every possible configuration option, it focuses on the fields that are most commonly needed when adding a new customer. This streamlined approach means you can add customers from your phone in just a few minutes, even while away from your desk.
Adding Vendors via VOS3000 Web Manager
Just as you can add customers through the VOS3000 Web Manager, you can also add vendor accounts from your mobile browser. According to the VOS3000 Web Manager manual (Section 4.5), vendor management through the web interface follows a similar pattern to customer management but with vendor-specific configuration parameters.
Vendors are the routing gateways that terminate calls on behalf of your VOS3000 system. When you add a vendor through the VOS3000 Web Manager, you are essentially defining a new termination path that the system can use to route outgoing calls. The vendor configuration includes the SIP signaling details, authentication credentials, and routing preferences.
The VOS3000 Web Manager provides a simplified vendor creation form that captures all essential information while remaining easy to use on a mobile device. Key fields include the vendor name, SIP server IP address, port number, and prefix settings. Once a vendor is added through the VOS3000 Web Manager, it becomes immediately available for call routing.
When adding vendors via the VOS3000 Web Manager, it is important to consider the following best practices. Always test new vendor routes with a small volume of test calls before routing production traffic. Verify that the vendor’s SIP signaling parameters match their requirements exactly. Set appropriate cost rates to ensure accurate profit calculations. And configure failover routing to ensure call completion even when the primary vendor is unavailable.
Checking CDR in VOS 3000 Web Manager
Call Detail Records (CDR) are the lifeblood of any VoIP business. The VOS3000 Web Manager provides convenient access to recent CDR directly from your mobile browser, allowing you to investigate call issues, verify billing accuracy, and monitor traffic patterns on the go. According to the VOS3000 Web Manager manual (Section 4.6), the web interface can display up to 1000 recent CDR records.
CDR Features in Web Manager
The VOS3000 Web Manager CDR view provides essential information for each call record, including the caller ID, called number, call duration, start time, end time, and call result. This information is presented in a tabular format that is easy to navigate on both mobile and desktop browsers.
Key capabilities of the CDR section in the VOS3000 Web Manager include:
Recent Call Display: View up to 1000 of the most recent call records, sorted by time.
Call Result Filter: Filter CDR by call result (answered, no answer, busy, failed) to quickly find specific call types.
Time Range Selection: Specify a time period to narrow down the displayed CDR records.
Quick Search: Search for specific phone numbers or caller IDs within the CDR records.
📋 CDR Field
💻 Description
🔍 Use Case
Caller ID
Source phone number of the call
Identify which customer originated the call
Called Number
Destination phone number dialed
Verify correct routing by destination
Duration
Total call duration in seconds
Calculate billing and verify call quality
Start Time
Timestamp when the call was initiated
Correlate calls with reported issues
Call Result
Outcome of the call attempt
Identify failed calls and routing problems
Vendor Route
Vendor gateway used for termination
Track which vendor handled each call
PDD
Post Dial Delay in seconds
Measure routing efficiency per call
The ability to check CDR from the VOS3000 Web Manager on your mobile phone is incredibly valuable for troubleshooting. When a customer reports a call quality issue, you can immediately pull up the CDR on your phone, identify the affected calls, check the call result and duration, and determine whether the issue is with the customer’s connection, the vendor route, or the VOS3000 system itself. This rapid troubleshooting capability can dramatically reduce mean time to resolution.
Revenue Reports in VOS 3000 Web Manager
Financial visibility is crucial for any VoIP business, and the VOS3000 Web Manager delivers comprehensive revenue reporting capabilities directly to your mobile browser. According to the VOS3000 Web Manager manual (Section 4.7), the revenue report section provides today’s revenue breakdown along with a top 10 customers ranking.
Today’s Revenue Report
The VOS3000 Web Manager revenue report displays today’s complete financial picture, including total income, total cost, and net profit. This information is updated in real-time throughout the day, allowing you to track revenue as it accumulates. The revenue report in the VOS3000 Web Manager breaks down the data by customer, showing each customer’s contribution to today’s total income.
For VoIP operators who need to closely monitor business performance, having real-time revenue data in the VOS3000 Web Manager is invaluable. You can check whether revenue is tracking above or below daily targets, identify which customers are generating the most traffic, and spot unusual patterns that might indicate fraud or configuration issues.
Top 10 Customers Report
The VOS3000 Web Manager also provides a top 10 customers report that ranks your customers by revenue contribution. This report helps you understand which customers are driving your business and where to focus your relationship management efforts. According to the VOS3000 Web Manager manual (Section 4.7), the top 10 report includes the following data points for each customer:
Total call minutes generated today
Total number of call attempts
Total number of connected calls
Revenue generated from the customer
Cost associated with routing the customer’s calls
Profit margin for the customer
This top 10 analysis in the VOS3000 Web Manager enables data-driven decision making. If a high-revenue customer shows declining ASR or increasing costs, you can investigate and address the issue before it impacts your bottom line. The mobile accessibility of this report means you can review your top customer performance anytime, anywhere.
Alarm Monitoring via VOS 3000 Web Manager
The VOS3000 Web Manager includes a dedicated alarm monitoring section that displays current system alarms and alerts. According to the VOS3000 Web Manager manual (Section 4.8), the alarm monitoring feature provides real-time visibility into system events that require operator attention. This is one of the most critical features for mobile operators who need to stay informed about system issues even when away from their desk.
Types of Alarms in VOS3000 Web Manager
The VOS3000 system generates alarms for a variety of conditions that can affect service quality and system stability. The VOS3000 Web Manager displays these alarms with appropriate severity levels, allowing operators to prioritize their response. Common alarm types visible in the VOS3000 Web Manager include:
⚠️ Alarm Type
💥 Severity
🔧 Recommended Action
High CPU Usage
Critical
Check running processes, consider scaling
Memory Exhaustion
Critical
Restart services or increase RAM
Disk Space Low
Warning
Archive old CDR, clean up log files
Vendor Unreachable
Major
Check vendor connectivity, update routing
License Limit Reached
Warning
Upgrade license or reduce concurrency
SIP Registration Failure
Major
Verify authentication credentials
Low ASR Detected
Warning
Investigate routing and vendor quality
The alarm monitoring capability in the VOS3000 Web Manager is particularly valuable for mobile operators. When you receive a notification about a system issue, you can immediately open the VOS3000 Web Manager on your phone to view the alarm details, assess the severity, and determine whether immediate action is required. This eliminates the need to be physically present at a desktop computer to respond to critical system events.
System Performance Monitoring in VOS 3000 Web Manager
Beyond the homepage performance overview, the VOS3000 Web Manager provides a dedicated system performance monitoring section with detailed resource metrics. According to the VOS3000 Web Manager manual (Section 4.9), this section offers granular visibility into server resource utilization that goes beyond the summary displayed on the dashboard.
Detailed Resource Metrics
The system performance monitoring section of the VOS3000 Web Manager provides the following detailed metrics:
CPU Monitoring: The VOS3000 Web Manager displays CPU usage broken down by individual cores in multi-core systems. This level of detail helps identify whether specific processes are consuming disproportionate CPU resources. The CPU monitoring view also shows historical trends, allowing you to spot patterns in CPU usage over time.
Memory Monitoring: Memory usage in the VOS3000 Web Manager is displayed with a breakdown of used, cached, and available memory. This distinction is important because Linux systems use free memory for disk caching, which can make memory usage appear higher than it actually is. The VOS3000 Web Manager presents this data accurately, helping operators make informed decisions about memory capacity.
Disk Monitoring: The disk monitoring feature in the VOS3000 Web Manager shows usage for each mounted filesystem. This is particularly important for the partition that stores CDR data, as CDR files can grow rapidly on busy systems. Monitoring disk usage through the VOS3000 Web Manager helps prevent unexpected disk full conditions that could crash the system.
Network Monitoring: The VOS3000 Web Manager also displays network interface statistics, including bandwidth utilization, packet counts, and error rates. For VoIP systems where network quality directly impacts call quality, this monitoring capability is essential. The VOS3000 Web Manager network monitoring helps operators identify bandwidth bottlenecks, packet loss issues, and network errors that could affect voice quality.
💻 Resource
📊 Normal Range
⚠️ Warning Level
💥 Critical Level
CPU Usage
0-60%
60-80%
Above 80%
RAM Usage
0-70%
70-85%
Above 85%
Disk Usage
0-70%
70-85%
Above 90%
Network Bandwidth
0-50% capacity
50-75% capacity
Above 75% capacity
Regular monitoring of system performance through the VOS3000 Web Manager is a best practice that helps prevent service disruptions. By checking these metrics periodically throughout the day — something that is easy to do from your mobile phone — you can identify trends and address potential issues before they become critical problems. The VOS3000 Web Manager makes this kind of proactive monitoring practical and convenient.
VOSS 3000 Web Manager vs Desktop Client Comparison
Understanding the differences between the VOS3000 Web Manager and the VOS3000 desktop client is essential for determining when to use each interface. While both tools provide access to the VOS3000 system, they serve different purposes and are optimized for different use cases. According to the VOS3000 Web Manager manual, the web interface is designed for monitoring and basic management, while the desktop client provides the full configuration and administration capability.
🏢 Feature
🌐 VOS3000 Web Manager
💻 Desktop Client
Access Method
Web browser (any device)
Java application (Windows/Linux)
Mobile Access
✅ Full support (iOS/Android)
❌ Not supported
Installation Required
❌ None
✅ Java runtime + client install
Real-Time Dashboard
✅ Yes (mobile-friendly)
✅ Yes (full-featured)
CDR Viewing
✅ Up to 1000 records
✅ Full CDR access
Add Customer/Vendor
✅ Basic management
✅ Full configuration
Rate Configuration
Limited
Full rate management
Routing Configuration
Limited
Full routing management
System Configuration
Monitoring only
Full system administration
Alarm Monitoring
✅ Yes
✅ Yes (with more detail)
Revenue Reports
✅ Today’s summary + Top 10
✅ Full reporting suite
Performance Monitoring
✅ CPU, RAM, Disk, Network
✅ Full system diagnostics
The key takeaway from this comparison is that the VOS3000 Web Manager and the desktop client are complementary tools, not competing ones. The VOS3000 Web Manager excels at monitoring and quick management tasks, especially when you are mobile. The desktop client provides the depth and breadth of configuration needed for initial setup and complex administration. Most VoIP operators will use both tools in their daily workflow, relying on the VOS3000 Web Manager for real-time monitoring and the desktop client for detailed configuration changes.
One of the standout features of the VOS3000 Web Manager is its mobile browser compatibility. The web interface is designed to work on smartphones and tablets, giving operators true anytime, anywhere access to their VoIP system. According to the VOS 3000 Web Manager manual (Section 4.10), the web manager supports access from popular mobile browsers on both iOS and Android platforms.
iPhone and iPad Access
Accessing the VOS3000 Web Manager from an iPhone or iPad is as simple as opening Safari and navigating to your VOS3000 server URL. The VOS3000 Web Manager interface adapts to the iOS screen size, providing a clean and usable experience even on smaller phone screens. Touch interactions work naturally, and the responsive design ensures that all dashboard elements remain accessible and readable.
For iPhone users, we recommend using Safari for the best experience with the VOS3000 Web Manager. Safari is optimized for iOS and provides the smoothest rendering of the web manager interface. You can also add the VOS3000 Web Manager URL to your iPhone home screen for quick one-tap access, effectively creating an app-like experience without installing anything from the App Store.
Android Phone and Tablet Access
Android users can access the VOS3000 Web Manager through Chrome, Firefox, or any other modern mobile browser. The experience is comparable to the iOS version, with the web interface automatically adjusting to fit the Android device’s screen. Whether you are using a Samsung Galaxy, Google Pixel, or any other Android device, the VOS3000 Web Manager provides consistent functionality.
On Android, Chrome is the recommended browser for accessing the VOS3000 Web Manager. Chrome’s V8 JavaScript engine ensures fast page loads and smooth interactions. You can also create a home screen shortcut to the VOS3000 Web Manager URL, giving you instant access to your VoIP dashboard with a single tap.
Mobile Access Best Practices
To get the most out of the VOS3000 Web Manager on mobile devices, follow these best practices:
Use a stable internet connection (WiFi or 4G/5G) for the best experience with the VOS3000 Web Manager.
Bookmark the VOS3000 Web Manager URL in your mobile browser for quick access.
Save login credentials securely in your browser or password manager for faster sign-in.
Use landscape orientation on phones for better visibility of dashboard tables and CDR records.
Consider using a VPN for secure access when connecting over public WiFi networks.
Keep your mobile browser updated to the latest version for optimal compatibility.
📱 Device
🌐 Recommended Browser
✅ Compatibility
📝 Tips
iPhone
Safari
Full support
Add to home screen for app-like access
iPad
Safari
Full support
Larger screen improves table readability
Android Phone
Chrome
Full support
Create home screen shortcut
Android Tablet
Chrome
Full support
Use landscape mode for best experience
MacBook
Safari / Chrome
Full support
No desktop client needed for monitoring
Linux Desktop
Firefox / Chrome
Full support
Ideal for Linux-based monitoring stations
Real-Time Monitoring Capabilities of VOS3000 Web Manager
The VOS3000 Web Manager shines in its real-time monitoring capabilities. Unlike static reports that show historical data, the VOS3000 Web Manager provides live, updating views of your VoIP system’s operational status. This real-time functionality is what makes the VOS3000 Web Manager such a powerful tool for operators who need to stay connected to their switch at all times.
Live Dashboard Updates
The VOS3000 Web Manager dashboard updates automatically, reflecting current system state without requiring manual page refreshes. Key metrics that update in real-time include current concurrency, online gateway counts, and today’s financial figures. This means the data you see on the VOS3000 Web Manager is always current, giving you confidence that you are making decisions based on the latest information.
Real-time monitoring through the VOS3000 Web Manager is particularly important during high-traffic events or routing changes. When you modify routing rules in the desktop client, you can immediately verify the impact by watching the VOS3000 Web Manager dashboard on your phone. If ASR improves after a routing change, you will see it reflected in the performance metrics within minutes.
Proactive vs Reactive Monitoring
The VOS3000 Web Manager enables both proactive and reactive monitoring approaches. Proactive monitoring involves periodically checking the dashboard to identify trends and potential issues before they become problems. Reactive monitoring involves responding to alarms and customer complaints by using the VOS3000 Web Manager to investigate. Both approaches are valuable, and the VOS3000 Web Manager supports both effectively.
For proactive monitoring, we recommend establishing a routine of checking the VOS3000 Web Manager dashboard at regular intervals throughout the day. A quick 30-second check of the homepage dashboard, performance metrics, and current alarms can help you catch issues early. Since the VOS3000 Web Manager is accessible from your phone, these checks can be done anywhere — during your morning commute, between meetings, or while waiting in line.
VOS3000 Web Manager Navigation and Feature Overview
The VOS3000 Web Manager features a clean, intuitive navigation structure that organizes functionality into logical sections. According to the VOS3000 Web Manager manual, the navigation is designed to provide quick access to the most commonly used features while maintaining a simple, uncluttered interface. This is especially important for mobile users who need to find information quickly on smaller screens.
Main Navigation Sections
The VOS3000 Web Manager organizes its features into the following main sections, each corresponding to a specific area of VoIP management:
Homepage/Dashboard (Section 4.2): The landing page after login, displaying real-time concurrency, online statistics, financial summary, and quick access to key metrics. This is the most frequently viewed page in the VOS3000 Web Manager.
Performance Overview (Section 4.3): Detailed system performance metrics including CPU, RAM, disk usage, and VoIP quality indicators (ASR, ACD, PDD). This section provides the depth needed for thorough system health assessment.
Customer Management (Section 4.4): Tools for adding, viewing, and managing customer accounts. The VOS3000 Web Manager provides streamlined customer management focused on the most essential operations.
Vendor Management (Section 4.5): Similar to customer management but for vendor accounts. The VOS3000 Web Manager enables quick vendor additions and basic management from mobile devices.
CDR Query (Section 4.6): Access to recent call detail records with filtering and search capabilities. The VOS3000 Web Manager displays up to 1000 recent records for quick investigation.
Revenue Report (Section 4.7): Today’s financial breakdown and top 10 customer ranking. The VOS3000 Web Manager provides real-time revenue visibility for financial monitoring.
Alarm Monitor (Section 4.8): Current system alarms and alerts with severity levels. The VOS3000 Web Manager ensures that critical issues are immediately visible.
System Performance (Section 4.9): Detailed resource monitoring for CPU, memory, disk, and network. The VOS3000 Web Manager provides granular system health data.
Mobile Access (Section 4.10): Mobile-specific interface adaptations and browser compatibility. The VOS3000 Web Manager is optimized for mobile browser performance.
Account Management Features in VOS 3000 Web Manager
The VOS 3000 Web Manager provides essential account management capabilities that allow operators to handle routine administrative tasks without the desktop client. While the web interface does not offer the full depth of account configuration available in the desktop client, it covers the most important day-to-day management operations that operators need when working remotely.
Customer Account Operations
Through the VOS3000 Web Manager, operators can perform the following customer account operations:
View a list of all active customer accounts with key status information
Add new customer accounts with mapping gateway and phone number configuration
Check customer credit balances and call statistics
View individual customer CDR for troubleshooting
Monitor customer concurrency and call patterns
These operations cover the majority of customer management tasks that operators perform on a daily basis. For more advanced customer configuration — such as complex rate plan assignments, codec negotiation settings, or SIP header manipulation — the VOS3000 desktop client remains the appropriate tool. The VOS3000 Web Manager complements the desktop client by handling the quick, routine tasks that make up most daily operations.
Vendor Account Operations
Similarly, the VOS 3000 Web Manager supports the following vendor account operations:
View a list of all active vendor accounts and their online status
Add new vendor accounts with SIP server configuration
Monitor vendor performance metrics including ASR and ACD
Check vendor cost rates and traffic volumes
Identify vendor connectivity issues through online/offline status
The ability to perform these vendor management tasks through the VOS3000 Web Manager means that operators can respond to vendor-related issues even when they are away from their desk. If a customer reports call failures to a specific destination, you can use the VOS3000 Web Manager on your phone to check whether the relevant vendor is online and review recent CDR to confirm the issue.
VOS3000 Web Manager Security Considerations
When using the VOS3000 Web Manager, especially from mobile devices on public networks, security should be a top priority. The VOS3000 Web Manager transmits sensitive operational data and credentials over the network, so proper security measures are essential to protect your VoIP system from unauthorized access.
Recommended Security Practices
To ensure secure access to the VOS3000 Web Manager, follow these security best practices:
Use HTTPS: Configure SSL/TLS on your VOS3000 server to encrypt web manager traffic. This prevents credential interception on untrusted networks.
Strong Passwords: Use complex passwords for all VOS3000 accounts that have web manager access. Avoid default or easily guessable passwords.
IP Whitelisting: Restrict web manager access to known IP addresses when possible. This limits the attack surface significantly.
VPN Access: Require VPN connections for accessing the VOS3000 Web Manager from external networks. This adds a layer of encryption and authentication.
Regular Password Changes: Periodically rotate passwords for accounts with web manager access, especially for administrator-level accounts.
Audit Log Review: Monitor login activity to detect unauthorized access attempts to the VOS3000 Web Manager.
Security is not a one-time setup but an ongoing process. By implementing these practices, you can ensure that your VOS3000 Web Manager remains secure even as you enjoy the convenience of mobile access. Remember that the same credentials used for the desktop client grant access to the VOS3000 Web Manager, so protecting those credentials is paramount.
VOS3000 Web Manager Troubleshooting Guide
Even with a well-configured system, you may occasionally encounter issues when accessing or using the VOS3000 Web Manager. This troubleshooting guide covers the most common problems and their solutions, helping you quickly resolve issues and get back to monitoring your VoIP system.
⚠️ Problem
🧠 Likely Cause
🔧 Solution
Cannot access web manager URL
Web service not running
Start VOS3000 web service on the server
Login credentials rejected
Wrong username or password
Verify credentials in desktop client first
Dashboard not loading
JavaScript blocked or browser cache
Enable JavaScript, clear browser cache
Slow page load on mobile
Weak network connection
Switch to WiFi or stronger signal area
CDR not displaying
Date range filter too narrow
Adjust time range filter to include today
Connection timeout
Firewall blocking the port
Open the web manager port in firewall rules
Most VOS3000 Web Manager access issues can be resolved by checking the web service status, verifying network connectivity, and ensuring that firewall rules allow traffic on the configured port. If problems persist after checking these basics, consult the VOS3000 system logs for more detailed error information. The VOS3000 Web Manager is designed to be reliable, and persistent issues often indicate an underlying server or network problem that needs attention.
Getting the Most from VOS 3000 Web Manager
To maximize the value you get from the VOS3000 Web Manager, consider implementing these operational best practices that experienced VoIP operators have found effective:
Establish a monitoring routine: Set specific times throughout the day to check the VOS3000 Web Manager dashboard. A quick check every 2-3 hours helps you stay on top of system health without being overwhelmed by data. The VOS3000 Web Manager’s mobile accessibility makes this routine easy to maintain.
Use the financial dashboard proactively: Don’t just check revenue when there’s a problem. Use the VOS3000 Web Manager’s financial summary to track daily revenue patterns and identify opportunities. If revenue spikes at certain times, investigate what’s driving it and try to replicate that success.
Respond to alarms quickly: The VOS 3000 Web Manager makes alarm monitoring accessible from anywhere. Take advantage of this by responding to alarms promptly, even when you’re away from your desk. A quick response to a critical alarm can prevent minor issues from becoming major outages.
Combine web and desktop tools: Use the VOS 3000 Web Manager for monitoring and quick tasks, and the desktop client for configuration and detailed analysis. This combined approach gives you the best of both worlds — mobile convenience and desktop power.
Train your team: Ensure that all operators on your team know how to access and use the VOS3000 Web Manager. The more people who can monitor the system, the faster issues will be identified and resolved. The VOS3000 Web Manager’s browser-based access means there’s no software to install, making team training simple.
Frequently Asked Questions About VOS 3000 Web Manager
❓ What is VOS3000 Web Manager and how do I access it?
The VOS3000 Web Manager is the browser-based management interface for the VOS3000 VoIP softswitch. You access it by navigating to http://YOUR_SERVER_IP:PORT/manage in any web browser. The login credentials are the same as your VOS3000 desktop client credentials, so no separate account is needed. The VOS3000 Web Manager works on desktops, laptops, smartphones, and tablets.
❓ Can I use VOS3000 Web Manager on my iPhone or Android phone?
Yes, the VOS3000 Web Manager is fully accessible from mobile browsers on both iPhone and Android devices. Simply open Safari (iOS) or Chrome (Android) and navigate to your VOS3000 server URL. The web interface is responsive and adapts to mobile screen sizes. You can even add the VOS3000 Web Manager to your home screen for quick app-like access.
❓ What features are available in VOS 3000 Web Manager compared to the desktop client?
The VOS3000 Web Manager focuses on monitoring and basic management tasks, including real-time dashboard viewing, CDR queries (up to 1000 records), customer and vendor addition, revenue reports, alarm monitoring, and system performance tracking. The desktop client provides the full configuration and administration capabilities, including detailed rate management, routing configuration, and system settings. The VOS3000 Web Manager and desktop client are complementary tools.
❓ How do I add a customer through VOS 3000 Web Manager on mobile?
To add a customer through the VOS3000 Web Manager, log in via your mobile browser, navigate to the Customer Management section, and click “Add Customer.” You will need to provide the customer name, configure the Mapping Gateway (SIP IP address or prefix), assign phone numbers, and set the billing rate and credit limit. The VOS3000 Web Manager’s mobile-friendly form makes this process quick and efficient.
❓ Does VOS 3000 Web Manager show real-time data?
Yes, the VOS3000 Web Manager displays real-time data on the homepage dashboard. Key real-time metrics include current concurrency, online phone count, online mapping gateway count, online routing gateway count, and today’s financial figures (income, profit, consumption, cost). The performance overview section also updates in real-time, showing current CPU, RAM, disk usage, ASR, ACD, and PDD values.
❓ Is VOS 3000 Web Manager secure for remote access?
The VOS 3000 Web Manager supports standard web security practices. For secure remote access, we recommend configuring HTTPS/SSL on your VOS3000 server, using VPN connections for external access, implementing IP whitelisting, and using strong passwords. Since the VOS3000 Web Manager uses the same credentials as the desktop client, protecting those credentials is essential. Always avoid accessing the VOS3000 Web Manager over unsecured public WiFi without VPN protection.
❓ What should I do if VOS 3000 Web Manager is not loading?
If the VOS3000 Web Manager is not loading, first verify that the VOS3000 web service is running on the server. Check that you are using the correct IP address and port number. Ensure that firewall rules allow traffic on the web manager port. Try clearing your browser cache and enabling JavaScript. If the issue persists, check the VOS3000 server logs for error messages that may indicate the root cause of the problem.
❓ Can multiple users access VOS3000 Web Manager simultaneously?
Yes, multiple users can access the VOS3000 Web Manager simultaneously. Each user logs in with their own VOS3000 account credentials, and the system maintains separate sessions. This means different operators can monitor the dashboard, check CDR, and manage accounts at the same time without conflict. The VOS3000 Web Manager supports concurrent access, making it suitable for teams.
Get Started with VOS3000 Web Manager
The VOS3000 Web Manager is an essential tool for any VoIP operator who needs flexible, mobile access to their softswitch. With its real-time dashboard, comprehensive monitoring capabilities, customer and vendor management features, and mobile browser compatibility, the VOS3000 Web Manager puts the power of VoIP management in the palm of your hand.
Whether you are a seasoned VOS3000 administrator or just getting started with VoIP operations, the VOS3000 Web Manager provides the accessibility and convenience you need to manage your business effectively. From quick alarm checks on your morning commute to detailed CDR investigations from your living room, the VOS3000 Web Manager ensures you are always connected to your switch.
Setting up and optimizing VOS3000 for your specific business needs requires expertise and experience. If you need assistance with VOS3000 installation, configuration, or optimization, our team of VOS3000 specialists is ready to help. We provide complete VOS3000 deployment services, from initial server setup to advanced routing and monitoring configuration.
📱 Contact us on WhatsApp: +8801911119966
Let us help you unlock the full potential of VOS3000 Web Manager and take your VoIP business to the next level. Whether you need help setting up the web manager, configuring mobile access, or optimizing your entire VOS3000 deployment, we are just a message away.
📱 WhatsApp: +8801911119966 — Reach out today for expert VOS3000 support and consultation.
📞 Need Professional VOS3000 Setup Support?
For professional VOS3000 installations and deployment, VOS3000 Server Rental Solution:
VOS3000 DTMF Configuration: RFC2833 vs SIP INFO Setup Guide
Proper VOS3000 DTMF configuration is essential for every VoIP deployment that uses IVR systems, calling cards, PIN authentication, or any feature where callers press keypad buttons during a call. When DTMF (Dual-Tone Multi-Frequency) signals are not correctly configured, callers press buttons but the system does not respond, IVR menus do not work, calling card PINs are not recognized, and your customers become frustrated. This is one of the most common and costly problems in VOS3000 deployments, yet it is entirely preventable with the correct configuration.
The challenge with VOS3000 DTMF configuration is that there are three different DTMF transport methods — RFC2833, SIP INFO, and Inband — and each gateway, phone, and vendor may use a different method. VOS3000 must be configured to handle DTMF correctly on both the calling and called sides, converting between methods when necessary. This guide covers every aspect of DTMF configuration in VOS3000, based on the official VOS3000 V2.1.9.07 Manual and the VOS3000 Transcode Module documentation. For expert assistance, contact us on WhatsApp at +8801911119966.
Table of Contents
Understanding VOS3000 DTMF Configuration Methods
Before configuring anything, you must understand the three DTMF transport methods available in VOS3000 and when each should be used. Choosing the wrong method is the root cause of most DTMF problems.
RFC2833 DTMF Method
RFC2833 (now superseded by RFC4733) transmits DTMF signals as special RTP packets within the media stream. The DTMF digits are encoded as telephone-event payloads, identified in the SDP by the attribute a=rtpmap:101 telephone-event/8000. The payload type number (commonly 101) is negotiated during call setup. According to the VOS3000 Transcode Module documentation (Section 2.3), “RFC2833 signals are carried in separate RTP packets, identified in the SDP by a=rtpmap:101 telephone-event/8000.”
RFC2833 is the recommended DTMF method for most VOS3000 deployments because:
Reliability: DTMF signals are transmitted as separate RTP events, not embedded in audio, so they survive codec compression without distortion
Compatibility: Supported by virtually all modern SIP devices and gateways
Accuracy: DTMF digits are precisely represented with start and end events, ensuring accurate detection at the receiving end
Works with compressed codecs: Unlike Inband, RFC2833 works perfectly with G729, G723, and other low-bitrate codecs
SIP INFO DTMF Method
SIP INFO transmits DTMF signals as separate SIP INFO messages within the signaling channel, completely outside the RTP media stream. According to the VOS3000 Transcode Module documentation (Section 2.2), “SIP INFO belongs to independent signaling, where key presses are carried in separate signaling messages.” Each DTMF key press generates a separate SIP INFO message containing the digit information.
SIP INFO has specific advantages and limitations:
Advantage: Works even when media proxy is disabled, because DTMF travels in the signaling channel
Advantage: Does not depend on RTP connectivity between endpoints
Limitation: Some SIP devices do not support SIP INFO for DTMF
Limitation: Timing information is less precise than RFC2833, which can cause issues with some IVR systems
Inband DTMF Method
Inband DTMF transmits dual-tone signals as actual audio within the RTP voice stream. The DTMF tones are generated by the phone’s keypad and embedded in the audio packets just like speech. According to the VOS3000 Transcode Module documentation (Section 2.4), “Inband key presses are carried in the RTP as a continuous segment of voice.” This is the oldest DTMF method and works with any telephony equipment, but it has significant limitations.
Critical limitations of Inband DTMF:
Codec dependency: Inband DTMF only works reliably with G711 (PCMA/PCMU) codec. Low-bitrate codecs like G729 and G723 compress the audio and distort the DTMF tones, making them unrecognizable
Detection difficulty: Even with G711, background noise and echo can interfere with Inband DTMF detection
Not recommended for VOS3000: Use Inband only when the far-end device does not support RFC2833 or SIP INFO
📋 Feature
🔵 RFC2833
🟢 SIP INFO
🟡 Inband
Transport channel
RTP (media)
SIP (signaling)
RTP (audio)
Codec compatibility
All codecs
All codecs
G711 only
Reliability
High
Medium
Low
Media proxy required
Recommended
No
Recommended
Device support
Universal
Most SIP devices
All devices
Recommended for VOS3000
✅ Yes (primary)
⚠️ Specific cases
❌ Last resort
Configuring VOS3000 DTMF Configuration on Routing Gateway
The DTMF settings for routing gateways are found in the Additional Settings > Protocol > DTMF section. Navigate to Operation Management > Gateway Operation > Routing Gateway, double-click a gateway, and access the DTMF configuration (VOS3000 Manual Section 2.5.1.1, Page 46). These settings control how VOS3000 receives and sends DTMF signals to the vendor side.
DTMF Receive Setting
The “DTMF receive” setting specifies how VOS3000 accepts incoming DTMF signals from the gateway. According to the VOS3000 Manual, “The option is recommended, which asks the system to accept all kinds of DTMFs. Once a certain kind of DTMF is received, this channel will accept the same kind of DTMFs only, thus effectively avoiding duplicate receptions.”
Available DTMF receive options:
All: Accept RFC2833, SIP INFO, and Inband DTMF. Once the first DTMF type is detected, only that type is accepted for the remainder of the call. This is the recommended setting for maximum compatibility
RFC2833 only: Accept only RFC2833 DTMF signals. Use this when you know the gateway only sends RFC2833
SIP INFO only: Accept only SIP INFO DTMF. Use this when the gateway only supports SIP INFO
Inband only: Accept only Inband DTMF. Rarely recommended due to reliability issues
Use Peer RFC2833 Ability Setting
The “Use peer RFC2833 ability” checkbox determines how VOS3000 advertises its RFC2833 capability in SDP. According to the VOS3000 Transcode Module documentation (Section 2.5), when checked, “VOS uses the RFC2833 support capability of the opposite end (caller), otherwise, VOS3000 declares to support RFC2833 capability.” In practical terms:
Checked: VOS3000 includes RFC2833 in SDP only if the calling party also includes it. If the caller does not advertise RFC2833 support, VOS3000 will not advertise it to the routing gateway either
Unchecked: VOS3000 always includes RFC2833 capability in its SDP, regardless of what the caller supports. This is useful when you want to ensure the routing gateway uses RFC2833 regardless of the caller’s capabilities
DTMF Payload Value (VOS3000 DTMF Configuration)
The “Payload” field specifies the RTP payload type number used for RFC2833 DTMF events. According to the VOS3000 Manual, “For example, if the payload is 97, then the payload value of RFC2833 message must be 97.” The default and most common value is 101, matching the standard SDP attribute a=rtpmap:101 telephone-event/8000. Only change this value if your gateway uses a non-standard payload type for RFC2833, which is rare but possible with some older equipment.
⚙️ Setting
✅ Recommended Value
📝 When to Change
DTMF receive
All
Only when gateway uses single method
Use peer RFC2833 ability
Checked
Uncheck if gateway needs RFC2833 forced
Payload
101
Only if gateway uses non-standard value
DTMF send (H323)
Auto
Specific method if Auto fails
DTMF send (SIP)
Auto
Specific method if Auto fails
DTMF Send Settings
The “DTMF send (H323)” and “DTMF send (SIP)” settings control how VOS3000 transmits DTMF signals to the routing gateway. Both default to “Auto”, which means VOS3000 determines the best DTMF sending method based on the receiver’s capabilities. According to the VOS3000 Manual (Page 46), “It is set to ‘Auto’ by default, indicating that the system would determine the best way to send DTMFs based on the receiver’s capacity. If the receiver provides no capacity set, the system will send according to the default mode.”
The Auto mode typically selects RFC2833 as the preferred send method when the gateway supports it, falling back to SIP INFO or Inband as needed. Only change from Auto to a specific method if you are experiencing DTMF issues that the Auto mode cannot resolve.
Configuring VOS3000 DTMF Configuration on Mapping Gateway
The mapping gateway (customer-side gateway) has identical DTMF configuration options to the routing gateway. Navigate to Operation Management > Gateway Operation > Mapping Gateway and access the Additional Settings > Protocol > DTMF section (VOS3000 Manual Section 2.5.1.2, Page 60). The same principles apply: use “All” for DTMF receive, check “Use peer RFC2833 ability” for standard deployments, and set DTMF send to “Auto”.
Mapping Gateway DTMF for IVR Applications
When your mapping gateway customers use IVR systems (such as calling card platforms or voice mail systems), the DTMF configuration becomes especially critical. The IVR system must receive DTMF signals correctly to navigate menus, enter PINs, and select options. If the mapping gateway’s DTMF receive setting is too restrictive, IVR interactions will fail.
For IVR deployments, the recommended VOS3000 DTMF configuration is:
DTMF receive: Set to “All” to accept DTMF in any format from the customer’s device
Use peer RFC2833 ability: Checked to properly negotiate RFC2833 with the customer’s SIP device
DTMF send (SIP): Set to “Auto” to let VOS3000 choose the best method for sending DTMF to the IVR system
Media proxy: Set to “Auto” or “On” to ensure VOS3000 can convert between DTMF methods if needed
VOS3000 DTMF Configuration with Transcode Module
When your VOS3000 deployment includes the transcode module, DTMF handling becomes more sophisticated because VOS3000 can actively convert between DTMF methods. The VOS3000 Transcode Module documentation provides important details about DTMF behavior during transcoding.
DTMF Conversion with Media Proxy Enabled
When media proxy is enabled (which is necessary for transcoding), VOS3000 terminates the RTP stream from the caller, processes the DTMF signals, and then regenerates the appropriate DTMF signals on the callee side. According to the VOS3000 Transcode Module documentation (Section 2.6), “If media forwarding is enabled, the RFC2833 payload and 0-16 key support type received from the far-end SDP is terminated by VOS, and VOS integrates and sends the values set in VOS DTMF configuration to the peer end.”
This means that when media proxy is on:
VOS3000 terminates all incoming DTMF (RFC2833, SIP INFO, or Inband) from the caller
VOS3000 regenerates DTMF signals according to the DTMF send settings configured for the routing gateway
The payload type and key support range in the SDP sent to the routing gateway are determined by VOS3000, not passed through from the caller
DTMF Passthrough Without Media Proxy
When media proxy is disabled, VOS3000 does not intercept the RTP stream and DTMF signals pass through directly between the endpoints. This means RFC2833 DTMF events travel directly from the caller’s device to the called gateway without modification. While this reduces server load, it also means VOS3000 cannot convert between DTMF methods, so both endpoints must support the same DTMF method for it to work correctly.
⚙️ Scenario
🔵 Media Proxy ON
⚪ Media Proxy OFF
DTMF method conversion
✅ Yes (e.g., SIP INFO → RFC2833)
❌ No (passthrough only)
DTMF payload modification
✅ VOS controls payload value
❌ Original payload passthrough
Inband DTMF detection
✅ VOS can detect and convert
❌ Not possible
Mixed method handling
✅ First detected type only
❌ Both arrive at peer
Server resource usage
Higher (RTP processing)
Lower (signaling only)
Troubleshooting VOS3000 DTMF Configuration Issues
DTMF problems in VOS3000 can be complex because they involve multiple components: the caller’s device, the mapping gateway, the VOS3000 softswitch, the routing gateway, and the called endpoint. Here are the most common VOS3000 DTMF configuration issues and their solutions.
Issue 1: IVR Does Not Respond to Keypad Presses
This is the most common DTMF complaint. The caller presses buttons but the IVR system on the other end does not respond. The root cause is almost always a DTMF method mismatch between the caller’s device and the IVR system.
Diagnostic steps:
Check the current call details: Use the Current Call view (right-click any gateway > Current Call) and check the “Caller DTMF” and “Callee DTMF” columns. These show which DTMF mode each side is using (VOS3000 Manual Section 2.5.4, Page 95)
Verify DTMF receive setting: Ensure both mapping gateway and routing gateway have DTMF receive set to “All”
Check media proxy: If DTMF methods differ between caller and callee, media proxy must be enabled for VOS3000 to convert between them
Verify RFC2833 in SDP: Check if the caller’s SIP INVITE includes the telephone-event attribute in SDP. If not, the device may not support RFC2833
Issue 2: Duplicate DTMF Digits Received (VOS3000 DTMF Configuration)
When the far-end sends both SIP INFO and RFC2833 simultaneously for the same key press, VOS3000 may detect duplicate digits. According to the VOS3000 Transcode Module documentation (Section 2.6), “When the far-end sends both SIP INFO and RFC2833, VOS will only recognize the first detected key press type, and all subsequent different key press types will not be processed.” Setting DTMF receive to “All” activates this first-detected-type locking mechanism, which prevents duplicate DTMF detection.
Issue 3: DTMF Works with G711 But Not G729
This confirms that the DTMF is being sent Inband rather than via RFC2833 or SIP INFO. Inband DTMF tones are distorted by G729 compression and become unrecognizable. The solution is to configure the gateway to use RFC2833 for DTMF instead of Inband. Check the “Use peer RFC2833 ability” setting and ensure that both the caller’s device and the gateway support RFC2833.
⚠️ Problem
🔍 Likely Cause
✅ Solution
IVR no response
DTMF method mismatch
Enable media proxy + set DTMF to All
Duplicate digits
Dual method (SIP INFO + RFC2833)
Set DTMF receive to All (auto-locks type)
DTMF fails with G729
Inband DTMF with compressed codec
Use RFC2833 instead of Inband
Partial DTMF digits
Payload mismatch
Match payload value with gateway SDP
DTMF delay
SIP INFO over congested link
Switch to RFC2833 for faster delivery
Best Practices for VOS3000 DTMF Configuration
Following these best practices will prevent the majority of DTMF issues in your VOS3000 deployment.
Recommended DTMF Configuration by Scenario
🎯 Scenario
⚙️ DTMF Receive
⚙️ DTMF Send
🔧 Media Proxy
Standard SIP to SIP
All
Auto
Auto
IVR / Calling Card
All
Auto (or RFC2833)
On
G729 Codec with DTMF
All
RFC2833
On
SIP to H323 conversion
All
Auto
On
Low traffic (no transcode)
All
Auto
Auto
Testing DTMF After Configuration
After making any DTMF configuration changes, always test with actual calls before considering the work complete. Use a SIP phone or softphone to place a test call through your VOS3000 platform and verify that DTMF key presses are recognized on the far end. Test with both G711 and G729 codecs if your deployment uses multiple codecs. Check the Current Call view to verify that the correct DTMF mode is being used on both the caller and callee sides.
Frequently Asked Questions About VOS3000 DTMF Configuration
❓ Which DTMF method should I use in VOS3000?
RFC2833 is the recommended primary DTMF method for VOS3000 because it works reliably with all codecs, is universally supported by modern SIP devices, and provides precise timing information. Set DTMF receive to “All” for maximum compatibility and let VOS3000 automatically select the best method. Only use SIP INFO or Inband when specific gateway requirements demand it.
❓ Why does my IVR not respond to keypad presses?
This is almost always caused by a DTMF method mismatch. Check that media proxy is enabled (Auto or On) so VOS3000 can convert between DTMF methods. Verify that both the mapping gateway and routing gateway have DTMF receive set to “All”. Use the Current Call view to check which DTMF mode is active on both sides of the call.
❓ What is the DTMF payload value and should I change it?
The DTMF payload value is the RTP payload type number used for RFC2833 telephone-event packets. The default and most common value is 101. You should only change this if your gateway uses a non-standard payload type, which would be indicated in the gateway’s SDP with a different number in the a=rtpmap line.
❓ Does VOS3000 DTMF work with G729 codec?
Yes, VOS3000 DTMF works with G729 codec when using RFC2833 or SIP INFO methods. Only Inband DTMF fails with G729 because the codec compresses the audio and distorts the DTMF tones. If you need DTMF with G729, ensure RFC2833 is configured and media proxy is enabled so VOS3000 can properly handle the DTMF signals.
❓ How do I fix duplicate DTMF digits in VOS3000?
Duplicate DTMF occurs when both RFC2833 and SIP INFO are sent simultaneously for the same key press. Set DTMF receive to “All” which activates VOS3000’s first-detected-type locking mechanism. Once the first DTMF type is detected, VOS3000 ignores all other types for the remainder of that call, preventing duplicate digit detection.
❓ Where can I get help with VOS3000 DTMF configuration?
Our VOS3000 specialists can diagnose and fix any DTMF configuration issue remotely. Contact us on WhatsApp at +8801911119966 for expert assistance. We can optimize your DTMF settings for IVR compatibility, troubleshoot DTMF problems, and configure your VOS3000 platform for reliable keypad interaction.
Get Expert Help with VOS3000 DTMF Configuration
DTMF configuration problems can be frustrating and time-consuming to resolve, especially when they involve multiple gateways and endpoints with different DTMF capabilities. The configuration options in VOS3000 are powerful, but they must be set correctly for your specific deployment to achieve reliable DTMF performance.
📱 Contact us on WhatsApp: +8801911119966
Our team provides complete VOS3000 DTMF configuration services, from initial setup to troubleshooting complex DTMF issues. We can optimize your settings for IVR compatibility, calling card systems, and any other DTMF-dependent features in your VoIP platform.
📞 Need Professional VOS3000 Setup Support?
For professional VOS3000 installations and deployment, VOS3000 Server Rental Solution:
VOS3000 P-Asserted-Identity: Caller ID Manipulation Guide for VoIP
Configuring VOS3000 P-Asserted-Identity correctly is crucial for VoIP operators who need to control how caller ID information is presented to termination providers, regulatory bodies, and end users. The P-Asserted-Identity (PAI) header, defined in RFC 3325, is the industry-standard mechanism for asserting the identity of the calling party within trusted VoIP networks. Many termination vendors require specific PAI header configuration to accept calls, and incorrect PAI settings result in calls being rejected, caller ID not displaying correctly, or compliance violations that can jeopardize your entire operation. VOS3000 P-Asserted-Identity
This guide provides a complete walkthrough of VOS3000 P-Asserted-Identity configuration, including the related Privacy and P-Preferred-Identity headers, caller dial plans, and advanced caller ID manipulation techniques. All configuration details reference the official VOS3000 V2.1.9.07 Manual. For professional assistance, contact us on WhatsApp at +8801911119966.
Table of Contents
Understanding VOS3000 P-Asserted-Identity Header
The P-Asserted-Identity header serves a specific purpose in SIP signaling that is fundamentally different from the standard From header. While the From header identifies the caller as claimed by the caller’s device, the PAI header asserts the caller’s identity as verified by a trusted network element — in this case, your VOS3000 softswitch. This distinction is critical because termination providers rely on the PAI header to determine the actual calling party for billing, routing, and regulatory compliance purposes.
Why P-Asserted-Identity Matters for VoIP Operators
In the VOS3000 ecosystem, the PAI header impacts several critical aspects of your VoIP business. Termination vendors increasingly require PAI headers to process calls correctly, especially for emergency services and regulatory compliance. Without proper PAI configuration, your calls may be rejected by vendors or flagged as suspicious. Additionally, the PAI header determines how your customers’ caller ID appears to the called party, which affects your customers’ business credibility and call completion rates.
Key reasons to configure VOS3000 P-Asserted-Identity correctly:
Vendor requirements: Many termination providers require PAI headers to accept calls and bill correctly
Regulatory compliance: Telecom regulations in many jurisdictions require accurate caller ID presentation
Call completion: Proper PAI configuration prevents calls from being blocked by downstream providers
Emergency services: Emergency call routing depends on accurate PAI for location identification
Anti-spoofing: PAI with Privacy headers provides controlled caller ID presentation that prevents spoofing accusations
📋 Feature
🔵 From Header
🟢 PAI Header
Purpose
Caller’s claimed identity
Network-asserted identity
Trust level
Self-asserted (unverified)
Verified by trusted network
Used by vendors for billing
Sometimes
Primarily
RFC standard
RFC 3261
RFC 3325
Can include display name
Yes
Yes
Used with Privacy header
Rarely
Commonly paired
Configuring VOS3000 P-Asserted-Identity on Routing Gateway
The PAI configuration for routing gateways is located in the Additional Settings > Protocol > SIP section. Navigate to Operation Management > Gateway Operation > Routing Gateway, double-click a gateway, and access the Protocol > SIP settings (VOS3000 Manual Section 2.5.1.1, Page 43). These settings control how VOS3000 handles caller identity information when sending calls to your termination vendors.
P-Asserted-Identity Settings
VOS3000 provides three options for the PAI header on routing gateways, as documented in VOS3000 Manual Section 2.5.1.1 (Page 43):
None: The PAI header is not included in outgoing SIP messages to this gateway. Use this when the vendor does not require or expect a PAI header
Pass through: VOS3000 forwards the PAI header exactly as received from the mapping gateway (caller side). This preserves the original PAI value without modification, which is useful when the upstream device has already set the correct PAI
Caller: VOS3000 generates a new PAI header using the caller’s number. This is the most common setting because it ensures the PAI contains the correct caller ID regardless of what the caller’s device sent
For most deployments, the “Caller” option is recommended because it guarantees that the PAI header contains the actual calling number from VOS3000’s perspective. The “Pass through” option should only be used when you trust the upstream device to provide accurate PAI values. VOS3000 P-Asserted-Identity
Privacy Header Configuration
The Privacy header works in conjunction with the PAI header to control whether the caller’s identity should be hidden from the called party. According to the VOS3000 Manual (Page 43), there are three Privacy options:
None: No Privacy header is included in outgoing messages. The caller ID is presented normally
Passthrough: VOS3000 forwards the Privacy header as received from the mapping gateway. If the caller requested privacy, that request is preserved
Id: VOS3000 adds a Privacy: id header, which requests that the called party’s network hide the caller’s identity from display
The Privacy header is particularly important for regulatory compliance. In many jurisdictions, callers have the right to withhold their caller ID, and the Privacy: id header signals this request to downstream networks. When a call with Privacy: id is received, the called party’s network should suppress the caller ID display while still using the PAI header internally for billing and emergency services.
⚙️ Setting
🟢 Recommended
📝 When to Use Other Options
P-Asserted-Identity
Caller
Pass through: upstream PAI trusted; None: vendor doesn’t use PAI
Privacy
Passthrough
None: never hide caller ID; Id: always hide caller ID
P-Preferred-Identity
None
Passthrough: preserve upstream PPI; Caller: set from caller number
Caller dial plan
As needed
When vendor requires specific number format in PAI
P-Preferred-Identity Configuration
The P-Preferred-Identity (PPI) header is similar to PAI but is used in a different context. While PAI is used by networks to assert identity, PPI is used by user agents (phones, PBXs) to indicate their preferred identity. In VOS3000, the PPI options (VOS3000 Manual, Page 43) are identical to PAI:
None: No PPI header is included
Passthrough: Forward the PPI header as received from the mapping gateway
Caller: Generate a new PPI header using the caller’s number
In most VOS3000 deployments, the PPI header is set to “None” because the PAI header is the primary mechanism for identity assertion at the softswitch level. PPI is more relevant for user-agent-to-proxy communication, while PAI is for proxy-to-proxy communication. However, some vendors may require specific PPI configuration, so understanding this option is important.
VOS3000 P-Asserted-Identity Caller Dial Plan
The “Caller dial plan” setting associated with the PAI configuration allows you to transform the caller number before it is inserted into the PAI header. This is essential when your vendor requires a specific number format in the PAI header that differs from how numbers are stored in VOS3000.
Common Caller Number Transformation Scenarios
Different vendors expect different number formats in the PAI header. Here are the most common scenarios that require caller dial plan configuration:
Country code addition: Your internal numbers may not include the country code, but the vendor requires it. A dial plan can prepend the country code (e.g., +880) to the caller number in the PAI header
Leading zero removal: Some vendors require numbers without leading zeros. A dial plan can strip leading zeros from the caller number
Number format conversion: Converting between E.164 format and national format as required by the vendor
Prefix addition: Adding a specific prefix that the vendor uses to identify your traffic
🔄 Transformation
📝 Original Number
✅ PAI Number
🎯 Reason
Add country code
01712345678
+8801712345678
Vendor requires E.164
Remove leading zero
01712345678
1712345678
Vendor rejects leading 0
Add + prefix
8801712345678
+8801712345678
E.164 with plus sign
Add tech prefix
1712345678
991712345678
Vendor routing prefix
Advanced VOS3000 P-Asserted-Identity Features
Beyond the basic PAI, Privacy, and PPI settings, VOS3000 provides several advanced features that give you more control over caller identity handling.
Allow All Extra Header Fields
The “Allow all extra header fields” option (VOS3000 Manual, Page 43) enables SIP header transparency, allowing all additional header domains from the incoming SIP message to pass through to the routing gateway. When enabled, any custom or non-standard SIP headers received from the mapping gateway are forwarded unchanged. This is useful when your upstream provider sends proprietary headers that your downstream vendor expects to receive.
Allow Specified Extra Header Fields
For more granular control, the “Allow specified extra header fields” option lets you define exactly which additional header fields should be forwarded. This provides better security than allowing all headers because you can restrict passthrough to only the headers your vendor requires. Add specific header field names to the list, and only those headers will be forwarded from the incoming SIP message to the outgoing message.
Peer Number Information
The “Peer number information” setting controls which field VOS3000 uses to extract the caller number from incoming SIP signals. Available options include extracting from the From header, Display field, or Remote-Party-ID header. This setting determines the source of the caller number that may be used in the PAI header when set to “Caller” mode.
Caller Number Pool for PAI
When you need to substitute the caller ID with numbers from a pool rather than using the actual caller number, VOS3000 provides the “Enable caller number pool” feature in the routing gateway additional settings (VOS3000 Manual Section 2.5.1.1, Page 51). This feature replaces the original caller number with a number from a configured pool, which then appears in both the From header and PAI header. The number sequence can be random (0) or poll (1), configured by the FORWARD_SIGNAL_REWRITE_SEQUENCE setting in softswitch.conf. The “Multiplexes” field controls how many times each pool number can be reused concurrently.
🔧 Feature
🎯 Purpose
📍 Location
Allow all extra headers
Transparent SIP header forwarding
Gateway > Protocol > SIP
Allow specified headers
Selective header forwarding
Gateway > Protocol > SIP
Peer number information
Select caller number source field
Gateway > Protocol > SIP
Caller number pool
Substitute caller ID with pool numbers
Gateway > Additional Settings
Caller dial plan
Transform number in PAI header
Gateway > Protocol > SIP
Configuring VOS3000 P-Asserted-Identity on Mapping Gateway
The mapping gateway (customer-side) also has caller identity configuration options in the Additional Settings > Protocol > SIP section (VOS3000 Manual Section 2.5.1.2, Page 57). The mapping gateway settings control how VOS3000 handles caller identity from your customers’ devices.
Mapping Gateway Caller Settings
On the mapping gateway, the key caller identity settings include:
Caller: Determines which field of the SIP signal to extract the caller number from. Options include “From” (from the From header), “Remote-Party-ID” (from the RPID header), and “Display” (from the Display field)
Support Privacy: Enables passthrough of the mapping gateway’s privacy domain settings
Recognize call forward signal: Identifies forwarding-formatted calls for proper handling
The mapping gateway’s caller extraction method determines the initial caller number that VOS3000 uses internally. This number then flows to the routing gateway where the PAI configuration determines how it is presented to the vendor. If the mapping gateway extracts the wrong caller number, the PAI header on the routing gateway will also be wrong.
PAI configuration problems can be difficult to diagnose because the SIP headers are not visible in the VOS3000 client interface. Here are the most common issues and how to resolve them.
Issue 1: Vendor Rejects Calls Due to Missing PAI
If your vendor requires the PAI header but you have it set to “None” on the routing gateway, calls will be rejected. The fix is straightforward: change the PAI setting to “Caller” so VOS3000 generates the PAI header with the caller’s number. Some vendors may also require the number in a specific format, which you can achieve with the Caller dial plan setting.
Issue 2: Wrong Number in PAI Header
If the PAI header contains an incorrect number, check the chain of caller number extraction. Start with the mapping gateway’s Caller setting to verify the correct source field is being used. Then check if any dial plans on the mapping gateway are transforming the number before it reaches the routing gateway. Finally, verify the Caller dial plan on the routing gateway’s PAI configuration is applying the correct transformation.
Issue 3: Caller ID Displayed When Privacy Is Requested
If a caller requests privacy but their number is still displayed to the called party, check that the Privacy setting on the routing gateway is not set to “None”. It should be “Passthrough” to honor the caller’s privacy request, or “Id” to always add the privacy header. Also verify that the mapping gateway’s “Support Privacy” option is enabled so that privacy requests from the caller’s device are forwarded.
⚠️ Problem
🔍 Likely Cause
✅ Solution
Vendor rejects calls
PAI set to None
Change PAI to Caller
Wrong number in PAI
Dial plan misconfiguration
Check caller extraction and dial plans
Privacy not honored
Privacy set to None
Set Privacy to Passthrough or Id
PAI missing country code
No caller dial plan
Add dial plan to prepend country code
Custom headers lost
Extra headers not allowed
Enable allow all/specified extra headers
Best Practices for VOS3000 P-Asserted-Identity Configuration
Following these best practices ensures your VOS3000 P-Asserted-Identity configuration works correctly and complies with industry standards.
PAI Configuration by Vendor Type
🏢 Vendor Type
⚙️ PAI Setting
🔒 Privacy
📝 Notes
Standard SIP trunk
Caller
Passthrough
Most common configuration
Legacy H323 gateway
None
None
H323 does not use PAI
Emergency services
Caller
None
Must always show caller ID
Privacy-required route
Caller
Id
Always hide caller ID display
Testing PAI Configuration
After configuring VOS3000 P-Asserted-Identity, test with actual calls to verify the headers are being set correctly. Use a SIP phone or softphone to place a test call and examine the SIP messages at the vendor’s side. Verify that the PAI header contains the correct number in the expected format, and that the Privacy header is present when required. For detailed call testing instructions, see our VOS3000 call test and troubleshooting guide.
Frequently Asked Questions About VOS3000 P-Asserted-Identity
❓ What is the difference between PAI and P-Preferred-Identity in VOS3000?
P-Asserted-Identity (PAI) is used by network servers (like VOS3000) to assert the identity of the calling party to other trusted network elements. P-Preferred-Identity (PPI) is used by user agents (like SIP phones) to indicate their preferred identity to the network. In VOS3000, PAI is the primary header for caller ID presentation to vendors, while PPI is rarely needed and is typically set to “None” in most deployments.
❓ Should I set PAI to “Passthrough” or “Caller”?
Use “Caller” in most cases because it ensures VOS3000 generates the PAI header from the verified caller number in its database. Use “Passthrough” only when you fully trust the upstream device to provide accurate PAI values and you want to preserve them unchanged. The risk with “Passthrough” is that incorrect or spoofed PAI values from the upstream could be forwarded to your vendor.
❓ Why does my vendor require a specific number format in the PAI header?
Vendors use the PAI header for billing, routing, and regulatory compliance. They need the number in a consistent format (usually E.164 with country code and plus sign) to correctly identify the calling party and apply the appropriate rates. Use the Caller dial plan on the routing gateway to transform the number into the format your vendor requires.
❓ How do I hide caller ID using VOS3000 P-Asserted-Identity?
Set the Privacy option to “Id” on the routing gateway to add a Privacy: id header to all outgoing calls. This signals to the called party’s network that the caller’s identity should be hidden from display. Note that the PAI header is still included (for billing and emergency purposes), but the called party’s device should not show the caller ID to the end user.
❓ Can I set different PAI configurations for different vendors?
Yes, each routing gateway in VOS3000 has its own independent PAI configuration. This means you can configure one vendor with PAI set to “Caller” and a specific dial plan, while another vendor uses “Passthrough” or “None”. This flexibility is essential when working with multiple vendors that have different caller ID requirements.
❓ Where can I get professional help with VOS3000 PAI configuration?
Our VOS3000 specialists can configure PAI headers, dial plans, and privacy settings for your specific vendor requirements. Contact us on WhatsApp at +8801911119966 for expert assistance with your VOS3000 caller ID configuration.
Configure Your VOS3000 Caller ID with Expert Help
Proper VOS3000 P-Asserted-Identity configuration ensures that your calls are accepted by vendors, comply with regulations, and present the correct caller ID to end users. The configuration options are powerful but require careful setup to work correctly across all your vendor relationships.
📱 Contact us on WhatsApp: +8801911119966
Our team provides complete VOS3000 caller ID configuration services, from PAI header setup to dial plan optimization and privacy configuration. We can help you ensure that your caller ID is correctly presented to every vendor in your routing infrastructure.
📞 Need Professional VOS3000 Setup Support?
For professional VOS3000 installations and deployment, VOS3000 Server Rental Solution:
VOS3000 iptables SIP Scanner: Block OPTIONS Floods Without Fail2Ban
Every VOS3000 operator who exposes SIP port 5060 to the internet has experienced the relentless pounding of SIP scanners. These automated tools send thousands of SIP OPTIONS requests per second, probing your server for open accounts, valid extensions, and authentication weaknesses. A VOS3000 iptables SIP scanner defense strategy using pure iptables rules — without the overhead of Fail2Ban — is the most efficient and reliable way to stop these attacks at the network level before they consume your server resources. This guide provides complete, production-tested iptables rules and VOS3000 native security configurations that will protect your softswitch from SIP OPTIONS floods and scanner probes.
The problem with relying on Fail2Ban for VOS3000 SIP scanner protection is that Fail2Ban parses log files reactively — it only blocks an IP after the attack has already reached your application layer and consumed CPU processing those requests. Pure iptables rules, on the other hand, drop malicious packets at the kernel level before they ever reach VOS3000, resulting in zero resource waste. When you combine kernel-level packet filtering with VOS3000 native features like IP whitelist authentication, Web Access Control (Manual Section 2.14.1), and mapping gateway rate limiting, you create an impenetrable defense that stops SIP scanners dead in their tracks.
In this comprehensive guide, we cover every aspect of building a VOS3000 iptables SIP scanner defense system: from understanding how SIP scanners operate and identifying attacks in your logs, to implementing iptables string-match rules, connlimit connection tracking, recent module rate limiting, and VOS3000 native security features. All configurations reference the VOS3000 V2.1.9.07 Manual and have been verified in production environments. For expert assistance with your VOS3000 security, contact us on WhatsApp at +8801911119966.
Table of Contents
How VOS3000 iptables SIP Scanner Attacks Waste Server Resources
SIP scanners are automated tools that systematically probe VoIP servers on port 5060 (UDP and TCP). They send SIP OPTIONS requests, REGISTER attempts, and INVITE probes to discover valid accounts and weak passwords. Understanding exactly how these attacks affect your VOS3000 server is the first step toward building an effective defense.
The SIP OPTIONS Flood Mechanism
A SIP OPTIONS request is a legitimate SIP method used to query a server or user agent about its capabilities. However, SIP scanners abuse this method by sending thousands of OPTIONS requests per minute from a single IP address or from distributed sources. Each OPTIONS request that reaches VOS3000 must be processed by the SIP stack, which allocates memory, parses the SIP message, generates a response, and sends it back. At high volumes, this processing consumes significant CPU and memory resources that should be serving your legitimate call traffic.
The impact of a SIP OPTIONS flood on an unprotected VOS3000 server includes elevated CPU usage on the SIP processing threads, increased memory consumption for tracking thousands of short-lived SIP dialogs, degraded call setup times for legitimate calls, potential SIP socket buffer overflow causing dropped legitimate SIP messages, and inflated log files that make it difficult to identify real problems. A severe SIP OPTIONS flood can effectively create a denial-of-service condition where your VOS3000 server is too busy responding to scanner probes to process real calls.
⚠️ Resource
🔬 Normal Load
💥 Under SIP Scanner Flood
📉 Impact on Service
CPU Usage
15-30%
70-99%
Delayed call setup, audio issues
Memory
Steady state
Rapidly increasing
Potential OOM kill of processes
SIP Socket Buffer
Normal queue
Overflow / packet drop
Lost legitimate SIP messages
Log Files
Manageable size
GBs per hour
Disk space exhaustion
Call Setup Time
1-3 seconds
5-30+ seconds
Customer complaints, lost revenue
Network Bandwidth
Normal SIP traffic
Saturated with probe traffic
Increased latency, jitter
Common VOS3000 iptables SIP Scanner Attack Patterns
SIP scanners targeting VOS3000 servers typically follow predictable patterns that can be identified and blocked with iptables rules. The most common attack patterns include rapid-fire SIP OPTIONS probes used to check if your server is alive and responding, brute-force REGISTER attempts with common username/password combinations, SIP INVITE probes to discover valid extension numbers, scanning from multiple IP addresses in the same subnet (distributed scanning), and scanning with spoofed or randomized User-Agent headers to avoid simple pattern matching. Each of these patterns has a distinctive signature that iptables can detect and block at the kernel level, before VOS3000 ever processes the malicious request.
The key insight for building an effective VOS3000 iptables SIP scanner defense is that legitimate SIP traffic and scanner traffic have fundamentally different behavioral signatures. Legitimate SIP clients send a small number of requests per minute, maintain established dialog states, and follow the SIP protocol flow. Scanners, on the other hand, send high volumes of stateless requests, often with identical or semi-random content, and never complete legitimate call flows. By targeting these behavioral differences, your iptables rules can block scanners with minimal risk of blocking legitimate traffic.
Identifying VOS3000 iptables SIP Scanner Attacks from Logs
Before implementing iptables rules, you need to confirm that your VOS3000 server is actually under a SIP scanner attack. VOS3000 provides several logging mechanisms that reveal scanner activity, and knowing how to read these logs is essential for both detection and for calibrating your iptables rules appropriately.
Checking VOS3000 SIP Logs for Scanner Activity
The VOS3000 SIP logs are located in the /home/vos3000/log/ directory. The key log files to monitor include sipproxy.log for SIP proxy activity, mbx.log for media box and call processing, and the system-level /var/log/messages for kernel-level network information. When a SIP scanner is active, you will see repetitive patterns of unauthenticated SIP requests from the same or similar IP addresses.
# Check VOS3000 SIP logs for scanner patterns
# Look for repeated OPTIONS from same IP
rg "OPTIONS" /home/vos3000/log/sipproxy.log | tail -100
# Count requests per source IP (identify top scanners)
rg "OPTIONS" /home/vos3000/log/sipproxy.log | \
awk '{print $1}' | sort | uniq -c | sort -rn | head -20
# Check for failed registration attempts
rg "401 Unauthorized|403 Forbidden" /home/vos3000/log/sipproxy.log | \
tail -50
# Monitor real-time SIP traffic on port 5060
tcpdump -n port 5060 -A -s 0 | rg "OPTIONS"
Using tcpdump to Detect SIP Scanner Floods
When you suspect a SIP scanner attack, tcpdump provides the most immediate and detailed view of the traffic hitting your server. The following tcpdump commands help you identify the source, volume, and pattern of SIP scanner traffic targeting your VOS3000 server.
# Real-time SIP packet count per source IP
tcpdump -n -l port 5060 | \
awk '{print $3}' | cut -d. -f1-4 | \
sort | uniq -c | sort -rn
# Count SIP OPTIONS per second
tcpdump -n port 5060 -l 2>/dev/null | \
rg -c "OPTIONS"
# Capture and display full SIP OPTIONS packets
tcpdump -n port 5060 -A -s 0 -c 50 | \
rg -A 20 "OPTIONS sip:"
# Check UDP connection rate from specific IP
tcpdump -n src host SUSPICIOUS_IP and port 5060 -l | \
awk '{print NR}'
🔍 Detection Method
💻 Command
🎯 What It Reveals
⚡ Action Threshold
Log analysis
rg “OPTIONS” sipproxy.log
Scanner IP addresses
50+ OPTIONS/min from one IP
Real-time capture
tcpdump -n port 5060
Packet volume and rate
100+ packets/sec from one IP
Connection tracking
conntrack -L | wc -l
Total connection count
Exceeds nf_conntrack_max
Netstat analysis
netstat -anup | grep 5060
Active UDP connections
Thousands from few IPs
System load
top / htop
CPU and memory pressure
Sustained CPU > 70%
Disk I/O
iostat -x 1
Log write rate
Disk I/O > 80%
Why Pure iptables Beats Fail2Ban for VOS3000 iptables SIP Scanner Defense
Many VOS3000 operators initially turn to Fail2Ban for SIP scanner protection because it is well-documented and widely recommended in general VoIP security guides. However, Fail2Ban has significant drawbacks when used as a VOS3000 iptables SIP scanner defense mechanism, and pure iptables rules provide superior protection in every measurable way.
The Fail2Ban Reactive Approach vs. iptables Proactive Approach
Fail2Ban operates by monitoring log files for patterns that indicate malicious activity, then dynamically creating iptables rules to block the offending IP addresses. This reactive approach means that the attack traffic must first reach VOS3000, be processed by the SIP stack, generate log entries, and then be parsed by Fail2Ban before any blocking occurs. The time delay between the start of an attack and Fail2Ban’s response can be several minutes, during which your VOS3000 server is processing thousands of malicious SIP requests.
Pure iptables rules, by contrast, operate at the kernel packet filtering level. When a packet arrives on the network interface, iptables evaluates it against your rules before it is delivered to any user-space process, including VOS3000. A malicious SIP OPTIONS packet that matches a rate-limiting rule is dropped instantly at the kernel level, consuming only the minimal CPU cycles needed for rule evaluation. VOS3000 never sees the packet, never processes it, and never writes a log entry for it. This proactive approach provides zero-latency protection with zero application-layer overhead.
⚖️ Comparison
🔴 Fail2Ban
🟢 Pure iptables
Blocking level
Application (reactive)
Kernel (proactive)
Response time
Seconds to minutes delay
Instant (packet-level)
Resource usage
High (Python process + log parsing)
Minimal (kernel only)
VOS3000 load
Processes all packets first
Drops malicious packets before VOS3000
Dependencies
Python, Fail2Ban, log config
None (iptables is built-in)
Log pollution
High (all attacks logged before block)
None (dropped packets not logged)
Rate limiting
Indirect (via jail config)
Direct (connlimit, recent, hashlimit)
String matching
Not available
Yes (string module)
Maintenance
Regular filter updates needed
Set once, works forever
The pure iptables approach for your VOS3000 iptables SIP scanner defense also eliminates the risk of Fail2Ban itself becoming a performance problem. Fail2Ban runs as a Python daemon that continuously reads log files, which adds its own CPU and I/O overhead. On a server under heavy SIP scanner attack, the log files grow rapidly, and Fail2Ban’s log parsing can consume significant resources — ironically adding to the very load you are trying to reduce. Pure iptables rules have no daemon, no log parsing, and no Python overhead; they run as part of the Linux kernel’s network stack.
Essential VOS3000 iptables SIP Scanner Rules: String Drop for OPTIONS
The most powerful weapon in your VOS3000 iptables SIP scanner defense arsenal is the iptables string match module. This module allows you to inspect the content of network packets and drop those that contain specific SIP method strings. By dropping packets that contain the SIP OPTIONS method string, you can instantly block the most common type of SIP scanner probe without affecting legitimate INVITE, REGISTER, ACK, BYE, and CANCEL messages that your VOS3000 server needs to process.
iptables String-Match Rule to Drop SIP OPTIONS
The following iptables rule uses the string module to inspect UDP packets destined for port 5060 and drop any that contain the text “OPTIONS sip:” in their payload. This is the most effective single rule for blocking SIP scanners because the vast majority of scanner probes use the OPTIONS method.
# ============================================
# VOS3000 iptables SIP Scanner: String Drop Rules
# ============================================
# Drop SIP OPTIONS probes from unknown sources
# This single rule blocks 90%+ of SIP scanner traffic
iptables -I INPUT -p udp --dport 5060 -m string \
--string "OPTIONS sip:" \
--algo bm -j DROP
# Also drop SIP OPTIONS on TCP port 5060
iptables -I INPUT -p tcp --dport 5060 -m string \
--string "OPTIONS sip:" \
--algo bm -j DROP
# Drop known SIP scanner User-Agent strings
iptables -I INPUT -p udp --dport 5060 -m string \
--string "friendly-scanner" \
--algo bm -j DROP
iptables -I INPUT -p udp --dport 5060 -m string \
--string "VaxSIPUserAgent" \
--algo bm -j DROP
iptables -I INPUT -p udp --dport 5060 -m string \
--string "sipvicious" \
--algo bm -j DROP
iptables -I INPUT -p udp --dport 5060 -m string \
--string "SIPScan" \
--algo bm -j DROP
# Save rules permanently
service iptables save
The --algo bm parameter specifies the Boyer-Moore string search algorithm, which is fast and efficient for fixed-string matching. An alternative is --algo kmp (Knuth-Morris-Pratt), which uses less memory but is slightly slower for most patterns. For VOS3000 iptables SIP scanner defense, Boyer-Moore is the recommended choice because the patterns are fixed strings and speed is critical.
Allowing Legitimate SIP OPTIONS from Trusted IPs
Before applying the blanket OPTIONS drop rule, you should insert accept rules for your trusted SIP peers and gateway IPs. iptables processes rules in order, so placing accept rules before the drop rule ensures that legitimate OPTIONS requests from known peers are allowed through while scanner OPTIONS from unknown IPs are dropped.
# ============================================
# Allow trusted SIP peers before dropping OPTIONS
# ============================================
# Allow SIP from trusted gateway IP #1
iptables -I INPUT -p udp -s 203.0.113.10 --dport 5060 -j ACCEPT
# Allow SIP from trusted gateway IP #2
iptables -I INPUT -p udp -s 203.0.113.20 --dport 5060 -j ACCEPT
# Allow SIP from entire trusted subnet
iptables -I INPUT -p udp -s 198.51.100.0/24 --dport 5060 -j ACCEPT
# THEN drop SIP OPTIONS from all other sources
iptables -A INPUT -p udp --dport 5060 -m string \
--string "OPTIONS sip:" \
--algo bm -j DROP
# Save rules permanently
service iptables save
🛡️ Rule Type
📝 iptables Match
🎯 Blocks
⚡ Priority
Trusted IP accept
-s TRUSTED_IP –dport 5060 -j ACCEPT
Nothing (allows traffic)
First (highest)
OPTIONS string drop
-m string –string “OPTIONS sip:”
All SIP OPTIONS probes
Second
Scanner UA drop
-m string –string “friendly-scanner”
Known scanner User-Agents
Third
SIPVicious drop
-m string –string “sipvicious”
SIPVicious tool probes
Third
Rate limit (general)
-m recent –hitcount 20 –seconds 60
Any IP exceeding rate
Fourth
Limiting UDP Connections Per IP with VOS3000 iptables SIP Scanner Rules
Beyond string matching, the iptables connlimit module provides another powerful tool for your VOS3000 iptables SIP scanner defense. The connlimit module allows you to restrict the number of parallel connections a single IP address can make to your server. Since SIP scanners typically open many simultaneous connections to probe multiple extensions or accounts, connlimit rules can effectively cap the number of concurrent SIP connections from any single source IP.
The connlimit module matches when the number of concurrent connections from a single IP address exceeds a specified limit. For VOS3000, a legitimate SIP peer typically maintains 1-5 concurrent connections for signaling, while a scanner may open dozens or hundreds. Setting a reasonable connlimit threshold allows normal SIP operation while blocking scanner floods.
# ============================================
# VOS3000 iptables SIP Scanner: connlimit Rules
# ============================================
# Limit concurrent UDP connections to port 5060 per source IP
# Allow maximum 10 concurrent SIP connections per IP
iptables -A INPUT -p udp --dport 5060 \
-m connlimit --connlimit-above 10 \
-j REJECT --reject-with icmp-port-unreachable
# More aggressive limit for non-trusted IPs
# Allow maximum 5 concurrent SIP connections per IP
# Insert BEFORE trusted IP accept rules do not match this
iptables -I INPUT 3 -p udp --dport 5060 \
-m connlimit --connlimit-above 5 \
--connlimit-mask 32 \
-j DROP
# Limit per /24 subnet (blocks distributed scanners)
iptables -A INPUT -p udp --dport 5060 \
-m connlimit --connlimit-above 30 \
--connlimit-mask 24 \
-j DROP
# Save rules permanently
service iptables save
The --connlimit-mask 32 parameter applies the limit per individual IP address (a /32 mask covers exactly one IP). Using --connlimit-mask 24 applies the limit per /24 subnet, which catches distributed scanners that use multiple IPs within the same subnet range. For a comprehensive VOS3000 iptables SIP scanner defense, use both per-IP and per-subnet limits to catch both concentrated and distributed scanning patterns.
Recent Module: Rate Limiting SIP Requests Without Fail2Ban
The iptables recent module maintains a dynamic list of source IP addresses and can match based on how many times an IP has appeared in the list within a specified time window. This is the most versatile rate-limiting tool for your VOS3000 iptables SIP scanner defense because it can track request rates over time, not just concurrent connections.
# ============================================
# VOS3000 iptables SIP Scanner: Recent Module Rules
# ============================================
# Create a rate-limiting chain for SIP traffic
iptables -N SIP_RATE_LIMIT
# Add source IP to the recent list
iptables -A SIP_RATE_LIMIT -m recent --set --name sip_scanner
# Check if IP exceeded 20 requests in 60 seconds
iptables -A SIP_RATE_LIMIT -m recent --update \
--seconds 60 --hitcount 20 \
--name sip_scanner \
-j LOG --log-prefix "SIP-RATE-LIMIT: "
# Drop if exceeded threshold
iptables -A SIP_RATE_LIMIT -m recent --update \
--seconds 60 --hitcount 20 \
--name sip_scanner \
-j DROP
# Accept if under threshold
iptables -A SIP_RATE_LIMIT -j ACCEPT
# Direct SIP traffic to the rate-limiting chain
iptables -A INPUT -p udp --dport 5060 -j SIP_RATE_LIMIT
# Save rules permanently
service iptables save
This rate-limiting approach is superior to Fail2Ban for VOS3000 iptables SIP scanner defense because it operates in real-time at the kernel level. A scanner that sends 20 or more SIP requests within 60 seconds is automatically dropped, with no log file parsing delay and no Python daemon overhead. You can adjust the --hitcount and --seconds parameters to match your legitimate traffic patterns — if your real SIP peers send more frequent keepalive OPTIONS requests, increase the hitcount threshold accordingly.
The following comprehensive iptables script combines all the techniques discussed above into a single, production-ready firewall configuration for your VOS3000 server. This script implements the full VOS3000 iptables SIP scanner defense strategy with trusted IP whitelisting, string-match dropping, connlimit restrictions, and recent module rate limiting.
#!/bin/bash
# ============================================
# VOS3000 iptables SIP Scanner: Complete Firewall Script
# Version: 1.0 | Date: April 2026
# ============================================
# Define trusted SIP peer IPs (space-separated)
TRUSTED_SIP_IPS="203.0.113.10 203.0.113.20 198.51.100.0/24"
# Flush existing rules (CAUTION: run from console only)
iptables -F
iptables -X
# Create custom chains
iptables -N SIP_TRUSTED
iptables -N SIP_SCANNER_BLOCK
iptables -N SIP_RATE_LIMIT
# ---- LOOPBACK ----
iptables -A INPUT -i lo -j ACCEPT
# ---- ESTABLISHED CONNECTIONS ----
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# ---- SSH ACCESS (restrict to your IP) ----
iptables -A INPUT -p tcp -s YOUR_ADMIN_IP --dport 22 -j ACCEPT
# ---- VOS3000 WEB INTERFACE ----
iptables -A INPUT -p tcp --dport 80 -s YOUR_ADMIN_IP -j ACCEPT
iptables -A INPUT -p tcp --dport 8080 -s YOUR_ADMIN_IP -j ACCEPT
# ---- TRUSTED SIP PEERS ----
for IP in $TRUSTED_SIP_IPS; do
iptables -A SIP_TRUSTED -s $IP -j ACCEPT
done
# Route port 5060 UDP through trusted chain first
iptables -A INPUT -p udp --dport 5060 -j SIP_TRUSTED
# ---- SIP SCANNER BLOCK CHAIN ----
# Drop SIP OPTIONS from unknown sources
iptables -A SIP_SCANNER_BLOCK -m string \
--string "OPTIONS sip:" \
--algo bm -j DROP
# Drop known scanner User-Agent strings
iptables -A SIP_SCANNER_BLOCK -m string \
--string "friendly-scanner" \
--algo bm -j DROP
iptables -A SIP_SCANNER_BLOCK -m string \
--string "VaxSIPUserAgent" \
--algo bm -j DROP
iptables -A SIP_SCANNER_BLOCK -m string \
--string "sipvicious" \
--algo bm -j DROP
iptables -A SIP_SCANNER_BLOCK -m string \
--string "SIPScan" \
--algo bm -j DROP
iptables -A SIP_SCANNER_BLOCK -m string \
--string "sipcli" \
--algo bm -j DROP
# Route port 5060 UDP through scanner block chain
iptables -A INPUT -p udp --dport 5060 -j SIP_SCANNER_BLOCK
# ---- RATE LIMIT CHAIN ----
# Limit concurrent connections per IP (max 10)
iptables -A SIP_RATE_LIMIT -p udp --dport 5060 \
-m connlimit --connlimit-above 10 \
--connlimit-mask 32 \
-j DROP
# Rate limit: max 20 requests per 60 seconds per IP
iptables -A SIP_RATE_LIMIT -m recent --set --name sip_rate
iptables -A SIP_RATE_LIMIT -m recent --update \
--seconds 60 --hitcount 20 \
--name sip_rate -j DROP
# Accept legitimate SIP traffic
iptables -A SIP_RATE_LIMIT -j ACCEPT
# Route port 5060 UDP through rate limit chain
iptables -A INPUT -p udp --dport 5060 -j SIP_RATE_LIMIT
# ---- MEDIA PORTS (RTP) ----
iptables -A INPUT -p udp --dport 10000:20000 -j ACCEPT
# ---- DEFAULT DROP ----
iptables -A INPUT -j DROP
# ---- SAVE ----
service iptables save
echo "VOS3000 iptables SIP scanner firewall applied successfully!"
The firewall script processes SIP traffic through four chains in order: first the SIP_TRUSTED chain (allowing known peer IPs), then the SIP_SCANNER_BLOCK chain (dropping packets with scanner signatures via string-match), then the SIP_RATE_LIMIT chain (enforcing connlimit and recent module rate limits), and finally the INPUT default policy (DROP all other traffic). This ordered processing ensures that trusted peers bypass all restrictions while unknown traffic is progressively filtered through increasingly strict rules.
For more advanced firewall configurations including extended iptables rules and kernel tuning, refer to our VOS3000 extended firewall guide which provides additional hardening techniques for CentOS servers running VOS3000.
VOS3000 Native IP Whitelist: Web Access Control (Section 2.14.1)
While iptables provides kernel-level packet filtering, VOS3000 also includes native IP whitelist functionality through the Web Access Control feature. This feature, documented in VOS3000 Manual Section 2.14.1 (Interface Management > Web Access Control), allows you to restrict access to the VOS3000 web management interface based on source IP addresses. Combined with your VOS3000 iptables SIP scanner rules, the Web Access Control feature adds another layer of defense by ensuring that only authorized administrators can access the management interface.
Configuring VOS3000 Web Access Control
The Web Access Control feature in VOS3000 limits which IP addresses can access the web management portal. This is critically important because SIP scanners and attackers often target the web interface as well as the SIP port. If an attacker gains access to your VOS3000 web interface, they can modify routing, create fraudulent accounts, and compromise your entire platform.
To configure Web Access Control in VOS3000, follow these steps as documented in the VOS3000 Manual Section 2.14.1:
Navigate to Interface Management: In the VOS3000 client, go to Operation Management > Interface Management > Web Access Control
Access the configuration panel: Double-click “Web Access Control” to open the IP whitelist editor
Add allowed IP addresses: Enter the IP addresses or CIDR ranges that should be permitted to access the web interface
Apply the configuration: Click Apply to activate the whitelist
Verify access: Test that you can still access the web interface from your authorized IP
🔐 Setting
📝 Value
📖 Manual Reference
💡 Recommendation
Feature
Web Access Control
Section 2.14.1
Always enable in production
Navigation
Interface Management > Web Access Control
Page 210
Add all admin IPs
IP Format
Single IP or CIDR range
Section 2.14.1
Use CIDR for admin subnets
Default Policy
Deny all not in whitelist
Section 2.14.1
Keep default deny policy
Scope
Web management interface only
Page 210
Pair with iptables for SIP
It is important to understand that the VOS3000 Web Access Control feature only protects the web management interface — it does not protect the SIP signaling port 5060. This is why you must combine Web Access Control with the VOS3000 iptables SIP scanner rules described earlier in this guide. The Web Access Control feature protects the management plane, while iptables rules protect the signaling plane. Together, they provide complete coverage for your VOS3000 server.
The VOS3000 mapping gateway configuration includes authentication mode settings that directly affect your vulnerability to SIP scanner attacks. Understanding and properly configuring these authentication modes is an essential component of your VOS3000 iptables SIP scanner defense strategy, as the authentication mode determines how VOS3000 validates incoming SIP traffic from mapping gateways (your customer-facing gateways).
Understanding the Three Authentication Modes
VOS3000 supports three authentication modes for mapping gateways, each providing a different balance between security and flexibility. These modes are configured in the mapping gateway additional settings and determine how VOS3000 authenticates SIP requests arriving from customer endpoints.
IP Authentication Mode: In IP authentication mode, VOS3000 accepts SIP requests only from pre-configured IP addresses. Any SIP request from an IP address not listed in the mapping gateway configuration is rejected, regardless of the username or password provided. This is the most secure authentication mode for your VOS3000 iptables SIP scanner defense because SIP scanners cannot authenticate from arbitrary IP addresses. However, it requires that all your customers have static IP addresses, which may not be practical for all deployments.
IP+Port Authentication Mode: This mode extends IP authentication by also requiring the correct source port. VOS3000 validates both the source IP address and the source port of incoming SIP requests. This provides even stronger security than IP-only authentication because it prevents IP spoofing attacks where an attacker might forge packets from a trusted IP address. However, IP+Port authentication can cause issues with NAT environments where source ports may change during a session.
Password Authentication Mode: In password authentication mode, VOS3000 authenticates SIP requests based on username and password credentials. This mode is the most flexible because it works with customers who have dynamic IP addresses, but it is also the most vulnerable to SIP scanner brute-force attacks. If you use password authentication, your VOS3000 iptables SIP scanner rules become even more critical because scanners will attempt to guess credentials.
🔐 Auth Mode
🛡️ Security Level
🎯 Validates
⚠️ Vulnerability
💡 Best For
IP
🟢 High
Source IP only
IP spoofing (rare)
Static IP customers
IP+Port
🟢 Very High
Source IP + Port
NAT issues
Dedicated SIP trunks
Password
🟡 Medium
Username + Password
Brute force attacks
Dynamic IP customers
Configuring Mapping Gateway Authentication for Maximum Security
To configure the authentication mode on a VOS3000 mapping gateway, follow these steps:
Open gateway properties: Double-click the mapping gateway to open its configuration
Set authentication mode: In the main configuration tab, select the desired authentication mode from the dropdown (IP / IP+Port / Password)
Configure authentication details: If IP mode, add the customer’s IP address in the gateway prefix or additional settings. If Password mode, ensure strong passwords are set
Apply changes: Click Apply to save the configuration
For the strongest VOS3000 iptables SIP scanner defense, use IP authentication mode whenever possible. This mode inherently blocks SIP scanners because scanner traffic originates from IP addresses not configured in your mapping gateways. When IP authentication is combined with iptables string-drop rules, your VOS3000 server becomes virtually immune to SIP scanner probes — the iptables rules block the scanner traffic at the kernel level, and the IP authentication mode blocks any traffic that somehow passes through iptables.
Rate Limit Setting on Mapping Gateway for CPS Control
VOS3000 includes built-in rate limiting on mapping gateways that provides call-per-second (CPS) control at the application level. This feature complements your VOS3000 iptables SIP scanner defense by adding a secondary rate limit that operates even if some scanner traffic passes through your iptables rules. The rate limit setting on mapping gateways restricts the maximum number of calls that can be initiated through the gateway per second, preventing any single customer or gateway from overwhelming your server with call attempts.
Configuring Mapping Gateway Rate Limits
The rate limit setting is found in the mapping gateway additional settings. This feature allows you to specify the maximum number of calls per second (CPS) that the gateway will accept. When the call rate exceeds this limit, VOS3000 rejects additional calls with a SIP 503 Service Unavailable response, protecting your server resources from overload.
# ============================================
# VOS3000 Mapping Gateway Rate Limit Configuration
# ============================================
# Navigate to: Operation Management > Gateway Operation > Mapping Gateway
# Right-click the mapping gateway > Additional Settings
#
# Configure these rate-limiting parameters:
#
# 1. Rate Limit (CPS): Maximum calls per second
# Recommended values:
# - Small customer: 5-10 CPS
# - Medium customer: 10-30 CPS
# - Large customer: 30-100 CPS
# - Premium customer: 100-200 CPS
#
# 2. Max Concurrent Calls: Maximum simultaneous calls
# Recommended values:
# - Small customer: 30-50 channels
# - Medium customer: 50-200 channels
# - Large customer: 200-500 channels
# - Premium customer: 500-2000 channels
#
# 3. Conversation Limitation (seconds): Max call duration
# Recommended: 3600 seconds (1 hour) for most customers
#
# Apply the settings and restart the gateway if required.
📊 Customer Tier
⚡ CPS Limit
📞 Max Concurrent
⏱️ Max Duration (s)
🛡️ Scanner Risk
Small / Basic
5-10
30-50
1800
🟢 Low (tight limits)
Medium
10-30
50-200
3600
🟡 Medium
Large
30-100
200-500
3600
🟠 Higher (needs monitoring)
Premium / Wholesale
100-200
500-2000
7200
🔴 High (strict iptables needed)
The mapping gateway rate limit works in conjunction with your VOS3000 iptables SIP scanner rules to provide multi-layered protection. The iptables rules block the initial scanner probes and floods at the kernel level, preventing the traffic from reaching VOS3000 at all. The mapping gateway rate limit acts as a safety net, catching any excessive call attempts that might pass through the iptables rules — for example, a sophisticated attacker who has somehow obtained valid credentials but is using them to flood your server with calls. This layered approach ensures that your server remains protected even if one layer is bypassed.
Advanced VOS3000 iptables SIP Scanner Techniques: hashlimit and conntrack
For operators who need even more granular control over their VOS3000 iptables SIP scanner defense, the hashlimit and conntrack modules provide advanced rate-limiting and connection-tracking capabilities. These modules are particularly useful in high-traffic environments where you need to distinguish between legitimate high-volume traffic from trusted peers and malicious scanner floods from unknown sources.
hashlimit Module: Per-Destination Rate Limiting
The hashlimit module is the most sophisticated rate-limiting module available in iptables. Unlike the recent module, which maintains a simple list of source IPs, hashlimit uses a hash table to track rates per destination, per source-destination pair, or per any combination of packet parameters. This allows you to create rate limits that account for both the source and destination of SIP traffic, providing more precise control than simple per-IP rate limiting.
# ============================================
# VOS3000 iptables SIP Scanner: hashlimit Rules
# ============================================
# Limit SIP requests to 10 per second per source IP
# with a burst allowance of 20 packets
iptables -A INPUT -p udp --dport 5060 \
-m hashlimit \
--hashlimit 10/s \
--hashlimit-burst 20 \
--hashlimit-mode srcip \
--hashlimit-name sip_limit \
--hashlimit-htable-expire 30000 \
-j ACCEPT
# Drop all SIP traffic that exceeds the hash limit
iptables -A INPUT -p udp --dport 5060 -j DROP
# View hashlimit statistics
cat /proc/net/ipt_hashlimit/sip_limit
# Save rules permanently
service iptables save
The --hashlimit-mode srcip parameter creates a separate rate limit for each source IP address. The --hashlimit-htable-expire 30000 parameter sets the hash table entry expiration to 30 seconds, meaning that an IP address that stops sending traffic will be removed from the rate-limiting table after 30 seconds. The burst parameter (--hashlimit-burst 20) allows a short burst of up to 20 packets above the rate limit before enforcing the cap, which accommodates the natural burstiness of legitimate SIP traffic.
conntrack Module: Connection Tracking Tuning
The Linux connection tracking system (conntrack) is essential for iptables stateful filtering, but its default parameters may be insufficient for a VOS3000 server under SIP scanner attack. When a scanner floods your server with SIP requests, each request creates a conntrack entry, and the conntrack table can fill up quickly. Once the conntrack table is full, new connections (including legitimate ones) are dropped. Tuning conntrack parameters is therefore an important part of your VOS3000 iptables SIP scanner defense.
# ============================================
# VOS3000 iptables SIP Scanner: conntrack Tuning
# ============================================
# Check current conntrack maximum
cat /proc/sys/net/nf_conntrack_max
# Check current conntrack count
cat /proc/sys/net/netfilter/nf_conntrack_count
# Increase conntrack maximum for VOS3000 under attack
echo 1048576 > /proc/sys/net/nf_conntrack_max
# Reduce UDP timeout to free entries faster
echo 30 > /proc/sys/net/netfilter/nf_conntrack_udp_timeout
echo 60 > /proc/sys/net/netfilter/nf_conntrack_udp_timeout_stream
# Make changes permanent across reboots
echo "net.netfilter.nf_conntrack_max = 1048576" >> /etc/sysctl.conf
echo "net.netfilter.nf_conntrack_udp_timeout = 30" >> /etc/sysctl.conf
echo "net.netfilter.nf_conntrack_udp_timeout_stream = 60" >> /etc/sysctl.conf
# Apply sysctl changes
sysctl -p
⚙️ Parameter
🔢 Default
✅ Recommended
💡 Reason
nf_conntrack_max
65536
1048576
Prevent table overflow under attack
nf_conntrack_udp_timeout
30s
30s
Quick cleanup of scanner entries
nf_conntrack_udp_timeout_stream
180s
60s
Free entries faster for stopped flows
nf_conntrack_tcp_timeout_established
432000s
7200s
Reduce stale TCP connections
Proper conntrack tuning ensures that your VOS3000 server can handle the increased connection table entries created by SIP scanner attacks without dropping legitimate traffic. The reduced UDP timeouts are particularly important because SIP uses UDP, and shorter timeouts mean that scanner connection entries are cleaned up faster, freeing space for legitimate connections.
Monitoring and Verifying Your VOS3000 iptables SIP Scanner Defense
After implementing your VOS3000 iptables SIP scanner rules, you need to verify that they are working correctly and monitor their ongoing effectiveness. Regular monitoring ensures that your rules are blocking scanner traffic as expected and that legitimate traffic is not being affected.
Verifying iptables Rules Are Active
# ============================================
# VOS3000 iptables SIP Scanner: Verification Commands
# ============================================
# List all iptables rules with line numbers
iptables -L -n -v --line-numbers
# List only SIP-related rules
iptables -L SIP_SCANNER_BLOCK -n -v
iptables -L SIP_RATE_LIMIT -n -v
iptables -L SIP_TRUSTED -n -v
# Check recent module lists
cat /proc/net/xt_recent/sip_scanner
cat /proc/net/xt_recent/sip_rate
# Monitor iptables rule hit counters in real-time
watch -n 1 'iptables -L SIP_SCANNER_BLOCK -n -v'
# Check if specific IP is being blocked
iptables -C INPUT -s SUSPICIOUS_IP -j DROP
# View dropped packets count per rule
iptables -L INPUT -n -v | rg "DROP"
Testing Your VOS3000 iptables SIP Scanner Rules
Before relying on your iptables rules in production, test them to ensure they block scanner traffic without affecting legitimate SIP calls. The following test procedures verify each component of your VOS3000 iptables SIP scanner defense.
# ============================================
# VOS3000 iptables SIP Scanner: Testing Commands
# ============================================
# Test 1: Send SIP OPTIONS from external IP (should be dropped)
# From a test machine (NOT a trusted IP):
sipsak -s sip:YOUR_SERVER_IP:5060 OPTIONS
# Test 2: Verify OPTIONS are dropped (check counter)
iptables -L SIP_SCANNER_BLOCK -n -v | rg "OPTIONS"
# Test 3: Verify legitimate SIP call still works
# Make a test call through VOS3000 from a trusted peer
# Check VOS3000 CDR for the test call
# Test 4: Verify rate limiting works
# Send rapid SIP requests and verify blocking
for i in $(seq 1 30); do
sipsak -s sip:YOUR_SERVER_IP:5060 OPTIONS &
done
# Test 5: Check that trusted IPs bypass rate limits
# Verify that trusted IP accept rules have higher packet counts
iptables -L SIP_TRUSTED -n -v
# Test 6: Monitor server performance under simulated attack
top -b -n 5 | rg "vos3000|mbx|sip"
After completing these tests, review the iptables rule hit counters to confirm that your VOS3000 iptables SIP scanner rules are actively dropping malicious traffic. The packet and byte counters next to each rule show how many packets have been matched and dropped. If the OPTIONS string-drop rule shows a high hit count, your rules are working correctly to block SIP scanner probes.
VOS3000 iptables SIP Scanner Defense: Putting It All Together
A successful VOS3000 iptables SIP scanner defense requires integrating multiple layers of protection. Each layer addresses a different aspect of the SIP scanner threat, and together they create a comprehensive defense that is far stronger than any single measure alone.
The Five-Layer Defense Model
Your complete VOS3000 iptables SIP scanner defense should consist of five layers, each operating at a different level of the network and application stack:
Layer 1 — iptables Trusted IP Whitelist: Allow SIP traffic only from known, trusted IP addresses. All traffic from trusted IPs bypasses the scanner detection rules. This is your first line of defense and should be configured with the IP addresses of all your SIP peers and customers who use static IPs.
Layer 2 — iptables String-Match Dropping: Drop packets containing known scanner signatures including SIP OPTIONS requests from unknown sources, known scanner User-Agent strings, and other malicious patterns. This layer catches the vast majority of automated scanner traffic before it reaches VOS3000.
Layer 3 — iptables Rate Limiting: Use the connlimit, recent, and hashlimit modules to restrict the rate of SIP requests from any single IP address. This layer catches sophisticated scanners that avoid the string-match rules by using legitimate SIP methods like REGISTER or INVITE instead of OPTIONS.
Layer 4 — VOS3000 Native Security: Configure VOS3000 mapping gateway authentication mode (IP or IP+Port), rate limiting (CPS control), Web Access Control (Section 2.14.1), and dynamic blacklist features. These application-level protections catch any threats that pass through the iptables layers.
Layer 5 — Monitoring and Response: Regularly monitor iptables hit counters, VOS3000 logs, conntrack table usage, and server performance metrics. Set up automated alerts for abnormal conditions and review your security configuration regularly to adapt to new threats.
🛡️ Layer
⚙️ Mechanism
🎯 What It Blocks
📍 Where
1 – Whitelist
iptables IP accept rules
All unknown IPs (by exclusion)
Kernel / Network
2 – String Match
iptables string module
OPTIONS probes, scanner UAs
Kernel / Network
3 – Rate Limit
connlimit + recent + hashlimit
Flood attacks, brute force
Kernel / Network
4 – VOS3000 Native
Auth mode + Rate limit + WAC
Unauthenticated calls, credential attacks
Application
5 – Monitoring
Log analysis + conntrack + alerts
New and evolving threats
Operations
For a broader overview of VOS3000 security practices, see our VOS3000 security guide which covers the complete security hardening process for your softswitch platform.
🔗 Related Resources – VOS3000 iptables SIP Scanner
Frequently Asked Questions About VOS3000 iptables SIP Scanner
❓ What is a VOS3000 iptables SIP scanner and why does it target my server?
A VOS3000 iptables SIP scanner refers to the category of automated tools that systematically probe VOS3000 VoIP servers by sending SIP OPTIONS, REGISTER, and INVITE requests on port 5060. These scanners target your server because VOS3000 platforms are widely deployed in the VoIP industry, and attackers know that many operators leave their SIP ports exposed without proper firewall protection. The scanners are looking for open SIP accounts, weak passwords, and exploitable configurations that they can use for toll fraud, call spoofing, or service theft. The iptables firewall on your CentOS server is the primary tool for blocking these scanners at the network level before they can interact with VOS3000.
❓ How do I know if my VOS3000 server is under a SIP scanner attack?
You can identify a SIP scanner attack by checking your VOS3000 logs for repetitive unauthenticated SIP requests from the same or similar IP addresses. Use the command rg "OPTIONS" /home/vos3000/log/sipproxy.log | tail -100 to look for a high volume of OPTIONS requests. You can also use tcpdump to monitor real-time SIP traffic on port 5060 with tcpdump -n port 5060 -A -s 0 | rg "OPTIONS". If you see dozens or hundreds of SIP requests per minute from IPs that are not your known SIP peers, your server is likely under a scanner attack. Elevated CPU usage and slow call setup times are also indicators of a SIP scanner flood affecting your VOS3000 server.
❓ Why should I use pure iptables instead of Fail2Ban for VOS3000 iptables SIP scanner defense?
Pure iptables is superior to Fail2Ban for VOS3000 iptables SIP scanner defense because iptables operates at the Linux kernel level, dropping malicious packets before they reach VOS3000, while Fail2Ban works reactively by parsing log files after the attack traffic has already been processed by VOS3000. This means Fail2Ban allows the first wave of attack traffic to consume your server resources before it can respond, whereas iptables blocks the attack from the very first packet. Additionally, iptables has no daemon overhead (Fail2Ban runs as a Python process), supports string matching to drop packets based on SIP method content, and provides direct rate limiting through connlimit, recent, and hashlimit modules that Fail2Ban cannot match.
❓ What VOS3000 native features complement iptables for SIP scanner protection?
Several VOS3000 native features complement your iptables SIP scanner defense. The Web Access Control feature (Manual Section 2.14.1) restricts web management access to authorized IPs. The mapping gateway authentication modes (IP / IP+Port / Password) control how SIP endpoints authenticate, with IP authentication being the most secure against scanners. The rate limit setting on mapping gateways provides CPS control that prevents excessive call attempts even if some scanner traffic passes through iptables. The dynamic blacklist feature automatically blocks numbers exhibiting suspicious calling patterns. Together with iptables, these features create a comprehensive, multi-layered defense against SIP scanner attacks.
❓ Can iptables string-match rules block legitimate SIP OPTIONS from my peers?
Yes, a blanket iptables string-match rule that drops all SIP OPTIONS packets will also block legitimate OPTIONS requests from your SIP peers. This is why you must insert accept rules for trusted IP addresses BEFORE the string-match drop rules in your iptables chain. iptables processes rules in order, so if a trusted IP accept rule matches first, the traffic is accepted and the string-drop rule is never evaluated. Always configure your trusted SIP peer IPs at the top of your INPUT chain, then add the scanner-blocking rules below them. This ensures that your legitimate peers can send OPTIONS requests for keepalive and capability queries while unknown IPs are blocked.
❓ How do I configure mapping gateway rate limiting in VOS3000 to complement iptables?
To configure mapping gateway rate limiting in VOS3000, navigate to Operation Management > Gateway Operation > Mapping Gateway, right-click the gateway, and select Additional Settings. In the rate limit field, set the maximum calls per second (CPS) appropriate for the customer tier — typically 5-10 CPS for small customers and up to 100-200 CPS for premium wholesale customers. Also configure the maximum concurrent calls and conversation limitation settings. These VOS3000 rate limits complement your iptables rules by providing application-level protection against any excessive call attempts that might pass through the network-level iptables filtering, ensuring that even a compromised account cannot overwhelm your server.
❓ What conntrack tuning is needed for VOS3000 under SIP scanner attack?
Under a SIP scanner attack, the Linux conntrack table can fill up quickly because each SIP request creates a connection tracking entry. You should increase nf_conntrack_max to at least 1048576 (1 million entries) and reduce the UDP timeouts to free entries faster. Set nf_conntrack_udp_timeout to 30 seconds and nf_conntrack_udp_timeout_stream to 60 seconds. These changes can be made live via the /proc filesystem and made permanent by adding them to /etc/sysctl.conf. Without these tuning adjustments, a severe SIP scanner attack can fill the conntrack table and cause Linux to drop all new connections, including legitimate SIP calls.
Protect Your VOS3000 from SIP Scanners
Implementing a robust VOS3000 iptables SIP scanner defense is not optional — it is a fundamental requirement for any VOS3000 operator who exposes SIP services to the internet. The pure iptables approach described in this guide provides the most efficient, lowest-overhead protection available, blocking scanner traffic at the kernel level before it can consume your server resources. By combining iptables trusted IP whitelisting, string-match dropping, connlimit connection tracking, recent module rate limiting, and hashlimit per-IP rate control with VOS3000 native features like IP authentication, Web Access Control, and mapping gateway rate limiting, you create a defense-in-depth system that stops SIP scanners at every level.
Remember that security is an ongoing process, not a one-time configuration. Regularly review your iptables rule hit counters, monitor your VOS3000 logs for new attack patterns, update your scanner User-Agent block list as new tools emerge, and verify that your trusted IP list is current. The VOS3000 iptables SIP scanner defense you implement today may need adjustments tomorrow as attackers develop new techniques.
📱 Contact us on WhatsApp: +8801911119966
Our VOS3000 security specialists can help you implement the complete iptables SIP scanner defense described in this guide, audit your existing configuration for vulnerabilities, and provide ongoing monitoring and support. Whether you need help with iptables rules, VOS3000 authentication configuration, mapping gateway rate limiting, or a comprehensive security overhaul, our team has the expertise to protect your VoIP platform. For professional VOS3000 security assistance, reach out to us on WhatsApp at +8801911119966.
📞 Need Professional VOS3000 Setup Support?
For professional VOS3000 installations and deployment, VOS3000 Server Rental Solution:
VOS3000 Echo Delay Fix: Resolve Choppy Audio and Jitter Problems
If you are running a VOS3000 VoIP softswitch and your customers complain about echo, choppy audio, or noticeable voice delay during calls, you are not alone. These audio quality issues are among the most frequently reported problems in VoIP deployments worldwide. A proper VOS3000 echo delay fix requires a systematic approach that addresses jitter buffer configuration, media proxy settings, codec negotiation, and network QoS parameters — all of which work together to determine the final voice quality your users experience.
Many VoIP operators mistakenly assume that echo and delay are the same problem, but they stem from entirely different root causes. Echo is typically caused by impedance mismatches at analog-to-digital conversion points, while delay is primarily a network and buffering issue. Choppy audio, on the other hand, is almost always related to jitter — the variation in packet arrival times — or packet loss. Understanding these distinctions is the first critical step toward implementing an effective VOS3000 echo delay fix that resolves all three symptoms simultaneously.
In this comprehensive guide, we will walk you through every configuration parameter, diagnostic technique, and best practice you need to master the VOS3000 echo delay fix process. From jitter buffer tuning in VOS3000 to SS_MEDIAPROXYMODE parameter selection, DSCP/ToS QoS markings, and codec mismatch resolution, this article covers everything documented in the VOS3000 Manual Sections 4.1.4, 4.3.2, and 4.3.5, plus real-world field experience from production deployments.
Table of Contents
Understanding the Root Causes: Echo vs. Delay vs. Choppy Audio
Before diving into the VOS3000 echo delay fix configuration steps, it is essential to understand the technical differences between echo, delay, and choppy audio. Each symptom has distinct root causes, and misdiagnosing the problem will lead to incorrect configuration changes that may actually worsen call quality rather than improve it.
Acoustic Echo occurs when sound from the speaker leaks back into the microphone, creating a delayed repetition of the speaker’s own voice. This is common with hands-free devices and poorly shielded handsets. In VOS3000, echo cancellation algorithms can mitigate this, but they must be properly configured to work effectively. The VOS3000 echo delay fix for acoustic echo involves enabling and tuning the built-in echo canceller parameters.
Network Delay (Latency) is the time it takes for a voice packet to travel from the sender to the receiver. According to ITU-T G.114 recommendations, one-way latency below 150ms is acceptable for most voice calls, 150-400ms is noticeable but tolerable, and above 400ms degrades the conversation significantly. A complete VOS3000 echo delay fix must account for all sources of latency, including propagation delay, serialization delay, and queuing delay in network devices.
Choppy Audio (Jitter) happens when voice packets arrive at irregular intervals. The jitter buffer at the receiving end must compensate for this variation, but when jitter exceeds the buffer’s capacity, packets are either discarded (causing gaps in audio) or played late (causing robotic-sounding voice). The VOS3000 echo delay fix for choppy audio centers on proper jitter buffer sizing and media proxy configuration.
🔊 Symptom
🧠 Root Cause
🔧 VOS3000 Fix Area
📋 Manual Reference
Echo (hearing own voice)
Impedance mismatch, acoustic coupling
Echo canceller, gain control
Section 4.3.5
Delay (late voice)
Network latency, oversized jitter buffer
Jitter buffer, media proxy, QoS
Sections 4.1.4, 4.3.2
Choppy audio (broken voice)
Jitter, packet loss, codec mismatch
Jitter buffer, codec negotiation
Sections 4.3.2, 4.3.5
One-way audio
NAT/firewall blocking RTP
Media proxy, RTP settings
Section 4.3.2
Robotic voice
Excessive jitter, codec compression
Jitter buffer size, codec selection
Section 4.3.5
One-Way Audio vs. Echo Delay: Know the Difference
One of the most common mistakes VoIP operators make is confusing one-way audio with echo/delay issues. A proper VOS3000 echo delay fix requires that you first confirm which problem you are actually facing. One-way audio — where one party can hear the other but not vice versa — is almost always a NAT traversal or firewall issue, not a jitter or codec problem.
When VOS3000 is deployed behind NAT, RTP media streams may fail to reach one or both endpoints if the media proxy is not correctly configured. The SIP signaling works fine (calls connect), but the RTP audio packets are blocked or sent to the wrong IP address. This is fundamentally different from echo and delay, which occur when audio does reach both parties but with quality degradation.
If you are experiencing one-way audio specifically, our detailed guide on VOS3000 one-way audio troubleshooting covers NAT configuration, firewall rules, and media proxy setup in depth. However, if your issue is echo, delay, or choppy audio on both sides of the call, the VOS3000 echo delay fix steps in this guide will address your needs directly.
Here is a quick diagnostic method to distinguish between the two problems. Place a test call and check the VOS3000 Current Call monitor. If you see RTP packets flowing in both directions but the audio is degraded, you have an echo/delay/jitter issue. If RTP packets are flowing in only one direction, or the packet count shows 0 for one leg, you have a one-way audio (NAT) problem requiring a different approach entirely.
Diagnosing Echo and Delay Using VOS3000 Current Call Monitor
The VOS3000 Current Call monitor is your primary diagnostic tool for implementing any VOS3000 echo delay fix. This real-time monitoring interface displays active calls with detailed audio traffic metrics that reveal exactly what is happening with your voice packets. Learning to read and interpret these metrics is essential for accurate diagnosis and effective troubleshooting.
To access the Current Call monitor, log into the VOS3000 admin panel and navigate to System Management > Current Call. During an active call, you will see a list of all ongoing sessions with key metrics for each call leg. The audio traffic metrics you need to focus on for the VOS3000 echo delay fix include packet counts, packet loss percentages, jitter values, and round-trip time estimates.
Key Audio Traffic Metrics to Monitor:
RTP Packets Sent/Received: Compare the sent count on one leg with the received count on the opposite leg. A significant discrepancy indicates packet loss in the network path.
Packet Loss %: Any packet loss above 0.5% will cause audible degradation. Loss above 2% makes conversation very difficult. This is a critical metric for the VOS3000 echo delay fix process.
Jitter (ms): The variation in packet arrival times. Jitter above 30ms typically requires jitter buffer adjustment. Above 50ms, users will notice choppy audio regardless of buffer settings.
Round-Trip Time (ms): High RTT values (above 300ms) indicate network latency that contributes to perceived delay and echo. The VOS3000 echo delay fix must account for this.
📊 Metric
✅ Good Range
⚠️ Warning
💥 Critical
Packet Loss
0 – 0.5%
0.5 – 2%
Above 2%
Jitter
0 – 20ms
20 – 50ms
Above 50ms
One-Way Latency
0 – 150ms
150 – 300ms
Above 300ms
Round-Trip Time
0 – 300ms
300 – 500ms
Above 500ms
Codec Bitrate
G711: 64kbps
G729: 8kbps
Below 8kbps
When you observe high jitter values in the Current Call monitor, the VOS3000 echo delay fix process should start with jitter buffer configuration. When you see significant packet loss, focus on network QoS and media proxy settings first. When both jitter and loss are present, address packet loss before jitter, as loss has a more severe impact on perceived audio quality.
Configuring Jitter Buffer Settings in VOS3000
The jitter buffer is one of the most important components in any VOS3000 echo delay fix strategy. It temporarily stores incoming RTP packets and releases them at regular intervals, smoothing out the variations in packet arrival times caused by network jitter. However, the jitter buffer introduces additional delay — the larger the buffer, the more delay it adds. Finding the optimal balance between jitter compensation and minimal delay is the key to a successful VOS3000 echo delay fix.
VOS3000 provides configurable jitter buffer parameters that allow you to fine-tune the buffer size based on your network conditions. These settings are found in the system parameters section of the VOS3000 admin panel, specifically referenced in VOS3000 Manual Section 4.3.5. The jitter buffer can operate in fixed or adaptive mode, and the correct choice depends on your network characteristics.
Fixed Jitter Buffer: Uses a constant buffer size. This provides predictable delay but may not handle varying network conditions well. If your network has consistent jitter levels, a fixed buffer can provide a stable VOS3000 echo delay fix with minimal configuration complexity.
Adaptive Jitter Buffer: Dynamically adjusts the buffer size based on measured jitter. This is generally recommended for most deployments because it automatically optimizes the trade-off between delay and jitter compensation. The adaptive buffer grows when jitter increases and shrinks when network conditions improve, providing the best overall VOS3000 echo delay fix for variable network environments.
To configure jitter buffer settings in VOS3000:
# Navigate to System Parameters in VOS3000 Admin Panel
# System Management > System Parameter > Media Settings
# Key Jitter Buffer Parameters:
# SS_JITTERBUFFER_MODE = 1 (0=Fixed, 1=Adaptive)
# SS_JITTERBUFFER_MIN = 20 (Minimum buffer size in ms)
# SS_JITTERBUFFER_MAX = 200 (Maximum buffer size in ms)
# SS_JITTERBUFFER_DEFAULT = 60 (Default starting buffer in ms)
# Recommended values for most deployments:
# Adaptive mode with 20ms min, 200ms max, 60ms default
# This provides flexibility while keeping initial delay low
When implementing the VOS3000 echo delay fix, be careful not to set the jitter buffer too small. A buffer below 20ms will not compensate for even moderate jitter, resulting in continued choppy audio. Conversely, setting the maximum buffer too high (above 400ms) introduces noticeable delay that users will perceive as echo, since the round-trip delay exceeds the threshold where the brain perceives delayed audio as a separate echo.
⚙️ Jitter Buffer Scenario
📝 Recommended Min (ms)
📝 Recommended Max (ms)
📝 Default (ms)
🎯 Mode
LAN / Low jitter (<10ms)
10
80
20
Fixed or Adaptive
WAN / Moderate jitter (10-30ms)
20
200
60
Adaptive
Internet / High jitter (30-80ms)
40
300
100
Adaptive
Satellite / Extreme jitter (>80ms)
60
400
150
Adaptive
VOS3000 Media Proxy Configuration: SS_MEDIAPROXYMODE Parameter
The media proxy (also called RTP proxy) is a critical component in the VOS3000 echo delay fix process. It determines how RTP media streams are handled between call endpoints. The SS_MEDIAPROXYMODE parameter, documented in VOS3000 Manual Section 4.3.2, offers several modes that significantly impact both audio quality and server resource utilization.
When the media proxy is enabled, VOS3000 acts as an intermediary for all RTP traffic, relaying media packets between the calling and called parties. This allows VOS3000 to monitor audio quality metrics, enforce codec transcoding, and ensure that NAT traversal issues do not cause one-way audio. However, the media proxy adds processing overhead and a small amount of additional latency. Understanding when to use each SS_MEDIAPROXYMODE setting is essential for an effective VOS3000 echo delay fix.
SS_MEDIAPROXYMODE Options Explained:
Mode 0 — Off (Direct RTP): RTP streams flow directly between endpoints without passing through VOS3000. This provides the lowest possible latency since there is no intermediary processing, making it attractive for VOS3000 echo delay fix scenarios where minimizing delay is the top priority. However, this mode means VOS3000 cannot monitor audio quality, cannot transcode codecs, and NAT traversal issues may cause one-way audio. Use this mode only when both endpoints are on the same network or have direct IP reachability without NAT constraints.
Mode 1 — On (Always Proxy): All RTP traffic is relayed through VOS3000. This is the safest mode for ensuring audio connectivity and enabling full monitoring, but it adds the most processing overhead and latency. For the VOS3000 echo delay fix, this mode is recommended when you need to troubleshoot audio issues, enforce transcoding, or deal with NAT scenarios. The slight additional latency (typically 1-5ms) is usually acceptable for most VoIP deployments.
Mode 2 — Auto: VOS3000 automatically determines whether to proxy media based on network topology. If both endpoints appear to be on the same network with direct IP reachability, media flows directly. If NAT is detected or endpoints are on different networks, VOS3000 proxies the media. This is a good balance for the VOS3000 echo delay fix in mixed deployment scenarios, but it requires that VOS3000 correctly detects the network topology, which is not always reliable.
Mode 3 — Must On (Forced Proxy): Similar to Mode 1 but with stricter enforcement. All media is proxied through VOS3000 with no exceptions. This mode is essential for the VOS3000 echo delay fix when dealing with complex NAT scenarios, multiple network interfaces, or when you need to guarantee that all audio traffic passes through VOS3000 for billing, monitoring, or legal compliance purposes. It is also the recommended mode for production deployments where audio quality troubleshooting is a regular requirement.
📶 SS_MEDIAPROXYMODE
💻 RTP Flow
📊 Latency Impact
🔧 Best Use Case
0 (Off)
Direct between endpoints
None (lowest)
Same-network endpoints only
1 (On)
Proxied through VOS3000
+1-5ms
NAT traversal, monitoring needed
2 (Auto)
Conditional proxy
Variable
Mixed network environments
3 (Must On)
Always proxied (forced)
+1-5ms
Production, compliance, NAT
To configure the SS_MEDIAPROXYMODE parameter in VOS3000, navigate to System Management > System Parameter and search for the parameter. For most VOS3000 echo delay fix scenarios, we recommend setting SS_MEDIAPROXYMODE to 3 (Must On) to ensure reliable media relay and full monitoring capability. You can learn more about RTP media handling in our dedicated VOS3000 RTP media configuration guide.
# VOS3000 SS_MEDIAPROXYMODE Configuration
# Navigate to: System Management > System Parameter
# Search for: SS_MEDIAPROXYMODE
# Set value to: 3 (Must On for production deployments)
# Additional related parameters:
# SS_MEDIAPROXYPORT_START = 10000 (Start of RTP port range)
# SS_MEDIAPROXYPORT_END = 60000 (End of RTP port range)
# SS_RTP_TIMEOUT = 30 (RTP timeout in seconds)
# After changing, restart the VOS3000 media service:
# service vos3000d restart
Codec Mismatch: PCMA vs G729 Negotiation Issues
Codec mismatch is one of the most overlooked causes of audio quality problems in VOS3000 deployments, and it plays a significant role in the VOS3000 echo delay fix process. When two endpoints negotiate different codecs, or when VOS3000 must transcode between codecs, the additional processing and compression can introduce artifacts, delay, and even echo-like symptoms that are difficult to distinguish from true network-related echo.
PCMA (G.711A) is an uncompressed codec that uses 64kbps of bandwidth. It provides the highest audio quality with the lowest processing overhead, making it ideal for the VOS3000 echo delay fix when bandwidth is not a constraint. PCMA introduces zero algorithmic delay beyond the standard packetization time (typically 20ms), so it does not contribute to latency problems.
G.729 is a compressed codec that uses only 8kbps of bandwidth but introduces algorithmic delay of approximately 15-25ms due to the compression and decompression process. While this delay is relatively small, it adds to the overall end-to-end delay budget. In a VOS3000 echo delay fix scenario where every millisecond counts, using G.729 on high-latency links can push the total delay past the perceptibility threshold.
The real problem occurs when one endpoint offers PCMA and the other only supports G.729 (or vice versa), and VOS3000 must perform real-time transcoding between the two. Transcoding not only adds processing delay but can also introduce audio artifacts that sound like echo or distortion. The VOS3000 echo delay fix for this scenario involves ensuring consistent codec preferences across all endpoints and trunks, or using VOS3000’s transcoding capabilities judiciously.
Our comprehensive VOS3000 transcoding and codec converter guide provides detailed instructions for configuring codec negotiation and transcoding in VOS3000. For the purposes of the VOS3000 echo delay fix, the key principle is to minimize transcoding wherever possible by aligning codec preferences between originating and terminating endpoints.
💻 Codec
📊 Bitrate
⏱️ Algorithmic Delay
🔊 Quality (MOS)
💰 Bandwidth Cost
G.711 (PCMA/PCMU)
64 kbps
0.125 ms
4.1 – 4.4
High
G.729 (AB)
8 kbps
15 – 25 ms
3.7 – 4.0
Low
G.723.1
5.3/6.3 kbps
37.5 ms
3.6 – 3.9
Very Low
G.722 (HD Voice)
64 kbps
0.125 ms
4.4 – 4.6
High
When implementing the VOS3000 echo delay fix, configure your SIP trunks and extensions to prefer the same codec on both legs of the call. If the originating leg uses G.711 and the terminating trunk only supports G.729, VOS3000 must transcode, adding delay and potential quality degradation. Setting consistent codec preferences eliminates unnecessary transcoding and is one of the most effective VOS3000 echo delay fix strategies.
Network QoS: DSCP and ToS Markings in VOS3000
Quality of Service (QoS) markings are a fundamental part of any comprehensive VOS3000 echo delay fix strategy. DSCP (Differentiated Services Code Point) and ToS (Type of Service) markings tell network routers and switches how to prioritize VoIP traffic relative to other data on the network. Without proper QoS markings, VoIP packets may be queued behind large data transfers, causing variable delay (jitter) and packet loss that directly result in echo, delay, and choppy audio.
VOS3000 provides two key system parameters for QoS configuration, both documented in VOS3000 Manual Section 4.1.4: SS_QOS_SIGNAL for SIP signaling traffic and SS_QOS_RTP for RTP media traffic. These parameters allow you to set the DSCP/ToS values in the IP headers of packets sent by VOS3000, ensuring that network devices can properly classify and prioritize your VoIP traffic.
SS_QOS_SIGNAL Parameter: This parameter sets the DSCP value for SIP signaling packets (UDP/TCP port 5060 and related ports). Signaling packets are less time-sensitive than RTP packets, but they still benefit from priority treatment to ensure fast call setup and teardown. The recommended value for the VOS3000 echo delay fix is CS3 (Class Selector 3), which corresponds to a DSCP decimal value of 24 (hex 0x18, binary 011000).
SS_QOS_RTP Parameter: This parameter sets the DSCP value for RTP media packets, which carry the actual voice audio. RTP packets are extremely time-sensitive — even a few milliseconds of additional queuing delay can cause noticeable audio degradation. The recommended value for the VOS3000 echo delay fix is EF (Expedited Forwarding), which corresponds to a DSCP decimal value of 46 (hex 0x2E, binary 101110). EF is the highest priority DSCP class and should be reserved exclusively for real-time voice and video traffic.
# VOS3000 QoS DSCP Configuration
# Navigate to: System Management > System Parameter
# SIP Signaling QoS Marking
# Parameter: SS_QOS_SIGNAL
# Recommended value: 24 (CS3 / Class Selector 3)
# This ensures SIP messages receive moderate priority
# RTP Media QoS Marking
# Parameter: SS_QOS_RTP
# Recommended value: 46 (EF / Expedited Forwarding)
# This ensures voice packets receive highest priority
# Common DSCP Values for VOS3000 Echo Delay Fix:
# EF (46) = Expedited Forwarding - Voice RTP (highest)
# AF41 (34) = Assured Forwarding 4,1 - Video
# CS3 (24) = Class Selector 3 - SIP Signaling
# CS0 (0) = Best Effort - Default (no priority)
# After changing QoS parameters, restart VOS3000:
# service vos3000d restart
# Verify DSCP markings using tcpdump on the VOS3000 server:
# tcpdump -i eth0 -vvv -n port 5060 or portrange 10000-60000
# Look for "tos 0x2e" (EF) on RTP packets
It is important to note that DSCP markings only work if the network devices between your VOS3000 server and the endpoints are configured to respect them. If you set SS_QOS_RTP to EF on VOS3000 but your routers are configured for best-effort forwarding on all traffic, the markings will have no effect. As part of the VOS3000 echo delay fix, ensure that your network infrastructure is configured to honor DSCP markings, particularly for EF-class RTP traffic.
🔢 DSCP Class
🔢 Decimal
🔢 Hex
🎯 VOS3000 Parameter
📝 Usage
EF (Expedited Forwarding)
46
0x2E
SS_QOS_RTP
Voice media (highest priority)
CS3 (Class Selector 3)
24
0x18
SS_QOS_SIGNAL
SIP signaling
AF41 (Assured Fwd 4,1)
34
0x22
—
Video conferencing
CS0 (Best Effort)
0
0x00
—
Default (no priority)
Complete VOS3000 Echo Delay Fix Step-by-Step Process
Now that we have covered all the individual components, let us walk through a complete, systematic VOS3000 echo delay fix process that you can follow from start to finish. This process is designed to be performed in order, with each step building on the diagnostic information gathered in the previous step.
Step 1: Diagnose the Problem
Place a test call through VOS3000 and open the Current Call monitor. Record the audio traffic metrics for both legs of the call, including packet loss, jitter, and latency values. This baseline measurement is essential for the VOS3000 echo delay fix process because it tells you exactly which parameters need adjustment. If you need help with basic call testing, refer to our VOS3000 SIP call setup guide.
Step 2: Check Media Proxy Mode
Verify the current SS_MEDIAPROXYMODE setting. If it is set to 0 (Off) and you are experiencing one-way audio or missing RTP metrics, change it to 3 (Must On). This ensures VOS3000 can monitor and relay all media traffic, which is a prerequisite for the rest of the VOS3000 echo delay fix steps to be effective.
Step 3: Configure Jitter Buffer
Based on the jitter values observed in Step 1, configure the jitter buffer settings. For most deployments, set SS_JITTERBUFFER_MODE to 1 (Adaptive), with minimum buffer of 20ms, maximum of 200ms, and default starting value of 60ms. Adjust these values based on your specific network conditions for optimal VOS3000 echo delay fix results.
Step 4: Align Codec Preferences
Review the codec settings on all SIP trunks, extensions, and gateways. Ensure that the preferred codecs match on both legs of the call to minimize transcoding. For the VOS3000 echo delay fix, G.711 (PCMA) should be preferred on high-bandwidth links, while G.729 can be used on bandwidth-constrained links — but avoid mixing the two on the same call path.
Step 5: Enable QoS Markings
Set SS_QOS_RTP to 46 (EF) and SS_QOS_SIGNAL to 24 (CS3). This ensures that network devices prioritize VoIP traffic appropriately. Verify that your network infrastructure is configured to honor these markings for the VOS3000 echo delay fix to be fully effective.
Step 6: Restart Services and Test
After making all configuration changes, restart the VOS3000 services and place another test call. Compare the new audio traffic metrics with the baseline from Step 1 to measure the improvement. If the VOS3000 echo delay fix has been applied correctly, you should see reduced jitter, lower packet loss, and improved overall audio quality.
🔧 Step
📋 Action
⚙️ Parameter
✅ Target Value
1
Diagnose with Current Call
—
Record baseline metrics
2
Set Media Proxy Mode
SS_MEDIAPROXYMODE
3 (Must On)
3
Configure Jitter Buffer
SS_JITTERBUFFER_*
Adaptive, 20/200/60ms
4
Align Codecs
Trunk/Extension codecs
PCMA preferred, no transcode
5
Enable QoS Markings
SS_QOS_RTP / SS_QOS_SIGNAL
46 (EF) / 24 (CS3)
6
Restart and Verify
service vos3000d restart
Improved metrics vs baseline
VOS3000 System Parameters for Echo and Delay Optimization
Beyond the jitter buffer and media proxy settings, VOS3000 offers several additional system parameters that contribute to the echo delay fix process. These parameters, documented in VOS3000 Manual Section 4.3.5, control various aspects of audio processing, gain control, and echo cancellation that directly impact voice quality.
Key System Parameters for VOS3000 Echo Delay Fix:
SS_ECHOCANCEL: This parameter enables or disables the built-in echo canceller. For the VOS3000 echo delay fix, this should always be set to 1 (Enabled). Disabling echo cancellation will make any existing echo much more noticeable and can cause severe quality degradation, especially on calls that traverse analog network segments.
SS_ECHOCANCELTAIL: This parameter sets the tail length for the echo canceller in milliseconds. The tail length determines how much echo the canceller can handle — it should be set longer than the expected echo delay. A value of 128ms covers most scenarios and is the recommended default for the VOS3000 echo delay fix. If you are dealing with very long echo tails (common on satellite links), you may need to increase this to 256ms.
SS_VOICEGAIN: This parameter controls the voice gain level. Setting this too high can cause distortion and clipping that sounds similar to echo. For the VOS3000 echo delay fix, keep this at the default value (0) and only adjust it if you have a specific gain-related issue that cannot be resolved through other means.
SS_COMFORTNOISE: This parameter controls whether comfort noise is generated during silence periods. While not directly related to echo or delay, comfort noise helps mask the artifacts that can make echo and delay more noticeable. For the VOS3000 echo delay fix, enabling comfort noise (value 1) can improve the subjective perception of call quality.
# VOS3000 Audio Quality System Parameters
# Navigate to: System Management > System Parameter
# Reference: VOS3000 Manual Section 4.3.5
# Echo Cancellation
SS_ECHOCANCEL = 1 # 0=Disabled, 1=Enabled (ALWAYS enable)
SS_ECHOCANCELTAIL = 128 # Tail length in ms (64/128/256)
# Voice Gain Control
SS_VOICEGAIN = 0 # Gain in dB (0=default, range -10 to +10)
# Comfort Noise
SS_COMFORTNOISE = 1 # 0=Disabled, 1=Enabled
# Jitter Buffer
SS_JITTERBUFFER_MODE = 1 # 0=Fixed, 1=Adaptive
SS_JITTERBUFFER_MIN = 20 # Minimum buffer (ms)
SS_JITTERBUFFER_MAX = 200 # Maximum buffer (ms)
SS_JITTERBUFFER_DEFAULT = 60 # Default starting buffer (ms)
# Media Proxy
SS_MEDIAPROXYMODE = 3 # 0=Off, 1=On, 2=Auto, 3=Must On
# QoS Markings
SS_QOS_SIGNAL = 24 # DSCP CS3 for SIP signaling
SS_QOS_RTP = 46 # DSCP EF for RTP media
# RTP Timeout
SS_RTP_TIMEOUT = 30 # Seconds before RTP timeout
# Apply changes:
# service vos3000d restart
Advanced VOS3000 Echo Delay Fix Techniques
For situations where the standard VOS3000 echo delay fix steps are not sufficient, there are several advanced techniques that can further improve audio quality. These techniques address edge cases and complex network topologies that require more granular control over VOS3000’s audio processing behavior.
Per-Trunk Media Proxy Override: While the SS_MEDIAPROXYMODE parameter sets the global default, VOS3000 allows you to override the media proxy setting on individual SIP trunks. This is useful for the VOS3000 echo delay fix when you have a mix of local and remote trunks — you can disable media proxy for local trunks (to minimize delay) while forcing it on for remote trunks (to ensure NAT traversal and monitoring).
Packetization Time (ptime) Optimization: The ptime parameter determines how many milliseconds of audio are packed into each RTP packet. The default is 20ms, which is standard for most VoIP deployments. However, in high-jitter environments, increasing ptime to 30ms or 40ms can reduce the number of packets per second, lowering the impact of packet loss on audio quality. This is an advanced VOS3000 echo delay fix technique that should be tested carefully, as it increases per-packet latency.
DTMF Mode Impact on Audio: Incorrect DTMF configuration can sometimes interfere with audio processing in VOS3000. If DTMF is set to inband mode and the call uses a compressed codec like G.729, the DTMF tones can be distorted and may cause momentary audio artifacts. For the VOS3000 echo delay fix, ensure DTMF is set to RFC2833 or SIP INFO mode, which keeps DTMF signaling separate from the audio stream.
Network Interface Binding: If your VOS3000 server has multiple network interfaces, ensure that the media proxy binds to the correct interface for RTP traffic. Misconfigured interface binding can cause RTP packets to be sent out the wrong interface, leading to asymmetric routing and increased latency. The VOS3000 echo delay fix for this issue involves checking the IP binding settings in the VOS3000 system configuration.
🧠 Advanced Technique
🎯 Benefit
⚠️ Risk
🔧 Configuration
Per-Trunk Media Proxy
Optimize per-trunk latency
Complexity in management
SIP Trunk > Advanced Settings
Ptime Optimization
Reduce packet loss impact
Higher per-packet delay
SDP ptime parameter
DTMF Mode Correction
Eliminate DTMF artifacts
Compatibility issues
Trunk/Extension DTMF settings
Interface Binding
Fix asymmetric routing
Requires network knowledge
System IP binding settings
Echo Tail Extension
Cancel longer echo tails
More CPU overhead
SS_ECHOCANCELTAIL = 256
Monitoring and Maintaining Audio Quality After the Fix
Implementing the VOS3000 echo delay fix is not a one-time task — it requires ongoing monitoring and maintenance to ensure that audio quality remains at acceptable levels as network conditions change. Production VoIP environments are dynamic, with new trunks, routes, and endpoints being added regularly, each of which can introduce new audio quality challenges.
Regular Metric Reviews: Schedule weekly reviews of the VOS3000 Current Call metrics, focusing on packet loss, jitter, and latency values across your busiest routes. Look for trends that indicate degrading performance before your customers notice the problem. The VOS3000 echo delay fix process should include a proactive monitoring component that catches issues early.
Alert Thresholds: Configure alert thresholds in VOS3000 so that you are automatically notified when audio quality metrics exceed acceptable ranges. Set packet loss alerts at 1%, jitter alerts at 30ms, and latency alerts at 200ms. These thresholds provide early warning of problems that may require additional VOS3000 echo delay fix adjustments.
Capacity Planning: As your call volume grows, the VOS3000 server’s CPU and memory resources may become constrained, which can degrade media proxy performance and increase processing delay. Monitor server resource utilization and plan capacity upgrades before they become bottlenecks. The VOS3000 echo delay fix is only effective if the server has sufficient resources to process all media streams without contention.
Network Path Changes: Internet routing changes can alter the network path between your VOS3000 server and remote endpoints, potentially increasing latency and jitter. If you notice a sudden degradation in audio quality on a route that was previously working well, investigate whether the network path has changed. The VOS3000 echo delay fix may need to be adjusted to accommodate new network conditions.
Common Mistakes to Avoid in VOS3000 Echo Delay Fix
Even experienced VoIP engineers can make mistakes when implementing the VOS3000 echo delay fix. Being aware of these common pitfalls can save you hours of troubleshooting and prevent you from making changes that worsen the problem rather than improving it.
Mistake 1: Disabling Echo Cancellation. Some operators disable the echo canceller in an attempt to reduce processing overhead. This is almost always a mistake — the echo canceller uses minimal CPU resources and disabling it will make any existing echo far more noticeable. The VOS3000 echo delay fix should always include keeping the echo canceller enabled.
Mistake 2: Setting Jitter Buffer Too Large. While a large jitter buffer can eliminate choppy audio caused by jitter, it introduces additional delay that makes echo more perceptible. A 300ms jitter buffer might eliminate all choppy audio, but it will add 300ms of one-way delay, pushing the round-trip delay well above the echo perceptibility threshold. The VOS3000 echo delay fix requires careful balancing of buffer size against delay budget.
Mistake 3: Ignoring QoS on the Local Network. Many operators focus on QoS configuration on VOS3000 but forget to configure the local network switches and routers to honor the DSCP markings. Without network device cooperation, the VOS3000 echo delay fix QoS settings have no effect on actual packet prioritization.
Mistake 4: Mixing Codecs Without Transcoding Resources. If you configure endpoints with different codec preferences but do not have sufficient transcoding capacity on the VOS3000 server, calls may fail to connect or may connect with degraded audio. The VOS3000 echo delay fix must account for transcoding resource availability when planning codec configurations.
Mistake 5: Changing Multiple Parameters Simultaneously. When troubleshooting audio issues, it is tempting to change multiple VOS3000 parameters at once to speed up the fix. However, this makes it impossible to determine which change resolved the problem (or which change made it worse). The VOS3000 echo delay fix should be performed methodically, changing one parameter at a time and testing after each change.
⚠️ Common Mistake
💥 Consequence
✅ Correct Approach
Disabling echo canceller
Severe echo on all calls
Always keep SS_ECHOCANCEL=1
Oversized jitter buffer
Excessive delay perceived as echo
Use adaptive buffer, keep max ≤200ms
Ignoring network QoS
Jitter and packet loss continue
Configure DSCP + network device QoS
Mixing codecs without resources
Failed calls or degraded audio
Align codec preferences across trunks
Changing multiple parameters at once
Cannot identify root cause
Change one parameter, test, repeat
VOS3000 Echo Delay Fix: Real-World Case Study
To illustrate how the VOS3000 echo delay fix process works in practice, let us examine a real-world scenario from a VoIP service provider operating in South Asia. This provider was experiencing widespread complaints about echo and choppy audio on international routes, despite having a well-provisioned VOS3000 cluster handling over 10,000 concurrent calls.
The Problem: Customers reported hearing their own voice echoed back with approximately 300-400ms delay, and many calls had noticeable choppy audio, especially during peak hours. The provider had initially attempted to fix the issue by increasing the jitter buffer maximum to 500ms, which reduced choppy audio but made the echo significantly worse because the round-trip delay exceeded 600ms.
The Diagnosis: Using the VOS3000 Current Call monitor, we observed that jitter on the affected routes ranged from 40-80ms during peak hours, with packet loss averaging 1.5-3%. The SS_MEDIAPROXYMODE was set to 2 (Auto), which was sometimes choosing direct RTP for routes that actually needed proxying. The QoS parameters were both set to 0 (no priority marking), and the codec configuration had G.711 on the originating side and G.729 on the terminating trunk, forcing transcoding on every call.
The VOS3000 Echo Delay Fix: We implemented the following changes systematically, one at a time, testing after each change:
Changed SS_MEDIAPROXYMODE from 2 (Auto) to 3 (Must On) — this immediately resolved intermittent one-way audio issues and enabled consistent monitoring of all call legs.
Set SS_JITTERBUFFER_MODE to 1 (Adaptive) with min=40ms, max=200ms, default=80ms — this was tailored to the observed jitter range and reduced choppy audio without adding excessive delay.
Configured SS_QOS_RTP=46 (EF) and SS_QOS_SIGNAL=24 (CS3), then worked with the network team to configure router QoS policies to honor these markings — packet loss dropped from 3% to under 0.5%.
Aligned codec preferences by configuring both originating and terminating trunks to prefer G.729 for international routes, eliminating transcoding delay — this removed approximately 20ms of algorithmic delay from each call.
Set SS_ECHOCANCELTAIL to 128ms (it was previously at 64ms, too short for the observed echo tail) — this improved echo cancellation effectiveness significantly.
The Result: After implementing the complete VOS3000 echo delay fix, customer complaints about echo dropped by 92%, and choppy audio complaints dropped by 85%. Average jitter measured on calls decreased from 60ms to 15ms (due to QoS improvements), and packet loss fell to below 0.3% on all monitored routes.
📊 Metric
💥 Before Fix
✅ After Fix
📉 Improvement
Average Jitter
60 ms
15 ms
75% reduction
Packet Loss
1.5 – 3%
0.3%
90% reduction
One-Way Latency
280 ms
140 ms
50% reduction
Echo Complaints
~150/week
~12/week
92% reduction
Choppy Audio Complaints
~200/week
~30/week
85% reduction
VOS3000 Manual References for Echo Delay Fix
The VOS3000 official documentation provides detailed information about the parameters discussed in this guide. For the VOS3000 echo delay fix, the most important manual sections to reference are:
VOS3000 Manual Section 4.1.4: Covers QoS and DSCP configuration, including the SS_QOS_SIGNAL and SS_QOS_RTP parameters. This section explains how to set DSCP values and how they interact with network device QoS policies. Essential reading for the network-level component of the VOS3000 echo delay fix.
VOS3000 Manual Section 4.3.2: Documents the Media Proxy configuration, including the SS_MEDIAPROXYMODE parameter and all its options (Off/On/Auto/Must On). Also covers RTP port range configuration and timeout settings. This is the primary reference for the media relay component of the VOS3000 echo delay fix.
VOS3000 Manual Section 4.3.5: Details the system parameters for audio processing, including echo cancellation, jitter buffer, gain control, and comfort noise settings. This section is the core reference for the audio processing component of the VOS3000 echo delay fix.
You can download the latest VOS3000 documentation from the official website at VOS3000 Downloads. Having the official manual on hand while implementing the VOS3000 echo delay fix ensures that you can verify parameter names and values accurately.
Frequently Asked Questions About VOS3000 Echo Delay Fix
❓ What is the most common cause of echo in VOS3000?
The most common cause of echo in VOS3000 is impedance mismatch at analog-to-digital conversion points, combined with insufficient echo cancellation. When voice signals cross from a digital VoIP network to an analog PSTN line, some energy reflects back as echo. The VOS3000 echo delay fix for this issue involves enabling the echo canceller (SS_ECHOCANCEL=1) and setting an appropriate tail length (SS_ECHOCANCELTAIL=128 or 256). Network delay makes echo more noticeable — if the round-trip delay exceeds 50ms, the brain perceives the reflected signal as a distinct echo rather than a natural resonance.
❓ How do I check jitter and packet loss in VOS3000?
To check jitter and packet loss for the VOS3000 echo delay fix, use the Current Call monitor in the VOS3000 admin panel. Navigate to System Management > Current Call, and during an active call, observe the audio traffic metrics for each call leg. The display shows packet counts (sent and received), from which you can calculate packet loss. Jitter values are displayed in milliseconds. For a more detailed analysis, you can use command-line tools like tcpdump or Wireshark on the VOS3000 server to capture and analyze RTP streams. Look for the jitter and packet loss metrics in the RTP statistics section of your capture tool.
❓ Should I use Media Proxy Mode On or Must On for the VOS3000 echo delay fix?
For the VOS3000 echo delay fix, Mode 3 (Must On) is generally recommended over Mode 1 (On) for production deployments. The difference is that Must On forces all media through the proxy without exception, while Mode 1 may allow some edge cases where media bypasses the proxy. Mode 3 ensures consistent monitoring, NAT traversal, and the ability to implement the full range of VOS3000 echo delay fix techniques. The additional processing overhead of Mode 3 compared to Mode 1 is negligible on properly provisioned hardware, but the reliability improvement is significant.
❓ Can codec mismatch cause echo in VOS3000?
Yes, codec mismatch can contribute to echo-like symptoms in VOS3000, though it is not the same as true acoustic echo. When VOS3000 must transcode between codecs (for example, from G.711 to G.729), the compression and decompression process can introduce audio artifacts that sound similar to echo. Additionally, the algorithmic delay of compressed codecs like G.729 (15-25ms) adds to the overall delay budget, making any existing echo more noticeable. The VOS3000 echo delay fix for codec-related issues involves aligning codec preferences across all call legs to minimize or eliminate transcoding.
❓ What DSCP value should I set for RTP in VOS3000?
For the VOS3000 echo delay fix, set the SS_QOS_RTP parameter to 46, which corresponds to DSCP EF (Expedited Forwarding). This is the highest priority DSCP class and is specifically designed for real-time voice and video traffic. EF marking tells network devices to prioritize RTP packets above all other traffic, minimizing queuing delay and jitter. Set the SS_QOS_SIGNAL parameter to 24 (CS3) for SIP signaling packets. Remember that DSCP markings only work if your network routers and switches are configured to honor them — configuring the markings in VOS3000 is necessary but not sufficient on its own.
❓ How do I adjust the jitter buffer for the VOS3000 echo delay fix?
To adjust the jitter buffer for the VOS3000 echo delay fix, navigate to System Management > System Parameter in the VOS3000 admin panel. Set SS_JITTERBUFFER_MODE to 1 (Adaptive) for most deployments. Configure SS_JITTERBUFFER_MIN to 20ms, SS_JITTERBUFFER_MAX to 200ms, and SS_JITTERBUFFER_DEFAULT to 60ms as starting values. The adaptive buffer will automatically adjust within these bounds based on measured network jitter. If you still experience choppy audio, increase the maximum to 300ms, but be aware that this adds more delay. If delay is the primary complaint, reduce the default and maximum values, accepting some jitter-related quality impact in exchange for lower latency.
❓ Why is my VOS3000 echo delay fix not working?
If your VOS3000 echo delay fix is not producing the desired results, there are several possible reasons. First, verify that you have restarted the VOS3000 service after making configuration changes — many parameters do not take effect until the service is restarted. Second, check whether the problem is actually echo/delay rather than one-way audio (which requires different fixes). Third, ensure your network devices are honoring DSCP QoS markings. Fourth, verify that the SS_MEDIAPROXYMODE is set to 3 (Must On) so that VOS3000 can properly monitor and relay all media. Finally, consider that the echo source may be on the far-end network beyond your control —
in this case, the VOS3000 echo delay fix can only partially mitigate the symptoms through echo cancellation and delay optimization.
❓ What is the difference between VOS3000 echo delay fix and one-way audio fix?
The VOS3000 echo delay fix addresses audio quality issues where both parties can hear each other but the audio is degraded with echo, delay, or choppiness. A one-way audio fix addresses a connectivity problem where one party cannot hear the other at all. Echo and delay are caused by network latency, jitter, codec issues, and impedance mismatch. One-way audio is caused by NAT/firewall blocking RTP packets, incorrect media proxy configuration, or IP routing issues. The VOS3000 echo delay fix involves jitter buffer tuning, QoS configuration, and codec alignment, while the one-way audio fix involves media proxy settings, NAT configuration, and firewall rules. Both issues may involve the SS_MEDIAPROXYMODE parameter, but the specific configuration changes are different.
Get Expert Help with Your VOS3000 Echo Delay Fix
Implementing the VOS3000 echo delay fix can be complex, especially in production environments with multiple trunks, varied network conditions, and diverse endpoint configurations. If you have followed the steps in this guide and are still experiencing audio quality issues, or if you need assistance with advanced configurations like per-trunk media proxy overrides or custom jitter buffer profiles, our team of VOS3000 experts is here to help.
We provide comprehensive VOS3000 support services including remote troubleshooting, configuration optimization, and hands-on training for your technical team. Whether you need a one-time VOS3000 echo delay fix consultation or ongoing managed support for your softswitch deployment, we can tailor a solution to meet your specific requirements and budget.
Our experience with VOS3000 deployments across diverse network environments means we have encountered and resolved virtually every type of audio quality issue, from simple echo canceller misconfigurations to complex multi-hop latency problems involving satellite links and international routes. Do not let audio quality problems drive your customers away — get expert assistance with your VOS3000 echo delay fix today.
📱 Contact us on WhatsApp: +8801911119966
Whether you are a small ITSP just getting started with VOS3000 or a large carrier with thousands of concurrent calls, our team has the expertise to implement the right VOS3000 echo delay fix for your specific environment. Reach out today and let us help you deliver crystal-clear voice quality to your customers.
📱 WhatsApp: +8801911119966 — Available 24/7 for urgent VOS3000 support requests.
📞 Need Professional VOS3000 Setup Support?
For professional VOS3000 installations and deployment, VOS3000 Server Rental Solution:
VOS3000 Time-Based Routing: Work Calendar and Period Rate Setup
Implementing VOS3000 time-based routing is one of the most powerful strategies for maximizing profit in a wholesale VoIP operation. While standard LCR routing selects gateways based on static cost priorities, this time-based approach adds a critical dimension: the ability to automatically shift traffic between vendors and rate tables based on the time of day, day of the week, and whether the day is a working day or a holiday. This means you can route calls through the cheapest available vendor during off-peak hours, switch to higher-quality providers during peak business hours, and apply entirely different rate structures on weekends and holidays — all without any manual intervention.
Many VOS3000 operators leave significant money on the table because they rely solely on static LCR routing and never configure time-based routing. Vendors frequently offer different rates for peak and off-peak hours, and failing to take advantage of these rate differences means you are overpaying for termination during low-cost periods. This guide walks you through the complete VOS3000 time-based routing configuration process, covering Work Calendar setup (VOS3000 Manual Section 2.12.4), Package Period Rate Management (VOS3000 Manual Section 2.3.2), and the practical integration of both features to create a dynamic routing strategy that adapts to time-based cost fluctuations. For professional assistance with your routing setup, contact us on WhatsApp at +8801911119966.
Table of Contents
Why VOS3000 Time-Based Routing Matters for VoIP Profitability
Understanding why VOS3000 time-based routing is essential requires looking at how VoIP termination costs actually work in the real world. Most carriers and termination providers offer different rates depending on the time of day. Peak hours typically have higher termination costs because network congestion is greater and demand is higher. Off-peak hours, usually nighttime and weekends, have significantly lower rates because network capacity is underutilized. A wholesale VoIP operator who routes all traffic through the same gateway with the same rate table regardless of time is effectively paying peak rates 24 hours a day.
The financial impact of this oversight can be enormous. Consider a VoIP operation handling 500,000 minutes per day. If the difference between peak and off-peak rates is just $0.002 per minute, and 40% of your traffic falls in off-peak hours, you are losing $400 per day or $12,000 per month by not implementing time-based routing. Over a year, that amounts to $146,000 in lost profit — all because you did not configure time-based routing properly.
📊 Scenario
💰 Daily Savings
💰 Monthly Savings
💰 Annual Savings
100K min/day, $0.002 diff
$80
$2,400
$29,200
500K min/day, $0.002 diff
$400
$12,000
$146,000
1M min/day, $0.002 diff
$800
$24,000
$292,000
1M min/day, $0.005 diff
$2,000
$60,000
$730,000
How VOS3000 Time-Based Routing Differs from Simple LCR
It is important to understand the distinction between standard LCR routing and VOS3000 time-based routing. Our VOS3000 LCR routing guide covers the fundamentals of least cost routing, which selects gateways based on static priorities and prefix matching. LCR routing always routes the same way regardless of when the call arrives. VOS3000 time-based routing adds a time dimension to this decision process, allowing different routing and billing rules to apply during different time periods.
Think of it this way: LCR routing answers the question “Which gateway is cheapest for this destination?” while VOS3000 time-based routing answers the question “Which gateway is cheapest for this destination at this specific time?” The combination of LCR and time-based routing gives you the most sophisticated routing strategy possible in VOS3000.
⚙️ Feature
📋 LCR Routing Only
🕐 VOS3000 Time-Based Routing
Gateway selection
Static priority-based
Dynamic, time-dependent
Rate table applied
Single rate table always
Different rate tables by time
Weekend handling
Same as weekday
Different routing and rates
Holiday handling
Same as any day
Custom holiday rates
Cost optimization
Lowest static cost
Lowest cost per time period
Manual intervention
Required for rate changes
Fully automatic switching
Profit potential
Good
Maximum
Understanding the VOS3000 Work Calendar System
The Work Calendar is the foundation of VOS3000 time-based routing. It defines what constitutes a working day, a non-working day, working hours, and non-working hours. These definitions are then used by the Package Period Rate system to determine which rate table and routing rules apply at any given moment. The Work Calendar is configured in the VOS3000 web interface under Navigation > System management > Work calendar (VOS3000 Manual Section 2.12.4, Page 174).
The Work Calendar system in VOS3000 is surprisingly powerful. It does not simply distinguish between “day” and “night” — it allows you to define complex schedules that account for different working hours on different days of the week, designated holidays, and special non-working days. This granularity is what makes time-based routing so effective for wholesale VoIP operations that need to adapt to carrier rate schedules.
Work Calendar Configuration Fields
When you create a new Work Calendar entry, you need to understand each configuration field and how it affects your routing. Here is a detailed breakdown of the Work Calendar settings as documented in VOS3000 Manual Section 2.12.4 (Page 174-176):
Calendar Name: A descriptive name for the calendar. Choose a name that clearly indicates its purpose, such as “BD_Wholesale_Schedule” for a Bangladesh wholesale operation or “UK_Business_Hours” for UK-oriented traffic. The calendar name is referenced by other VOS3000 modules including Package Period Rate and account settings.
Working Day: Specify which days of the week are considered working days. Typically Monday through Friday are working days, while Saturday and Sunday are non-working days. However, in some regions, the work week differs, and VOS3000 allows you to configure any combination of days as working or non-working.
Working Hours: Define the start and end times for working hours on working days. For example, 08:00 to 18:00 means that calls between 8 AM and 6 PM on working days use the working-hour rate table and routing rules. The time format is 24-hour (HH:MM).
Non-Working Hours: The period outside the defined working hours on working days, plus all hours on non-working days. Non-working hours automatically use different rate tables and potentially different gateway priorities.
Holiday Settings: Designate specific dates as holidays, which are treated as non-working days regardless of which day of the week they fall on. This is essential for applying special holiday rates.
⚙️ Field
📝 Description
💡 Example Value
🎯 Routing Impact
Calendar Name
Identifier for the calendar
BD_Wholesale_Schedule
Referenced by period rates and accounts
Working Days
Days classified as working
Mon-Fri
Applies working hour rates
Working Hours Start
Beginning of working period
08:00
Switches to daytime rate table
Working Hours End
End of working period
18:00
Switches to nighttime rate table
Holidays
Designated non-working dates
2026-01-01, 2026-03-26
Applies non-working day rates
Step-by-Step Work Calendar Configuration for VOS3000 Time-Based Routing
Now let us walk through the actual process of creating and configuring a Work Calendar for VOS3000 time-based routing. This step-by-step guide follows the interface described in VOS3000 Manual Section 2.12.4 (Page 174-176).
Step 1: Access the Work Calendar Interface
Log in to the VOS3000 web management interface with an administrator account. Navigate to Navigation > System management > Work calendar. The Work Calendar list page displays all existing calendars. From here, you can add, modify, or delete calendar entries.
To create a new calendar, click the Add button. A new calendar configuration form will appear with the fields described above.
Step 2: Define Calendar Name and Working Days
Enter a descriptive Calendar Name that reflects the purpose of this calendar. For time-based routing purposes, use names that clearly indicate the schedule type and target market. Examples include:
BD_PeakOffPeak: For Bangladesh traffic with peak/off-peak rate switching
UK_BusinessHours: For UK-destined traffic following UK business hours
Global_247_Weekend: For a global operation that only differentiates weekday vs. weekend
Holiday_Special_2026: For a calendar specifically designed for holiday rate management
Select the Working Days checkboxes to indicate which days of the week are working days. In most wholesale VoIP scenarios, Monday through Friday are working days because carrier rate structures typically differentiate between weekday and weekend rates.
Step 3: Set Working and Non-Working Hours
Define the Working Hours start and end times. The most common configuration for time-based routing is 08:00 to 18:00, which aligns with typical carrier peak-hour billing periods. However, you should check your vendor rate agreements to determine their exact peak and off-peak definitions.
Some important considerations when setting working hours:
Match vendor definitions: Your working hours must align with when your vendors charge peak rates. If a vendor defines peak hours as 09:00-21:00, set your working hours accordingly to avoid paying peak rates while applying off-peak rates to your customers.
Time zone awareness: Working hours should correspond to the time zone of your vendor or destination, not necessarily your local time zone. If you route traffic to the US but operate from Asia, your working hours should reflect US business hours.
Multiple calendars: Create separate calendars for different destination regions if they have different peak-hour definitions. You can then assign the appropriate calendar to each account or rate configuration.
Step 4: Configure Holiday Dates
Add specific dates as holidays in the Work Calendar. Holidays are treated as non-working days regardless of the day of the week. For time-based routing, holidays are important because many carriers offer special low rates on public holidays, similar to weekend rates.
To add a holiday, specify the date in the holiday list within the calendar configuration. You can add as many holidays as needed. Common holidays to include for Bangladesh-destined traffic include:
March 26 — Independence Day
December 16 — Victory Day
Eid ul-Fitr and Eid ul-Adha (variable dates)
January 1 — New Year’s Day
For international operations, include the public holidays of your primary destination countries. Remember to update holiday dates annually as some holidays change each year.
Step 5: Save and Verify the Calendar
After configuring all fields, click Save to create the calendar. Verify the calendar appears in the Work Calendar list with the correct configuration. The calendar is now ready to be referenced by Package Period Rate configurations and account settings.
Configuring Package Period Rate Management for VOS3000 Time-Based Routing
The Work Calendar defines when different time periods occur, but it is the Package Period Rate Management that determines what actually happens during those periods. This is where you bind specific rate tables to working hours and non-working hours, creating the actual time-dependent billing and routing behavior. Navigate to Rate Management > Package Period Rate Management (VOS3000 Manual Section 2.3.2, Page 10-12).
Package Period Rate Management is the engine that drives time-based routing in VOS3000. Without it, the Work Calendar simply categorizes time periods but does not change any routing or billing behavior. The Package Period Rate configuration links a calendar to specific rate tables, ensuring that the correct rates are applied at the correct times automatically.
Package Period Rate Configuration Fields
When you create a Package Period Rate entry, you need to configure the following fields as described in VOS3000 Manual Section 2.3.2 (Page 10-12):
Period Rate Name: A descriptive name for this period rate configuration. Use names that clearly describe the rate switching behavior, such as “BD_DayNight_Switch” or “UK_PeakOffPeak_Rate”.
Work Calendar: Select the Work Calendar that defines the time periods for this configuration. The calendar determines which hours are working hours and which are non-working hours.
Working Hours Rate Table: Select the rate table that applies during working hours as defined by the selected calendar. This is typically your peak-hour rate table with higher rates.
Non-Working Hours Rate Table: Select the rate table that applies during non-working hours. This is typically your off-peak rate table with lower rates.
⚙️ Field
📝 Description
🎯 Purpose in Time-Based Routing
Period Rate Name
Identifier for the configuration
Links to account and rate group settings
Work Calendar
Reference to calendar definition
Determines when each period starts/ends
Working Hours Rate Table
Rate table for peak hours
Higher sell rates during business hours
Non-Working Hours Rate Table
Rate table for off-peak hours
Lower sell rates during nights/weekends
Step-by-Step Package Period Rate Configuration
Follow these steps to configure Package Period Rate Management for VOS3000 time-based routing:
Step 1: Navigate to Rate Management > Package Period Rate Management in the VOS3000 web interface.
Step 2: Click Add to create a new Package Period Rate entry.
Step 3: Enter the Period Rate Name. Use a descriptive name that indicates the routing purpose, such as “BD_Wholesale_DayNight”.
Step 4: Select the Work Calendar from the dropdown list. This should be the calendar you created earlier that defines the working and non-working hours for your target market.
Step 5: Select the Working Hours Rate Table from the dropdown. This rate table should contain your peak-hour selling rates. These rates are typically higher because vendor costs are higher during peak hours, and you need to maintain your margin.
Step 6: Select the Non-Working Hours Rate Table from the dropdown. This rate table should contain your off-peak selling rates. These can be lower while still maintaining profit margins because vendor costs are lower during off-peak hours.
Step 7: Click Save to create the Package Period Rate configuration.
After saving, the period rate configuration will automatically switch between the two rate tables based on the Work Calendar schedule. No manual intervention is required — the system handles the switching seamlessly.
Binding Rate Tables for Daytime vs. Nighttime in VOS3000 Time-Based Routing
Creating effective rate table bindings is where time-based routing translates from configuration into actual financial results. The rate tables you bind to working and non-working hours determine exactly how much you charge customers during each period, directly affecting your profit margins.
Before configuring Package Period Rate bindings, you need to have both rate tables already created in Rate Management > Rate Table Management (VOS3000 Manual Section 2.2.2). Each rate table must contain rate entries for all the prefixes you plan to bill. For a comprehensive understanding of rate table setup, refer to our VOS3000 billing system guide.
Designing Daytime and Nighttime Rate Tables
The key principle for designing rate tables for this routing method is that each rate table must cover the same set of prefixes but with different rate values. The daytime rate table has higher rates that account for peak vendor costs plus your desired margin. The nighttime rate table has lower rates that reflect reduced vendor costs while still maintaining acceptable margins.
🔢 Prefix
📋 Destination
☀️ Day Rate (08:00-18:00)
🌙 Night Rate (18:00-08:00)
💰 Rate Difference
88017
BD Grameenphone
$0.012/min
$0.008/min
33% lower
88018
BD Robi Mobile
$0.012/min
$0.008/min
33% lower
88019
BD Banglalink
$0.013/min
$0.009/min
31% lower
8802
BD Landline
$0.010/min
$0.005/min
50% lower
44
UK Landline
$0.008/min
$0.004/min
50% lower
1
USA/Canada
$0.005/min
$0.003/min
40% lower
Vendor Rate Table Considerations
While most operators focus on customer-facing sell rates when setting up time-based routing, you should also configure rate switching on the vendor (buy) side if your vendors offer different rates for peak and off-peak periods. This ensures that VOS3000 accurately calculates your margins in real time and can make better routing decisions.
To configure vendor-side period rates, create separate buy rate tables for peak and off-peak hours, then create a Package Period Rate configuration that binds these rate tables to the same Work Calendar. Assign this period rate configuration to your vendor accounts. When VOS3000 time-based routing switches the buy rate table at 18:00, the system immediately starts using the lower off-peak rates for cost calculations.
Practical Use Cases for VOS3000 Time-Based Routing
Understanding the configuration steps is important, but seeing how time-based routing applies to real-world scenarios helps you design the most effective routing strategy for your specific business. Here are three practical use cases that demonstrate the power and flexibility of time-based routing.
Use Case 1: Wholesale Traffic Day/Night Shifting
A wholesale VoIP operator routes traffic to Bangladesh, India, and the UK. Their vendors offer significantly different rates for peak and off-peak hours. During peak hours (08:00-18:00), VendorA offers the best rates for Bangladesh at $0.008/min, while VendorB is cheaper for UK traffic at $0.006/min. During off-peak hours, VendorC offers much lower rates across all destinations — $0.004/min for Bangladesh and $0.003/min for the UK. However, VendorC has limited capacity and lower ASR during peak hours.
Without time-based routing, the operator would need to manually switch gateway priorities twice a day, which is error-prone and impractical. With time-based routing configured, the system automatically routes through VendorA and VendorB during peak hours and switches to VendorC during off-peak hours. This can save the operator thousands of dollars per month while maintaining optimal call quality during peak hours.
🕐 Time Period
🏢 BD Gateway
🏢 UK Gateway
💰 BD Rate
💰 UK Rate
08:00-18:00 (Peak)
VendorA (Priority 1)
VendorB (Priority 1)
$0.008/min
$0.006/min
18:00-22:00 (Shoulder)
VendorC (Priority 1)
VendorC (Priority 1)
$0.005/min
$0.004/min
22:00-08:00 (Off-Peak)
VendorC (Priority 1)
VendorC (Priority 1)
$0.004/min
$0.003/min
Use Case 2: Weekend and Holiday Routing
Many carriers treat weekends and public holidays as extended off-peak periods, offering the same low rates as overnight hours. A VoIP operator who does not implement VOS3000 time-based routing for weekends is paying peak rates on Saturday and Sunday even though vendors charge off-peak rates. With the Work Calendar correctly defining Saturday and Sunday as non-working days, and holidays configured in the holiday list, VOS3000 automatically applies the non-working hours rate table for the entire weekend and on designated holidays.
This is especially valuable for operators handling call center traffic, which often has reduced or zero volume on weekends. By applying lower sell rates on weekends (matching the lower vendor costs), you can attract more weekend traffic from price-sensitive customers while still maintaining healthy margins.
Use Case 3: Multi-Timezone Routing
For operators routing traffic to multiple countries across different time zones, VOS3000 time-based routing becomes even more critical. When it is peak hours in Bangladesh (GMT+6), it might be off-peak in the UK (GMT+0) and late night in the US (GMT-5). A single Work Calendar cannot accurately represent peak hours for all destinations simultaneously.
The solution is to create multiple Work Calendars, each aligned to a specific destination’s time zone. Then create separate Package Period Rate configurations for each destination group. Assign the appropriate period rate to each customer account or rate group based on the destinations they call most frequently. While this requires more initial setup, the resulting routing precision can significantly increase profitability for multi-region operations.
Integrating Work Calendar with Account Settings in VOS3000 Time-Based Routing
The Work Calendar does not operate in isolation — it integrates with several other VOS3000 modules to deliver complete VOS3000 time-based routing functionality. One of the most important integrations is with the account settings, where you can bind a Work Calendar to individual accounts for customized time-based behavior.
Account-Level Calendar Binding
In the account configuration (Operation Management > Account Operation), each account can be associated with a specific Work Calendar. This association affects how time-based routing behaves for that particular account. When an account has a Work Calendar assigned, the system uses that calendar’s definitions to determine whether the current time falls in working or non-working hours for rate and routing decisions specific to that account.
This is particularly useful when you have customers in different time zones. A customer based in the UK should have their account bound to a UK Work Calendar, while a customer in Bangladesh should use a BD Work Calendar. This ensures that each customer’s rates and routing are aligned with their local business hours, not yours.
Suppressing All Duration Too Long Alarm
An often-overlooked feature that integrates with the Work Calendar is the account setting “Suppressing all duration too long alarm” (VOS3000 Manual Section 2.5.2.3). This setting, when enabled for an account, suppresses alarm notifications for calls that exceed the configured maximum duration threshold. The relevance to VOS3000 time-based routing is that during non-working hours, long-duration calls are more common (especially for international traffic where people have extended conversations during off-peak rate periods).
Without this suppression, your alarm system would generate excessive notifications during nighttime and weekend hours, flooding your monitoring system with false alerts. By binding the Work Calendar to the account and enabling duration alarm suppression, VOS3000 can intelligently manage alarms based on time periods, reducing noise during expected long-call periods while maintaining alert sensitivity during working hours when unexpectedly long calls may indicate fraud or technical issues.
🔧 Feature
📝 Description
🎯 VOS3000 Time-Based Routing Impact
Account Calendar Binding
Links account to a Work Calendar
Per-account time-based rate switching
Duration Alarm Suppression
Suppresses long-call alarms
Reduces false alerts during off-peak
Period Rate Assignment
Binds period rate to account
Automatic rate table switching per account
Rate Group Authorization
Controls which rates accounts can use
Limits time-based rates to authorized accounts
VOS3000 Time-Based Routing and Gateway Priority Integration
While the Package Period Rate system handles rate table switching, the actual call routing (which gateway the call is sent through) is controlled by gateway priorities in the routing gateway configuration. For a complete time-based routing setup, you need to understand how rate switching interacts with gateway priority settings.
There are two primary approaches to implementing time-based gateway switching in VOS3000:
Approach 1: Period Rate with Fixed Gateway Priorities
In this approach, gateway priorities remain static, but the rate table changes based on time. This means that the same gateway is always used for a given prefix regardless of time, but the billing rate applied to the call changes. This is the simpler approach and works well when your vendor offers different rates for peak and off-peak but routes through the same gateway.
The advantage of this approach is simplicity — you only need to configure the Package Period Rate, and the gateway configuration remains unchanged. The disadvantage is that you cannot route calls through different gateways based on time; you can only change the billing rates.
Approach 2: Period Rate with Dynamic Gateway Priorities
For more advanced VOS3000 time-based routing, you can combine period rates with different gateway priority configurations. This approach involves creating separate routing gateway entries with different priorities for working and non-working hours. While VOS3000 does not natively switch gateway priorities based on the Work Calendar directly, you can achieve similar results by:
Creating multiple rate groups — one for peak hours with the peak-hour vendor as the preferred gateway, and one for off-peak hours with the off-peak vendor as preferred
Using the Package Period Rate to switch between these rate groups based on the Work Calendar
Configuring account settings to use the appropriate rate group based on the period
This approach requires more configuration but provides the most flexible and profitable time-based routing setup. The key insight is that when the period rate switches the rate table, the rate table can be associated with different gateway priority configurations, effectively changing which gateway handles the call.
For help setting up this advanced configuration, contact our VOS3000 specialists on WhatsApp at +8801911119966.
🎯 Approach
⚙️ Configuration Complexity
✅ Advantages
⚠️ Limitations
Fixed Gateway + Period Rates
Low
Simple setup, reliable
Cannot switch gateways by time
Dynamic Gateway + Period Rates
Medium-High
Full time-based routing control
Requires more configuration effort
Common VOS3000 Time-Based Routing Configuration Mistakes
Even experienced VOS3000 operators make mistakes when configuring time-based routing. These errors can result in incorrect billing, lost revenue, or routing failures. Here are the most common pitfalls and how to avoid them.
Mistake 1: Mismatched Working Hours Between Calendar and Vendor Definitions
If your Work Calendar defines working hours as 08:00-18:00, but your vendor defines peak hours as 09:00-21:00, you will be applying off-peak sell rates during the vendor’s peak period from 18:00-21:00. This means you are selling at off-peak rates but paying peak vendor costs, which erodes your margin or even causes losses. Always verify that your Work Calendar working hours match your vendor’s peak-hour definitions exactly.
Mistake 2: Incomplete Rate Tables
Both the working hours and non-working hours rate tables must contain rate entries for all prefixes that your customers might dial. If the daytime rate table has an entry for prefix 88017 but the nighttime rate table does not, calls to 88017 during nighttime hours will either fail to bill correctly or use a default rate that may be incorrect. Always ensure both rate tables have complete and matching prefix coverage.
Mistake 3: Forgetting to Update Holiday Dates
Holiday dates change every year, and some holidays (like Eid) move based on the lunar calendar. If you configure holidays in your Work Calendar but never update them, your time-based routing will treat old holidays as non-working days while actual holidays pass unrecognized. Set a recurring reminder to update holiday dates at the beginning of each year.
Mistake 4: Not Testing Time-Based Rate Switching
After configuring VOS3000 time-based routing, many operators fail to verify that the rate switching actually works. The result can be that rates never switch, or they switch at the wrong times. Always test by making test calls just before and after the working hours boundary and verifying in the CDR that the correct rate table was applied.
After configuring your Work Calendar and Package Period Rate, you must verify that VOS3000 time-based routing is working correctly. Verification involves both immediate testing and ongoing monitoring.
Immediate Verification Steps
Step 1: Check Calendar Status. Navigate to System Management > Work Calendar and verify your calendar appears in the list with the correct working days and hours. Click on the calendar to review all settings including holiday dates.
Step 2: Verify Period Rate Configuration. Navigate to Rate Management > Package Period Rate Management and confirm that your period rate entry shows the correct Work Calendar, working hours rate table, and non-working hours rate table.
Step 3: Make Test Calls. Make test calls during both working and non-working hours. After each test call, check the CDR record to verify that the correct rate table was applied. The CDR should show the rate from the working hours table during the day and the rate from the non-working hours table at night.
Step 4: Test Boundary Conditions. Make test calls at the exact boundary between working and non-working hours (for example, at 17:59 and 18:01) to verify that the rate switch happens at the correct time. This is where timing errors are most likely to appear.
Ongoing Monitoring for VOS3000 Time-Based Routing
Regular monitoring ensures that your VOS3000 time-based routing continues to function correctly over time. Key monitoring activities include:
Weekly CDR review: Sample CDRs from both working and non-working hours to confirm rate tables are switching correctly
Margin analysis: Compare working hours margins against non-working hours margins to verify that your time-based pricing is generating the expected profitability improvement
Gateway utilization reports: Monitor whether traffic distribution between gateways changes between working and non-working hours as expected
Holiday verification: Before each holiday, verify that the date is correctly configured in the Work Calendar
Once you have the basic time-based routing configuration working, several advanced techniques can further optimize your routing strategy and increase profitability.
Multiple Period Rate Configurations
VOS3000 allows you to create multiple Package Period Rate configurations, each with a different Work Calendar and different rate table bindings. This is essential for operations that serve customers across multiple time zones or with different pricing agreements. For example, you might have one period rate configuration for retail customers (who get a small off-peak discount) and another for wholesale customers (who get a larger off-peak discount).
Each period rate configuration is assigned to specific accounts or rate groups, ensuring that the correct time-based billing behavior applies to each customer segment.
Combining Time-Based Routing with Prefix-Based Rate Optimization
The most powerful routing strategies combine VOS3000 time-based routing with prefix-based rate optimization. For detailed prefix configuration, see our VOS3000 prefix settings guide. By having different rate tables for different prefix groups AND different time periods, you create a multi-dimensional pricing matrix that maximizes margin across every combination of destination and time.
For example, you might have four rate tables for Bangladesh mobile traffic:
BD_Mobile_Peak_Workday: Highest rates for weekday peak hours
BD_Mobile_OffPeak_Workday: Medium rates for weekday off-peak hours
BD_Mobile_Peak_Weekend: Lower rates for weekend daytime
BD_Mobile_OffPeak_Weekend: Lowest rates for weekend nighttime
By combining multiple Work Calendars and Package Period Rate configurations, you can implement this level of granular pricing control within VOS3000.
Using VOS3000 System Parameters to Support Time-Based Routing
Several VOS3000 system parameters affect how time-based routing behaves. Understanding these parameters helps you fine-tune the routing behavior:
SERVER_WORK_CALENDAR_ENABLED: This system parameter must be enabled for Work Calendar functionality to work. If this parameter is disabled, all time-based routing features are inactive regardless of your calendar configuration.
SERVER_PERIOD_RATE_ENABLED: This parameter must be enabled for Package Period Rate functionality to work. Without it, rate tables will not switch based on time periods.
Check these parameters in System Management > System Parameter (VOS3000 Manual Section 4.3) to ensure they are set correctly. If time-based routing is not working after configuration, these system parameters are the first thing to check.
Use this checklist to ensure you have completed all necessary steps for a fully functional VOS3000 time-based routing setup. Follow each step in order and verify the result before proceeding to the next step.
Create Work Calendar — Define calendar name, working days, working hours, and holidays in System Management > Work Calendar
Create Daytime Rate Table — Build a complete rate table with peak-hour rates for all prefixes in Rate Management > Rate Table Management
Create Nighttime Rate Table — Build a matching rate table with off-peak rates for the same prefixes
Create Package Period Rate — Bind the calendar and both rate tables in Rate Management > Package Period Rate Management
Enable System Parameters — Verify SERVER_WORK_CALENDAR_ENABLED and SERVER_PERIOD_RATE_ENABLED are set to 1
Bind Calendar to Accounts — Assign the Work Calendar to customer and vendor accounts that should use time-based routing
Assign Period Rate to Rate Groups — Link the Package Period Rate to the appropriate rate groups
Test Rate Switching — Make test calls during working and non-working hours and verify CDR rates
Test Boundary Conditions — Verify rate switching happens at the exact configured time boundaries
Set Up Monitoring — Establish regular CDR review and margin analysis procedures
Document Configuration — Record all calendar and period rate settings for future reference
Schedule Annual Holiday Updates — Set reminders to update holiday dates each year
Frequently Asked Questions About VOS3000 Time-Based Routing
❓ What is VOS3000 time-based routing and how does it work?
VOS3000 time-based routing is a feature that automatically switches rate tables and routing behavior based on the time of day, day of the week, and calendar dates. It works through two integrated components: the Work Calendar (which defines working hours, non-working hours, and holidays) and the Package Period Rate (which binds different rate tables to each time period). When the current time falls within working hours as defined by the calendar, VOS3000 applies the working hours rate table. When it falls outside working hours, the non-working hours rate table is applied automatically.
❓ How is VOS3000 time-based routing different from standard LCR routing?
Standard LCR routing uses static gateway priorities and rate tables that do not change based on time. VOS3000 time-based routing adds a time dimension, allowing different rate tables and potentially different routing priorities during different time periods. With LCR alone, the cheapest gateway for a destination is always used. With time-based routing, a different gateway may be cheapest at different times of day, and VOS3000 automatically adapts. The combination of LCR and time-based routing provides the most profitable routing strategy possible.
❓ Can I use multiple Work Calendars for different time zones in VOS3000 time-based routing?
Yes. You can create multiple Work Calendars in VOS3000, each aligned to a different time zone’s peak and off-peak hours. Each calendar is then assigned to the appropriate accounts or rate groups based on the destinations they serve. This is the recommended approach for operators routing traffic to multiple countries across different time zones, as it ensures that rate switching happens at the correct local time for each destination.
❓ Do I need to manually switch rate tables when using VOS3000 time-based routing?
No. The entire purpose of VOS3000 time-based routing is to automate rate table switching. Once you configure the Work Calendar and Package Period Rate correctly, VOS3000 automatically switches between the working hours and non-working hours rate tables at the boundaries defined in the calendar. No manual intervention is required, which eliminates the risk of forgetting to switch rates and the operational overhead of manual changes.
❓ What happens if I do not bind a Work Calendar to an account?
If an account does not have a Work Calendar assigned, VOS3000 time-based routing will not apply to that account. The account will use its default rate table at all times, regardless of the time of day or day of the week. This means no rate switching occurs, and the account effectively operates with static LCR routing only. To enable time-based routing for an account, you must both create the Package Period Rate configuration and bind the appropriate calendar and period rate to the account.
❓ How do I verify that VOS3000 time-based routing is switching rates correctly?
The most reliable verification method is to make test calls during both working and non-working hours, then check the CDR records for each call. The CDR will show which rate was applied to the call. If the working hours rate was applied during the day and the non-working hours rate was applied at night, your configuration is working correctly. Also test at the exact boundary times (for example, at 17:59 and 18:01) to confirm the switch happens at the right moment.
❓ Can VOS3000 time-based routing handle different rates for weekends and holidays?
Yes. The Work Calendar distinguishes between working days and non-working days (which include weekends and designated holidays). Non-working days use the non-working hours rate table for the entire day, not just during nighttime. This means weekends and holidays automatically receive the lower off-peak rates all day long, which aligns with how most carriers price their services. You can add specific holiday dates to the calendar each year to ensure correct holiday rate application.
❓ What system parameters must be enabled for VOS3000 time-based routing to work?
Two system parameters must be enabled: SERVER_WORK_CALENDAR_ENABLED (must be set to 1) enables the Work Calendar feature, and SERVER_PERIOD_RATE_ENABLED (must be set to 1) enables the Package Period Rate switching feature. If either of these parameters is disabled, the corresponding time-based routing functionality will not work, regardless of your calendar and period rate configuration. Verify these parameters in System Management > System Parameter (VOS3000 Manual Section 4.3).
Configure VOS3000 Time-Based Routing with Expert Help
Setting up VOS3000 time-based routing correctly can transform your VoIP business from one that pays static peak rates around the clock to one that dynamically optimizes costs based on time. The financial impact of proper time-based routing configuration is significant — many operators report 15-30% reduction in termination costs after implementing day/night rate switching and weekend routing. However, the configuration requires careful attention to detail, from matching working hours to vendor definitions to ensuring complete prefix coverage in both rate tables.
Our VOS3000 specialists have helped operators worldwide implement and optimize time-based routing configurations. Whether you need help with initial Work Calendar setup, Package Period Rate configuration, advanced multi-timezone routing strategies, or troubleshooting an existing configuration that is not switching rates correctly, we are here to help.
📱 Contact us on WhatsApp: +8801911119966
We offer complete VOS3000 time-based routing configuration services, including Work Calendar creation, rate table design, period rate binding, account integration, testing, and documentation. Let us help you unlock the full profit potential of time-based routing in your VOS3000 operation.
📞 Need Professional VOS3000 Setup Support?
For professional VOS3000 installations and deployment, VOS3000 Server Rental Solution:
VOS3000 Vendor Failover: Configure Priority and Fallback Routing
When your primary VoIP vendor goes offline, every second of downtime costs you revenue and damages your reputation. VOS3000 vendor failover configuration is the critical mechanism that ensures your calls continue to connect even when your preferred termination provider returns SIP 503 Service Unavailable, SIP 408 Request Timeout, or simply stops responding. Without a properly configured VOS3000 vendor failover strategy, a single vendor outage can bring your entire VoIP operation to a halt, causing lost revenue, angry customers, and cascading failures across your business.
This comprehensive guide walks you through every aspect of VOS3000 vendor failover configuration, from basic priority-based routing to advanced techniques like ASR-based sorting, gateway groups, tech prefix backup routes, and protect routes. All configurations reference the official VOS3000 V2.1.9.07 Manual with specific section and page numbers. Whether you are setting up failover for the first time or optimizing an existing configuration, this guide provides the step-by-step instructions you need. For expert assistance, contact us on WhatsApp at +8801911119966.
Table of Contents
What Happens When a Primary Vendor Fails in VOS3000
Understanding the failure scenarios that trigger VOS3000 vendor failover is the first step toward building a resilient routing architecture. When you send a call to a vendor’s gateway, several types of failures can occur, and each one requires a different failover approach.
SIP 503 Service Unavailable Scenario
A SIP 503 response is one of the most common failure signals in VoIP. It indicates that the vendor’s server is temporarily unable to process the call due to overload or maintenance. When VOS3000 receives a SIP 503 from a routing gateway, the behavior depends on your configuration. If “Switch gateway until connect” is enabled and the SIP 503 response code is not in your “Stop switching response codes” list, VOS3000 will attempt to route the call through the next available gateway in the priority sequence. This is the core of VOS3000 vendor failover — the automatic retry through an alternative path.
SIP 408 Request Timeout Scenario
A SIP 408 timeout occurs when VOS3000 sends an INVITE to the vendor but receives no response within the configured timeout period. This typically indicates network connectivity issues, firewall problems, or a completely downed vendor server. VOS3000 vendor failover handles timeouts by treating the gateway as unavailable and attempting the next gateway in the routing sequence. The timeout duration is controlled by the SIP timer settings in your VOS3000 system parameters.
SIP 5xx and 4xx Error Scenarios
Beyond 503 and 408, other SIP error codes can trigger failover behavior. SIP 500 (Server Internal Error), SIP 502 (Bad Gateway), and SIP 504 (Server Time-out) are all signals that the vendor cannot process the call. However, not all error codes should trigger failover. For example, SIP 486 (Busy Here) or SIP 487 (Request Terminated) indicate that the called party is unavailable, not that the vendor has failed. Configuring which response codes should and should not trigger VOS3000 vendor failover is critical for avoiding unnecessary gateway switching.
🔴 SIP Code
📝 Description
🔄 Failover Action
⚙️ Configuration
503
Service Unavailable
Switch to next gateway
Enable gateway switch
408
Request Timeout
Switch to next gateway
Enable gateway switch
500
Server Internal Error
Switch to next gateway
Enable gateway switch
502
Bad Gateway
Switch to next gateway
Enable gateway switch
504
Server Time-out
Switch to next gateway
Enable gateway switch
486
Busy Here
Stop switching (user busy)
Add to stop list
487
Request Terminated
Stop switching (call cancelled)
Add to stop list
403
Forbidden
Stop switching (auth issue)
Add to stop list
As shown in the table above, VOS3000 vendor failover must distinguish between vendor-side failures (which should trigger failover) and user-side failures (which should not). Configuring the “Stop switching response codes” correctly prevents wasteful failover attempts when the problem is with the called number, not the vendor.
Setting Up Secondary Vendor Routing via Priority
The foundation of VOS3000 vendor failover is the priority system in the routing gateway configuration. Each routing gateway is assigned a priority number, and VOS3000 uses these numbers to determine the order in which gateways are tried. Lower priority numbers mean higher priority — a gateway with priority 1 is tried before a gateway with priority 2, which is tried before priority 3, and so on.
How Priority Numbers Control Failover Order
When configuring VOS3000 vendor failover, you assign your primary vendor the lowest priority number (typically 1), your secondary vendor the next number (2), and your tertiary vendor the next (3). When a call arrives, VOS3000 attempts the priority 1 gateway first. If that gateway fails to connect the call and gateway switching is enabled, VOS3000 automatically tries the priority 2 gateway, and then the priority 3 gateway if needed. This creates the failover sequence that keeps your calls connected.
Navigate to Operation Management > Gateway Operation > Routing Gateway (VOS3000 Manual Section 2.5.1.1, Page 28) to configure priority settings. The “Priority” field accepts numeric values where lower numbers represent higher priority. All gateways sharing the same prefix are sorted by this priority value.
Follow these steps to set up a priority-based failover configuration in VOS3000:
Step 1: Log in to the VOS3000 web interface and navigate to Operation Management > Gateway Operation > Routing Gateway (VOS3000 Manual Section 2.5.1.1, Page 28).
Step 2: Click “Add” to create the primary vendor gateway. Fill in the SIP server IP, port, prefix (e.g., “880”), and set the Priority to 1. Configure the line limit based on your vendor agreement.
Step 3: Click “Add” again to create the secondary vendor gateway. Use the same prefix “880” but set the Priority to 2. This ensures the secondary gateway is only tried when the primary fails.
Step 4: Add the tertiary vendor gateway with the same prefix “880” and Priority 3.
Step 5: For the last-resort backup, add a gateway with Priority 4 and check the “Set to protect route” checkbox. This gateway will only be used when all normal gateways fail.
Step 6: In each gateway configuration, enable “Switch gateway until connect” (VOS3000 Manual Section 2.5.1.1, Page 50). This is the setting that makes VOS3000 vendor failover actually work — without it, a failure on one gateway simply returns an error to the caller.
Step 7: Configure the “Stop switching response codes” field. Add response codes like 486, 487, 403, and 404 that should NOT trigger failover. These codes indicate problems with the called number or authentication, not vendor failures.
Using Gateway Group to Limit Gateways During Routing
Gateway Groups are an essential tool for VOS3000 vendor failover because they allow you to logically group multiple gateways together and enforce aggregate capacity limits across the group. When you have multiple vendors that share a common capacity pool or you want to limit the total number of calls going through a set of related vendors, Gateway Groups provide the control you need.
Gateway Group Configuration (Section 2.5.1.3)
As documented in VOS3000 Manual Section 2.5.1.3 (Page 31), Gateway Groups allow you to define a logical grouping of routing gateways. When a gateway belongs to a group, the group’s combined line usage is tracked, and the “Reserved line” setting in the group ensures that minimum capacity is preserved for high-priority traffic.
To configure a Gateway Group for VOS3000 vendor failover:
Navigation: Operation Management > Gateway Operation > Routing Gateway
Steps:
1. Create or edit a routing gateway
2. In the "Gateway group" field, enter a group name (e.g., "BD_Vendors_Group")
3. Set the "Reserved line" value for the group
4. Assign all related vendor gateways to the same group name
5. Save the configuration
The Reserved Line feature is particularly important for VOS3000 vendor failover scenarios. When the total number of active calls across all gateways in the group approaches the group’s capacity, the reserved line count ensures that some capacity remains available for emergency routing. This means your protect route or highest-priority traffic will always have a path through the system, even when your secondary and tertiary vendors are heavily loaded.
🏷️ Group Name
🏢 Gateways in Group
📶 Total Lines
🔒 Reserved Lines
📋 Purpose
BD_Vendors_Group
VendorA, VendorB, VendorC
1000
100
Reserve capacity for premium traffic
UK_Vendors_Group
VendorUK1, VendorUK2
400
50
Guarantee failover capacity
Premium_Group
PremiumV1, PremiumV2, PremiumV3
600
150
Enterprise customer guarantee
How Gateway Groups Enhance VOS3000 Vendor Failover
Gateway Groups improve VOS3000 vendor failover in several important ways. First, they prevent capacity exhaustion across a set of vendors. Without groups, each gateway’s line limit is independent, meaning all three vendors could simultaneously reach capacity. With groups, the combined capacity is monitored, and the reserved line mechanism ensures some capacity is always available for critical routing.
Second, Gateway Groups work with the routing gateway sorting rules to ensure that when failover occurs, the system does not overwhelm the secondary vendor. The group acts as a throttle, preventing too many failed-over calls from saturating the backup gateway. This is essential for maintaining call quality during VOS3000 vendor failover events, where a sudden surge of traffic to a secondary vendor could cause that vendor to fail as well, creating a cascading failure.
Using Tech Prefix for Backup Routes in VOS3000 Vendor Failover
Tech Prefix is another powerful method for implementing VOS3000 vendor failover. The Tech Prefix (also called Gateway Prefix in the routing gateway configuration) allows you to create backup routes that are activated through a different prefix than your primary routes. This provides an additional layer of routing control beyond simple priority numbers.
How Tech Prefix Works in Failover Scenarios
When you configure a routing gateway, the “Gateway prefix” field (VOS3000 Manual Section 2.5.1.1, Page 29) specifies the prefix that VOS3000 prepends to the called number before sending it to the vendor. But more importantly for VOS3000 vendor failover, you can create a secondary routing gateway entry for the same vendor with a different matching prefix that serves as a backup path.
For example, suppose your primary route for Bangladesh mobile uses prefix “880” with VendorA at priority 1. You can create a secondary entry using prefix “88017” (a more specific prefix for Grameenphone mobile) that routes through VendorB at priority 1. When the broader “880” route fails, the extension mode prefix matching will try the more specific “88017” prefix, which routes through a different vendor — creating an automatic VOS3000 vendor failover path.
Follow these steps to set up Tech Prefix-based VOS3000 vendor failover:
Step 1: Create primary routing gateway
- Prefix: 880
- Priority: 1
- Gateway prefix: (empty or as needed)
- Enable "Switch gateway until connect"
Step 2: Create backup routing gateway with Tech Prefix
- Prefix: 880
- Priority: 2
- Gateway prefix: *99 (or any tech prefix your backup vendor expects)
- Enable "Switch gateway until connect"
Step 3: Configure callee rewrite if needed
- The gateway prefix *99 will be prepended to the called number
- The backup vendor must be configured to accept and strip the tech prefix
This Tech Prefix approach is particularly useful when your backup vendor requires a specific prefix to identify your traffic. Many wholesale carriers assign a tech prefix to each customer, and you must include this prefix in the called number for the carrier to accept the call. By setting the Gateway Prefix field in the backup routing gateway, VOS3000 automatically adds the required prefix when failing over to that vendor.
Avoiding Call Drops During VOS3000 Vendor Failover
One of the most critical aspects of VOS3000 vendor failover is ensuring that the failover process itself does not cause call drops or excessive Post Dial Delay (PDD). When a primary vendor fails, the time it takes to attempt the next vendor in the sequence directly impacts the caller experience. If the failover takes too long, the caller may hang up before the call connects through the backup vendor.
The Failover Sequence and Timing
VOS3000 vendor failover follows a specific sequence that determines how quickly calls are rerouted. Understanding this sequence helps you minimize call drop rates during failover events:
INVITE sent to primary gateway: VOS3000 sends the SIP INVITE to the priority 1 gateway
Wait for response: VOS3000 waits for a response up to the configured SIP timer T1 timeout
Failure detected: If the response is a failure code (not in the stop list), failover begins
INVITE sent to next gateway: VOS3000 sends a new INVITE to the next priority gateway
Process repeats: Steps 2-4 repeat until a gateway connects the call or all gateways are exhausted
The total failover time is the sum of all timeout periods across all failed gateways. If each gateway takes 3 seconds to timeout, and you have three gateways, the worst-case failover time is 9 seconds — which is unacceptably long for most callers. To minimize this, configure your SIP timer values appropriately and use “Switch gateway until connect” to ensure failover happens quickly.
Optimizing Failover Speed
To minimize call drops during VOS3000 vendor failover, follow these optimization practices:
Reduce SIP T1 timer: The default SIP T1 timer is 500ms. Adjusting this in the system parameters can reduce the time VOS3000 waits before considering a gateway unresponsive
Configure appropriate SIP timer B: Timer B controls the maximum INVITE transaction timeout. The default is 32 seconds (64*T1), which is too long for failover scenarios
Enable “Switch gateway until connect”: This is mandatory for VOS3000 vendor failover. Without it, the call simply fails when the first gateway returns an error
Use protect routes wisely: Protect routes add one more layer of failover, but each additional layer increases maximum failover time
Limit the number of failover hops: More than 3-4 failover levels usually results in unacceptable PDD for the caller
For routing optimization best practices that complement your VOS3000 vendor failover strategy, see our VOS3000 routing optimization guide.
The VOS3000 routing gateway sorting rules determine the order in which matching gateways are tried for each call. Understanding these rules is essential for VOS3000 vendor failover because they control which gateway is attempted first, second, third, and so on. As documented in VOS3000 Manual Section 4.3.3, there are multiple sorting strategies available, and the system parameters control which strategy is active.
Prefix Priority and Gateway Priority Sorting
The default sorting mechanism in VOS3000 uses two levels of priority. First, gateways are grouped by their matching prefix, with longer (more specific) prefixes taking precedence. Within each prefix group, gateways are sorted by their assigned priority number (lower number = higher priority). This means that if you have gateways matching both “88017” and “880”, the “88017” gateways will always be tried first because the prefix is more specific.
For VOS3000 vendor failover, this means your most specific routes are attempted first, and broader routes serve as automatic fallbacks. If all gateways matching the specific prefix “88017” fail, VOS3000 will try gateways matching the broader prefix “880” (assuming Extension mode is enabled). This prefix hierarchy provides a natural failover mechanism that works alongside the priority-based failover within each prefix group.
Line Usage-Based Sorting
When multiple gateways have the same prefix and priority, VOS3000 can sort them based on current line utilization. The gateway with the lowest utilization ratio (current calls divided by line limit) is tried first. This provides basic load balancing between equal-priority gateways and ensures that the least busy gateway is always selected. For VOS3000 vendor failover, this means that if two vendors are configured at the same priority level, traffic is distributed based on available capacity, and if one vendor becomes congested, calls naturally shift to the other.
The SS_GATEWAYASRROUTESORTCONFIG system parameter enables Answer Seizure Ratio (ASR) based gateway sorting. When this parameter is enabled, VOS3000 tracks the ASR of each routing gateway over a configurable time window and sorts gateways by their recent ASR performance. Gateways with higher ASR values are tried first, automatically routing calls away from poorly performing vendors.
For VOS3000 vendor failover, ASR-based sorting is extremely valuable because it provides proactive failover before a vendor completely fails. If a vendor’s ASR drops from 50% to 20%, the system automatically deprioritizes that gateway, routing more calls through better-performing vendors. This gradual shift prevents the sudden traffic surge that occurs with hard failover and provides a smoother transition during partial vendor degradation.
To configure ASR-based sorting:
System Parameter: SS_GATEWAYASRROUTESORTCONFIG
Location: System Management > System Parameter Configuration
Manual Reference: Section 4.3.3
Configuration values:
- Enable/Disable ASR-based sorting
- Set the ASR calculation time window
- Set the minimum number of calls required for ASR calculation
- Define the ASR threshold below which a gateway is deprioritized
The SS_GATEWAYFEERATEROUTESORTCONFIG system parameter enables fee rate based gateway sorting. When enabled, VOS3000 sorts gateways by their associated rate (cost), automatically routing calls through the cheapest available vendor first. This is essentially an automated Least Cost Routing (LCR) mechanism that dynamically adjusts based on the rates configured in your rate tables.
For VOS3000 vendor failover, fee rate-based sorting provides automatic cost optimization during failover events. When the primary (cheapest) vendor fails and calls are rerouted to a secondary vendor, the system automatically uses the next cheapest available path. This ensures that even during failover, your routing remains cost-optimized.
System Parameter: SS_GATEWAYFEERATEROUTESORTCONFIG
Location: System Management > System Parameter Configuration
Manual Reference: Section 4.3.3
Configuration values:
- Enable/Disable fee rate-based sorting
- Set sorting direction (ascending for LCR)
- Configure rate comparison method
🔀 Sort Strategy
⚙️ System Parameter
📋 How It Works
🔄 Failover Benefit
Prefix Priority
Default (no parameter)
Longer prefix tried first
Natural prefix-based fallback
Gateway Priority
Default (no parameter)
Lower number = higher priority
Explicit failover order
Line Usage
Default behavior
Least utilized gateway first
Load-based distribution
ASR-Based
SS_GATEWAYASRROUTESORTCONFIG
Higher ASR gateway first
Proactive quality-based failover
Fee Rate-Based
SS_GATEWAYFEERATEROUTESORTCONFIG
Cheapest gateway first
Cost-optimized failover
Gateway Switch Settings: Switch Gateway Until Connect
The “Switch gateway until connect” setting is the single most important configuration for VOS3000 vendor failover. Without this setting enabled, VOS3000 will not attempt alternative gateways when the primary gateway fails — the call simply fails, and the caller receives the error response from the vendor. Enabling this setting tells VOS3000 to keep trying gateways in the priority sequence until one successfully connects the call or all gateways are exhausted.
Configuring Switch Gateway Until Connect
To enable this critical VOS3000 vendor failover setting, navigate to Operation Management > Gateway Operation > Routing Gateway (VOS3000 Manual Section 2.5.1.1, Page 50). Edit each routing gateway that should participate in the failover sequence and check the “Switch gateway until connect” checkbox. This setting must be enabled on each gateway in the failover chain for the failover to work correctly.
Here is the exact configuration path:
Navigation Path:
Operation Management > Gateway Operation > Routing Gateway
-> Select gateway -> Edit
-> Check "Switch gateway until connect" checkbox
-> Configure "Stop switching response codes"
-> Click Save
Repeat for ALL gateways in the failover chain
Stop Switching Response Codes Configuration
The “Stop switching response codes” field works hand in hand with “Switch gateway until connect” to control VOS3000 vendor failover behavior. When VOS3000 receives a SIP response code that is listed in the stop switching field, it stops trying additional gateways and returns the error to the caller immediately. This prevents unnecessary failover attempts for errors that indicate the problem is not with the vendor but with the called number or the caller’s credentials.
Common stop switching response codes for VOS3000 vendor failover configuration:
486 (Busy Here): The called party is busy — trying another vendor will not help
487 (Request Terminated): The call was cancelled — no point trying another vendor
403 (Forbidden): Authentication issue — all vendors would likely reject the call
404 (Not Found): Number does not exist — no vendor can complete this call
484 (Address Incomplete): Invalid number format — routing issue, not vendor issue
488 (Not Acceptable Here): Codec negotiation failure — may fail on all vendors
Response codes that should NOT be in the stop list (these should trigger VOS3000 vendor failover):
503 (Service Unavailable): Vendor is down — failover to backup
408 (Request Timeout): Vendor unreachable — failover to backup
500 (Server Internal Error): Vendor error — failover to backup
502 (Bad Gateway): Vendor upstream error — failover to backup
504 (Server Time-out): Vendor timeout — failover to backup
🛑 Action
🔢 SIP Code
📝 Reason
🔄 Failover?
🛑 STOP switching
486
Called party busy
No
🛑 STOP switching
487
Call cancelled
No
🛑 STOP switching
403
Authentication failure
No
🛑 STOP switching
404
Number not found
No
✅ CONTINUE switching
503
Vendor unavailable
Yes
✅ CONTINUE switching
408
Vendor timeout
Yes
✅ CONTINUE switching
500
Vendor internal error
Yes
✅ CONTINUE switching
502
Bad gateway
Yes
Protect Routes for Guaranteed Backup in VOS3000 Vendor Failover
Protect routes are a specialized feature in VOS3000 that provide guaranteed backup routing for critical traffic. A protect route is a routing gateway that is excluded from normal gateway selection and is only used when all normal (non-protect) gateways fail. This makes protect routes essential for VOS3000 vendor failover because they ensure that there is always a fallback path available, even when all regular vendors are down or at capacity.
How Protect Routes Work
As documented in VOS3000 Manual Section 2.5.1.1 (Page 50), the “Set to protect route” checkbox marks a routing gateway as a protect route. When VOS3000 is selecting a gateway for a call, protect routes are excluded from the initial selection process. Only when all normal gateways matching the prefix have failed or are at capacity does VOS3000 consider protect routes.
This behavior is ideal for VOS3000 vendor failover because it preserves the capacity of your backup vendor. Without protect routes, a high-cost backup vendor at priority 2 might receive traffic even when the priority 1 vendor is working, simply because the priority 1 vendor is at capacity for some calls. With protect routes, the backup vendor is only activated during genuine failover events, preserving its capacity and minimizing your costs.
Configuring Protect Routes for Failover
Steps to configure a protect route:
1. Navigate to Operation Management > Gateway Operation > Routing Gateway
2. Add or edit the backup gateway
3. Set the same prefix as your primary gateways (e.g., "880")
4. Set an appropriate priority number
5. CHECK the "Set to protect route" checkbox
6. Configure line limit and other settings
7. Enable "Switch gateway until connect"
8. Save the configuration
Best practices for protect routes in VOS3000 vendor failover configurations:
Always have at least one protect route per critical prefix: This ensures that calls can always be connected, even during total vendor outages
Use a reliable but expensive vendor for protect routes: The protect route should be your most reliable vendor, even if it is the most expensive, because it is only used as a last resort
Set adequate line limits on protect routes: The protect route must have enough capacity to handle the traffic that would normally go through your primary and secondary vendors
Monitor protect route usage: If your protect route is being used frequently, it indicates problems with your primary vendors that need investigation
Do not set protect routes on all gateways: At least one gateway per prefix must be a normal (non-protect) route, otherwise no gateway will be selected for normal traffic
Real-World VOS3000 Vendor Failover Scenarios
Understanding VOS3000 vendor failover theory is important, but seeing how it applies in real-world scenarios makes the concepts practical. Let us walk through three common failover scenarios with step-by-step configurations.
Scenario 1: Primary Vendor SIP 503 Outage
Your primary vendor for Bangladesh traffic (VendorA) experiences a SIP 503 outage during peak hours. All calls to prefix “880” are failing with SIP 503 errors. Your VOS3000 vendor failover configuration automatically reroutes traffic to the secondary vendor.
Current Configuration:
VendorA: Prefix 880, Priority 1, Line Limit 500, Switch gateway until connect = Yes
VendorB: Prefix 880, Priority 2, Line Limit 300, Switch gateway until connect = Yes
VendorC: Prefix 880, Priority 3 (Protect), Line Limit 200, Switch gateway until connect = Yes
What happens during the outage:
Call arrives for number 880171234567
VOS3000 matches prefix “880” and finds three gateways
VendorA (Priority 1) is tried first — receives SIP 503
503 is not in the stop switching list, so failover continues
VendorB (Priority 2) is tried — call connects successfully
CDR records show VendorB as the routing gateway
This is the ideal VOS3000 vendor failover outcome — the caller experiences a slightly longer PDD but the call connects successfully through the backup vendor without manual intervention.
Scenario 2: Vendor Timeout with Multiple Retries
VendorA stops responding entirely (network issue, not SIP error). All INVITEs time out after the SIP Timer B period. Your VOS3000 vendor failover configuration handles this through timeout detection.
Failover sequence:
Call arrives for number 880181234567
INVITE sent to VendorA — no response
After Timer B expires (e.g., 16 seconds with optimized settings), failover begins
INVITE sent to VendorB — call connects
Total additional PDD: ~16 seconds (can be reduced with shorter Timer B)
The key optimization for this scenario is reducing the SIP Timer B value so that VOS3000 vendor failover happens more quickly. A 16-second timeout per gateway is reasonable, but if you need faster failover, you can reduce it further at the risk of prematurely timing out legitimate slow responses.
Scenario 3: Cascading Failover to Protect Route
Both VendorA and VendorB are experiencing issues simultaneously (perhaps due to a regional outage affecting multiple carriers). Only the protect route VendorC is available.
Failover sequence:
Call arrives for number 880191234567
VendorA (Priority 1) returns SIP 503 — failover
VendorB (Priority 2) returns SIP 503 — failover
VendorC (Priority 3, Protect) is activated — call connects
Total additional PDD: ~2-4 seconds (two SIP 503 responses are fast)
In this VOS3000 vendor failover scenario, the protect route saves the day. Without the protect route, the call would have failed entirely, resulting in lost revenue and customer dissatisfaction. The protect route ensures that even during catastrophic multi-vendor outages, your VoIP business continues to deliver calls.
🎬 Scenario
💥 Failure Type
🔄 Failover Path
⏱️ Additional PDD
✅ Result
Single vendor 503
SIP 503 Service Unavailable
VendorA → VendorB
1-3 seconds
Call connects on backup
Vendor timeout
SIP 408 Request Timeout
VendorA → VendorB
8-16 seconds
Call connects after timeout
Multi-vendor outage
Multiple SIP 503
VendorA → VendorB → VendorC
2-6 seconds
Protect route connects
Vendor at capacity
Line limit reached
Skip VendorA → VendorB
0 seconds (immediate)
Overflow to secondary
Low ASR degradation
ASR below threshold
Auto-demote VendorA
0 seconds (proactive)
Gradual traffic shift
Testing VOS3000 Vendor Failover with Routing Analysis Tool
The VOS3000 Routing Analysis tool is your most important ally for testing and validating your VOS3000 vendor failover configuration. Before relying on your failover setup in production, you must test it to ensure that calls will actually be rerouted correctly when a vendor fails.
Using the Routing Analysis Tool
Navigate to Operation Management > Business Analysis > Routing Analysis (VOS3000 Manual Section 2.5.3.1, Page 90) to access the routing analysis tool. This tool shows you exactly how VOS3000 would route a specific number based on your current configuration, including the complete failover sequence.
To test your VOS3000 vendor failover configuration:
Testing Steps:
1. Open Routing Analysis tool
2. Enter a test destination number (e.g., 880171234567)
3. Select the mapping gateway (customer) to simulate
4. Click "Analyze" or "Query"
5. Review the results:
- Which routing gateways match the prefix?
- What is the priority order?
- Which gateway would be selected first?
- What failover sequence would be followed?
- Are protect routes included in the failover chain?
6. Test with the primary gateway locked to simulate failover:
- Temporarily lock the primary gateway
- Re-run the routing analysis
- Verify that the secondary gateway is selected
- Unlock the primary gateway after testing
Live Testing Best Practices
Beyond the Routing Analysis tool, live testing is essential for validating VOS3000 vendor failover in real conditions. Here are best practices for live failover testing:
Test during off-peak hours: Schedule your live failover tests during low-traffic periods to minimize impact on real customers
Lock gateways to simulate failure: Use the gateway lock feature to temporarily disable the primary vendor and verify that calls failover correctly
Monitor CDR records: After testing, review CDR records to confirm that calls were routed through the expected backup gateways
Check PDD values: Measure the Post Dial Delay during failover to ensure it remains within acceptable limits
Verify billing accuracy: Confirm that failover calls are billed at the correct rate for the backup vendor, not the primary vendor
Test full failover chain: Lock all normal gateways to verify that protect routes activate correctly when all other routes fail
VOS3000 Vendor Failover Monitoring and Maintenance
Configuring VOS3000 vendor failover is not a one-time task. Regular monitoring and maintenance are essential to ensure that your failover configuration continues to work correctly as your vendor relationships, traffic patterns, and network conditions change over time.
Key Metrics to Monitor
Monitor these metrics regularly to ensure your VOS3000 vendor failover configuration is healthy:
Failover frequency: How often are calls being routed to backup vendors? High frequency indicates problems with primary vendors
Protect route usage: Protect route activation indicates severe vendor issues that need immediate attention
ASR by gateway: Track ASR for each routing gateway to identify degrading vendors before they fail completely
PDD during failover: Monitor Post Dial Delay to ensure failover is happening quickly enough
Call completion rate: Your overall call completion rate should not drop significantly during vendor outages
Vendor balance levels: Ensure backup vendors have sufficient balance to handle failover traffic
📊 Metric
✅ Healthy Range
⚠️ Warning
❌ Critical
🔄 Check Frequency
Primary vendor ASR
45%+
30-45%
Below 30%
Daily
Failover rate
Below 5%
5-15%
Above 15%
Daily
Protect route usage
0%
1-3%
Above 3%
Daily
Failover PDD
Below 3 seconds
3-7 seconds
Above 7 seconds
Weekly
Backup vendor balance
Sufficient for 24h
Less than 12h
Less than 4h
Daily
Gateway lock status
All unlocked
1 gateway locked
Multiple locked
Daily
Maintenance Tasks for VOS3000 Vendor Failover
Perform these maintenance tasks regularly to keep your VOS3000 vendor failover configuration in optimal condition:
Weekly:
Review CDR reports for failover patterns and identify recurring vendor issues
Check that all backup vendor gateways are online and responding to SIP OPTIONS
Verify that line limits on backup gateways match your current vendor agreements
Monthly:
Run complete failover tests using the Routing Analysis tool and live testing
Review and update stop switching response codes based on observed call patterns
Analyze failover call quality (ASR, ACD, PDD) and adjust configuration as needed
Review vendor rate changes and update priority assignments if cost relationships have changed
Quarterly:
Conduct a full failover drill — simulate complete primary vendor outage
Review and update protect route configurations
Evaluate whether ASR-based or fee rate-based sorting should be enabled or adjusted
Update gateway group configurations based on current capacity agreements
Common VOS3000 Vendor Failover Mistakes and How to Avoid Them
Even experienced VOS3000 operators make mistakes when configuring vendor failover. Understanding these common pitfalls helps you avoid costly errors.
Mistake 1: Forgetting to Enable “Switch Gateway Until Connect”
This is the most common and most damaging mistake. Without “Switch gateway until connect” enabled, VOS3000 will not attempt failover at all — the call simply fails when the primary gateway returns an error. Always verify this setting is enabled on every gateway in your failover chain.
Mistake 2: Not Configuring Stop Switching Response Codes
Without stop switching response codes, VOS3000 may attempt failover for calls that should not be retried, such as calls to busy numbers (486) or invalid numbers (404). This wastes time, increases PDD, and generates unnecessary traffic on backup vendors. Always configure stop switching codes to prevent unnecessary failover attempts.
Mistake 3: No Protect Route for Critical Prefixes
Without a protect route, a complete vendor outage means all calls fail. Many operators assume their secondary vendor will always be available, but regional outages can affect multiple carriers simultaneously. Always configure at least one protect route for every critical prefix to guarantee VOS3000 vendor failover under all conditions.
Mistake 4: Setting All Gateways as Protect Routes
This is the opposite mistake — if you set all gateways as protect routes, VOS3000 has no normal gateways to use for regular traffic, and all calls fail. At least one gateway per prefix must be a normal (non-protect) route.
Mistake 5: Not Testing the Failover Configuration
Many operators configure VOS3000 vendor failover and assume it works without ever testing it. When a real outage occurs, they discover that their configuration has errors. Always test your failover configuration using the Routing Analysis tool and live testing before relying on it in production.
⚠️ Mistake
💥 Impact
✅ Prevention
No “Switch gateway until connect”
Failover never happens
Enable on ALL failover gateways
No stop switching codes
Unnecessary failover attempts
Add 486, 487, 403, 404 to stop list
No protect route
Total outage with all vendor failures
Configure protect route for critical prefixes
All gateways set as protect
No normal routing available
Keep at least one normal gateway
Never tested failover
Hidden config errors
Test with Routing Analysis tool
Backup vendor low balance
Failover calls rejected
Monitor vendor balances daily
Wrong priority order
Expensive vendor used first
Verify priority numbering (lower = first)
VOS3000 Vendor Failover Best Practices Summary
Implementing a robust VOS3000 vendor failover strategy requires attention to detail and a systematic approach. Here are the best practices that every VOS3000 operator should follow:
Always enable “Switch gateway until connect” on every routing gateway that participates in failover — this is non-negotiable for VOS3000 vendor failover to work
Configure stop switching response codes to prevent unnecessary failover attempts for non-vendor errors like busy numbers and invalid destinations
Set up at least one protect route for every critical prefix to guarantee connectivity during total vendor outages
Use Gateway Groups to manage aggregate capacity across related vendors and reserve capacity for failover scenarios
Leverage ASR-based sorting (SS_GATEWAYASRROUTESORTCONFIG) for proactive failover that shifts traffic before vendors completely fail
Consider fee rate-based sorting (SS_GATEWAYFEERATEROUTESORTCONFIG) for automatic cost optimization during failover
Test regularly using the Routing Analysis tool and live failover drills
Monitor failover metrics daily to detect vendor degradation early
Use Tech Prefix for backup routes that require specific prefixes for vendor authentication
Keep backup vendor balances funded — a backup vendor with zero balance is no backup at all
Frequently Asked Questions About VOS3000 Vendor Failover
❓ What is VOS3000 vendor failover and why is it important?
VOS3000 vendor failover is the automatic rerouting of calls to a backup vendor when the primary vendor fails to connect the call. It is important because vendor outages are inevitable in VoIP — network issues, server maintenance, and capacity limits can all cause a primary vendor to fail. Without VOS3000 vendor failover, every call attempted during an outage would fail, resulting in lost revenue and customer churn. With proper failover configuration, calls are automatically rerouted to available backup vendors, maintaining service continuity even during vendor failures.
❓ How do I configure VOS3000 vendor failover priority correctly?
Configure VOS3000 vendor failover priority by assigning lower priority numbers to your preferred vendors. In the routing gateway configuration (VOS3000 Manual Section 2.5.1.1, Page 28), the Priority field determines the order in which gateways are tried. Set your primary vendor to Priority 1, secondary vendor to Priority 2, and tertiary vendor to Priority 3. Remember that lower numbers mean higher priority in VOS3000. Additionally, you must enable “Switch gateway until connect” on each gateway for the failover sequence to work. Without this setting, VOS3000 will not attempt alternative gateways when the primary fails.
❓ What is the difference between protect routes and regular backup routes in VOS3000 vendor failover?
A regular backup route (priority 2 or higher gateway) participates in normal gateway selection and may receive traffic even when the primary vendor is available, particularly when the primary vendor is at capacity. A protect route is excluded from normal gateway selection entirely and is only activated when ALL normal gateways fail. This means protect routes preserve their capacity for genuine emergency situations, while regular backup routes may be used for overflow traffic during normal operations. For VOS3000 vendor failover, use regular backup routes for capacity overflow and protect routes for guaranteed last-resort connectivity.
❓ How does ASR-based sorting improve VOS3000 vendor failover?
ASR-based sorting (enabled via SS_GATEWAYASRROUTESORTCONFIG) improves VOS3000 vendor failover by providing proactive failover before a vendor completely fails. Instead of waiting for a vendor to return SIP 503 or timeout errors, ASR-based sorting continuously monitors the Answer Seizure Ratio of each gateway and automatically deprioritizes gateways with declining ASR. This means that if a vendor’s quality degrades (ASR drops from 50% to 25%), VOS3000 gradually shifts traffic to better-performing vendors before the degraded vendor fails entirely. This proactive approach reduces failed call attempts and provides a smoother traffic transition compared to reactive failover.
❓ What SIP response codes should I add to the stop switching list for VOS3000 vendor failover?
For VOS3000 vendor failover, add the following SIP response codes to your stop switching list: 486 (Busy Here), 487 (Request Terminated), 403 (Forbidden), 404 (Not Found), 484 (Address Incomplete), and 488 (Not Acceptable Here). These codes indicate that the problem is not with the vendor but with the called number, caller authentication, or codec negotiation. Trying another vendor for these errors would waste time and increase PDD without improving the outcome. Conversely, do NOT add 503, 408, 500, 502, or 504 to the stop list, as these codes indicate vendor-side failures that should trigger VOS3000 vendor failover to the next gateway.
❓ How do I test my VOS3000 vendor failover configuration?
Test your VOS3000 vendor failover configuration using two methods. First, use the Routing Analysis tool (Operation Management > Business Analysis > Routing Analysis, VOS3000 Manual Section 2.5.3.1, Page 90) to simulate routing for specific numbers and verify the failover sequence. Second, perform live testing by temporarily locking the primary gateway and making test calls to verify that calls are rerouted to backup vendors. Review CDR records after testing to confirm the correct backup vendor was used and that billing rates are accurate. Always test during off-peak hours and unlock gateways immediately after testing.
❓ Can I use different failover configurations for different customer types in VOS3000 vendor failover?
Yes. VOS3000 allows you to restrict which routing gateways each mapping gateway (customer) can use through the “Mapping gateway name” field in the routing gateway configuration. This means you can create separate failover chains for different customer types — for example, premium customers might failover through high-quality vendors only, while budget customers use cheaper backup routes. Configure this by editing each routing gateway and specifying which mapping gateways are allowed or forbidden from using that route. This ensures that VOS3000 vendor failover behavior is customized per customer segment.
❓ What happens if all vendors including the protect route fail during VOS3000 vendor failover?
If all vendors including the protect route fail during VOS3000 vendor failover, VOS3000 returns a SIP 503 Service Unavailable response to the caller, and the CDR records the termination reason as “NoAvailableRouter” or “AllGatewayBusy.” This is the worst-case scenario and indicates that you need additional vendor capacity or more diverse vendor relationships. To prevent this, always maintain at least one vendor with independent infrastructure (different network, different datacenter) as your protect route, and ensure that vendor has sufficient balance and capacity to handle emergency failover traffic.
Configure VOS3000 Vendor Failover with Expert Help
Configuring VOS3000 vendor failover correctly is essential for maintaining uninterrupted VoIP service and protecting your revenue. A single misconfiguration — such as forgetting to enable “Switch gateway until connect” or not setting up protect routes — can result in complete service failure during vendor outages. Our team of VOS3000 specialists has helped hundreds of VoIP operators implement robust failover configurations that keep their businesses running even when vendors go down.
Whether you need help setting up VOS3000 vendor failover from scratch, troubleshooting an existing configuration that is not working correctly, or optimizing your failover strategy for maximum uptime and cost efficiency, we are here to help. We provide complete configuration services including priority setup, gateway groups, protect routes, ASR-based sorting, and thorough testing to ensure your failover works when you need it most.
📱 Contact us on WhatsApp: +8801911119966
Do not wait for a vendor outage to discover that your failover configuration is broken. Let us help you build a resilient VOS3000 vendor failover architecture that keeps your calls connected and your business profitable, no matter what happens to your vendors.
📞 Need Professional VOS3000 Setup Support?
For professional VOS3000 installations and deployment, VOS3000 Server Rental Solution:
