A SIP inbound call is a phone call that arrives at your SIP server or PBX from an external source through a SIP trunk, beginning with a SIP INVITE message that carries headers identifying the caller, the destination, and the media capabilities being negotiated. The server processes that INVITE, authenticates the source, matches it against routing and dispatch rules, and either forwards it to an internal extension, a queue, or a WebRTC-based room through platforms like VideoSDK. Proper configuration of inbound call handling determines whether calls connect reliably or fail silently at the gateway.
Contact centers, VoIP service providers, and any platform that bridges traditional telephony with modern web applications depend on reliable SIP inbound call processing. A misconfigured trunk, a missing authentication header, or a routing rule that matches the wrong destination can drop thousands of calls per day without a single error message visible to the end user. Developers building telephony infrastructure need to understand the full INVITE lifecycle, how to configure inbound treatment on their SIP platform, and how to debug failures when calls do not arrive where expected.
This guide walks through the SIP inbound call flow from INVITE to ACK, covers configuration options across popular SIP platforms, explains routing and dispatch rule logic, addresses authentication and security, and provides a troubleshooting playbook for the most common failure modes.

Understanding SIP Inbound Call Flow

Every SIP inbound call begins with a SIP INVITE message sent from the calling party's SIP user agent or gateway to your SIP server or PBX. The INVITE carries critical information in its headers that your server uses to identify, authenticate, and route the call. Understanding this lifecycle is the foundation for every configuration and troubleshooting decision that follows.
The SIP INVITE lifecycle for an inbound call follows a deterministic sequence defined by RFC 3261. When the INVITE arrives, the receiving server immediately responds with a 100 Trying message to acknowledge receipt and stop the caller from retransmitting. The server then evaluates routing rules, checks authentication, and determines where to send the call. If the destination is available, the server responds with 180 Ringing to indicate that the called party is being alerted. When the called party answers, a 200 OK message travels back to the caller, who finalizes the session with an ACK. At that point, media flows bidirectionally using RTP or SRTP.
Four SIP headers do the heavy lifting for inbound call identification. The From header identifies the caller, typically carrying their SIP URI or phone number. The To header identifies the intended recipient, which your server uses to match against DIDs or extension numbers. The Contact header provides the direct address where the caller wants to receive subsequent requests for this dialog. The Via header records the transport path, and your server uses it to route responses back along the correct path. Mismatches in any of these headers are a leading cause of inbound call failures.
For developers integrating SIP with modern WebRTC applications, platforms like VideoSDK extend this flow by bridging the inbound SIP call into a WebRTC room. The SIP gateway receives the INVITE, processes it through the standard lifecycle, and then connects the audio stream to a VideoSDK room participant, allowing phone callers to interact with web-based users or AI voice agents seamlessly.

Configuring SIP Inbound Call Settings

SIP inbound call configuration is where most routing failures originate, and getting these settings right requires understanding what your platform exposes and what each option controls. The configuration options you choose determine how your server classifies incoming calls, which domains it trusts, and whether it enforces strict inbound treatment rules.
Most enterprise SIP platforms expose several server-side options that control inbound call behavior. One common option, often called enforce-1pcc-inbound, forces all incoming calls to be treated as external inbound calls regardless of their source IP or header content. This is useful when you want a single, consistent processing path for every call that arrives from a SIP trunk. Another option, internal-call-domains, lets you define a list of SIP domains that your server should treat as internal, meaning calls from those domains bypass external inbound treatment. A third option, enforce-external-domains, takes the opposite approach by specifying which domains must always be treated as external sources.
On platforms like Genesys, inbound call treatment is configured through trunk-level settings where you define the inbound classification mode and associate DIDs with specific routing destinations. On 3CX, you configure inbound calls by creating inbound rules on your SIP trunk that match incoming numbers and route them to extensions, ring groups, or digital receptionists. On LiveKit, SIP inbound calls are handled through a telephony integration that bridges incoming SIP INVITEs into LiveKit rooms, similar to how VideoSDK telephony integration routes phone calls into WebRTC-based rooms.
Architecture Diagram
The decision tree above illustrates how these configuration options interact. The key insight is that the order of evaluation matters. Most platforms check IP-based allow lists first, then domain classification, then enforcement rules. If you enable enforce-1pcc-inbound without also updating your internal-call-domains list, legitimate internal calls may suddenly be classified as external, triggering unexpected authentication challenges or routing through the wrong dispatch path.

Inbound Call Routing and Dispatch Rules

Routing is the brain of SIP inbound call handling, and dispatch rules are the logic that determines where each call lands. Once your server has classified a call as inbound and authenticated it, the routing engine takes over to match the call against your configured rules and deliver it to the right destination.
Matching an incoming INVITE to a SIP trunk or DID works through a combination of source identification criteria. The most common criteria include the rinstance parameter, which some carriers include to identify a specific trunk instance. The Auth ID, which is the authentication username associated with the trunk. And the CalledNum, which is the destination phone number extracted from the To header or the Request-URI. Your routing engine evaluates these criteria in the order you define, and the first match wins. This means the sequence of your dispatch rules directly affects which rule handles each call.
Setting up dispatch rules involves defining a matching condition and a destination for each rule. A typical rule might say: if the CalledNum matches a specific DID, route the call to a particular extension. Another rule might route calls from a specific Auth ID to a hunt group or call queue. More advanced setups use time-based routing to send calls to different destinations based on business hours, or skill-based routing to distribute calls across agents with specific competencies.
For developers building with VideoSDK, dispatch rules can route inbound SIP calls directly into VideoSDK rooms where they become participants in a real-time communication session. This enables scenarios like AI voice agents that answer phone calls, telehealth intake lines that connect callers to video consultations, and customer support queues that bridge phone callers with web-based agents. The dispatch rule in this case matches the inbound DID and routes the call to a VideoSDK room ID, where the telephony gateway handles the SIP-to-WebRTC media transcoding.
A practical recommendation is to start with simple DID-based routing rules and add complexity only as your routing requirements grow. Over-engineering dispatch rules with too many matching criteria creates a configuration that is difficult to debug when calls start landing at the wrong destination.

Authentication and Security for Inbound Calls

Securing SIP inbound calls is non-negotiable for any production telephony deployment, and the authentication method you choose affects both security posture and call completion rates. Without proper authentication, your SIP server becomes an open relay that attackers can exploit for toll fraud, and without media encryption, call content is vulnerable to interception.
Two primary authentication methods dominate SIP inbound call handling. Digest authentication challenges the incoming INVITE with a 401 Unauthorized or 407 Proxy Authentication Required response, prompting the caller's user agent to resend the INVITE with an Authorization header containing a cryptographic hash of the credentials. This method is secure but adds a round trip to every inbound call, slightly increasing setup time. IP-based allow lists skip the authentication challenge entirely for calls arriving from trusted IP addresses, which is faster but requires you to maintain an accurate list of your carrier's signaling IPs. Most production deployments use a combination: IP-based allow lists for known carrier trunks and digest authentication for everything else.
For media protection, TLS secures the SIP signaling layer, encrypting the INVITE and all subsequent messages so that headers and authentication credentials cannot be intercepted. SRTP secures the media layer, encrypting the RTP packets that carry the actual voice audio. Using both together provides end-to-end protection for the call. VideoSDK's telephony integration supports secure SIP with TLS and SRTP, ensuring that inbound calls bridged into WebRTC rooms maintain encryption across the full path.
Common authentication pitfalls include mismatched usernames between the trunk configuration and the SIP server, missing Authorization headers when digest authentication is required, and incorrect realm values that cause the hash calculation to fail. Another frequent issue is clock skew between the SIP server and the caller's user agent, which can cause nonce values to be rejected as expired. Always verify that your server's clock is synchronized using NTP and that your carrier's authentication credentials match exactly.

Common Issues and Troubleshooting SIP Inbound Calls

When SIP inbound calls fail, the symptoms range from complete silence to cryptic SIP response codes, and a systematic debugging approach is the fastest path to resolution. Most inbound call failures fall into three categories: routing mismatches, authentication failures, and classification errors.
Call rejected due to routing mismatch is the most common failure mode. The INVITE arrives at your server, but no dispatch rule matches the CalledNum or Auth ID, so the server returns a 404 Not Found response. To diagnose this, capture a SIP trace of the incoming INVITE and verify that the Request-URI and To header contain the number you expect. Compare those values against your dispatch rule matching criteria. A frequent cause is a format mismatch: your carrier may send the number in E.164 format with a plus sign, while your routing rules expect a bare national number.
Unexpected internal call classification happens when a call that should be treated as external inbound gets classified as internal, or vice versa. This typically occurs when the internal-call-domains list contains a domain that your carrier also uses, or when enforce-1pcc-inbound is not enabled and the From header domain matches an internal domain by coincidence. The symptom is that the call bypasses inbound authentication or gets routed through the wrong dispatch path. Check your SIP trace for the From header domain and compare it against your internal-call-domains configuration.
Debugging with SIP trace logs is the single most valuable troubleshooting technique. Look for Via header mismatches, which occur when the top Via header does not match the source IP of the incoming packet, often indicating a NAT traversal issue or a misconfigured proxy. SIP 403 Forbidden responses indicate authentication failures, while 404 Not Found responses indicate routing failures. 488 Not Acceptable Here responses indicate media negotiation failures, where the offered codecs in the SDP body do not intersect with your server's supported codecs.
Here is a troubleshooting checklist to resolve typical SIP inbound call failures:
  • Capture a full SIP trace of the failed call, including the INVITE and all responses
  • Verify the Request-URI and To header match your dispatch rule criteria exactly
  • Check whether the From header domain triggers unexpected internal classification
  • Confirm that the Authorization header is present if digest authentication is required
  • Validate that the source IP is in your allow list if using IP-based authentication
  • Inspect the SDP body for codec compatibility between caller and server
  • Check server logs for any policy-based rejection messages
  • Verify NTP synchronization to rule out nonce expiry issues
  • Test with a softphone using the same trunk credentials to isolate carrier-side issues
  • Review recent configuration changes that may have altered routing or classification rules

Best Practices for Reliable SIP Inbound Calls

Reliable SIP inbound call handling is not a one-time configuration task but an ongoing operational discipline that requires regular review and monitoring. Following established best practices reduces failure rates and makes troubleshooting faster when issues do arise.
A gradual migration approach works best when tightening inbound call classification. Start by enabling enforce-external-domains to explicitly mark known external domains, then monitor call flows for any unexpected behavior. Once you are confident that your domain classification is accurate, enable enforce-1pcc-inbound to force all remaining calls through the external inbound path. This phased approach avoids the sudden classification changes that occur when you flip enforcement settings all at once.
Keep your internal-call-domains list up to date as your infrastructure evolves. Every time you add a new internal SIP domain, remove a decommissioned server, or change your carrier's signaling domain, update the list. Stale entries cause classification errors that are difficult to trace because the call appears to route correctly but bypasses intended security or routing policies.
Monitor call metrics continuously and set alerts for high failure rates. Track the ratio of 4xx responses to total inbound INVITEs, the average call setup time, and the number of calls failing authentication. A sudden spike in 403 or 404 responses often indicates a carrier-side configuration change or an expired credential. VideoSDK's REST APIs provide session analytics that can complement your SIP server logs with WebRTC-side metrics for calls bridged into VideoSDK rooms.

Quick Reference Summary

Here is a condensed reference for SIP inbound call configuration, routing, and troubleshooting:
  • Configuration steps: Define internal-call-domains for trusted internal sources, enable enforce-external-domains for known external domains, then enable enforce-1pcc-inbound for strict inbound treatment
  • Routing setup: Create dispatch rules that match CalledNum or Auth ID, ordered from most specific to most general, with the first match winning
  • Authentication: Use IP-based allow lists for known carrier trunks, digest authentication for all other sources, and TLS with SRTP for signaling and media encryption
  • Troubleshooting checklist: Capture SIP trace, verify Request-URI against dispatch rules, check From header domain classification, confirm Authorization header presence, inspect SDP codec compatibility, review server logs, validate NTP sync
  • Monitoring: Track 4xx response ratios, call setup time, and authentication failure counts with automated alerts for threshold breaches
  • VideoSDK integration: Route inbound SIP calls into VideoSDK rooms using dispatch rules that match DIDs to room IDs, enabling phone-to-WebRTC bridging for AI agents, telehealth, and support queues

Definitions Glossary

SIP INVITE: The initial SIP message sent by a calling party to initiate a session, carrying headers that identify the caller, the destination, and the media capabilities being offered.
SIP Trunk: A logical connection between a SIP server and a telephony service provider that carries inbound and outbound calls, identified by its Auth ID, source IP, and associated DIDs.
DID (Direct Inward Dialing): A phone number assigned to a SIP trunk that allows external callers to reach a specific extension or destination directly without going through a switchboard.
Dispatch Rule: A routing configuration entry that matches incoming call attributes, such as CalledNum or Auth ID, and directs the call to a specific extension, queue, or room.
Internal Call Classification: The process by which a SIP server determines whether an incoming call originates from a trusted internal domain or an external source, affecting which routing and authentication policies apply.
SDP (Session Description Protocol): The payload carried inside a SIP INVITE that describes the media capabilities of the caller, including codec preferences, port numbers, and transport protocols.

Key Takeaways

  • A SIP inbound call follows a deterministic INVITE to 100 Trying to 180 Ringing to 200 OK to ACK lifecycle, and understanding each stage is essential for configuration and debugging.
  • Configuration options like enforce-1pcc-inbound, internal-call-domains, and enforce-external-domains control how your server classifies and processes incoming calls, and their interaction order matters.
  • Dispatch rules match incoming calls to destinations using criteria like CalledNum and Auth ID, with the first matching rule winning, so rule ordering is critical.
  • Authentication through IP allow lists, digest challenges, TLS, and SRTP protects both signaling and media, and most authentication failures stem from credential mismatches or clock skew.
  • Systematic troubleshooting using SIP traces, Via header inspection, and response code analysis resolves the majority of inbound call failures quickly.
  • VideoSDK's telephony integration extends SIP inbound call handling by bridging phone calls into WebRTC rooms, enabling AI voice agents, telehealth, and customer support use cases.

Conclusion

Proper SIP inbound call handling is the backbone of any reliable telephony infrastructure, from contact center routing to AI-powered voice agents. Getting the INVITE lifecycle, configuration options, dispatch rules, and authentication right means the difference between calls connecting on the first try and silent failures that erode caller trust. The troubleshooting checklist and best practices in this guide give you a systematic framework for both building and maintaining your inbound call pipeline.
If you are bridging SIP inbound calls into modern web or AI applications, VideoSDK's telephony integration handles the SIP-to-WebRTC gateway so you can focus on your application logic. You can start with the VideoSDK free tier and route your first inbound call into a room in minutes. What are you building with SIP inbound calls? Drop a comment below, and join the VideoSDK Discord community to connect with other developers working on telephony integrations.

Free $20 Balance for AI Voice Agents & Video Calls

FAQ