VOS3000 Callee Source Header Flexible To Request-Line Selection
Configuring the VOS3000 callee source header setting determines how VOS3000 extracts the destination (called) number from incoming SIP INVITE messages at the mapping gateway. The two available sources — the To header and the Request-Line (Request-URI) — can contain different values when a SIP proxy rewrites the destination during call routing. Choosing the correct source is essential for accurate dialed-number extraction, which directly affects routing prefix matching, billing rate lookups, and CDR recording of the called number. Get help with this configuration on WhatsApp: +8801911119966.
In SIP signaling, the called party number appears in two places: the To header and the Request-Line (also called Request-URI). Under normal conditions, both contain the same destination number. However, when calls pass through SIP proxies that perform number translation, load balancing, or routing decisions, the Request-Line may be rewritten to a different URI while the To header retains the original dialed number. Understanding which header contains the correct destination number for your deployment is the key to proper VOS3000 callee source header selection.
Table of Contents
To Header vs Request-Line — What Each Contains
The SIP To header and Request-Line serve different purposes in the SIP protocol. The To header identifies the logical recipient of the call (the originally dialed number), while the Request-Line specifies where the SIP message should actually be delivered (which may be a proxy-modified address). VOS3000 lets you choose which one to use for extracting the callee number.
Header
SIP Purpose
Typical Content
Modified by Proxy?
To
Logical recipient identification
Original dialed number
Rarely (per RFC 3261)
Request-Line
Message delivery target
May be rewritten by proxy
Commonly rewritten
When To and Request-Line Differ
Understanding the scenarios where the To header and Request-Line contain different values is critical for correct VOS3000 callee source header selection. These differences arise from SIP proxy behavior and can significantly impact routing accuracy if the wrong source is selected.
Configuration Steps for VOS3000 Callee Source Selection
To configure VOS3000 callee source header selection, navigate to the mapping gateway settings in the VOS3000 client. The callee source option is located under §2.5.1.2 of the mapping gateway configuration panel. For step-by-step gateway configuration guidance, see our gateway configuration guide. Need hands-on help? Message us on WhatsApp: +8801911119966.
Step
Action
Detail
1
Open mapping gateway
Gateway > Mapping Gateway > select gateway
2
Locate Callee Source field
Under SIP header settings section
3
Select source header
Choose “To” or “Request-Line” based on upstream proxy behavior
4
Save configuration
Click Save to apply changes
5
Test with sample calls
Verify CDR callee number matches expected dialed digits
Impact on Routing Prefix Matching
The extracted callee number is used for prefix matching in the VOS3000 routing table. If the wrong source is selected, the prefix may not match any routing entry, causing the call to fail with “No Available Router” or “Route Not Found” errors. For example, if a carrier prepends a tech prefix of 00 in the Request-Line, selecting Request-Line as the callee source would extract “0012015551234” instead of “12015551234”, which would fail to match the rate table entry for “1” prefix. For more on this, see our VOS3000 number transform guide.
When VOS3000 callee source header selection is misconfigured, the most common symptom is calls failing with “No Available Router” errors or CDRs showing incorrect called numbers. For broader routing troubleshooting, see our VOS3000 NoAvailableRouter guide and call routing reference.
Problem
Likely Cause
Solution
No Available Router errors
Request-Line has tech prefix, extracting wrong number
Change callee source to To header
Wrong rate applied
Extracted number has extra prefix digits
Switch to To header or strip prefix in dial plan
CDR shows internal URI
Request-Line rewritten by proxy to internal address
Frequently Asked Questions About VOS3000 Callee Source Header
What is the difference between To header and Request-Line in SIP?
The SIP To header identifies the logical recipient of the call — the party the caller intended to reach, which is typically the original dialed number. The Request-Line (Request-URI) specifies the actual network destination where the SIP message should be delivered, which may differ from the To header if a SIP proxy has rewritten it during routing. Under RFC 3261, the To header is generally not modified by proxies, while the Request-Line is commonly rewritten for routing purposes.
When should I use Request-Line as the callee source?
Use Request-Line as the VOS3000 callee source when the Request-URI contains the actual dialed number you need for routing, and there is no intermediate SIP proxy that modifies it. This is common in simple point-to-point SIP trunk configurations where the gateway sends INVITEs directly to VOS3000 without proxy intervention. If the Request-Line contains a different value than the To header due to proxy rewriting, you should typically use the To header instead to extract the original dialed number.
How do I know if my SIP proxy is rewriting the Request-Line?
You can determine whether your SIP proxy is rewriting the Request-Line by capturing SIP traffic using tcpdump or Wireshark and comparing the To header and Request-Line values in incoming INVITE messages. If they differ, a proxy is modifying the Request-Line. You can also check VOS3000 CDRs — if the CDR callee number shows unexpected prefixes or internal URIs, the Request-Line may contain modified values that are not suitable for routing or billing.
Does callee source affect the CDR called number field?
Yes, the VOS3000 callee source header selection directly determines what value appears in the CDR called number field. If To is selected, the CDR records the number from the To header. If Request-Line is selected, the CDR records the number from the Request-URI. Changing the callee source configuration can therefore change your CDR data, which affects billing reports, traffic analysis, and dispute resolution records. Always verify that the CDR called number matches the actual dialed number after changing this setting.
What happens if both To and Request-Line contain the same value?
If the To header and Request-Line contain the same value, the VOS3000 callee source header selection does not matter — either source will extract the same destination number. This is the case for direct gateway connections without intermediate SIP proxies. In such deployments, you can safely use either setting. However, it is still good practice to select “To” as the default because it is more stable and less likely to be modified by future network changes.
Can callee source and caller source be configured independently?
Yes, VOS3000 callee source header selection and caller source header selection are configured independently per mapping gateway. You can set the callee source to “To” while setting the caller source to “Remote-Party-ID”, or any other combination that matches your carrier’s SIP header conventions. This flexibility allows you to optimize CLI and DN extraction independently based on how each identity is delivered in your specific SIP trunk configuration.
Professional VOS3000 Gateway Configuration Support
Correct VOS3000 callee source header selection ensures that dialed numbers are extracted accurately for routing, billing, and CDR recording. Misconfigured callee source settings cause routing failures and billing discrepancies that are difficult to diagnose without understanding the SIP header structure.
Contact us on WhatsApp: +8801911119966
Our VOS3000 experts can analyze your SIP traffic, identify the correct callee source for each trunk, and configure your mapping gateways for optimal accuracy. Reach out today at +8801911119966 and eliminate routing failures caused by incorrect dialed-number extraction.
📞 Need Professional VOS3000 Setup Support?
For professional VOS3000 installations and deployment, VOS3000 Server Rental Solution:
VOS3000 Caller Source Header Selection Complete From Remote-Party-ID Display
Configuring VOS3000 caller source header selection determines which SIP header VOS3000 uses to extract the calling party number (CLI) from incoming calls at the mapping gateway. The three available sources — From header, Remote-Party-ID header, and Display name — each provide different caller identity information, and choosing the right one is critical for accurate caller ID presentation, correct billing rate lookups, and proper prefix matching. Misconfigured caller source selection leads to wrong CLI in CDRs, incorrect rate table matches, and caller ID presentation failures that affect both billing and user experience. Need help configuring this? Contact us on WhatsApp: +8801911119966.
In SIP signaling, the calling party identity can appear in multiple headers simultaneously, and these headers may contain different values. The From header always contains a URI with the caller number, but it may be modified by intermediate proxies. The Remote-Party-ID (RPID) header, defined in RFC 3325, provides a more trustworthy identity inserted by the network. The Display name component carries a human-readable caller label. VOS3000 lets you choose which source to trust for CLI extraction at each mapping gateway independently.
Table of Contents
Three Caller Source Options in VOS3000
The VOS3000 mapping gateway configuration under §2.5.1.2 provides three caller source options. Each option extracts the calling number from a different part of the SIP INVITE message, and the choice affects how the CLI is used for routing, billing, and presentation downstream.
Source Option
SIP Header
What Is Extracted
From
From: <sip:number@host>
User part of the From URI (the number before @)
Remote-Party-ID
Remote-Party-ID: <sip:number@host>
User part of the RPID URI (network-trusted identity)
Display
From: “Display Name” <sip:number@host>
Display name string from the From header
When to Use Each VOS3000 Caller Source
Choosing the correct VOS3000 caller source header selection depends on your upstream carrier configuration and how caller identity is delivered in your SIP trunks. Different carriers use different headers for CLI, and using the wrong source will extract incorrect or incomplete caller information.
Scenario
Recommended Source
Reason
Standard SIP carrier trunk
From
Most carriers put CLI in From header
Carrier with RPID support
Remote-Party-ID
RPID contains network-verified CLI
From header has privacy proxy value
Remote-Party-ID
RPID has real CLI behind privacy proxy
Display name contains actual number
Display
Some PBX systems put CLI in display name
Wholesale interconnect
Remote-Party-ID or From (per carrier)
Depends on interconnect agreement
From Header Source — Detailed Behavior
When VOS3000 caller source header selection is set to From, the system extracts the user portion of the SIP URI from the From header. This is the most commonly used source because virtually all SIP implementations include the calling number in the From header. However, the From header can be modified by intermediate proxies and does not carry network-verified identity — any SIP user agent can set any value in the From header. For environments where CLI accuracy is critical, the From header alone may not be trustworthy enough.
Aspect
From Header Source
Always present
Yes — mandatory in all SIP requests
Trust level
Low — can be spoofed by caller
Format
User part of sip:user@host URI
Privacy support
May contain anonymous value when privacy requested
Best for
Simple deployments without RPID support
Remote-Party-ID Source — Detailed Behavior
The Remote-Party-ID header, defined in RFC 3325, carries the network-verified identity of the calling party. When a carrier or SIP proxy authenticates the caller, it inserts the RPID header with the verified identity, which may differ from the From header value. Setting VOS3000 caller source header selection to Remote-Party-ID tells VOS3000 to prefer this network-verified identity over the self-declared From header. This is the recommended setting when your upstream carrier provides RPID, as it ensures accurate CLI for both routing and billing. For related CLI management, see our VOS3000 caller ID management guide.
Aspect
RPID Source
Always present
No — only if carrier/proxy inserts it
Trust level
High — network-verified identity
Privacy indicator
Contains privacy=id tag for caller ID restrictions
Screen indicator
Contains screen=yes for verified identity
Best for
Wholesale interconnects with carrier CLI verification
Impact of Caller Source on Billing and Rate Lookup
The extracted caller number is not just used for display — VOS3000 also uses it for prefix matching in rate tables and routing decisions. If the wrong source is selected, the extracted CLI may be incorrect, causing rate table mismatches and billing errors. For example, if the From header contains an anonymous value but the RPID has the real number, selecting From would result in no rate match, while RPID would produce the correct billing. For billing configuration, see our VOS3000 billing system guide. For direct support, message us on WhatsApp: +8801911119966.
Frequently Asked Questions About VOS3000 Caller Source Header Selection
What is caller source header selection in VOS3000?
Caller source header selection in VOS3000 is a mapping gateway configuration that determines which SIP header the system uses to extract the calling party number. The three options are From (extracts from the standard SIP From header URI), Remote-Party-ID (extracts from the RPID header that carries network-verified identity), and Display (extracts the display name from the From header). This setting is configured per mapping gateway under §2.5.1.2 of the VOS3000 administration manual.
When should I use Remote-Party-ID instead of From?
You should use Remote-Party-ID instead of From when your upstream carrier or SIP proxy inserts the RPID header with the verified calling party identity. The From header can be set to any value by the calling party and may contain anonymous or privacy-shielded values, while RPID is inserted by the network after authentication and represents the verified identity. If your carrier provides RPID headers, using this source ensures more accurate CLI for billing rate lookups and caller ID presentation.
What happens if Remote-Party-ID is selected but not present?
If VOS3000 caller source header selection is set to Remote-Party-ID but the incoming SIP INVITE does not contain an RPID header, VOS3000 falls back to extracting the caller number from the From header. This fallback behavior ensures that calls are not rejected or misrouted simply because the RPID header is absent. However, if the From header also contains an invalid or anonymous value, the CLI extraction will produce incorrect results.
Does caller source selection affect the CDR caller number field?
Yes, the caller source selection directly determines what value appears in the CDR caller number field. If From is selected, the CDR records the number from the From header URI. If Remote-Party-ID is selected, the CDR records the network-verified number from the RPID header. This means that changing the caller source configuration can change what appears in your CDRs, which affects billing reports, dispute resolution, and regulatory compliance records.
Can I use the Display name source for caller ID extraction?
Yes, the Display source option extracts the display name string from the From header (the quoted text before the URI). However, this option should be used with caution because display names are typically free-text strings that may not contain valid phone numbers. This option is useful only when the display name field contains the actual caller number in a specific deployment where PBX systems or carriers use this convention. For most production deployments, From or Remote-Party-ID are the appropriate choices.
How does caller source interact with P-Asserted-Identity?
VOS3000 caller source header selection focuses on the From, Remote-Party-ID, and Display headers. P-Asserted-Identity (PAI) is a separate SIP header defined in RFC 3325 that also carries network-verified identity. VOS3000 has separate configuration for PAI handling, which can work alongside or independently of the caller source selection. In some configurations, the PAI header may be used for outbound caller ID presentation while the caller source setting controls inbound CLI extraction. For detailed PAI configuration, see our VOS3000 PAI guide.
Get Expert VOS3000 Caller ID Configuration
Proper VOS3000 caller source header selection is essential for accurate caller ID extraction, correct billing, and reliable routing. Misconfigured caller source settings can cause billing discrepancies, failed rate lookups, and caller ID presentation issues across your entire network.
Contact us on WhatsApp: +8801911119966
Our VOS3000 specialists can help you configure the optimal caller source settings for each mapping gateway based on your carrier agreements. Reach out today at +8801911119966 and ensure your CLI handling is accurate and reliable.
📞 Need Professional VOS3000 Setup Support?
For professional VOS3000 installations and deployment, VOS3000 Server Rental Solution:
VOS3000 LRN Number Portability Proven US Carrier Lookup Configuration
Configuring VOS3000 LRN number portability is a mandatory step for any VoIP operator routing US termination traffic. The Local Routing Number (LRN) system, mandated by the FCC under the Local Number Portability (LNP) framework, ensures that calls to ported numbers reach the correct serving carrier instead of the original rate center assignment. Without LRN lookups enabled in VOS3000, calls to ported US numbers will route to the wrong carrier, resulting in failed completions, billing disputes, and regulatory non-compliance. Need help setting this up? Contact us on WhatsApp: +8801911119966.
Number portability in the United States allows subscribers to keep their phone numbers when switching carriers. Since the dialed number no longer identifies the serving carrier, the LRN acts as a routing alias — a 10-digit number that represents the actual switch currently serving the ported subscriber. VOS3000 performs an LRN dip (query) before routing each US call to determine the true serving carrier, then uses the returned LRN for rate table lookups and gateway selection.
Table of Contents
VOS3000 LRN Number Portability Parameter Overview
The LRN settings in VOS3000 are configured per mapping gateway under section §2.5.1.1 of the administration manual. These settings control whether LRN queries are performed, how the query is sent, and how VOS3000 processes the response for subsequent routing decisions.
Parameter
Description
Values
LRN Query Enable
Enables or disables LRN lookup for this gateway
Yes / No
LRN Query Mode
How the LRN query is performed
Internal / External
LRN Response Action
What to do with the returned LRN
Route by LRN / Route by DN
LRN Timeout
Maximum wait time for LRN response
Milliseconds (default varies)
Manual Section
VOS3000 documentation reference
§2.5.1.1
Why LRN Is Mandatory for US Termination Routing
In the US telecommunications market, over 100 million numbers have been ported since LNP was mandated in 2003. Without VOS3000 LRN number portability lookups, the system routes calls based on the NPA-NXX rate center assignment of the dialed number, which may no longer reflect the actual serving carrier. This leads to misrouted calls that either fail at the wrong carrier or get rejected entirely. For operators handling US wholesale traffic, LRN dips are not optional — they are a business-critical requirement that directly impacts ASR, ACD, and revenue accuracy.
Scenario
Without LRN Lookup
With LRN Lookup
Non-ported number
Routes correctly (coincidence)
Routes correctly (confirmed)
Ported number
Routes to original carrier (WRONG)
Routes to current carrier (CORRECT)
Billing rate lookup
Rates based on original rate center
Rates based on serving LRN
ASR impact
Lower (misrouted calls fail)
Higher (correct routing)
Regulatory compliance
Non-compliant
FCC compliant
LRN Query Mode Configuration (VOS3000 LRN Number Portability)
VOS3000 supports two LRN query modes as defined in §2.5.1.1. Internal mode uses the built-in LRN client that connects directly to an external LRN dip server configured via SS_LRN_SERVER_IP and PORT (covered in our gateway configuration guide). External mode expects the upstream carrier or SIP proxy to perform the LRN dip and pass the LRN in the SIP INVITE, typically in the P-Asserted-Identity or a custom header.
Query Mode
How LRN Is Obtained
Best For
Internal
VOS3000 queries LRN server directly
Operators with own LRN dip subscription
External
Upstream carrier provides LRN in SIP headers
Operators relying on carrier LRN dip
LRN Response Handling and Routing Logic
When VOS3000 LRN number portability is enabled and a query returns an LRN, the system must decide how to use it for routing. The LRN response action determines whether VOS3000 routes the call using the returned LRN (which identifies the serving carrier) or falls back to the original dialed number. Routing by LRN is the recommended setting for US traffic because it ensures the call reaches the correct serving switch. For detailed routing configuration, see our VOS3000 call routing guide.
Response Action
Routing Behavior
Rate Lookup Basis
Route by LRN
Uses LRN for prefix/rate matching
LRN NPA-NXX
Route by Dialed Number
Uses original DN for prefix/rate matching
Original NPA-NXX
Hybrid (LRN first, DN fallback)
Tries LRN match, falls back to DN
LRN with DN fallback
Step-by-Step LRN Configuration Procedure
Follow these steps to enable VOS3000 LRN number portability on a mapping gateway. Ensure your LRN dip server is already configured as described in our CDR analysis guide and reachable from the VOS3000 server. For direct assistance, message us on WhatsApp: +8801911119966.
Step
Action
Detail
1
Open mapping gateway settings
Navigate to Gateway > Mapping Gateway in VOS3000 client
2
Enable LRN Query
Set LRN Query Enable to Yes on the gateway
3
Select Query Mode
Choose Internal if using own LRN server, External if carrier provides
4
Set Response Action
Set to Route by LRN for accurate US routing
5
Configure LRN Server IP/PORT
Set SS_LRN_SERVER_IP and PORT in softswitch parameters
6
Save and test
Place a test call to a known ported number and verify CDR
LRN Impact on Billing and Rate Tables
When VOS3000 LRN number portability routes by LRN, the rate table lookup uses the LRN NPA-NXX prefix instead of the dialed number NPA-NXX. This is critical because the cost to terminate a call varies by serving carrier, not by the original number assignment. A number originally assigned to a low-cost rural carrier may have been ported to a high-cost urban carrier, and without LRN-based rating, you would undercharge or misrate the call.
Billing Aspect
Without LRN
With LRN
Rate prefix lookup
Based on dialed number NPA-NXX
Based on LRN NPA-NXX
Cost accuracy
Inaccurate for ported numbers
Accurate for all numbers
Revenue leakage
High (under-rating ported calls)
Minimized
CDR recording
Shows dialed number only
Shows both DN and LRN
Troubleshooting LRN Configuration Issues
When VOS3000 LRN number portability lookups are not working correctly, calls to ported numbers will fail or route incorrectly. Common issues include unreachable LRN servers, incorrect query mode settings, and mismatched LRN response handling. For deeper CDR troubleshooting, see our VOS3000 call end reasons guide.
Problem
Likely Cause
Solution
LRN queries timing out
LRN server unreachable or high latency
Verify SS_LRN_SERVER_IP and network connectivity
Ported calls still misrouted
Response action set to Route by DN
Change to Route by LRN
Rate table not matching LRN
Rate table missing LRN-based prefixes
Add LRN NPA-NXX entries to rate table
All calls failing after LRN enable
LRN server returning errors
Check LRN server logs and configuration
Related Resources – VOS3000 LRN Number Portability
Frequently Asked Questions About VOS3000 LRN Number Portability
What is LRN and why is it needed for US termination?
LRN stands for Local Routing Number, a 10-digit number that identifies the serving switch for a telephone number in the US. It is needed because US number portability allows subscribers to keep their numbers when switching carriers, meaning the dialed number alone no longer identifies which carrier currently serves that number. Without LRN lookups, VOS3000 would route calls based on the original rate center assignment, causing misrouted calls to ported numbers. The LRN acts as a routing alias that always points to the correct serving carrier.
How do I enable LRN lookups in VOS3000?
To enable LRN lookups in VOS3000, navigate to the mapping gateway configuration for the gateway handling US termination traffic. Under the LRN settings section (§2.5.1.1), set LRN Query Enable to Yes, select the appropriate Query Mode (Internal for self-managed LRN dips, External if your upstream carrier provides the LRN), and set the Response Action to Route by LRN. You must also configure the SS_LRN_SERVER_IP and SS_LRN_SERVER_PORT parameters in the softswitch configuration to point to your LRN dip service provider.
What is the difference between Internal and External LRN query modes?
Internal LRN query mode means VOS3000 itself initiates the LRN dip by sending a query to the configured LRN server (SS_LRN_SERVER_IP/PORT) and waits for the response before routing the call. External mode means VOS3000 expects the upstream SIP proxy or carrier to have already performed the LRN dip and to include the LRN value in the incoming SIP INVITE, typically in the P-Asserted-Identity or a custom X-header. Internal mode gives you full control over LRN resolution, while External mode relies on your upstream provider.
Does LRN affect billing rate lookups?
Yes, LRN significantly affects billing rate lookups in VOS3000. When Route by LRN is enabled, the billing engine uses the NPA-NXX of the returned LRN to match against the rate table, rather than the NPA-NXX of the dialed number. This ensures accurate cost calculation because termination rates vary by serving carrier. A number originally assigned to a low-cost carrier but ported to a higher-cost carrier would be undercharged without LRN-based rating, causing revenue leakage.
What happens if the LRN server is unreachable?
If the LRN server is unreachable when VOS3000 attempts a query, the call routing behavior depends on the configured timeout and fallback settings. Typically, VOS3000 will wait for the configured LRN timeout period, and if no response is received, it will fall back to routing by the dialed number. This means calls to non-ported numbers will still route correctly, but calls to ported numbers may be misrouted. It is critical to monitor LRN server availability and ensure high-availability configurations for production US traffic.
How do I verify LRN lookups are working correctly?
To verify that VOS3000 LRN number portability lookups are working, place a test call to a known ported US number and then inspect the CDR record. The CDR should show both the original dialed number and the LRN value returned by the query. If the LRN field is populated and the call completed successfully through the correct carrier, your configuration is working. You can also check the VOS3000 monitoring tools for LRN query statistics — refer to our VOS3000 monitoring guide for detailed steps.
Get Expert Help with VOS3000 LRN Configuration
Properly configuring VOS3000 LRN number portability is critical for any operator routing US traffic. Misconfigured LRN settings lead to failed calls, billing discrepancies, and regulatory compliance issues that directly impact your bottom line. Our VOS3000 specialists have extensive experience deploying LRN configurations for US wholesale operators. (VOS3000 LRN Number Portability)
Contact us on WhatsApp: +8801911119966
Whether you need initial LRN setup, integration with an LRN dip provider, or troubleshooting existing configurations, we provide expert support. Reach out today at +8801911119966 and ensure your US termination routing is accurate and compliant.
📞 Need Professional VOS3000 Setup Support?
For professional VOS3000 installations and deployment, VOS3000 Server Rental Solution:
VOS3000 LRN Server Configuration Reliable SS_LRN_SERVER_IP PORT Setup
Setting up VOS3000 LRN server configuration with SS_LRN_SERVER_IP and SS_LRN_SERVER_PORT is the foundational step for enabling number portability lookups in your VOS3000 softswitch. These two parameters define the IP address and TCP/UDP port of the external LRN (Local Routing Number) dip server that VOS3000 queries before routing US termination calls. Without a properly configured LRN server connection, your VOS3000 system cannot perform number portability lookups, and all US calls will route based on the dialed number’s original rate center rather than the actual serving carrier. Need assistance? Contact us on WhatsApp: +8801911119966.
The LRN dip server is an external service — typically provided by a specialized NPAC (Number Portability Administration Center) query aggregator — that receives a dialed number query and returns the Local Routing Number identifying the current serving carrier. VOS3000 acts as an LRN client, sending queries to this server and processing the responses to make routing and billing decisions. The SS_LRN_SERVER_IP and SS_LRN_SERVER_PORT parameters, documented in §4.3.5.2 of the softswitch parameters manual, define where VOS3000 sends these queries.
Table of Contents
VOS3000 LRN Server Configuration Parameter Reference
The two primary parameters for VOS3000 LRN server configuration are defined in the softswitch configuration file. These are global parameters that apply to all mapping gateways using Internal LRN query mode.
Parameter
Description
Default / Range
SS_LRN_SERVER_IP
IP address of the external LRN dip server
Empty (must be configured)
SS_LRN_SERVER_PORT
TCP/UDP port of the LRN dip server
Empty (must be configured)
Configuration File
Softswitch parameters (mbx2008.conf)
/etc/vos3000/mbx2008.conf
Manual Section
VOS3000 softswitch parameters reference
§4.3.5.2
Scope
Global (applies to all gateways using Internal LRN)
System-wide
Why an External LRN Server Is Required
VOS3000 does not include a built-in LRN database. The NPAC databases that store number portability records are managed by third-party administrators (such as Neustar/Iconectiv in the US) and are accessed through dedicated LRN query services. VOS3000 must connect to an external LRN dip server that has subscriptions to these NPAC databases. The LRN server receives the dialed number query, performs the NPAC lookup on behalf of VOS3000, and returns the LRN result. This architecture separates the softswitch routing logic from the number portability data management.
Component
Role
Managed By
VOS3000 Softswitch
Sends LRN query, processes response, routes call
VoIP Operator
LRN Dip Server
Receives query, looks up NPAC, returns LRN
LRN Service Provider
NPAC Database
Master number portability records
Iconectiv / Neustar
Serving Carrier Switch
Terminates the call to the subscriber
Termination Carrier
Step-by-Step VOS3000 LRN Server Configuration
Follow these steps to configure SS_LRN_SERVER_IP and SS_LRN_SERVER_PORT in your VOS3000 system. Before starting, obtain the LRN server IP address and port number from your LRN service provider. For configuration help, message us on WhatsApp: +8801911119966.
Place test call to ported number, check CDR for LRN field
How VOS3000 Sends and Processes LRN Lookups
When a call arrives at a mapping gateway with Internal LRN query mode enabled, VOS3000 initiates an LRN lookup to the configured server. The softswitch sends a query containing the dialed number to the SS_LRN_SERVER_IP on the SS_LRN_SERVER_PORT. The LRN server processes the query against the NPAC database and returns the LRN for that number. VOS3000 then uses the returned LRN for prefix matching in the rate table and for gateway routing decisions. The entire LRN dip typically adds 20-100 milliseconds to call setup time depending on network latency to the LRN server. For understanding the broader call flow, see our VOS3000 SIP call flow guide.
Lookup Phase
Action
Typical Duration
Query Send
VOS3000 sends dialed number to LRN server
1-5 ms (local) / 10-30 ms (remote)
Server Processing
LRN server queries NPAC database
5-50 ms
Response Receive
VOS3000 receives LRN response
1-5 ms (local) / 10-30 ms (remote)
Routing Decision
VOS3000 uses LRN for rate/gateway lookup
1-5 ms
LRN Server Connectivity Requirements
For VOS3000 LRN server configuration to work reliably, the VOS3000 softswitch server must have network connectivity to the LRN dip server on the specified IP and port. Firewall rules must allow outbound connections from the VOS3000 server to SS_LRN_SERVER_IP on SS_LRN_SERVER_PORT. The LRN service provider will typically specify whether the connection uses TCP or UDP and whether TLS encryption is required. Network latency between VOS3000 and the LRN server should be minimized to avoid adding excessive delay to call setup. (VOS3000 LRN Server Configuration)
Requirement
Specification
Notes
Network Access
Outbound TCP/UDP to LRN server
Firewall must allow specified port
Latency
Under 50ms round-trip recommended
Higher latency increases PDD
TLS Support
Depends on LRN provider
Some providers require encrypted connections
Service Availability
99.99% uptime SLA recommended
LRN downtime impacts all US calls
Troubleshooting LRN Server Connection Issues
When VOS3000 LRN server configuration problems occur, the most common symptom is that LRN lookups fail or timeout, causing calls to fall back to dialed-number routing. For deeper troubleshooting, check our CDR billing discrepancy guide and call termination reasons reference.
Problem
Likely Cause
Solution
Connection refused
Wrong IP or port in SS_LRN_SERVER_IP/PORT
Verify IP and port with LRN provider
Connection timeout
Firewall blocking or network issue
Check firewall rules, test with telnet
LRN queries return empty
LRN server subscription issue
Contact LRN service provider
High PDD after LRN enable
High latency to LRN server
Use closer LRN server or reduce timeout
Config not taking effect
Service not restarted after change
Restart vos3000 service
Related Resources (VOS3000 LRN Server Configuration)
Frequently Asked Questions About VOS3000 LRN Server Configuration
What is SS_LRN_SERVER_IP in VOS3000?
SS_LRN_SERVER_IP is a VOS3000 softswitch parameter that specifies the IP address of the external LRN (Local Routing Number) dip server. When a mapping gateway is configured for Internal LRN query mode, VOS3000 uses this IP address to connect to the LRN server and send number portability queries. This parameter is defined in the softswitch configuration file (mbx2008.conf) under section §4.3.5.2 of the VOS3000 manual. It must be set to the IP address provided by your LRN service provider.
What port should I use for SS_LRN_SERVER_PORT?
The port number for SS_LRN_SERVER_PORT depends on your LRN service provider’s configuration. Common ports include 8443 for HTTPS-based LRN queries, 5060 for SIP-based queries, or custom ports specified by the provider. You should use the exact port number provided by your LRN service provider. Never guess or use default ports without confirming with the provider, as incorrect port configuration will cause all LRN queries to fail. (VOS3000 LRN Server Configuration)
Do I need to restart VOS3000 after changing LRN server settings?
Yes, changes to SS_LRN_SERVER_IP and SS_LRN_SERVER_PORT require a restart of the VOS3000 softswitch service to take effect. These parameters are read during softswitch initialization and are not reloaded dynamically. Use the command service vos3000 restart after making changes to the configuration file. Always schedule restarts during low-traffic periods to minimize call disruption.
Can VOS3000 connect to multiple LRN servers for redundancy?
The standard SS_LRN_SERVER_IP parameter supports a single LRN server endpoint. For high-availability deployments, operators typically configure a load balancer or DNS round-robin in front of multiple LRN server instances, and point SS_LRN_SERVER_IP to the virtual IP of the load balancer. This provides redundancy at the infrastructure level without requiring VOS3000 to manage multiple LRN connections directly. Some advanced LRN service providers offer their own failover endpoints.
How do I verify the LRN server connection is working?
To verify the LRN server connection, first test network connectivity using telnet SS_LRN_SERVER_IP SS_LRN_SERVER_PORT from the VOS3000 server. If the connection succeeds, place a test call to a known ported US number and inspect the CDR record. A working LRN configuration will show the LRN value in the CDR alongside the dialed number. If the CDR shows no LRN field or routing appears incorrect, check your softswitch logs for LRN query errors.
What protocol does VOS3000 use for LRN queries?
The protocol used for LRN queries depends on the LRN service provider and the configured SS_LRN_SERVER_PORT. Some providers use TCP-based proprietary protocols, while others use SIP-based queries or HTTP/HTTPS REST APIs. VOS3000 supports the query format specified by the LRN server it connects to. The specific protocol details and query format should be obtained from your LRN service provider documentation.
Get Professional VOS3000 LRN Server Setup
Configuring VOS3000 LRN server settings correctly is essential for accurate US termination routing. Incorrect SS_LRN_SERVER_IP or PORT values will prevent LRN lookups from functioning, causing all ported US numbers to be misrouted. Our team specializes in VOS3000 number portability configurations and can help you integrate with any LRN service provider. (VOS3000 LRN Server Configuration)
Contact us on WhatsApp: +8801911119966
From initial LRN server setup to troubleshooting existing configurations and optimizing query performance, we provide comprehensive support. Reach out today at +8801911119966 and ensure your VOS3000 system delivers accurate US termination routing.
📞 Need Professional VOS3000 Setup Support?
For professional VOS3000 installations and deployment, VOS3000 Server Rental Solution:
VOS3000 Server End Reasons Definitive 25-Code Reference Guide
Understanding VOS3000 server end reasons is essential for any VoIP operator who needs to diagnose call failures, resolve billing disputes, and improve overall network quality. VOS3000 records 25 distinct server-side end reason codes in its CDRs, each representing a different cause for call termination as observed from the softswitch perspective. These codes go beyond simple SIP response codes or Q.850 cause values — they represent the VOS3000 internal decision for why a call ended, providing the most granular insight into call lifecycle events. Need help analyzing your CDRs? Contact us on WhatsApp: +8801911119966.
Unlike SIP response codes (which are protocol-level) or Q.850 cause codes (which are network-level), VOS3000 server end reasons are application-level codes generated by the softswitch itself. They capture scenarios that are unique to the VOS3000 platform, such as billing-related terminations, route selection failures, and account management events. By analyzing these codes across your CDR data, you can identify systemic issues affecting ASR, pinpoint billing discrepancies, and understand exactly why calls fail at the softswitch level.
Table of Contents
Complete VOS3000 Server End Reasons Code Table
The following table lists all 25 VOS3000 server-side end reason codes as documented in §4.5 of the administration manual. Each code has a specific meaning that maps to an internal VOS3000 decision point in the call processing pipeline.
Code
End Reason
Category
1
Normal Clearing
Normal
2
User Busy
Normal
3
No Answer
Normal
4
Unallocated Number
Number Error
5
Network Congestion
Network
6
Route Not Found
Routing
7
Rate Not Found
Billing
8
Balance Insufficient
Billing
9
Account Expired
Account
10
Account Disabled
Account
11
Caller Hangup
Normal
12
Callee Hangup
Normal
13
Server Forced Release
System
14
Session Timeout
Timeout
15
Media Timeout
Timeout
16
Authentication Failed
Security
17
Unauthorized IP
Security
18
Concurrent Limit Exceeded
Capacity
19
CPS Limit Exceeded
Capacity
20
Blacklist Match
Security
21
Gateway Unavailable
Routing
22
No Available Route
Routing
23
Call Rejected
Network
24
Prepaid Duration Exceeded
Billing
25
Service Not Subscribed
Account
End Reason Categories and Severity Classification
The 25 VOS3000 server end reasons can be grouped into six functional categories. Understanding these categories helps operators quickly identify whether call failures are due to billing issues, routing problems, security blocks, or normal call completion events. For more on how these codes affect your quality metrics, see our VOS3000 ASR ACD analysis guide.
Category
Codes
Impact Level
Action Required
Normal
1, 2, 3, 11, 12
Low
No action needed
Routing
6, 21, 22
High
Check rate table and gateway config
Billing
7, 8, 24
High
Review rates and account balances
Account
9, 10, 25
Medium
Verify account status and subscriptions
Security
16, 17, 20
Critical
Investigate unauthorized access attempts
Capacity/Timeout
5, 14, 15, 18, 19
Medium-High
Scale resources or adjust limits
Common End Reasons and Their Troubleshooting Steps
The most frequently encountered VOS3000 server end reasons in production environments typically fall into a handful of codes. Understanding what each means and how to address it is critical for maintaining healthy ASR and ACD metrics. For detailed SIP-level troubleshooting, see our VOS3000 SIP debug guide.
Code
End Reason
Common Cause
Resolution
6
Route Not Found
No matching prefix in route table
Add prefix to routing configuration
7
Rate Not Found
Dialed prefix not in rate table
Add rate entry for missing prefix
8
Balance Insufficient
Prepaid account depleted
Recharge account balance
22
No Available Route
All gateways busy or offline
Add more gateways or check existing
15
Media Timeout
No RTP received after call setup
Check NAT/firewall, media proxy settings
End Reasons and Billing Impact Analysis
Certain VOS3000 server end reasons directly affect billing calculations. Code 8 (Balance Insufficient) and Code 24 (Prepaid Duration Exceeded) are billing-driven terminations initiated by the VOS3000 billing engine. Code 7 (Rate Not Found) means the call was never rated and generates no revenue. Understanding which end reasons produce billable vs non-billable CDRs is essential for revenue assurance. For more on billing configurations, see our VOS3000 billing system guide.
End Reason
CDR Generated
Billable
Billing Mode Code
Normal Clearing (1)
Yes
Yes
0 or 1
Rate Not Found (7)
Yes
No
-1
Balance Insufficient (8)
Yes
No
-1
Prepaid Duration Exceeded (24)
Yes
Yes (partial)
1
Route Not Found (6)
Yes
No
-1
How End Reasons Map to SIP and H.323 Codes
VOS3000 server end reasons are internal to the platform, but they often have corresponding SIP response codes or Q.850 cause codes in the signaling layer. Understanding these mappings helps correlate CDR end reasons with protocol-level traces captured by tools like Wireshark or tcpdump. For protocol-level analysis, message us on WhatsApp: +8801911119966.
Frequently Asked Questions About VOS3000 Server End Reasons
What are VOS3000 server end reasons?
VOS3000 server end reasons are 25 internal codes that the softswitch records in CDRs to indicate why a call was terminated from the server’s perspective. These codes cover normal call completion (like user hangup and normal clearing), routing failures (like route not found and no available route), billing issues (like balance insufficient and rate not found), security events (like authentication failed and unauthorized IP), and system-level terminations (like server forced release and session timeout). They are documented in §4.5 of the VOS3000 administration manual.
How do server end reasons differ from SIP response codes?
VOS3000 server end reasons are application-level codes generated by the softswitch itself, while SIP response codes are protocol-level status indicators defined in RFC 3261. A single SIP response code like 503 Service Unavailable could map to multiple VOS3000 end reasons depending on the internal context — it could be Network Congestion (code 5), No Available Route (code 22), or Gateway Unavailable (code 21). Server end reasons provide more granular insight into the VOS3000 internal decision process than SIP codes alone.
Which end reasons indicate billing problems?
The primary billing-related end reasons are Code 7 (Rate Not Found — no matching rate entry), Code 8 (Balance Insufficient — prepaid account depleted), and Code 24 (Prepaid Duration Exceeded — call ended because maximum allowed duration was reached). These codes directly indicate that billing engine decisions terminated the call. High volumes of code 7 suggest missing rate table entries, while high code 8 volumes indicate accounts running out of balance frequently.
How can I analyze end reasons across my CDR data?
You can analyze VOS3000 server end reasons by querying the CDR database and grouping records by end reason code. This reveals the distribution of call termination causes and helps identify systemic issues. For example, if code 22 (No Available Route) dominates, you need more gateway capacity. If code 7 (Rate Not Found) is frequent, you have gaps in your rate tables. Use the VOS3000 CDR query tools or export CDRs to an external analytics platform for detailed analysis.
What does Server Forced Release (code 13) mean?
Code 13 (Server Forced Release) indicates that the VOS3000 softswitch actively terminated the call for an internal reason, such as a system-level resource constraint, administrative intervention, or a forced disconnect triggered by a monitoring rule. Unlike timeout-based terminations, Server Forced Release is an active decision by the softswitch to end the call. Investigating the system logs around the time of the CDR can reveal the specific trigger for the forced release.
Are all 25 end reason codes used in both SIP and H.323 calls?
Yes, the 25 VOS3000 server end reason codes are protocol-independent and apply to both SIP and H.323 calls. The same internal end reason code is recorded in the CDR regardless of the signaling protocol used. However, the corresponding protocol-level codes differ — a SIP call with end reason 2 (User Busy) will show 486 Busy Here in the SIP layer, while an H.323 call with the same end reason will show Q.850 cause code 17. The server end reason provides a unified view across both protocols.
Need Expert VOS3000 CDR Analysis?
Analyzing VOS3000 server end reasons across millions of CDRs requires both technical expertise and the right analytical approach. Our VOS3000 specialists can help you build CDR analysis workflows, identify the root causes of call failures, and optimize your routing and billing configurations to improve ASR and reduce revenue leakage.
Contact us on WhatsApp: +8801911119966
Whether you need help interpreting end reason distributions, troubleshooting high failure rates, or building automated CDR monitoring dashboards, our team is here to assist. Reach out today at +8801911119966 and take control of your VOS3000 call quality.
📞 Need Professional VOS3000 Setup Support?
For professional VOS3000 installations and deployment, VOS3000 Server Rental Solution:
VOS3000 H323 Q850 Cause Codes Comprehensive 60-Plus Code Reference
Mastering VOS3000 H323 Q850 cause codes is indispensable for any VoIP operator who runs H.323 trunks and needs to analyze call failures, troubleshoot interconnect issues, and assess trunk quality from CDR data. The Q.850 cause codes are ITU-T standard values carried in H.323 Release Complete messages that indicate the specific reason for call termination. VOS3000 records these codes in H.323 CDRs, giving operators the most detailed insight into why calls fail at the network level. This reference covers all 60+ Q.850 cause codes you will encounter in VOS3000 H.323 deployments. Need help analyzing your H.323 CDRs? Contact us on WhatsApp: +8801911119966.
The Q.850 specification, defined by the ITU-T in Recommendation Q.850, provides a standardized set of cause codes originally designed for ISDN DSS1 signaling and later adopted by H.323 for call termination reporting. Each cause code includes a numeric value, a textual description, and a diagnostic class. When an H.323 call terminates, the releasing party includes a Q.850 cause value in the Release Complete message, and VOS3000 captures this value in the CDR for post-call analysis. (VOS3000 H323 Q850 Cause)
Table of Contents
Q850 Cause Code Categories (VOS3000 H323 Q850 Cause)
The 60+ Q.850 cause codes are organized into several categories based on the originating event class. Understanding the category helps narrow down the troubleshooting scope before diving into the specific code.
Code Range
Category
Typical Source
1-9
Normal Event
Endpoint / subscriber action
10-19
Resource Unavailable
Network or gateway resource limits
20-29
Service/Option Not Available
Service incompatibility or restriction
30-39
Service/Option Not Implemented
Feature not supported by endpoint
40-49
Invalid Message
Protocol error or invalid call setup
50-59
Protocol Error
Signaling layer malfunction
96-127
Interworking / Vendor Specific
Interoperability or vendor extensions
Most Common Q850 Cause Codes in VOS3000 CDRs
In production VOS3000 H.323 environments, a small subset of Q.850 codes accounts for the vast majority of CDR records. The following table lists the most frequently encountered codes with their descriptions and typical resolution approaches. (VOS3000 H323 Q850 Cause)
Code
Description
Frequency
Action
16
Normal Call Clearing
Very High
No action — normal hangup
17
User Busy
High
Normal — callee was busy
18
No User Responding
High
Check alerting timeout settings
21
Call Rejected
Medium
Investigate rejection reason at callee side
27
Destination Out of Order
Medium
Callee switch is down — contact carrier
34
No Circuit/Channel Available
Medium
Add capacity or switch gateway
38
Network Out of Order
Low-Medium
Network issue — check carrier status
42
Switching Equipment Congestion
Medium
Reduce traffic or add alternate routes
Full Q850 to SIP Response Code Mapping
When VOS3000 performs H.323 to SIP protocol translation, Q.850 cause codes are mapped to corresponding SIP response codes. This mapping is essential for understanding cross-protocol call flows and for correlating H.323 CDR data with SIP-side traces. For detailed protocol configuration, see our VOS3000 DTMF configuration guide.
Q.850 Code
Description
SIP Mapping
1
Unallocated Number
404 Not Found
16
Normal Call Clearing
200 OK (BYE)
17
User Busy
486 Busy Here
18
No User Responding
408 Request Timeout
19
No Answer from User
480 Temporarily Unavailable
21
Call Rejected
603 Decline
27
Destination Out of Order
502 Bad Gateway
34
No Circuit Available
503 Service Unavailable
42
Switching Equipment Congestion
503 Service Unavailable
44
Requested Circuit Not Available
503 Service Unavailable
102
Recovery on Timer Expiry
408 Request Timeout
Additional Q850 Codes Encountered in H.323 Deployments
Beyond the most common codes, several additional Q.850 values appear regularly in VOS3000 H.323 CDRs. These codes often indicate more specific network conditions or interop issues. For more on H.323 protocol parameters, see our VOS3000 architecture overview. For direct support, message us on WhatsApp: +8801911119966.
Code
Description
Typical Scenario
3
No Route to Destination
Prefix not provisioned in carrier switch
22
Number Changed
Callee number has been reassigned
28
Invalid Number Format
Dialed digits not in valid format
31
Normal Unspecified
Generic clearing without specific cause
41
Temporary Failure
Transient network condition
88
Incompatible Destination
Codec or capability mismatch
Using Q850 Codes for Trunk Quality Assessment
Analyzing the distribution of Q.850 cause codes across your H.323 trunks provides a powerful quality assessment metric. A healthy trunk should show predominantly code 16 (Normal Clearing) with minimal congestion or failure codes. High percentages of codes 34, 38, or 42 indicate capacity or network problems that require immediate attention. (VOS3000 H323 Q850 Cause)
Frequently Asked Questions About VOS3000 H323 Q850 Cause Codes
What is Q.850 cause code 16 in VOS3000?
Q.850 cause code 16 means Normal Call Clearing — the call was terminated by one of the parties through normal hangup procedures. This is the most common cause code in VOS3000 H.323 CDRs and indicates a successfully completed call lifecycle. Code 16 calls are typically billable (depending on duration and billing mode) and do not indicate any problem with the call or the network.
How do Q.850 codes differ from VOS3000 server end reasons?
Q.850 cause codes are network-level standard codes from the ITU-T that indicate why a call was terminated from the signaling perspective, while VOS3000 server end reasons are application-level codes generated by the VOS3000 softswitch itself. Q.850 codes come from the H.323 protocol layer and reflect the network or endpoint reason for termination, while server end reasons capture the VOS3000 internal decision. A single call will have both a Q.850 code (from the H.323 signaling) and a server end reason (from the VOS3000 billing/routing engine).
What does Q.850 code 42 mean and how do I fix it?
Q.850 code 42 means Switching Equipment Congestion — the carrier’s switch is overloaded and cannot process the call. This typically occurs during high-traffic periods when the terminating carrier lacks sufficient capacity. To address this, you can add alternate gateway routes for the affected destination, implement traffic shaping to reduce peak loads, or contact the carrier to increase capacity allocation. Persistent code 42 errors on a specific route indicate you need to either distribute traffic across more carriers or negotiate higher capacity limits.
How are Q.850 codes mapped to SIP responses in VOS3000?
VOS3000 automatically maps Q.850 cause codes to corresponding SIP response codes during H.323-to-SIP protocol translation. For example, Q.850 code 17 (User Busy) maps to SIP 486 Busy Here, code 34 (No Circuit Available) maps to SIP 503 Service Unavailable, and code 1 (Unallocated Number) maps to SIP 404 Not Found. This mapping follows the guidelines in RFC 3398 and ITU-T Q.1912.5 for ISUP-to-SIP interworking, ensuring consistent error reporting across protocols.
Can I customize Q.850 to SIP mapping in VOS3000?
The default Q.850 to SIP mapping in VOS3000 follows standard interworking rules and is not directly configurable on a per-code basis. However, you can use the Replace Failed Reason feature in the mapping gateway settings to override specific SIP response codes with alternative values. This allows you to change how certain H.323 termination causes are presented to downstream SIP gateways, which can affect failover behavior and routing decisions.
What Q.850 code indicates a codec incompatibility?
Q.850 code 88 (Incompatible Destination) typically indicates a codec or capability mismatch between the calling and called parties. When VOS3000 cannot negotiate a common codec with the H.323 gateway, the call fails with code 88. To resolve this, verify that both endpoints support at least one common codec and that the VOS3000 codec priority list includes codecs supported by the gateway. You may need to enable transcoding if the endpoints have no codec overlap.
Expert VOS3000 H.323 Troubleshooting Support (VOS3000 H323 Q850 Cause)
Analyzing VOS3000 H323 Q850 cause codes across your CDR data is the fastest way to identify trunk quality issues and interconnect problems. Our team has deep experience with H.323 deployments and can help you build systematic CDR analysis workflows that turn raw Q.850 data into actionable insights.
Contact us on WhatsApp: +8801911119966
From H.323 gateway configuration to Q.850 code analysis and cross-protocol troubleshooting, we provide comprehensive VOS3000 support. Reach out today at +8801911119966 and optimize your H.323 trunk performance. (VOS3000 H323 Q850 Cause)
📞 Need Professional VOS3000 Setup Support?
For professional VOS3000 installations and deployment, VOS3000 Server Rental Solution:
Understanding VOS3000 SIP response codes CDR data is fundamental for any VoIP operator who needs to diagnose call failures, optimize routing, and maintain high call completion rates. SIP response codes are 3-digit status indicators defined in RFC 3261 that every SIP element generates during call signaling. VOS3000 records the final SIP response code in each CDR, providing a direct view into why calls succeeded or failed at the protocol level. This reference covers all 30+ SIP response codes you will encounter in VOS3000 CDRs, organized by class with troubleshooting guidance for each. Need help analyzing your CDR data? Contact us on WhatsApp: +8801911119966.
SIP response codes follow a class-based structure where the first digit indicates the response category. VOS3000 CDRs capture the final SIP response that determined the call outcome — for successful calls this is typically 200 OK, while failed calls record the error response that caused termination. By analyzing the distribution of SIP response codes across your CDR data, you can identify routing problems, capacity issues, and configuration errors that affect your ASR and revenue.
Table of Contents
SIP Response Code Classes Overview
The six SIP response code classes each represent a different category of signaling outcome. Understanding the class structure is the first step in interpreting VOS3000 SIP response codes CDR data efficiently.
Class
Category
Meaning
CDR Impact
1xx
Provisional
Call in progress, not final
Rarely recorded as final CDR code
2xx
Success
Call successfully established
Billable call — 200 OK most common
3xx
Redirection
Call redirected to another URI
May or may not result in billable call
4xx
Client Error
Request failed due to client issue
Non-billable — configuration or routing problem
5xx
Server Error
Server failed to fulfill request
Non-billable — upstream or capacity issue
6xx
Global Failure
Call rejected at all locations
Non-billable — should stop failover
4xx Client Error Codes in VOS3000 CDRs
4xx response codes indicate that the request contained bad syntax or could not be fulfilled at the client side. These are the most actionable codes because they often point to configuration problems that operators can fix directly.
Code
Name
Common Cause in VOS3000
Resolution
400
Bad Request
Malformed SIP message from VOS3000
Check SIP header settings and dial plan
401
Unauthorized
Authentication credential mismatch
Verify username/password on gateway
403
Forbidden
IP not authorized, account blocked
Check IP whitelist, account status
404
Not Found
Dialed number not routable
Add prefix to routing table
407
Proxy Auth Required
Outbound proxy requires authentication
Configure proxy auth credentials
408
Request Timeout
No response from gateway within timeout
Check gateway availability and network
480
Temporarily Unavailable
Callee offline or DND active
Check callee registration status
486
Busy Here
Callee line is busy
Normal — enable busy stop switch
487
Request Terminated
Call cancelled by originator
Check for early hangup or timeout
5xx Server Error Codes in VOS3000 CDRs
5xx codes indicate that the server side failed to process the request. These are often outside your direct control but understanding them helps identify which upstream carriers are experiencing problems. For more on failover behavior, see our VOS3000 call routing guide.
Code
Name
Meaning
Action
500
Server Internal Error
Gateway encountered unexpected error
Contact gateway vendor or check logs
502
Bad Gateway
Upstream gateway returned invalid response
Check upstream gateway health
503
Service Unavailable
Gateway overloaded or in maintenance
Route to alternate gateway
504
Server Timeout
No response from upstream server
Check network path to upstream
6xx Global Failure Codes
6xx response codes are global failures that indicate the call should not be retried at any other location. When VOS3000 receives a 6xx response, it should stop failover switching and record the code in the CDR. Understanding these codes helps prevent unnecessary gateway switching. For failover configuration, see our VOS3000 routing optimization guide. For assistance, message us on WhatsApp: +8801911119966.
Code
Name
Meaning
Failover Behavior
600
Busy Everywhere
All locations report busy
Stop switching
603
Decline
Call explicitly rejected
Stop switching
604
Does Not Exist Anywhere
Number does not exist globally
Stop switching
606
Not Acceptable
Session description not acceptable
Check codec negotiation
SIP Response Codes and ASR Correlation
Analyzing VOS3000 SIP response codes CDR data alongside ASR metrics reveals which response codes are dragging down your call completion rates. A healthy deployment should show 200 OK dominating the CDR distribution, with error codes representing a small percentage of total calls.
Frequently Asked Questions About VOS3000 SIP Response Codes CDR
What SIP response code indicates a successful call in VOS3000?
In VOS3000 CDRs, a SIP 200 OK response code indicates that the call was successfully established and answered. This is the standard success response defined in RFC 3261 that confirms the INVITE was accepted and a media session was established. All calls with 200 OK as the final response are typically billable (assuming they have non-zero duration), and a high percentage of 200 OK responses relative to total calls indicates healthy ASR performance.
What does SIP 503 Service Unavailable mean in my CDRs?
SIP 503 Service Unavailable in VOS3000 CDRs means the terminating gateway or server is currently unable to handle the call due to overload, maintenance, or capacity constraints. This is one of the most impactful error codes because it directly reduces ASR and often triggers gateway failover. If 503 responses are frequent from a specific gateway, that gateway may be under-provisioned or experiencing issues. You can use the Replace Failed Reason feature to change how VOS3000 handles 503 responses for failover decisions.
How do I reduce 408 Request Timeout errors?
SIP 408 Request Timeout errors indicate that VOS3000 sent an INVITE but did not receive a response within the configured timeout period. To reduce these errors, first verify that the destination gateway is online and reachable. Then check network connectivity and latency between VOS3000 and the gateway. You can also adjust the INVITE timeout settings in the softswitch parameters, but increasing timeouts too much will raise PDD for all calls. Also check whether the gateway is silently dropping packets due to firewall or NAT issues.
Why am I seeing 403 Forbidden in my H.323 gateway CDRs?
SIP 403 Forbidden appears when VOS3000 rejects the call because the source IP address is not authorized, the account is disabled, or a specific policy prevents the call. In the context of H.323-to-SIP translation, this code may appear when VOS3000 sends the call to a SIP gateway that does not recognize the originating credentials. Check the mapping gateway authentication settings, verify that the source IP is in the allowed list, and confirm that the account is active and not suspended.
What is the difference between 486 Busy and 600 Busy Everywhere?
SIP 486 Busy Here means a specific endpoint or gateway reported busy, but other locations might still accept the call — VOS3000 can continue failover to alternate gateways. SIP 600 Busy Everywhere is a global failure indicating that all known locations for the called number are busy, and VOS3000 should stop trying alternate routes. The key difference is failover behavior: 486 allows continued switching (unless busy stop switch is enabled), while 600 always terminates the call attempt.
Can I change how VOS3000 handles specific SIP response codes?
Yes, VOS3000 provides the Replace Failed Reason feature in mapping gateway settings that allows you to override how specific SIP response codes are handled. For example, you can change a 503 Service Unavailable to a 486 Busy Here to prevent aggressive failover that wastes CPS capacity. This feature is configured per mapping gateway and affects both routing behavior and the response code recorded in the CDR. See our termination reason replacement guide for details.
Get Expert VOS3000 CDR Analysis Support
Interpreting VOS3000 SIP response codes CDR data correctly is the key to identifying and resolving call quality issues quickly. Our VOS3000 specialists can help you build systematic CDR analysis workflows, set up automated alerting for problematic response code patterns, and optimize your routing configurations to maximize ASR.
Contact us on WhatsApp: +8801911119966
From CDR analysis to routing optimization and gateway troubleshooting, we provide comprehensive VOS3000 support. Reach out today at +8801911119966 and take control of your call quality metrics.
📞 Need Professional VOS3000 Setup Support?
For professional VOS3000 installations and deployment, VOS3000 Server Rental Solution:
📡 How does your VOS3000 softswitch keep track of how many simultaneous calls each routing gateway is handling? How does it know when a gateway has reached its capacity limit and should stop receiving new calls? The answer lies in the SIP PUBLISH method — and the timer that controls it is SS_SIP_PUBLISH_EXPIRE, the parameter that governs the VOS3000 SIP publish expire interval. 🎯
🔄 The SIP PUBLISH method, defined in RFC 3903, allows VOS3000 to broadcast gateway status information — including current concurrency levels — across the softswitch cluster. The VOS3000 SIP publish expire parameter sets how long each published status remains valid before it must be refreshed. With a default of 300 seconds (5 minutes) and a configurable range of 30 to 7200 seconds, this timer directly impacts how quickly the softswitch detects gateway state changes and enforces concurrency limits. Combined with the per-gateway Allow Publish checkbox, this creates a powerful system for automatic gateway concurrency control. ⚙️
🔧 All data in this guide is sourced exclusively from the official VOS3000 V2.1.9.07 Manual, Section 4.3.5.2 (Table 4-3) and the Routing Gateway Additional Settings documentation — no fabricated values, no guesswork. For expert assistance with your VOS3000 deployment, contact us on WhatsApp at +8801911119966. 💡
Table of Contents
🔐 What Is VOS3000 SIP Publish Expire?
⏱️ The VOS3000 SIP publish expire is the default timeout duration (in seconds) for routing gateway public status updates sent via the SIP PUBLISH method. This parameter is governed by SS_SIP_PUBLISH_EXPIRE with a default value of 300 seconds and a configurable range of 30 to 7200 seconds. 📋
📌 According to the official VOS3000 V2.1.9.07 Manual, Table 4-3:
Attribute
Value
📌 Parameter Name
SS_SIP_PUBLISH_EXPIRE
🔢 Default Value
300
📐 Range
30–7200 seconds
📝 Description
Routing gateway public update timeout default duration
💡 Key insight: The word “public” in the manual description refers to the broadcast nature of the PUBLISH method — VOS3000 publicly updates the routing gateway’s status (including active call count) so that the softswitch cluster can make informed routing decisions. When the publish expire timer runs out without a refresh, the published state information is considered stale and the softswitch may lose accurate concurrency data for that gateway. 📡
🎯 Why VOS3000 SIP Publish Expire Matters
⚠️ Without a properly configured publish expire timer, several critical problems can arise in your VOS3000 deployment:
🔄 Stale gateway status: Too-long expire intervals mean the softswitch relies on outdated concurrency data, potentially routing calls to overloaded gateways
📡 Excessive network overhead: Too-short expire intervals cause frequent PUBLISH messages, consuming bandwidth and processing resources across the cluster
🛡️ Concurrency overshoot: If a published state expires before a refresh arrives, the softswitch may underestimate active calls and send more traffic than the gateway can handle
📊 Routing inefficiency: Inaccurate concurrency data leads to poor call routing decisions, with traffic unevenly distributed across gateways
📞 Call quality degradation: Overloaded gateways experience audio issues, increased latency, and call drops when concurrency limits are not properly enforced
⚙️ How the SIP PUBLISH Method Works in VOS3000
🔄 The SIP PUBLISH method (RFC 3903) is fundamentally different from REGISTER, INVITE, or other common SIP methods. While REGISTER associates an address-of-record with a Contact URI, and INVITE establishes a dialog, PUBLISH carries event state information that other entities in the network can subscribe to or reference. In VOS3000, this mechanism is used specifically for gateway concurrency reporting. 📡
📊 Key behavior: VOS3000 sends a PUBLISH message with the Expires header set to the value of SS_SIP_PUBLISH_EXPIRE. Before this timer expires, VOS3000 should send a refreshed PUBLISH with updated concurrency data. If the refresh does not arrive before expiry, the published state is removed, and the softswitch no longer has authoritative concurrency information for that gateway. This is why the expire interval must be carefully tuned — too short means excessive refresh traffic; too long means stale data persists. ⚖️
📋 Per-Gateway Allow Publish Setting
🔑 The VOS3000 SIP publish expire parameter is a global default, but the PUBLISH method is only activated on a per-gateway basis. Each routing gateway has an Allow Publish checkbox that must be explicitly enabled for that gateway to participate in the publish-based concurrency control system. 🛠️
📌 According to the VOS3000 Routing Gateway configuration documentation:
This protocol can make routing gateway control concurrency automatically
💡 How it works: When Allow Publish is checked for a specific routing gateway, VOS3000 uses the SIP PUBLISH method to broadcast that gateway’s status and concurrency information. This enables the softswitch to automatically track how many concurrent calls are active on the gateway and enforce call limits without manual intervention. When unchecked, VOS3000 does not publish status for that gateway, and concurrency tracking relies on other mechanisms. 📡
🔗 Allow Publish — Gateway Concurrency Flow
🔄 Gateway Concurrency Control — With vs. Without Allow Publish:
┌─────────────────────────────────────────────────────────────────────┐
│ ✅ Allow Publish = CHECKED │
│ │
│ VOS3000 ──PUBLISH──► Gateway Status Broadcast │
│ │ │
│ ├── Active calls tracked in real-time via PUBLISH │
│ ├── Concurrency limit enforced automatically │
│ ├── New calls routed based on published capacity data │
│ └── Expire timer: SS_SIP_PUBLISH_EXPIRE (300s default) │
│ │
├─────────────────────────────────────────────────────────────────────┤
│ ❌ Allow Publish = UNCHECKED │
│ │
│ VOS3000 ──────────► No PUBLISH for this gateway │
│ │ │
│ ├── No automatic concurrency tracking via PUBLISH │
│ ├── Concurrency enforcement via other mechanisms only │
│ ├── Call limits may rely on manual configuration │
│ └── Risk of over-assignment if other limits not set │
└─────────────────────────────────────────────────────────────────────┘
📞 For detailed guidance on configuring routing gateways, see our VOS3000 gateway configuration and routing mapping guide. Need help setting up gateway concurrency control? Reach us on WhatsApp at +8801911119966. 📱
📊 VOS3000 SIP Publish Expire — Range Analysis
⏱️ The configurable range for SS_SIP_PUBLISH_EXPIRE spans from 30 to 7200 seconds (2 hours). Each segment of this range has distinct implications for gateway concurrency management: 📋
Expire Value
Refresh Frequency
Data Freshness
Network Load
Best For
30s (minimum)
Every 30 seconds
🟢 Very Fresh
🔴 Higher
⚡ High-capacity gateways with rapid traffic changes
60s
Every minute
🟢 Fresh
🟡 Moderate
📊 Busy wholesale gateways
300s (default)
Every 5 minutes
🟡 Moderate
🟢 Low
🏢 Standard deployments with stable traffic
600s (10 min)
Every 10 minutes
🟡 Acceptable
🟢 Very Low
📡 Low-traffic gateway links
1800s (30 min)
Every 30 minutes
🔴 Stale risk
🟢 Minimal
🔄 Backup/overflow gateways
7200s (2 hr max)
Every 2 hours
🔴 Very Stale
🟢 Negligible
💾 Dormant/archived gateways only
🎯 Recommendation: The default 300 seconds provides an excellent balance between data freshness and network efficiency for most deployments. Only reduce to 30-60 seconds for gateways handling high call volumes with rapidly changing concurrency. For a deeper understanding of SIP protocol behavior, see our VOS3000 SIP call flow guide. 📖
🔗 Related SIP Protocol Parameters
📋 The VOS3000 SIP publish expire parameter operates alongside several other SIP parameters that affect gateway communication and call management. Understanding how they interact is essential for proper system configuration. 🛠️
Parameter
Default
Range
Description
SS_SIP_PUBLISH_EXPIRE
300
30–7200s
Routing gateway public update timeout default duration
SS_SIP_USER_AGENT_EXPIRE
Auto Negotiation
20–7200s
SIP registration expiration time to other server
SS_SIP_SESSION_TTL
600
90–7200s
SIP session timer TTL
SS_SIP_TIMEOUT_INVITE
10
1–300s
INVITE timeout
SS_SIP_TIMEOUT_RINGING
120
1–600s
Ringing timeout
SS_SIP_RESEND_INTERVAL
0.5,1,2,4,4,4,4,4,4,4
—
SIP message resend interval sequence
📍 All parameters are located at: Operation management → Softswitch management → Additional settings → SIP parameter. For the complete parameter reference, see our VOS3000 parameter description guide and VOS3000 system parameters reference. 📖
🔄 Publish Expire vs. Registration Expire — Key Difference
⚠️ A common source of confusion is the difference between SS_SIP_PUBLISH_EXPIRE and SS_SIP_USER_AGENT_EXPIRE. Although both set expiry timers, they serve completely different purposes: 🎯
Aspect
SS_SIP_PUBLISH_EXPIRE
SS_SIP_USER_AGENT_EXPIRE
📌 SIP Method
PUBLISH (gateway status broadcast)
REGISTER (outbound registration to server)
🔢 Default
300 seconds
Auto Negotiation (20–7200s)
🔄 Purpose
Gateway concurrency state validity
Outbound registration validity
📡 Direction
Softswitch broadcasts gateway status internally
VOS3000 registers to upstream server
📊 Effect on Expiry
Stale concurrency data → routing errors
Registration lost → calls cannot route
💡 Simple rule: PUBLISH expire controls how long gateway concurrency status remains valid. Registration expire controls how long VOS3000’s outbound registration to another server remains valid. They are completely independent mechanisms. For more on session management, see our VOS3000 SIP session guide. 🔧
🔍 Select the gateway that requires publish-based concurrency control
🔧 Navigate to: Additional settings → Protocol → SIP
☑️ Check the Allow Publish checkbox — “This protocol can make routing gateway control concurrency automatically”
💾 Save gateway settings
Step 3: Configure Gateway Call Capacity 📊
📌 In the same Routing Gateway settings, configure:
📞 Maximum concurrent calls: Set the call capacity limit for the gateway
📋 Call limit enforcement: Ensure the concurrency limit is active
💾 Save all gateway configuration changes
Step 4: Verify with SIP Debug 🔍
📝 After configuration, verify that PUBLISH messages are being sent with the correct expire value. For comprehensive debugging techniques, see our VOS3000 SIP debug guide. 🔧
🔍 Verifying VOS3000 SIP Publish Expire Configuration:
Step 1: Open SIP debug / packet capture tool
Step 2: Filter for PUBLISH method messages
Step 3: Verify the Expires header matches your SS_SIP_PUBLISH_EXPIRE setting
Expected SIP PUBLISH message format:
┌──────────────────────────────────────────────────┐
│ PUBLISH sip:gateway-status@softswitch SIP/2.0 │
│ Via: SIP/2.0/UDP vos3000-server:5060 │
│ From: │
│ To: │
│ Expires: 300 │
│ Content-Type: application/pidf+xml │
│ │
│ [Gateway status / concurrency data] │
└──────────────────────────────────────────────────┘
✅ Confirm Expires value = SS_SIP_PUBLISH_EXPIRE setting
✅ Confirm PUBLISH messages appear at regular intervals
✅ Confirm Allow Publish gateways generate PUBLISH messages
❌ Gateways without Allow Publish should NOT generate PUBLISH
📊 VOS3000 SIP Publish Expire Best Practices by Deployment
🎯 Different VoIP deployment scenarios require different publish expire configurations. Here are recommended settings based on the VOS3000 manual specifications and real-world deployment experience: 💡
Deployment Type
Recommended Publish Expire
Rationale
📞 High-volume carrier gateway (500+ CPS)
30–60 seconds
Rapid traffic changes require fresh concurrency data; network overhead is acceptable at this scale
🏢 Wholesale VoIP (100-500 CPS)
60–120 seconds
Moderate traffic changes; balance between data freshness and efficiency
🌐 Standard enterprise gateway
300 seconds (default)
Stable traffic patterns; default provides good balance for typical deployments
Gateway is not primary route; only needs periodic status updates
🖥️ Multi-server cluster
60–120 seconds
Cluster nodes need relatively fresh data for coordinated routing decisions
💡 Important: The publish expire works together with your routing optimization configuration. Accurate concurrency data from timely PUBLISH refreshes enables the softswitch to make optimal routing decisions. Stale data can lead to over-assignment or under-utilization of gateway capacity. 📡
🛡️ Common VOS3000 SIP Publish Expire Problems and Solutions
⚠️ Misconfigured publish expire settings can cause a range of issues in your VOS3000 deployment. Here are the most common problems and their solutions:
❌ Problem 1: Gateway Overloaded Despite Concurrency Limit
🔍 Symptom: A routing gateway with a configured maximum concurrent call limit continues to receive calls beyond its capacity, resulting in call quality degradation or failures.
💡 Cause: The Allow Publish checkbox is not enabled for this gateway, so VOS3000 is not using the PUBLISH method for automatic concurrency control. Without PUBLISH, the softswitch may not have real-time visibility into the gateway’s active call count.
✅ Solutions:
☑️ Enable Allow Publish in the routing gateway Additional settings → Protocol → SIP
📋 Verify the gateway’s maximum concurrent call limit is properly configured
🔍 Check SIP debug traces to confirm PUBLISH messages are being generated
❌ Problem 2: Stale Concurrency Data After Publish Expire
🔍 Symptom: The softswitch makes poor routing decisions, sending calls to gateways that appear to have available capacity but are actually at or near their limits.
💡 Cause: SS_SIP_PUBLISH_EXPIRE is set too high (e.g., 1800-7200 seconds), and PUBLISH refreshes arrive so infrequently that the softswitch operates on stale concurrency data for extended periods.
✅ Solutions:
⏱️ Reduce SS_SIP_PUBLISH_EXPIRE to 300 seconds (default) or lower for active gateways
📊 Monitor PUBLISH refresh frequency in SIP debug traces
🔄 For high-traffic gateways, consider 60-120 second expire for fresher data
❌ Problem 3: Excessive PUBLISH Network Traffic
🔍 Symptom: Unusually high volume of PUBLISH messages in SIP traces, consuming network bandwidth and VOS3000 processing resources, especially in deployments with many routing gateways.
💡 Cause: SS_SIP_PUBLISH_EXPIRE is set very low (30 seconds) across all gateways, including those with stable, low-traffic patterns that do not require frequent status updates.
✅ Solutions:
🔧 Increase SS_SIP_PUBLISH_EXPIRE to 300 seconds for standard gateways
📊 Only use short expire intervals (30-60s) for high-traffic, high-CPS gateways
📡 Consider disabling Allow Publish on dormant or very-low-traffic gateways
❌ Problem 4: Cluster Routing Conflicts After Publish Timeout
🔍 Symptom: In a multi-server VOS3000 cluster, different softswitch nodes have conflicting views of a gateway’s active call count, leading to simultaneous over-assignment.
💡 Cause: PUBLISH messages expire on one node before a refresh arrives, while another node still has valid published data. This can occur if the publish expire interval is too short relative to network latency between cluster nodes.
✅ Solutions:
🌐 Ensure SS_SIP_PUBLISH_EXPIRE is set consistently across all cluster nodes
⏱️ Use 120-300 second expire in cluster deployments to account for inter-node latency
📋 Verify cluster network connectivity and latency between softswitch nodes
✅ Use this checklist when deploying or tuning your VOS3000 SIP publish expire settings:
Check
Action
Status
📌 1
Set SS_SIP_PUBLISH_EXPIRE to appropriate value for your deployment (30–7200s)
☐
📌 2
Enable Allow Publish on routing gateways that require automatic concurrency control
☐
📌 3
Configure maximum concurrent call limits on each gateway with Allow Publish enabled
☐
📌 4
Verify PUBLISH messages in SIP debug trace with correct Expires header value
☐
📌 5
Confirm gateways without Allow Publish are NOT generating PUBLISH messages
☐
📌 6
Test concurrency enforcement by generating calls up to the gateway limit
☐
📌 7
In cluster deployments, verify SS_SIP_PUBLISH_EXPIRE is consistent across all nodes
☐
📌 8
Monitor gateway analysis reports to validate concurrency data accuracy
☐
❓ Frequently Asked Questions
❓ What is the default VOS3000 SIP publish expire value?
⏱️ The default VOS3000 SIP publish expire value is 300 seconds (5 minutes), configured via the SS_SIP_PUBLISH_EXPIRE parameter. This means that routing gateway status information published via the SIP PUBLISH method remains valid for 300 seconds before requiring a refresh. The configurable range is 30–7200 seconds. The default of 300 seconds provides a practical balance between data freshness and network efficiency for most VoIP deployments. 🔧
❓ What does the Allow Publish checkbox do in VOS3000?
☑️ The Allow Publish checkbox, found under Routing Gateway → Additional settings → Protocol → SIP, enables the SIP PUBLISH method for that specific routing gateway. According to the VOS3000 manual, “This protocol can make routing gateway control concurrency automatically.” When checked, VOS3000 uses the PUBLISH method to broadcast the gateway’s status and active call count, enabling automatic concurrency control. When unchecked, the gateway does not participate in PUBLISH-based status broadcasting, and concurrency tracking relies on other mechanisms. 📡
❓ What is the difference between SS_SIP_PUBLISH_EXPIRE and SS_SIP_USER_AGENT_EXPIRE?
📊 These two parameters control different SIP method expiry timers. SS_SIP_PUBLISH_EXPIRE (default: 300s, range: 30–7200s) controls how long a PUBLISH message’s gateway status information remains valid — it governs concurrency data freshness. SS_SIP_USER_AGENT_EXPIRE (default: Auto Negotiation, range: 20–7200s) controls how long VOS3000’s outbound REGISTER to another server remains valid — it governs registration freshness. PUBLISH is about gateway status broadcasting; REGISTER is about server registration. They are completely independent mechanisms. 🔑
❓ Should I set the publish expire to the minimum 30 seconds for better concurrency tracking?
⚡ Not necessarily. While 30 seconds provides the freshest concurrency data, it also means VOS3000 sends PUBLISH refresh messages every 30 seconds for every gateway with Allow Publish enabled. In deployments with many gateways, this can generate significant network traffic. For high-volume carrier gateways where call counts change rapidly, 30-60 seconds is appropriate. For standard deployments, the default 300 seconds provides adequate data freshness with minimal overhead. Evaluate your specific traffic patterns and number of gateways before reducing the expire interval. 📡
❓ What happens when the VOS3000 SIP publish expire timer runs out?
🔄 When the publish expire timer runs out without a refresh PUBLISH being received, the published gateway status information is considered expired or stale. The softswitch no longer has authoritative, real-time concurrency data for that gateway. This can lead to routing decisions based on outdated call counts — potentially over-assigning calls to a gateway that has reached capacity, or under-utilizing a gateway that has available capacity. This is why it is critical that PUBLISH refreshes arrive before the expire timer elapses. ⏱️
❓ Does Allow Publish need to be enabled on every routing gateway?
📋 No. Allow Publish is a per-gateway setting, and you should only enable it on gateways where automatic concurrency control via the PUBLISH method is beneficial. For high-traffic, active gateways where call capacity management is critical, enabling Allow Publish provides valuable real-time concurrency tracking. For low-traffic, backup, or dormant gateways, leaving Allow Publish unchecked avoids unnecessary PUBLISH traffic while still allowing basic gateway operation. Use gateway configuration FAQ guidance for your specific setup. 🛠️
❓ Can different routing gateways have different effective publish expire values?
🔧 The SS_SIP_PUBLISH_EXPIRE parameter is a global setting — it applies to all routing gateways that have Allow Publish enabled. There is no per-gateway override for the publish expire duration in the standard VOS3000 configuration. If you need different refresh rates for different gateways, consider the trade-off: setting the global value to the shortest required interval ensures the busiest gateways have fresh data, but may generate more refresh traffic than necessary for quieter gateways. The default 300 seconds is designed to accommodate the majority of deployment scenarios. 💡
🔗 Related Resources
📚 Explore these related VOS3000 guides for deeper understanding of SIP protocol parameters, gateway management, and call routing optimization:
📞 Need expert help configuring VOS3000 SIP publish expire and gateway concurrency control? Contact our team on WhatsApp at +8801911119966 for personalized deployment assistance. We help VoIP operators worldwide optimize their VOS3000 softswitch configurations for maximum performance and reliability. 🌍
📞 Need Professional VOS3000 Setup Support?
For professional VOS3000 installations and deployment, VOS3000 Server Rental Solution:
🔄 What happens when you restart your VOS3000 softswitch? Does the upstream SIP server still think you are registered, holding stale registration entries that could cause misrouted calls or ghost registrations? The answer depends on a single but critical parameter: SS_SIP_USER_AGENT_SEND_UNREGISTER, which controls the VOS3000 SIP send unregister behavior. When enabled (the default), VOS3000 sends a cancel register message to upstream servers during shutdown or restart — cleanly removing your registration state before the softswitch goes offline. 🛡️
📡 Whether you are performing scheduled maintenance, restarting services after configuration changes, or migrating your VOS3000 server to new hardware, the VOS3000 SIP send unregister parameter determines whether upstream carriers and SIP proxies receive proper notification that your registration is being withdrawn. Without this cleanup, the upstream server may continue routing calls to your softswitch for the duration of the remaining registration expiry — leading to failed calls, lost revenue, and confused SIP signaling states. This guide covers every aspect of the SS_SIP_USER_AGENT_SEND_UNREGISTER parameter, from its default On setting to related registration parameters like SS_SIP_USER_AGENT_EXPIRE, SS_SIP_USER_AGENT_RETRY_DELAY, and system-level parameters such as SS_ENDPOINT_REGISTER_REPLACE. 🎯
🔧 All data in this guide is sourced exclusively from the official VOS3000 V2.1.9.07 Manual, Section 4.3.5.2 (Tables 4-3 and 4-4) — no fabricated values, no guesswork. For expert assistance with your VOS3000 deployment, contact us on WhatsApp at +8801911119966. 💡
Table of Contents
🔐 What Is VOS3000 SIP Send Unregister?
🔄 The VOS3000 SIP send unregister feature controls whether VOS3000 sends a SIP REGISTER request with an expiration of zero (0) to upstream servers when the softswitch is stopping or restarting. This is commonly known as a “cancel register message” or “de-registration.” The parameter is governed by SS_SIP_USER_AGENT_SEND_UNREGISTER with a default value of On and two possible options: On or Off. 📋
📌 According to the official VOS3000 V2.1.9.07 Manual, Table 4-3:
💡 Key insight: This parameter applies specifically to VOS3000’s outbound SIP registration — when VOS3000 acts as a SIP User Agent registering to another server (such as an upstream carrier or SIP trunk provider). It does not control how VOS3000 handles inbound de-registrations from your own endpoints. For inbound registration handling, see our VOS3000 SIP registration configuration guide. 📡
🎯 Why VOS3000 SIP Send Unregister Matters
⚠️ Without proper unregister behavior, several critical problems can arise:
📞 Ghost registrations: Upstream servers retain stale registration entries, routing calls to a softswitch that is offline
🔄 Misrouted incoming calls: Calls arrive at the upstream server, which forwards them to your old (now-offline) registration contact, resulting in call failures
🛡️ Security stale state: Abandoned registration entries may linger for the full expiry duration, potentially exposing routing data
📊 Billing discrepancies: Calls that fail due to stale registrations may still be billed by the upstream carrier if they consider the registration valid
⏱️ Extended recovery time: After restart, VOS3000 must compete with its own stale registration on the upstream server before it can register cleanly
⚙️ How VOS3000 SIP Send Unregister Works
🔄 Understanding the unregister mechanism requires knowing how SIP registration and de-registration work at the protocol level. When SS_SIP_USER_AGENT_SEND_UNREGISTER is set to On, VOS3000 sends a REGISTER request with the Contact header Expires parameter set to 0 — this is the standard SIP mechanism for canceling a registration. 📡
📊 Key behavior: The cancel register message is sent before VOS3000 fully stops its SIP stack. This means the softswitch must still have network connectivity when the shutdown process begins. If VOS3000 is killed abruptly (power loss, kill -9), the unregister message may not be sent, regardless of the parameter setting. ⚡
🔴 What Happens When SS_SIP_USER_AGENT_SEND_UNREGISTER Is Off?
⚠️ When this parameter is set to Off, VOS3000 simply stops without sending any cancel register message. The upstream server retains the registration entry until it naturally expires based on the SS_SIP_USER_AGENT_EXPIRE value. Here is the problematic scenario: 🔧
⚠️ VOS3000 SIP Send Unregister OFF — Stale Registration Problem:
VOS3000 ──── REGISTER (Expires: 3600) ────► Upstream SIP Server
│ │
│◄──────────── 200 OK ─────────────────────│ ✅ Registered
│ │
│ ⛔ VOS3000 shutdown — NO unregister sent │
│ │
│ ┌─────────────────────────────────────┐ │
│ │ Upstream server still has: │ │
│ │ 📌 Registration: VOS3000 → Active │ │
│ │ ⏱️ Expires in: ~3600 seconds │ │
│ │ 📞 Routing: Calls → VOS3000 IP │ │
│ └─────────────────────────────────────┘ │
│ │
│ Incoming call arrives ──► Routed to │
│ offline VOS3000 ──► ❌ Call fails! │
│ │
│ ... waiting for expiry (up to 3600s) ...│
│ │
│ 🔄 VOS3000 restarts, sends new REGISTER │
│ ✅ Registration restored (replaces old) │
└───────────────────────────────────────────┘
💡 Critical observation: The duration of the stale registration depends on SS_SIP_USER_AGENT_EXPIRE. If the expiry is set to 3600 seconds (1 hour) and VOS3000 shuts down without sending unregister, the upstream server will consider the registration valid for up to 1 hour — during which all incoming calls to that registration will fail. For more on registration expiry, see our outbound registration SIP guide. 📡
📋 Related SIP User Agent Registration Parameters
🔗 The VOS3000 SIP send unregister parameter does not operate in isolation. It is part of a family of User Agent parameters that control outbound registration behavior. Understanding their interactions is essential for proper configuration. 🛠️
📍 All parameters are located at: Operation management → Softswitch management → Additional settings → SIP parameter. For the complete parameter reference, see our VOS3000 parameter description guide. 📖
🔄 Unregister vs. Registration Expiry — Key Difference
⚠️ A common source of confusion is the difference between sending an unregister and letting a registration expire naturally. Here is the critical distinction: 🎯
Aspect
SIP Send Unregister (Expires: 0)
Registration Natural Expiry
📌 Mechanism
Explicit REGISTER with Expires=0
No refresh sent; server times out
⏱️ Effectiveness
Immediate — server removes registration instantly
Delayed — server waits until expiry timer completes
📡 Control
VOS3000 actively signals intent to unregister
VOS3000 passively allows registration to lapse
🛡️ Stale State Risk
None — registration removed on 200 OK
High — registration lingers until Expiry timer ends
🔧 Trigger
VOS3000 shutdown or restart (if parameter is On)
VOS3000 stops sending refresh REGISTER
💡 Simple rule: Sending unregister is an active, immediate cleanup. Letting registration expire is a passive, delayed cleanup. Always prefer active unregister for clean server state management. For more details on registration expiry, see our VOS3000 system parameters reference. 📡
🔐 System-Level Registration Parameters That Affect Unregister Behavior
📊 While SS_SIP_USER_AGENT_SEND_UNREGISTER controls the timing of VOS3000’s outbound de-registration, VOS3000 also provides system-level parameters that govern how inbound terminal registrations are handled. These are documented in Table 4-4 of the VOS3000 manual: 📋
Parameter
Default
Description
SS_ENDPOINT_REGISTER_REPLACE
On
Allow replace current registered users when terminal registration
SS_ENDPOINT_REGISTER_RETRY
6
Max retry times when terminal registration
SS_ENDPOINT_REGISTER_SUSPEND
180
Disable duration after exceeding retry times
🔧 How these relate to unregister: When VOS3000 restarts after a clean shutdown with unregister sent, and then sends a new REGISTER to the upstream server, SS_ENDPOINT_REGISTER_REPLACE (default: On) on the upstream side allows the new registration to replace any remaining stale entry. This is important because even with unregister sent, network conditions may cause the cancel register message to be lost. If SS_ENDPOINT_REGISTER_REPLACE is On on the receiving server, the new registration cleanly overrides the old one. 🔑
🖥️ Beyond the SIP parameters, VOS3000 provides specific registration management settings for each outbound registration configured on the softswitch. These settings are documented on pages 106-107 of the VOS3000 manual and directly interact with the SS_SIP_USER_AGENT_SEND_UNREGISTER behavior: 📡
Setting
Options
Relevance to Unregister
📡 Signaling port
Configurable port number
Cancel register message uses the same signaling port
🖥️ Host name
FQDN or IP address
Identifies VOS3000 in the unregister Contact header
🌐 Sip proxy
Address of the SIP route
Cancel register is sent to the same SIP proxy
📋 Register period
Default or Auto negotiation
Determines how long stale registration persists if unregister fails
🔑 Authentication user
Username for SIP auth
Cancel register uses same credentials (401/407 challenge-response)
💡 Important note: The cancel register message must pass through the same SIP proxy and authenticate with the same credentials as the original registration. If authentication fails for the cancel register, the upstream server will not remove the registration entry, leaving a stale state. For more on SIP authentication, see our VOS3000 SIP authentication guide. 🔑
🖥️ The behavior of VOS3000 during shutdown varies significantly based on how the softswitch is stopped and the state of SS_SIP_USER_AGENT_SEND_UNREGISTER. Here is a comprehensive analysis: 🌐
📡 Scenario Comparison: On vs. Off
📊 Understanding the practical difference between the two settings requires examining what happens in various shutdown and restart scenarios: 📋
Scenario
SS_SIP_USER_AGENT_SEND_UNREGISTER = On
SS_SIP_USER_AGENT_SEND_UNREGISTER = Off
🔧 Planned restart
✅ Cancel REGISTER sent → Clean removal
❌ No cancel sent → Stale entry remains
⚡ Service crash
⚠️ Cancel may not be sent (no graceful shutdown)
⚠️ No cancel sent (same as On, since crash is ungraceful)
🔌 Power loss
❌ Cancel cannot be sent
❌ Cancel cannot be sent
🛡️ Network outage before shutdown
⚠️ Cancel sent but may not reach server
❌ No cancel sent
🔄 Rapid restart (within seconds)
✅ Old registration removed, new one sent
⚠️ New REGISTER may conflict with stale entry
📋 Configuration change and restart
✅ Clean state for new configuration
❌ Old registration may interfere with new settings
🎯 Conclusion: Keeping SS_SIP_USER_AGENT_SEND_UNREGISTER set to On (the default) is strongly recommended for all deployments. The only scenario where it provides no benefit is an abrupt crash or power loss — which is the same outcome as having it Off. In all planned shutdown and restart scenarios, On provides clean registration cleanup. For a complete SIP call flow reference, see our VOS3000 SIP call flow guide. 📡
🔍 Select the gateway that requires outbound registration
🔧 In gateway settings, configure:
📡 Sip proxy: Address of the SIP route (upstream server)
🔑 Authentication user: Username for 401/407 authentication
📋 Register period: Default or Auto negotiation
🖥️ Host name: FQDN or IP address of VOS3000
💾 Save gateway settings
Step 4: Verify with SIP Debug 🔍
📝 After configuration, verify the unregister behavior is working correctly by monitoring the SIP registration flow during a controlled restart. For comprehensive debugging techniques, see our VOS3000 troubleshooting guide. 🔧
💡 Verification tip: The cancel register message goes through the same authentication challenge (401/407) as the original registration. This is standard SIP behavior — even de-registration requires proper authentication. If you see the REGISTER with Expires: 0 followed by a 200 OK in your SIP trace, the unregister is working correctly. 📡
📊 VOS3000 SIP Send Unregister Best Practices by Deployment
🎯 Different VoIP deployment scenarios may have different requirements for unregister behavior. Here are our recommendations based on real-world deployment experience and VOS3000 manual specifications: 💡
Deployment Type
Recommended Setting
Rationale
📞 Primary SIP trunk (carrier)
✅ On (default)
Essential — stale registrations cause incoming call failures during maintenance
🏢 Enterprise SIP trunk
✅ On (default)
Clean state management prevents call routing confusion during restarts
🌍 Wholesale VoIP (multi-vendor)
✅ On (default)
Multiple upstream carriers must all receive clean unregister to avoid ghost routes
📡 Backup/secondary trunk
✅ On (default)
Even backup trunks should clean up registration to prevent call misrouting
🔄 High-availability cluster
✅ On (default)
Critical — failover depends on clean registration state transitions
🧪 Test/lab environment
⚠️ Off (optional)
May be disabled for testing registration expiry behavior and stale state scenarios
⚠️ Strong recommendation: Keep SS_SIP_USER_AGENT_SEND_UNREGISTER set to On in all production deployments. The default setting is correct for virtually every scenario. Disabling it should only be done intentionally for testing purposes. For more on call routing strategies, see our VOS3000 call routing guide. 🛡️
🛡️ Common VOS3000 SIP Send Unregister Problems and Solutions
⚠️ Even with SS_SIP_USER_AGENT_SEND_UNREGISTER enabled, several issues can arise. Here are the most common problems and their solutions:
❌ Problem 1: Cancel Register Message Not Received by Upstream Server
🔍 Symptom: VOS3000 sends the unregister, but the upstream server still has the registration entry after VOS3000 restarts. Incoming calls may be routed to the old contact.
💡 Cause: Network conditions or firewall rules may prevent the cancel register message from reaching the upstream server. The unregister REGISTER with Expires: 0 may be lost due to UDP unreliability or blocked by a firewall during the shutdown sequence.
✅ Solutions:
🔧 Use TCP transport for SIP signaling if possible — ensures reliable delivery of the cancel register
📡 Check firewall rules to confirm that outbound SIP traffic is not blocked during the shutdown process
📊 Verify that the cancel register reaches the upstream server using SIP debug traces
🔄 After restart, the new REGISTER will replace the stale entry (if SS_ENDPOINT_REGISTER_REPLACE is On on the upstream server)
❌ Problem 2: Cancel Register Authentication Fails
🔍 Symptom: VOS3000 sends the cancel register, but receives a 403 Forbidden or repeated 401/407 challenges that cannot be completed before shutdown finishes.
💡 Cause: The authentication credentials stored in VOS3000 may not match the upstream server’s current requirements, or the shutdown process does not allow enough time for the full authentication handshake.
✅ Solutions:
🔑 Verify the Authentication user credentials in the gateway configuration match the upstream server
📞 Test registration manually before shutdown to confirm credentials are valid
📋 Check that the SIP proxy address is correct and reachable
⏱️ Ensure VOS3000 has enough time during shutdown to complete the authentication exchange
❌ Problem 3: Stale Registration Persists After Abrupt Crash
🔍 Symptom: VOS3000 crashes (process killed, power loss) and the upstream server retains the registration entry for the full expiry duration.
💡 Cause: An abrupt crash prevents VOS3000 from sending the cancel register message, regardless of the SS_SIP_USER_AGENT_SEND_UNREGISTER setting. This is an inherent limitation of the SIP protocol — there is no way to send an unregister after a crash.
✅ Solutions:
⚡ Use shorter SS_SIP_USER_AGENT_EXPIRE values (e.g., 300 seconds instead of 3600) to limit the maximum stale registration duration
🔄 Configure SS_ENDPOINT_REGISTER_REPLACE (default: On) on the upstream server to allow new registration to override stale entries
🛡️ Implement UPS (uninterruptible power supply) and process monitoring to prevent abrupt shutdowns
📡 Use backup vendor gateways so that calls continue through alternative paths while the stale entry expires
❌ Problem 4: Multiple VOS3000 Instances Competing for Same Registration
🔍 Symptom: Two VOS3000 instances register to the same upstream server with the same credentials. When one shuts down with unregister, it cancels the other instance’s registration.
💡 Cause: Both instances use the same SIP user credentials and register to the same SIP proxy. The cancel register from one instance removes the registration that the other instance depends on. 📊
✅ Solutions:
🔑 Use different Authentication user credentials for each VOS3000 instance
🖥️ Configure different Host name values to distinguish registrations
📋 Use separate SIP proxy entries if the upstream server supports multiple registrations per account
🛠️ For HA failover scenarios, disable unregister on the standby server to prevent accidental de-registration
📞 Complete Registration Parameter Quick Reference
📊 Here is the complete reference for all parameters that govern SIP registration behavior in VOS3000 — both outbound (User Agent) and inbound (Endpoint): 📋
✅ Use this checklist when deploying or verifying your VOS3000 SIP send unregister settings:
Check
Action
Status
📌 1
Verify SS_SIP_USER_AGENT_SEND_UNREGISTER is On (default) in SIP parameters
☐
📌 2
Set appropriate SS_SIP_USER_AGENT_EXPIRE (shorter = less stale time after crash)
☐
📌 3
Configure SS_SIP_USER_AGENT_RETRY_DELAY for post-restart re-registration timing
☐
📌 4
Verify Authentication user credentials match upstream server requirements
☐
📌 5
Test graceful shutdown and verify cancel register in SIP debug trace
☐
📌 6
Configure backup vendor gateways for failover during restart periods
☐
📌 7
Verify SS_ENDPOINT_REGISTER_REPLACE is On on upstream server (allows clean override)
☐
📌 8
Document expected stale registration window (based on EXPIRE value) for incident response
☐
❓ Frequently Asked Questions
❓ What is the default setting for VOS3000 SIP send unregister?
🔄 The default setting for VOS3000 SIP send unregister is On, configured via the SS_SIP_USER_AGENT_SEND_UNREGISTER parameter. When set to On, VOS3000 automatically sends a cancel register message (REGISTER with Expires: 0) to all upstream SIP servers during a graceful shutdown or restart. This ensures that registration entries are removed from the upstream server immediately, preventing stale registration states and misrouted calls. The default On setting is recommended for all production deployments. 🔧
❓ When should I set SS_SIP_USER_AGENT_SEND_UNREGISTER to Off?
⚠️ In virtually all production scenarios, you should keep this parameter at its default value of On. The only cases where you might consider setting it to Off are: (1) Testing environments where you want to observe stale registration behavior, (2) Troubleshooting upstream server registration replacement issues, or (3) Very specific carrier requirements where the upstream server does not support de-registration. Disabling unregister in production will cause stale registrations to persist after every restart, leading to call routing failures. For help evaluating your specific scenario, contact us on WhatsApp at +8801911119966. 📡
❓ What happens to the cancel register if VOS3000 crashes?
⚡ If VOS3000 crashes abruptly (power loss, kill -9, kernel panic), the cancel register message cannot be sent regardless of the SS_SIP_USER_AGENT_SEND_UNREGISTER setting. The unregister mechanism only works during a graceful shutdown where VOS3000 has time to send the REGISTER with Expires: 0 before the SIP stack stops. After an abrupt crash, the upstream server will retain the stale registration until the expiry timer (governed by SS_SIP_USER_AGENT_EXPIRE) elapses. Using shorter expiry values (e.g., 300s instead of 3600s) limits the maximum stale registration duration after a crash. 🔧
❓ Does the cancel register message require authentication?
🔑 Yes, the cancel register message (REGISTER with Expires: 0) typically goes through the same authentication process as a normal registration. When VOS3000 sends the cancel register, the upstream server will usually respond with a 401 Unauthorized or 407 Proxy Authentication Required challenge, and VOS3000 must resend the cancel register with proper credentials. This is standard SIP behavior per RFC 3261. The Authentication user configured in the gateway settings must match the upstream server’s requirements for the cancel register to succeed. For more on SIP authentication, see our VOS3000 SIP authentication guide. 📡
❓ How does SS_SIP_USER_AGENT_EXPIRE affect the unregister behavior?
⏱️ The SS_SIP_USER_AGENT_EXPIRE parameter determines how long a successful registration remains valid on the upstream server. If VOS3000 shuts down without sending unregister (parameter Off or crash), the stale registration persists for the remaining expiry duration. With the default Auto Negotiation setting, the expiry is typically negotiated between VOS3000 and the upstream server within the range of 20–7200 seconds. Shorter expiry values mean stale registrations clear faster, while longer values increase the risk window. If you want to minimize stale registration impact, use a shorter fixed expiry (e.g., 300 seconds) and keep unregister On. 📊
❓ Can the cancel register message get lost in transit?
📡 Yes, since SIP commonly uses UDP transport, the cancel register message can be lost. If VOS3000 sends the cancel register but the upstream server never receives it, the registration entry will persist until the expiry timer elapses. To mitigate this: (1) Use TCP transport for SIP if supported by the upstream server, (2) Verify the cancel register reaches the server using SIP debug traces, (3) Configure backup vendor gateways so calls continue through alternative paths during the stale period, and (4) Rely on SS_ENDPOINT_REGISTER_REPLACE (On) on the upstream server to allow the new registration after restart to override any stale entry. For complete troubleshooting guidance, see our VOS3000 troubleshooting guide. 🔧
❓ What is the SIP message format for a cancel register?
📋 A cancel register is a standard SIP REGISTER request with the Contact header Expires parameter set to 0. This tells the registrar server to remove the binding immediately. The message includes the same Call-ID, From tag, and To tag as the original registration (per RFC 3261 requirements for registration updates). VOS3000 handles this automatically when SS_SIP_USER_AGENT_SEND_UNREGISTER is On — no manual message construction is needed. For more on SIP message flows, see our VOS3000 SIP call flow guide. 💡
📚 Related Resources
🔗 Explore these related VOS3000 guides for comprehensive softswitch configuration:
📞 Need expert help with your VOS3000 SIP send unregister configuration or registration cleanup? Contact us on WhatsApp at +8801911119966 for professional assistance with your VoIP softswitch deployment. 🚀
📞 Need Professional VOS3000 Setup Support?
For professional VOS3000 installations and deployment, VOS3000 Server Rental Solution:
VOS3000 SIP Display From: Important E164 Caller Configuration
📞 When a SIP INVITE leaves your VOS3000 softswitch, the From header carries the caller’s identity — but what exactly appears in that header? Is it the raw E164 number? The display name? Or something else entirely? The answer depends on a critical parameter: SS_SIP_E164_DISPLAY_FROM, which governs the VOS3000 SIP display from mode and determines how caller information is presented in the From header of every SIP signal your softswitch sends. 🎯
📡 The From header is one of the most fundamental elements in SIP signaling. It tells the receiving server who is calling. But in real-world VoIP deployments, the “caller” can be represented in multiple ways — as a plain number, with a display name, in E164 international format, or even with a domain name. Getting the VOS3000 SIP display from configuration right is essential for caller ID presentation, carrier interoperability, and regulatory compliance with number formatting standards. This guide covers the SS_SIP_E164_DISPLAY_FROM parameter (default: Ignore), per-gateway display settings, mapping gateway caller number extraction, and the relationship with privacy headers like P-Asserted-Identity and P-Preferred-Identity. 🔧
💡 All data in this guide is sourced exclusively from the official VOS3000 V2.1.9.07 Manual, Section 4.3.5.2 (Table 4-3) — no fabricated values, no guesswork. For expert assistance with your VOS3000 deployment, contact us on WhatsApp at +8801911119966. 📱
Table of Contents
🔐 What Is VOS3000 SIP Display From?
📋 The VOS3000 SIP display from is the mode that controls how VOS3000 populates the display information in the SIP From header. This is governed by the parameter SS_SIP_E164_DISPLAY_FROM, which has a default value of Ignore and offers multiple display mode options. 📡
📌 According to the official VOS3000 V2.1.9.07 Manual, Table 4-3:
💡 Key insight: When set to Ignore, VOS3000 does not modify the display information in the From header — it passes the caller information as-is from the original signaling. When a specific display mode is selected, VOS3000 formats the From header according to the E164 standard, ensuring consistent international number formatting across all outbound calls. This is especially important for carriers that require E164-compliant caller numbers. 📞
🎯 Why VOS3000 SIP Display From Matters
⚠️ Misconfigured display information in the From header can cause several critical issues:
📞 Caller ID failure: Some carriers reject calls where the From header does not contain a properly formatted E164 number, resulting in 403 Forbidden or 484 Number Incomplete responses
🌐 Interoperability problems: Different SIP equipment expects different formats — some require display names, others require E164 numbers only
🔒 Privacy conflicts: Incorrect display modes may expose caller numbers that should be hidden by privacy settings
📊 Billing discrepancies: CDR records may not match the actual caller numbers presented in signaling, causing reconciliation issues
🛡️ Regulatory compliance: Some jurisdictions require caller numbers in E164 international format (+CC.NDC.SN) for emergency services and lawful interception
⚙️ Understanding the SIP From Header Structure
📡 Before diving into the configuration, it is essential to understand the structure of the SIP From header and where the VOS3000 SIP display from parameter exerts its influence. Here is the anatomy of a SIP From header: 🔍
📞 SIP From Header Anatomy:
From: "Display Name" <sip:number@domain>;tag=abc123
─────────── ──────────────────── ─────────
│ │ │
│ │ └── Tag (dialog identifier)
│ │
│ └── URI (number + domain)
│ ├── number: caller number (E164 format)
│ └── domain: server IP or domain name
│
└── Display Name (what appears on phone screen)
└── SS_SIP_E164_DISPLAY_FROM controls THIS part
Examples:
Ignore mode: From: <sip:[email protected]>;tag=x1
E164 mode: From: "+8801911119966" <sip:[email protected]>;tag=x1
Display mode: From: "John" <sip:[email protected]>;tag=x1
🔧 The critical distinction: The SS_SIP_E164_DISPLAY_FROM parameter specifically controls the display information portion of the From header — not the SIP URI itself. When set to Ignore, VOS3000 leaves the display name empty or unchanged. When set to a display mode, it populates the display portion with the E164-formatted number. For more on SIP signaling fundamentals, see our VOS3000 SIP call flow guide. 📖
📋 SS_SIP_E164_DISPLAY_FROM Display Modes
🔀 The VOS3000 SIP display from parameter offers different modes that determine how the display information appears in the From header. Here is a detailed comparison: 📊
Display Mode
From Header Format
Use Case
Carrier Compatibility
Ignore (Default)
From: <sip:number@domain>
Pass-through; no display name modification
🟢 Broad compatibility
E164 Display
From: “+CC.NDC.SN” <sip:+CC.NDC.SN@domain>
International format required by carrier
🟡 Carrier-specific
Number Display
From: “number” <sip:number@domain>
Display name set to caller number
🟢 Good compatibility
📌 When to use Ignore vs. E164 display: The default Ignore mode works well for most deployments where carriers do not enforce strict From header formatting. However, if your upstream carrier requires E164-formatted numbers in both the display name and URI of the From header, you must change SS_SIP_E164_DISPLAY_FROM from Ignore to the appropriate display mode. For more on carrier requirements, see our VOS3000 caller ID management guide. 📞
🔗 Per-Gateway SIP Settings for From Header
🖥️ Beyond the global SS_SIP_E164_DISPLAY_FROM parameter, VOS3000 provides per-gateway SIP settings that further control the From header behavior. These settings are configured in the Routing Gateway > Additional settings > Protocol > SIP section and allow fine-grained control over how each gateway presents caller information. 🔧
Setting
Function
Impact on From Header
Enable local domain name
Change the IP corresponding to the “From” field in signaling to SS_LOCAL_IP_DOMAIN domain
Replaces the IP address in the From URI domain part with the configured local domain name
Peer number information
Set select mode to SIP signal’s caller
Determines how VOS3000 extracts the peer (callee/caller) number from SIP signaling
💡 Enable local domain name is particularly important when your VOS3000 server has a public domain name but communicates using a private IP address internally. By enabling this setting, the From header’s domain portion changes from the server’s private IP (e.g., 192.168.1.100) to the configured SS_LOCAL_IP_DOMAIN (e.g., sip.yourdomain.com), which improves interoperability with carriers that validate the From header domain. 🌐
🔧 Peer number information controls how VOS3000 selects the caller number from incoming SIP signals. This setting works in conjunction with the mapping gateway caller field selection (covered below) to ensure the correct caller number is extracted and presented. For detailed gateway configuration, see our VOS3000 gateway configuration guide. 📖
🛡️ Per-Gateway Privacy Settings and Display From
🔒 The VOS3000 SIP display from setting does not operate in isolation. It interacts with per-gateway privacy settings that control how caller identity is presented and protected. These settings are configured at the Routing Gateway > Additional settings > Protocol level and include: 🛡️
Privacy Setting
Options
Description
Interaction with Display From
P-Asserted-Identity
None / Passthrough / Caller
Controls P-Asserted-Identity header insertion
When set to Caller, PAI carries the real caller; From header may differ based on display mode
P-Preferred-Identity
None / Passthrough / Caller
Controls P-Preferred-Identity header insertion
Similar to PAI; provides preferred identity that may differ from From display
Privacy
None / Passthrough / Id
Controls Privacy header in outbound signaling
When set to Id, caller identity in From is hidden; display name shows “anonymous”
🎯 Critical interaction: When Privacy is set to Id, the From header display information shows “anonymous” or ” withheld” regardless of the SS_SIP_E164_DISPLAY_FROM setting. The real caller number is then carried in the P-Asserted-Identity header (if P-Asserted-Identity is set to Caller). This is how VOS3000 supports caller ID blocking while still providing the real number to trusted carriers. For a complete guide on this topic, see our VOS3000 P-Asserted-Identity caller ID guide. 📞
🔒 Privacy Header vs. Display From — Priority Order
📊 Understanding the priority order is essential when both privacy settings and display from settings are configured: 🔑
🔒 VOS3000 From Header Priority — Privacy vs Display From:
Step 1: Check Privacy Setting (per-gateway)
├── Privacy = None
│ └── No Privacy header added → proceed to Step 2
├── Privacy = Passthrough
│ └── Pass existing Privacy header → proceed to Step 2
└── Privacy = Id
└── Add "Privacy: id" header
└── From header → "Anonymous" <sip:[email protected]>
└── Real caller in PAI (if P-Asserted-Identity = Caller)
└── ⛔ STOP — SS_SIP_E164_DISPLAY_FROM is overridden
Step 2: Check SS_SIP_E164_DISPLAY_FROM (global)
├── Ignore (default)
│ └── From header display name = empty or original
├── E164 Display
│ └── From header display name = "+8801911119966"
└── Number Display
└── From header display name = "8801911119966"
Step 3: Check Enable Local Domain Name (per-gateway)
├── Disabled
│ └── From URI domain = server IP (e.g., 192.168.1.100)
└── Enabled
└── From URI domain = SS_LOCAL_IP_DOMAIN (e.g., sip.carrier.com)
💡 Key takeaway: Privacy settings always take priority over display from settings. If Privacy is set to Id, the From header becomes anonymous regardless of what SS_SIP_E164_DISPLAY_FROM is configured to. For more on privacy configurations, see our VOS3000 parameter description reference. 📖
🔄 Mapping Gateway Caller Number Extraction
📊 While SS_SIP_E164_DISPLAY_FROM controls how the From header is presented on outbound calls, the Mapping Gateway settings control how VOS3000 extracts the caller number from inbound SIP signals. This is a critical complementary configuration that determines which field VOS3000 reads to identify the caller. 🔍
Extraction Field
SIP Header
Format
When to Use
From
From: <sip:number@domain>
Standard SIP From URI
✅ Default; most common; broad compatibility
Remote-Party-ID
Remote-Party-ID: number;party=calling
RFC 3325 identity header
📡 Carriers that send verified caller ID in RPID
Display
From: “Display” <sip:number@domain>
Display name portion of From header
📞 When display name differs from URI number
🔧 How this interacts with VOS3000 SIP display from: The Mapping Gateway “Caller” setting determines which field VOS3000 reads as the caller number on incoming calls. The SS_SIP_E164_DISPLAY_FROM setting determines how VOS3000 presents the caller number in the From header on outgoing calls. These two settings work in opposite directions but must be configured consistently to ensure end-to-end caller ID integrity. For detailed mapping gateway configuration, see our VOS3000 gateway configuration and routing mapping guide. 📖
📊 Caller Number Extraction Scenario
🎯 Consider a scenario where an upstream carrier sends caller information in the Remote-Party-ID header but the From header contains a generic number. Here is how the Mapping Gateway “Caller” setting determines what VOS3000 uses: 📡
📞 Incoming SIP INVITE from Carrier:
From: "Unknown" <sip:[email protected]>;tag=abc
Remote-Party-ID: "+8801911119966" <sip:[email protected]>;party=calling
Mapping Gateway Caller Setting = "From"
└── VOS3000 reads: 0000 (generic number)
└── ❌ Wrong caller number for CDR and routing
Mapping Gateway Caller Setting = "Remote-Party-ID"
└── VOS3000 reads: +8801911119966 (real caller)
└── ✅ Correct caller number for CDR and routing
Mapping Gateway Caller Setting = "Display"
└── VOS3000 reads: "Unknown" (display name from From)
└── ❌ Not a valid caller number
💡 Pro tip: Always verify which field your upstream carrier uses to send the real caller number. Many international carriers use Remote-Party-ID or P-Asserted-Identity instead of the From header. Configuring the Mapping Gateway “Caller” setting to the correct field ensures VOS3000 extracts the right caller number. For authentication-related configurations, see our VOS3000 SIP authentication guide. 🔑
📋 Related SIP Privacy and Display Parameters
🔗 The VOS3000 SIP display from parameter is part of a family of parameters that control caller identity presentation in SIP signaling. Understanding their relationships is essential for proper configuration. 🛠️
Parameter
Default
Description
Scope
SS_SIP_E164_DISPLAY_FROM
Ignore
Mode of SIP display information
Global (From header display)
SS_SIP_USER_AGENT_PRIVACY
Ignore
Privacy setting for register user
Outbound registration privacy
📍 Both parameters are located at: Operation management → Softswitch management → Additional settings → SIP parameter. For the complete parameter reference, see our VOS3000 system parameters guide. 📖
🔄 SS_SIP_E164_DISPLAY_FROM vs. SS_SIP_USER_AGENT_PRIVACY
⚠️ A common source of confusion is the difference between SS_SIP_E164_DISPLAY_FROM and SS_SIP_USER_AGENT_PRIVACY. While both affect how caller information appears in SIP headers, they serve different purposes: 🎯
Aspect
SS_SIP_E164_DISPLAY_FROM
SS_SIP_USER_AGENT_PRIVACY
📌 Purpose
Controls display format in From header
Controls privacy level for registration user
🔢 Default
Ignore
Ignore
📡 Applied To
From header display name (INVITE and call signaling)
REGISTER messages (outbound registration)
🔄 Effect
Formats how the caller number appears in From display name
Adds Privacy header to registration; hides identity
⚙️ Options
Ignore / display modes
Ignore / Id / None
💡 Simple rule: SS_SIP_E164_DISPLAY_FROM controls how the caller looks in the From header. SS_SIP_USER_AGENT_PRIVACY controls whether the registration user is hidden in outbound REGISTER messages. They apply to different SIP methods and serve different purposes. For more on SIP session management, see our VOS3000 SIP session guide. 📡
📋 Step-by-Step VOS3000 SIP Display From Configuration
⚙️ Follow these steps to configure the VOS3000 SIP display from settings on your system:
Step 1: Configure Global SS_SIP_E164_DISPLAY_FROM 📋
🔐 Log in to VOS3000 Client with administrator credentials
🔍 Select the mapping gateway that handles incoming calls
🔧 Set Caller field to extract caller number from:
📞 From — standard From header (default, most common)
📡 Remote-Party-ID — RFC 3325 verified identity
📟 Display — display name portion of From header
💾 Save mapping gateway settings
Step 5: Verify with SIP Debug 🔍
📝 After configuration, verify the display from settings are working correctly by examining the SIP INVITE messages. For comprehensive debugging techniques, see our VOS3000 troubleshooting guide. 🔧
🔍 Verifying VOS3000 SIP Display From — SIP Debug Trace:
──► Outbound INVITE (SS_SIP_E164_DISPLAY_FROM = Ignore):
INVITE sip:[email protected] SIP/2.0
From: <sip:[email protected]>;tag=z9hG4bK123
└── No display name (Ignore mode)
To: <sip:[email protected]>
──► Outbound INVITE (SS_SIP_E164_DISPLAY_FROM = E164 Display):
INVITE sip:[email protected] SIP/2.0
From: "+8801911119966" <sip:[email protected]>;tag=z9hG4bK456
└── E164 format display name added ✅
To: <sip:[email protected]>
──► Outbound INVITE (Privacy = Id, PAI = Caller):
INVITE sip:[email protected] SIP/2.0
From: "Anonymous" <sip:[email protected]>;tag=z9hG4bK789
└── Privacy overrides display from ⛔
To: <sip:[email protected]>
P-Asserted-Identity: <sip:[email protected]>
└── Real caller in PAI header 🔒
Privacy: id
📊 VOS3000 SIP Display From Best Practices by Deployment
🎯 Different VoIP deployment scenarios require different display from configurations. Here are recommended settings based on real-world deployment experience and VOS3000 manual specifications: 💡
Deployment Type
SS_SIP_E164_DISPLAY_FROM
Privacy Setting
Mapping Gateway Caller
📞 International wholesale (E164 required)
E164 Display
None
From or Remote-Party-ID
🏢 Enterprise SIP trunk
Ignore (default)
None
From
🌍 Multi-carrier termination
E164 Display
Passthrough
Remote-Party-ID
🔒 Privacy-focused (CLIR)
Ignore
Id
From
📞 Domestic carrier (no E164)
Ignore (default)
None
From
📡 RPID-based upstream
E164 Display
Passthrough
Remote-Party-ID
💡 Important: The VOS3000 SIP display from setting works together with your call routing and gateway privacy configuration. Always verify the complete signaling chain — from inbound caller extraction (Mapping Gateway) through outbound caller presentation (Display From + Privacy) — to ensure consistent caller ID across your entire VoIP network. For expert guidance, reach us on WhatsApp at +8801911119966. 📱
🛡️ Common VOS3000 SIP Display From Problems and Solutions
⚠️ Misconfigured display from settings can cause a range of caller ID issues. Here are the most common problems and their solutions:
❌ Problem 1: Carrier Rejects Calls — 403 Forbidden Due to Invalid From Header
🔍 Symptom: Upstream carrier returns 403 Forbidden or 484 Number Incomplete on calls that pass through VOS3000. The carrier’s technical support reports that the From header does not contain a valid E164 number.
💡 Cause: SS_SIP_E164_DISPLAY_FROM is set to Ignore (default), so the From header does not include the E164-formatted display name that the carrier requires for number validation.
✅ Solutions:
🔧 Change SS_SIP_E164_DISPLAY_FROM from Ignore to the E164 display mode
📞 Verify the carrier’s exact From header format requirements (with or without “+” prefix)
📊 Test with a single call first and verify the From header in SIP debug output
❌ Problem 2: Wrong Caller Number Appears on Called Party Phone
🔍 Symptom: The called party sees a generic or incorrect number instead of the real caller number on their phone display.
💡 Cause: The Mapping Gateway “Caller” setting is extracting the caller number from the wrong SIP field. For example, if the carrier sends the real number in Remote-Party-ID but the Mapping Gateway is set to extract from “From”, VOS3000 may be reading a generic or incorrect number.
✅ Solutions:
🔍 Examine incoming SIP INVITE messages to identify which field carries the real caller number
🔧 Change Mapping Gateway “Caller” setting to the correct field (From / Remote-Party-ID / Display)
📞 Verify caller number after the change by making a test call
❌ Problem 3: Caller ID Shows “Anonymous” When It Should Not
🔍 Symptom: Outbound calls show “Anonymous” or “Unknown” on the called party’s phone even though the caller has not requested privacy.
💡 Cause: The per-gateway Privacy setting is configured to “Id” which adds a Privacy: id header and changes the From header to anonymous, overriding the SS_SIP_E164_DISPLAY_FROM setting.
✅ Solutions:
🔒 Check the per-gateway Privacy setting — change from “Id” to “None” if caller ID blocking is not required
🔧 If selective CLIR (Caller Line Identification Restriction) is needed, use P-Asserted-Identity = Caller with Privacy = Id
📊 Verify that SS_SIP_E164_DISPLAY_FROM is not set to Ignore if you need a display name
❌ Problem 4: From Header Shows Private IP Instead of Domain Name
🔍 Symptom: The From header contains a private IP address (e.g., 192.168.1.100) in the URI domain portion, which some carriers reject because they cannot route responses to a private IP.
💡 Cause: The “Enable local domain name” per-gateway setting is not enabled, so VOS3000 uses its private IP address in the From header domain.
✅ Solutions:
🌐 Enable “Enable local domain name” in the routing gateway’s SIP settings
🔧 Verify that SS_LOCAL_IP_DOMAIN is configured with your public domain name or public IP
📞 Test call and verify the From header domain matches your public-facing address
📞 Complete Display and Privacy Parameter Quick Reference
📊 Here is the complete reference for all parameters and settings that govern caller identity presentation in VOS3000: 📋
Parameter / Setting
Default
Scope
Function
SS_SIP_E164_DISPLAY_FROM
Ignore
Global
Mode of SIP display information in From header
SS_SIP_USER_AGENT_PRIVACY
Ignore
Global
Privacy setting for register user (outbound REGISTER)
💡 VOS3000 SIP Display From Configuration Checklist
✅ Use this checklist when deploying or tuning your VOS3000 SIP display from settings:
Check
Action
Status
📌 1
Set SS_SIP_E164_DISPLAY_FROM to appropriate mode (Ignore for passthrough, E164 for formatted display)
☐
📌 2
Verify per-gateway “Enable local domain name” setting matches your deployment needs
☐
📌 3
Configure per-gateway “Peer number information” for correct caller extraction mode
☐
📌 4
Set P-Asserted-Identity to Caller if carriers require verified caller identity
☐
📌 5
Configure Privacy setting (None for normal, Id for caller ID blocking, Passthrough for carrier passthrough)
☐
📌 6
Set Mapping Gateway “Caller” field to the correct SIP header (From / Remote-Party-ID / Display)
☐
📌 7
Test outbound call and verify From header format in SIP debug
☐
📌 8
Verify caller ID appears correctly on called party phone display
☐
❓ Frequently Asked Questions
❓ What is the default VOS3000 SIP display from setting?
📋 The default VOS3000 SIP display from setting is Ignore, configured via the SS_SIP_E164_DISPLAY_FROM parameter. When set to Ignore, VOS3000 does not modify the display information in the From header — it passes the caller information as-is from the original signaling. This provides broad compatibility with most carriers and SIP equipment. If your upstream carrier requires E164-formatted display names in the From header, you must change this from Ignore to the appropriate display mode. 🔧
❓ How does SS_SIP_E164_DISPLAY_FROM interact with Privacy settings?
🔒 Privacy settings take priority over SS_SIP_E164_DISPLAY_FROM. When the per-gateway Privacy setting is configured to “Id”, VOS3000 adds a Privacy: id header and changes the From header to anonymous, regardless of what SS_SIP_E164_DISPLAY_FROM is set to. The real caller number is then carried in the P-Asserted-Identity header (if P-Asserted-Identity is set to Caller). This is the standard mechanism for supporting Caller Line Identification Restriction (CLIR) in VOS3000. For more details, see our VOS3000 P-Asserted-Identity guide. 📡
❓ What is E164 format and why do carriers require it?
📞 E164 is the ITU-T international numbering plan standard that defines the format of international telephone numbers. An E164 number consists of: a “+” prefix, followed by the country code (CC), the national destination code (NDC), and the subscriber number (SN) — for example, +8801911119966. Many international carriers require caller numbers in E164 format in the SIP From header to properly route calls, validate caller identity, and comply with regulatory requirements for emergency services and lawful interception. The VOS3000 SIP display from parameter allows you to ensure the From header displays the E164-formatted number when required. 🌐
❓ What is the Mapping Gateway “Caller” field setting?
🔄 The Mapping Gateway “Caller” field setting determines which SIP header VOS3000 reads to extract the caller number on incoming calls. The available options are: From (reads from the standard From header URI), Remote-Party-ID (reads from the RFC 3325 Remote-Party-ID header), and Display (reads the display name portion of the From header). This setting works in the opposite direction from SS_SIP_E164_DISPLAY_FROM — while Display From controls outbound presentation, the Caller field controls inbound extraction. For detailed configuration, see our VOS3000 gateway configuration guide. 📖
❓ When should I enable “Enable local domain name” in per-gateway settings?
🌐 Enable “Enable local domain name” when your VOS3000 server uses a private IP address internally but has a public domain name or public IP for external communication. When enabled, VOS3000 replaces the private IP in the From header URI domain portion with the configured SS_LOCAL_IP_DOMAIN. This is essential when upstream carriers validate the From header domain and cannot route responses to a private IP address (e.g., 192.168.x.x or 10.x.x.x). Without this setting, calls may fail with 403 Forbidden because the carrier cannot identify the origin server. 🔧
❓ Can I set different display from modes for different gateways?
📊 The SS_SIP_E164_DISPLAY_FROM parameter is a global SIP parameter that applies to all gateways. However, you can achieve per-gateway differentiation through the per-gateway Privacy settings and Enable local domain name settings, which modify how the From header appears independently of the global display from mode. For example, you can set SS_SIP_E164_DISPLAY_FROM to E164 display globally, then use per-gateway Privacy = Id for specific gateways where caller ID blocking is required. For advanced configuration assistance, contact us on WhatsApp at +8801911119966. 📱
❓ How do I troubleshoot caller ID issues related to VOS3000 SIP display from?
🔍 Start by examining the SIP INVITE messages in VOS3000’s SIP debug trace. Check the From header format, display name, Privacy header, P-Asserted-Identity header, and the domain portion of the From URI. Compare the actual signaling with your expected format. Common issues include: SS_SIP_E164_DISPLAY_FROM set to Ignore when the carrier requires E164, Mapping Gateway Caller set to the wrong field, Privacy = Id overriding display from settings, and private IP in the From URI domain. For comprehensive troubleshooting techniques, see our VOS3000 troubleshooting guide. 🔧
📚 Related Resources
🔗 Explore these related guides for comprehensive VOS3000 configuration knowledge:
📞 When VOS3000 sends a SIP INVITE to a routing gateway, which header determines the callee number? Is it the To header, the Request-Line, or the Contact header? The answer depends on a critical — yet often overlooked — parameter: SS_SIP_ROUTING_GATEWAY_INVITE_USE_CONTACT, which governs the VOS3000 SIP routing gateway contact behavior for outbound INVITE messages. 🎯
🔄 By default, this parameter is set to Off, meaning VOS3000 uses the standard SIP convention where the callee number is taken from the To header. But when enabled (On), VOS3000 extracts the callee number from the request-line of the INVITE and preserves the original number in the To field. This subtle change has a significant impact on how calls are routed through your VoIP softswitch — especially when interfacing with gateways that rely on the Contact header or request-line for number identification. 🔧
📡 This guide covers everything you need to know about the VOS3000 SIP routing gateway contact setting — from the core parameter SS_SIP_ROUTING_GATEWAY_INVITE_USE_CONTACT to the related per-gateway SIP settings (Reply address, Request address, Peer number information) and Mapping Gateway callee/caller field selection. All data is sourced exclusively from the official VOS3000 V2.1.9.07 Manual, Section 4.3.5.2 (Table 4-3). For expert assistance, contact us on WhatsApp at +8801911119966. 💡
Table of Contents
🔐 What Is VOS3000 SIP Routing Gateway Contact?
📞 The VOS3000 SIP routing gateway contact parameter controls how VOS3000 constructs the SIP INVITE message when sending calls to a routing gateway. Specifically, it determines whether the callee number should be extracted from the request-line and whether the original number should be preserved in the To field. 📋
📌 According to the official VOS3000 V2.1.9.07 Manual, Table 4-3:
Attribute
Value
📌 Parameter Name
SS_SIP_ROUTING_GATEWAY_INVITE_USE_CONTACT
🔢 Default Value
Off
📝 Description
Use number from request-line as callee and keep original number in To field when send invite to callee
💡 Key insight: When this parameter is set to Off (default), VOS3000 follows the standard SIP RFC 3261 convention — the callee number in the INVITE is determined by the To header, and the request-line matches. When set to On, VOS3000 extracts the callee number from the request-line of the incoming SIP message and uses that for routing, while keeping the original number in the To field of the outbound INVITE. This is essential when upstream gateways manipulate the request-line during transit. 📡
🎯 Why VOS3000 SIP Routing Gateway Contact Matters
⚠️ Understanding and correctly configuring this parameter is critical for several reasons:
📞 Number routing accuracy: If the callee number source does not match what the downstream gateway expects, calls may be routed to the wrong destination or rejected entirely
🔄 To field preservation: Enabling this setting preserves the original dialed number in the To field, which is essential for billing, CDR accuracy, and troubleshooting
🔗 Gateway compatibility: Some SIP gateways and carrier equipment extract the callee number from the request-line rather than the To header — this parameter ensures compatibility
📊 Call flow integrity: Mismatched headers can cause call failures, one-way audio, or incorrect number display on the receiving end
🛡️ Interoperability: Different vendors implement SIP differently; this parameter gives you the flexibility to adapt VOS3000 to various gateway behaviors
⚙️ How SS_SIP_ROUTING_GATEWAY_INVITE_USE_CONTACT Works
🔄 To understand this parameter, you need to see how the SIP INVITE message changes based on the setting. Here is a text-based comparison of the two modes: 📡
📋 SIP INVITE Message Structure — SS_SIP_ROUTING_GATEWAY_INVITE_USE_CONTACT:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⬇️ Mode: OFF (Default)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
INVITE sip:[email protected] SIP/2.0 ← Request-Line
Via: SIP/2.0/UDP 10.0.0.1:5060
From: "Caller" <sip:[email protected]>;tag=abc
To: <sip:[email protected]> ← Callee = To header
Contact: <sip:[email protected]:5060>
Content-Type: application/sdp
📌 Result: Callee number = 8801234567 (from To header)
Request-Line and To header contain the SAME number
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⬇️ Mode: ON
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
INVITE sip:[email protected] SIP/2.0 ← Request-Line (used for routing)
Via: SIP/2.0/UDP 10.0.0.1:5060
From: "Caller" <sip:[email protected]>;tag=abc
To: <sip:[email protected]> ← Original number PRESERVED
Contact: <sip:[email protected]:5060>
Content-Type: application/sdp
📌 Result: Callee number = 8801234567 (from Request-Line)
To field keeps the ORIGINAL number (before any manipulation)
📊 Critical distinction: When the parameter is On, the request-line contains the number that VOS3000 uses for actual routing (the callee number), while the To header retains the original dialed number before any prefix manipulation or routing transformation. This is extremely useful when VOS3000 applies prefix conversion rules — the gateway receives the routing number in the request-line but the original number remains in the To field for reference. 🎯
📋 Per-Gateway SIP Settings: Reply Address and Request Address
🔗 Beyond the global SS_SIP_ROUTING_GATEWAY_INVITE_USE_CONTACT parameter, VOS3000 provides per-gateway SIP settings that control how reply and request signals are addressed. These settings are configured at the individual gateway level under Routing Gateway → Additional settings → Protocol → SIP. 🛠️
📨 Reply Address: Where to Send Reply Signal
📬 The Reply address setting determines where VOS3000 sends the reply signal after receiving a SIP request from the gateway. This is critical for ensuring SIP responses (such as 200 OK, 180 Ringing) reach the correct destination. 📡
Option
Description
Recommendation
🟢 Socket
Send reply to the source IP and port from which the SIP request was received
✅ Recommended — most reliable for NAT traversal
🔵 Via port
Send reply to the port specified in the Via header
⚠️ Use when gateway requires Via-based routing
🟡 Via
Send reply to the address and port in the Via header
⚠️ Standard SIP behavior per RFC 3261
💡 Best practice: The Socket option is recommended for the Reply address because it ensures SIP responses are sent back to the actual source of the request, which is critical for NAT traversal scenarios. For a deeper understanding of SIP signal flow, see our VOS3000 SIP call flow guide. 📖
📤 Request Address: Where to Send Request Signal
📨 The Request address setting determines where VOS3000 sends the request signal after a call is established. This setting directly relates to the VOS3000 SIP routing gateway contact concept because it controls whether VOS3000 uses the Contact header or socket information for subsequent requests. 🔧
Option
Description
Recommendation
🟢 Socket
Send request to the source IP and port from which the SIP request was received
✅ Recommended — most reliable
🔵 Contact Port
Send request to the port specified in the Contact header
⚠️ Use when gateway advertises a specific Contact port
🟡 Contact
Send request to the full address in the Contact header
⚠️ Standard SIP per RFC 3261
🔧 How this relates to the Contact header: The Request address setting determines how VOS3000 uses the Contact header for subsequent in-dialog requests (such as re-INVITE or BYE). When set to Contact, VOS3000 follows the SIP standard and sends requests to the URI in the Contact header. When set to Socket, VOS3000 uses the source socket address instead — which can be more reliable in NAT scenarios. This is especially important when combined with SS_SIP_ROUTING_GATEWAY_INVITE_USE_CONTACT. 📡
👤 Peer Number Information: Caller Selection Mode
📋 The Peer number information setting in the Routing Gateway SIP configuration determines how VOS3000 selects the caller number from incoming SIP signals. This works in conjunction with the Contact and request-line settings to ensure proper number identification for both caller and callee. 🎯
🗺️ Mapping Gateway SIP Settings: Callee and Caller Field Selection
🔄 While the Routing Gateway settings control how VOS3000 sends INVITE messages, the Mapping Gateway settings control how VOS3000 receives and interprets incoming SIP signals. These are configured at Mapping Gateway → Additional settings → Protocol → SIP. 📡
📞 Callee Number Field Selection
🎯 The Mapping Gateway provides a setting to determine which SIP field VOS3000 uses to extract the callee number from incoming INVITE messages. This is the inbound counterpart to SS_SIP_ROUTING_GATEWAY_INVITE_USE_CONTACT: 📋
Callee Source Field
Description
When to Use
📩 To
Extract callee number from the SIP To header
✅ Default — standard SIP behavior, use when gateways follow RFC 3261
📨 Request-Line
Extract callee number from the SIP Request-Line
⚠️ Use when upstream gateway modifies the request-line with the routing number
💡 Critical relationship: The Mapping Gateway callee setting (To vs Request-Line) is the receiving side of the same concept that SS_SIP_ROUTING_GATEWAY_INVITE_USE_CONTACT handles on the sending side. If an upstream system sends INVITE messages where the request-line contains the routing number (different from the To header), you must configure the Mapping Gateway to extract the callee from the Request-Line. Similarly, if your downstream gateway expects the callee in the request-line, enable SS_SIP_ROUTING_GATEWAY_INVITE_USE_CONTACT. 🔄
📞 Caller Number Field Selection
👤 The Mapping Gateway also provides settings for extracting the caller number from incoming SIP signals: 📋
Caller Source Field
Description
When to Use
📩 From
Extract caller number from the SIP From header
✅ Default — standard SIP behavior
🆔 Remote-Party-ID
Extract caller number from the Remote-Party-ID header
⚠️ Use when upstream gateway sends caller ID in RPID header
🖥️ Display
Extract caller number from the Display name portion of the From header
⚠️ Use when caller ID is in the display name, not the URI
📞 Practical tip: When connecting to carrier gateways that manipulate caller ID through P-Asserted-Identity or Remote-Party-ID headers, configure the Mapping Gateway caller field accordingly. For more on caller ID management, see our VOS3000 callee rewrite rule and prefix conversion guide. 🔧
🔄 VOS3000 SIP Routing Gateway Contact: Complete Signal Flow
📊 To fully understand how SS_SIP_ROUTING_GATEWAY_INVITE_USE_CONTACT interacts with per-gateway settings, here is a complete signal flow diagram: 📡
🎯 Key takeaway: The Mapping Gateway settings control what VOS3000 reads from incoming INVITE messages, while SS_SIP_ROUTING_GATEWAY_INVITE_USE_CONTACT and the per-gateway Reply/Request address settings control what VOS3000 writes into outgoing INVITE messages. For a comprehensive understanding of SIP session management, see our VOS3000 SIP session guide. 📖
📞 Callee: To / Request-Line — determines which field VOS3000 reads for the callee number
👤 Caller: From / Remote-Party-ID / Display — determines which field VOS3000 reads for the caller number
💾 Save mapping gateway settings
Step 4: Verify with SIP Debug 🔍
📝 After configuration, verify the Contact header behavior by monitoring the SIP INVITE flow. Use the SIP debug tools to confirm that the request-line and To header are populated correctly. For comprehensive debugging techniques, see our VOS3000 SIP debug guide. 🔧
📊 VOS3000 SIP Routing Gateway Contact: When to Enable vs. Disable
🎯 The decision to enable or disable SS_SIP_ROUTING_GATEWAY_INVITE_USE_CONTACT depends on your specific gateway interoperability requirements. Here is a detailed comparison: 💡
Aspect
Off (Default)
On
📌 Callee Number Source
To header
Request-Line
🔄 To Field Content
Same as request-line callee
Original number (preserved)
📞 Request-Line
Matches To header
Contains routing number
🛡️ RFC 3261 Compliance
✅ Full compliance
⚠️ Modified behavior
🔧 Best For
Standard SIP gateways, carriers that follow RFC 3261
Gateways that read callee from request-line, prefix conversion scenarios
📊 Billing Impact
CDR shows final routing number
CDR can preserve original dialed number
🔗 Compatibility
Broad — works with most gateways
Specific — needed for certain gateway types
💡 Decision rule: Keep the default Off unless you encounter a specific gateway that routes based on the request-line callee number instead of the To header. Most modern SIP gateways follow RFC 3261 and use the To header. However, some legacy systems or carrier equipment may depend on the request-line — in those cases, enable the parameter to On. For help identifying which mode your gateway requires, contact us on WhatsApp at +8801911119966. 📞
🎯 Different gateway types require different configurations for the VOS3000 SIP routing gateway contact settings. Here are recommended configurations based on common deployment scenarios: 💡
Gateway Type
SS_SIP_ROUTING_GATEWAY_INVITE_USE_CONTACT
Callee Field (Mapping)
Reply / Request Address
🏢 Standard SIP carrier
Off (default)
To
Socket / Socket
🔄 Legacy gateway (request-line routing)
On
Request-Line
Socket / Socket
📞 PSTN gateway (prefix conversion)
On
Request-Line
Socket / Contact
📡 NAT-traversed gateway
Off (default)
To
Socket / Socket
🌐 Wholesale carrier (multiple prefixes)
On
Request-Line
Socket / Contact
💡 Key pattern: Enable SS_SIP_ROUTING_GATEWAY_INVITE_USE_CONTACT (On) when your gateway performs prefix conversion and you need the original number preserved in the To field while the routing number goes in the request-line. For more on prefix conversion, see our VOS3000 routing optimization guide. 🔧
🛡️ Common VOS3000 SIP Routing Gateway Contact Problems and Solutions
⚠️ Misconfigured Contact header settings can cause a range of call routing issues. Here are the most common problems and their solutions:
❌ Problem 1: Calls Routed to Wrong Number After Prefix Conversion
🔍 Symptom: VOS3000 applies a prefix conversion rule, but the downstream gateway still routes the call using the original number instead of the converted number.
💡 Cause: SS_SIP_ROUTING_GATEWAY_INVITE_USE_CONTACT is set to Off, so both the request-line and To header contain the original number. The gateway reads the To header and ignores the prefix conversion.
✅ Solutions:
🔧 Enable SS_SIP_ROUTING_GATEWAY_INVITE_USE_CONTACT to On
📞 This puts the converted (routing) number in the request-line while preserving the original in the To field
📊 Verify with SIP debug that the request-line contains the correct routing number
❌ Problem 2: Gateway Rejects INVITE — 404 Not Found
🔍 Symptom: Downstream gateway returns 404 Not Found for calls that should be routable, even though the callee number exists in the gateway’s routing table.
💡 Cause: The gateway extracts the callee number from a different header than what VOS3000 is populating. For example, the gateway reads the request-line but VOS3000 is only populating the To header (parameter set to Off).
✅ Solutions:
🔧 Confirm which SIP field the downstream gateway uses for callee identification
📋 If the gateway reads the request-line, enable SS_SIP_ROUTING_GATEWAY_INVITE_USE_CONTACT
📡 Check the gateway documentation or contact the carrier for their header requirements
❌ Problem 3: CDR Shows Incorrect Original Number
🔍 Symptom: Call Detail Records show the routing number (with prefix) instead of the original dialed number, making billing reconciliation difficult.
💡 Cause: SS_SIP_ROUTING_GATEWAY_INVITE_USE_CONTACT is Off, so the To header always contains the same number as the request-line — no original number is preserved.
✅ Solutions:
🔄 Enable SS_SIP_ROUTING_GATEWAY_INVITE_USE_CONTACT to On — this preserves the original number in the To field
📊 CDR systems can then read the original number from the To field for billing accuracy
❌ Problem 4: One-Way Audio After Enabling Contact Header Routing
🔍 Symptom: After enabling SS_SIP_ROUTING_GATEWAY_INVITE_USE_CONTACT, calls connect but audio only flows in one direction.
💡 Cause: The Request address setting is configured to use Contact or Contact Port, and the Contact header in the gateway’s 200 OK response points to an incorrect or unreachable address.
✅ Solutions:
🔧 Change the Request address to Socket — this ensures subsequent requests go to the actual source IP:port
📡 Verify the Contact header in the gateway’s responses using SIP debug
🛠️ If the gateway is behind NAT, Socket-based routing is more reliable than Contact-based routing
Configure Routing Gateway Request address (Socket recommended for NAT)
☐
📌 5
Configure Mapping Gateway Callee field (To or Request-Line)
☐
📌 6
Configure Mapping Gateway Caller field (From, Remote-Party-ID, or Display)
☐
📌 7
Test with SIP debug — verify INVITE header fields match expected values
☐
📌 8
Verify CDR records show correct callee number for billing
☐
📞 Need help configuring your gateway Contact header settings? Contact our VOS3000 experts on WhatsApp at +8801911119966 for personalized assistance. 🔧
❓ Frequently Asked Questions
❓ What is SS_SIP_ROUTING_GATEWAY_INVITE_USE_CONTACT in VOS3000?
📋 SS_SIP_ROUTING_GATEWAY_INVITE_USE_CONTACT is a VOS3000 SIP parameter that controls how the callee number is placed in outbound INVITE messages to routing gateways. When set to Off (default), VOS3000 follows standard SIP behavior where the To header and request-line contain the same callee number. When set to On, VOS3000 uses the number from the request-line as the callee for routing and keeps the original number in the To field. This is essential for gateways that read the callee from the request-line rather than the To header. 🔧
❓ When should I enable VOS3000 SIP routing gateway contact?
🔄 Enable SS_SIP_ROUTING_GATEWAY_INVITE_USE_CONTACT (On) when your downstream routing gateway extracts the callee number from the SIP request-line instead of the To header. This is common with legacy PSTN gateways, gateways that perform number manipulation, and carrier equipment that routes based on the INVITE request-line. You should also enable it when you apply prefix conversion rules and need the original dialed number preserved in the To field for billing and CDR accuracy. 📡
❓ What is the difference between the Routing Gateway Contact setting and the Mapping Gateway Callee field?
📊 These settings control opposite directions of SIP signaling. SS_SIP_ROUTING_GATEWAY_INVITE_USE_CONTACT (Routing Gateway) controls what VOS3000 writes into outbound INVITE messages — it determines whether the callee comes from the request-line and whether the To field preserves the original number. The Mapping Gateway Callee field (To / Request-Line) controls what VOS3000 reads from inbound INVITE messages — it determines which SIP field VOS3000 uses to extract the callee number from incoming calls. They work together to ensure proper number handling in both directions. 🔄
❓ What does the Reply address Socket setting do in VOS3000?
📬 The Reply address setting in the Routing Gateway SIP configuration determines where VOS3000 sends SIP response messages (such as 200 OK, 180 Ringing, 403 Forbidden) after receiving a request from the gateway. When set to Socket (recommended), VOS3000 sends replies to the source IP address and port of the incoming SIP request. When set to Via, it uses the address in the Via header. When set to Via port, it uses the port from the Via header. The Socket option is most reliable for NAT traversal scenarios. 🛡️
❓ How does the Request address setting relate to the Contact header?
📤 The Request address setting controls where VOS3000 sends in-dialog SIP requests (like re-INVITE or BYE) after call establishment. When set to Contact, VOS3000 sends requests to the full URI in the Contact header of the gateway’s response. When set to Contact Port, it uses only the port from the Contact header. When set to Socket (recommended), it sends to the source IP:port of the received signal. This is closely related to the VOS3000 SIP routing gateway contact behavior because it determines how the Contact header is used for subsequent signaling. 🔧
❓ Can I configure SS_SIP_ROUTING_GATEWAY_INVITE_USE_CONTACT per gateway?
⚙️ The SS_SIP_ROUTING_GATEWAY_INVITE_USE_CONTACT parameter is a global SIP parameter configured at the system level under Operation management → Softswitch management → Additional settings → SIP parameter. However, the related per-gateway settings (Reply address, Request address, Peer number information for Routing Gateways; Callee and Caller field selection for Mapping Gateways) are configured at the individual gateway level. This means the base Contact header behavior is global, but the specific address routing and field selection can be customized per gateway. For system-level parameter documentation, see VOS3000 system parameters. 📖
❓ What happens to the To field when VOS3000 SIP routing gateway contact is enabled?
📞 When SS_SIP_ROUTING_GATEWAY_INVITE_USE_CONTACT is set to On, VOS3000 preserves the original callee number in the To field of the outbound INVITE. The request-line contains the number that VOS3000 uses for actual routing (which may include prefix modifications or routing transformations), while the To field retains the original dialed number before any manipulation. This dual-number approach ensures that downstream gateways can route using the request-line number while billing and CDR systems can reference the original number from the To field. 🎯
📚 Related Resources – VOS3000 SIP Routing Gateway
🔗 Explore these related VOS3000 guides for deeper understanding:
📞 Nothing kills call completion rates faster than an incorrectly configured VOS3000 SIP INVITE timeout — and nothing disrupts active calls more than misconfigured gateway switching behavior. When your softswitch sends an INVITE and the far end never responds, how long should it wait? What happens when a gateway responds with SDP — should VOS3000 commit to that gateway or keep trying alternatives? These decisions, controlled by SS_SIP_TIMEOUT_INVITE, SS_SIP_STOP_SWITCH_AFTER_SDP, and SS_SIP_USER_AGENT_STOP_SWITCH_AFTER_INVITE_TIMEOUT, directly impact your ASR, call reliability, and caller experience. ⏱️
⚙️ Set the INVITE timeout too short, and legitimate calls get abandoned before the gateway can answer. Set it too long, and failed calls consume precious port capacity. Enable gateway switching after SDP, and you risk disrupting early media. Disable switching after INVITE timeout, and backup routes never get tried. Understanding how these three parameters work together is what separates a basic VOS3000 deployment from a professionally tuned one. 🔧
🎯 This guide covers every aspect of the VOS3000 SIP INVITE timeout, gateway switching decisions, and stop switch behavior: the global parameters, per-gateway overrides, related system parameters like SS_GATEWAY_SWITCH_LIMIT and SS_GATEWAY_SWITCH_STOP_AFTER_RTP_START, and best practices for configuring gateway failover in production environments. All data is sourced exclusively from the official VOS3000 V2.1.9.07 Manual, Section 4.3.5.2 (Tables 4-3 and 4-4). For expert assistance, contact us on WhatsApp at +8801911119966. 💡
Table of Contents
🔐 What Is VOS3000 SIP INVITE Timeout?
⏱️ The VOS3000 SIP INVITE timeout defines the maximum number of seconds the softswitch will wait for a response after sending a SIP INVITE message to a gateway. If no provisional response (100 Trying, 180 Ringing, 183 Session Progress) or final response (200 OK, 4xx, 5xx, 6xx) arrives within this period, VOS3000 considers the INVITE failed and proceeds to the gateway switching decision. 📞
📋 This parameter is governed by SS_SIP_TIMEOUT_INVITE with a default value of 10 seconds:
Attribute
Value
📌 Parameter Name
SS_SIP_TIMEOUT_INVITE
🔢 Default Value
10
📐 Unit
Seconds
📝 Description
SIP INVITE timeout. Default value in “Routing Gateway > Additional settings > Protocol > SIP”
💡 How the 10-second default works: When VOS3000 sends an INVITE to a gateway, it starts a countdown timer. During this period, SIP retransmissions occur based on SS_SIP_RESEND_INTERVAL (default: 0.5,1,2,4,4,4,4,4,4,4). If no response arrives within 10 seconds total, VOS3000 stops retransmitting, marks the INVITE as failed, and proceeds based on your gateway switching configuration.
📋 VOS3000 SIP INVITE Timeout vs Other SIP Timers
🌐 The VOS3000 SIP INVITE timeout is just one of several SIP timers that govern call setup. Understanding the differences is essential:
Timer
Parameter
Default
Controls
📞 INVITE Timeout
SS_SIP_TIMEOUT_INVITE
10 seconds
Total wait for any INVITE response
⏳ Trying Timeout
SS_SIP_TIMEOUT_TRYING
20 seconds
Wait for progress after 100 Trying
🔔 Ringing Timeout
SS_SIP_TIMEOUT_RINGING
120 seconds
Wait for answer while ringing
📡 Session Progress
SS_SIP_TIMEOUT_SESSION_PROGRESS
20 seconds
Wait after 183 Session Progress
🔑 Key distinction: The VOS3000 SIP INVITE timeout is the overall timer for the INVITE transaction. The Trying, Ringing, and Session Progress timers only activate after specific provisional responses are received. If no response comes at all, only the INVITE timeout applies.
🔄 Gateway Switching Decision Points
🌐 VOS3000 makes gateway switching decisions at multiple points during call setup. Understanding these decision points is critical for configuring reliable failover. The two most important are controlled by the VOS3000 SIP INVITE timeout parameters: 📡
🔑 Key insight: These parameters work together as a layered decision system. The VOS3000 SIP INVITE timeout parameters (stop switch after SDP and stop switch after INVITE timeout) are the two most important because they control the two most common switching decisions: committing after media negotiation begins, and failing over after a gateway is unresponsive.
🛑 SS_SIP_STOP_SWITCH_AFTER_SDP — Stop Switch After SDP
📞 The SS_SIP_STOP_SWITCH_AFTER_SDP parameter controls whether VOS3000 stops trying alternative gateways once it receives SDP (Session Description Protocol) in a provisional response from the current gateway. When this parameter is On (default), VOS3000 commits to the current gateway as soon as SDP arrives — preventing mid-setup failover that would disrupt early media and call progress. 🛡️
💡 Why SDP matters in gateway switching: In the SIP call flow, SDP carries the media negotiation details — codecs, IP addresses, and port numbers. When a gateway sends SDP in a 183 Session Progress response, it means the gateway has allocated media resources, early media may already be playing, the media session is partially established, and switching to another gateway at this point causes audio disruption and potential double-answer scenarios.
Setting
Gateway Switching Behavior
Call Impact
When to Use
✅ On (default)
Stops switching after SDP — commits to current gateway
🛡️ Prevents audio disruption, no double-answer, stable media path
📞 Nearly all deployments — recommended default
❌ Off
Continues switching even after SDP — may try other gateways
⚠️ Audio disruption risk, potential double-answer, unstable media
🔬 Only for special testing or specific carrier requirements
🚨 Warning: Setting SS_SIP_STOP_SWITCH_AFTER_SDP to Off is rarely appropriate. When a gateway has already sent SDP and you switch to another gateway, the original gateway may continue playing audio or billing for the session while the new gateway also attempts call setup. This creates chaotic call states. ⚡
🔄 The companion parameter to stop switch after SDP is SS_SIP_USER_AGENT_STOP_SWITCH_AFTER_INVITE_TIMEOUT. While the SDP parameter controls switching after media negotiation begins, this parameter controls switching after an INVITE times out with no response at all. ⏳
🔑 Why the default is Off: When a gateway does not respond to an INVITE within the timeout period (defined by SS_SIP_TIMEOUT_INVITE), the most common cause is a network or gateway failure. In this scenario, you want VOS3000 to try the next available gateway — not give up. Setting this parameter to Off (default) ensures that backup routes are attempted, maximizing call completion rates. 📈
Setting
INVITE Timeout Behavior
Impact on Call
❌ Off (default)
VOS3000 continues gateway switching to the next available gateway
VOS3000 stops switching — call fails immediately after INVITE timeout
⚠️ No failover — caller gets failure tone right away
💡 When to set On: The only scenario where setting this to On makes sense is for compliance or regulatory routing where calls must use a specific carrier and failover to alternatives is not permitted. 🏛️
📊 Complete Gateway Switching Flow
🔄 Understanding how the VOS3000 SIP INVITE timeout interacts with gateway switching requires seeing the complete flow. Here is the full decision tree: 🌳
📞 VOS3000 INVITE Timeout & Gateway Switching Flow:
VOS3000 ──► INVITE ──► Gateway A (Primary)
│ │
│ ⏱️ INVITE Timeout countdown starts
│ 📡 Retransmissions per SS_SIP_RESEND_INTERVAL
│ │
│ ┌── T = INVITE Timeout ──┐
│ │ No response received │
│ └────────────────────────┘
│ │
├── ❌ Gateway A INVITE failed
│
├── Check: Stop switch after INVITE timeout?
│ │
│ ├── OFF (default) ✅
│ │ └──► Try next gateway in route
│ │ VOS3000 ──► INVITE ──► Gateway B (Backup)
│ │ │
│ │ (new INVITE timeout starts)
│ │
│ └── ON ⚠️
│ └──► Stop switching
│ Return error to caller (SIP 408 / 503)
│
┌── OR Gateway A responds ─────────────────┐
│ │
│ ├── 100 Trying / 180 Ringing (no SDP) │
│ │ └──► Continue waiting │
│ │ (may still switch) │
│ │ │
│ ├── 183 Session Progress + SDP │
│ │ ├── Stop switch after SDP = │
│ │ │ ON (default) ✅ │
│ │ │ └──► Commit to Gateway A │
│ │ │ No more switching │
│ │ │ │
│ │ └── Stop switch after SDP = │
│ │ OFF ⚠️ │
│ │ └──► May switch to Gateway B │
│ │ (risk of disruption!) │
│ │ │
│ ├── SIP Error Code (4xx/5xx/6xx) │
│ │ └──► May try next gateway │
│ │ │
│ └── 200 OK (Answer) │
│ └──► Call established │
│ No switching │
│ │
└── 📝 CDR recorded with switching details │
🛡️ Related System Parameters for Gateway Switching
📋 The VOS3000 SIP INVITE timeout and stop switch parameters do not work in isolation. Several system-level parameters from Table 4-4 of the official VOS3000 2.1.9.07 manual control the broader gateway switching behavior: 🔧
Parameter
Default
Description
📌 SS_GATEWAY_SWITCH_LIMIT
None
Times limit for Routing Gateway Auto-Switch — maximum number of gateways VOS3000 will try
📡 SS_GATEWAY_SWITCH_STOP_AFTER_RTP_START
On
Stop Switch Gateway when RTP Start — prevents switching once media flows
📞 SS_GATEWAY_SWITCH_STOP_AFTER_USER_BUSY
On
Callee busy stop switch — stops trying other gateways when 486 Busy received
🔗 SS_GATEWAY_SWITCH_UNTIL_CONNECT
Off
Switch Gateway Until Connect — when On, continues switching until 200 OK received
🔑 Key takeaway: The default VOS3000 configuration creates a logical switching strategy — try alternative gateways when the primary is unresponsive (INVITE timeout), but stop switching once the call progresses to the point where switching would cause disruption (SDP received, RTP started, callee busy). This is the correct behavior for virtually all VoIP deployments. ✅
🖥️ Per-Gateway INVITE Timeout and Stop Switch Settings
🎯 Not all gateways are created equal. VOS3000 provides per-gateway overrides for both INVITE timeout and stop switch behavior. 📡
Control failover behavior after INVITE timeout expires
🎯 Recommended INVITE Timeout by Gateway Type
Gateway Type
Recommended INVITE Timeout
Rationale
🏢 Local LAN gateway
5–8 seconds
✅ Fast response expected; shorter timeout frees resources quickly
🌐 Standard WAN gateway
10 seconds (default)
🔧 Proven balance for typical VoIP networks
📡 High-latency / satellite
15–20 seconds
⏱️ Accounts for propagation delay and slow gateway response
🛡️ Premium carrier gateway
8–10 seconds
📞 Reliable carriers respond quickly; faster failover on failure
⚠️ Intermittent gateway
5–7 seconds
🔄 Quick failover to backup route; minimize dead air time
🚫 Stop Switching Response Code — Per-Code Control
📋 Beyond the global stop switch parameters, VOS3000 offers a more granular control: the “Stop switching response code” per-gateway setting. This lets you specify a particular SIP response code that triggers stop-switch behavior. 🎯
⏱️ The default VOS3000 SIP INVITE timeout is 10 seconds, configured via SS_SIP_TIMEOUT_INVITE. VOS3000 will wait up to 10 seconds for any response before considering the attempt failed. The default can be overridden per gateway in Routing Gateway > Additional settings > Protocol > SIP.
❓ What does SS_SIP_STOP_SWITCH_AFTER_SDP do?
🛑 When On (default), VOS3000 stops trying alternative gateways once it receives SDP in a provisional response (like 183 Session Progress with SDP). This prevents mid-call audio disruption, double-answer scenarios, and media path instability. When Off, VOS3000 may switch gateways even after media negotiation has begun — which is almost never desirable. Keep this On. 🔧
❓ Should I enable stop switch after INVITE timeout?
🔄 No — keep it Off (default) for most deployments. When a gateway does not respond to an INVITE, you want VOS3000 to try the next available gateway (failover). Setting it to On means VOS3000 stops switching and the call fails immediately. The only exception is compliance routing where failover to a different carrier is not permitted. 🏛️
❓ How do I prevent infinite gateway switching loops?
🔢 Set SS_GATEWAY_SWITCH_LIMIT to a reasonable value (3–5 gateway attempts). This prevents VOS3000 from endlessly cycling through gateways when all are failing. Also keep SS_GATEWAY_SWITCH_UNTIL_CONNECT Off (default) and ensure SS_SIP_STOP_SWITCH_AFTER_SDP is On (default). 🛡️
📞 Need Expert Help?
🔧 Proper VOS3000 SIP INVITE timeout and gateway switching configuration is essential for maximizing call completion rates, enabling fast gateway failover, and delivering a quality caller experience. Whether you need help with timeout tuning, stop switch configuration, or troubleshooting failover issues, our team is ready to assist. 🛡️
