📞 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. 💡
📞 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 |
| 🔀 Options | On / Off |
| 📍 Navigation | Operation management → Softswitch management → Additional settings → SIP parameter |
💡 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. 📡
⚠️ Understanding and correctly configuring this parameter is critical for several reasons:
🔄 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:8801234567@gateway.example.com SIP/2.0 ← Request-Line Via: SIP/2.0/UDP 10.0.0.1:5060 From: "Caller" <sip:8801999888@vos3000.local>;tag=abc To: <sip:8801234567@gateway.example.com> ← Callee = To header Contact: <sip:8801999888@10.0.0.1: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:8801234567@gateway.example.com SIP/2.0 ← Request-Line (used for routing) Via: SIP/2.0/UDP 10.0.0.1:5060 From: "Caller" <sip:8801999888@vos3000.local>;tag=abc To: <sip:ORIGINAL_NUMBER@gateway.example.com> ← Original number PRESERVED Contact: <sip:8801999888@10.0.0.1: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. 🎯
🔗 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. 🛠️
📬 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. 📖
📨 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. 📡
📋 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. 🎯
📞 For complete gateway configuration details, see our VOS3000 gateway configuration routing mapping guide. 🔧
🔄 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. 📡
🎯 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. 🔄
👤 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. 🔧
📊 To fully understand how SS_SIP_ROUTING_GATEWAY_INVITE_USE_CONTACT interacts with per-gateway settings, here is a complete signal flow diagram: 📡
🔄 VOS3000 SIP Routing Gateway Contact — Complete Signal Flow:
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Calling │ SIP │ VOS3000 │ SIP │ Routing │
│ Endpoint │ INVITE │ Softswitch │ INVITE │ Gateway │
└──────┬───────┘ └──────┬───────┘ └──────┬───────┘
│ │ │
│─── INVITE ────────────►│ │
│ To: 8801234567 │ │
│ From: 8801999888 │ │
│ │ │
│ 📋 Mapping Gateway: │ │
│ Callee from: To/ │ │
│ Request-Line │ │
│ Caller from: From/ │ │
│ RPID/Display │ │
│ │ │
│ │ 📤 SS_SIP_ROUTING_ │
│ │ GATEWAY_INVITE_USE_ │
│ │ CONTACT = ? │
│ │ │
│ │─── INVITE ─────────────►│
│ │ ┌──────────────────┐ │
│ │ │ OFF (default): │ │
│ │ │ Request-Line: │ │
│ │ │ 8801234567 │ │
│ │ │ To: 8801234567 │ │
│ │ └──────────────────┘ │
│ │ ┌──────────────────┐ │
│ │ │ ON: │ │
│ │ │ Request-Line: │ │
│ │ │ 8801234567 │ │
│ │ │ To: ORIGINAL │ │
│ │ │ (preserved) │ │
│ │ └──────────────────┘ │
│ │ │
│ │ 📨 Reply address: │
│ │ Socket / Via port / Via│
│ │ 📤 Request address: │
│ │ Socket / Contact Port │
│ │ / Contact │
│ │ │
│◄── 200 OK ────────────│◄── 200 OK ─────────────│
│ │ │
└────────────────────────┴─────────────────────────┘
🎯 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. 📖
🔧 Follow these steps to configure the VOS3000 SIP routing gateway contact and related settings on your system:
📝 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. 🔧
🎯 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. 📞
📊 Here is the complete reference for all per-gateway SIP settings related to the VOS3000 SIP routing gateway contact configuration: 📖
| Setting | Location | Options | Recommended |
|---|---|---|---|
| 📬 Reply address | Routing Gateway → Protocol → SIP | Socket / Via port / Via | ✅ Socket |
| 📤 Request address | Routing Gateway → Protocol → SIP | Socket / Contact Port / Contact | ✅ Socket |
| 👤 Peer number info | Routing Gateway → Protocol → SIP | Caller selection mode | Depends on gateway |
| 📞 Callee field | Mapping Gateway → Protocol → SIP | To / Request-Line | To (default) |
| 👤 Caller field | Mapping Gateway → Protocol → SIP | From / Remote-Party-ID / Display | From (default) |
🔧 For complete documentation on all SIP parameters, see our VOS3000 parameter description reference. 📖
🎯 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. 🔧
⚠️ Misconfigured Contact header settings can cause a range of call routing issues. Here are the most common problems and their solutions:
🔍 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:
🔍 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:
🔍 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:
🔍 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:
✅ Use this checklist when deploying or tuning your VOS3000 SIP routing gateway contact settings:
| Check | Action | Status |
|---|---|---|
| 📌 1 | Determine if downstream gateway reads callee from To or Request-Line | ☐ |
| 📌 2 | Set SS_SIP_ROUTING_GATEWAY_INVITE_USE_CONTACT to On if gateway uses Request-Line | ☐ |
| 📌 3 | Configure Routing Gateway Reply address (Socket recommended) | ☐ |
| 📌 4 | 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. 🔧
📋 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. 🔧
🔄 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. 📡
📊 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. 🔄
📬 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. 🛡️
📤 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. 🔧
⚙️ 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. 📖
📞 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. 🎯
🔗 Explore these related VOS3000 guides for deeper understanding:
For professional VOS3000 installations and deployment, VOS3000 Server Rental Solution:
📱 WhatsApp: +8801911119966
🌐 Website: www.vos3000.com
🌐 Blog: multahost.com/blog
📥 Downloads: VOS3000 Downloads
VOS3000 LRN number portability configuration for accurate US carrier lookup. Enable LRN query mode, handle…
VOS3000 server end reasons reference with all 25 codes. Understand call termination causes in CDRs…
VOS3000 LRN server configuration with SS_LRN_SERVER_IP and PORT parameters. Set up external LRN dip server…
VOS3000 H323 Q850 cause codes reference with 60+ ITU-T codes. Map Q.850 values to SIP…
VOS3000 SIP response codes CDR reference with 30+ codes. Understand 1xx through 6xx SIP responses…
Master VOS3000 SIP publish expire with SS_SIP_PUBLISH_EXPIRE. Configure 30-7200s timeout for gateway concurrency control, PUBLISH…