This guide walks you through verifying your Elastic SIP Trunk configuration for both outbound and inbound calls. It's designed to ensure your setup is working correctly once your Trunk and SIP Endpoints have been created in the Sinch Build Dashboard or APIs.
1. Create a SIP Trunk:
Add a SIP Trunk Domain - choose a clear, identifiable domain - must be unique may only contain letters, numbers, and hyphens ("-").
Example:my-company.pstn.sinch.com
2. Configure SIP Endpoint(s)
Each SIP Endpoint defines where Sinch will send your inbound calls (PBX, SBC, SIP server) and how your system will send calls to Sinch.
Option 1 — Static Endpoint
Name: Descriptive label (e.g., “San Diego Office PBX”)
IP Address: Your system’s public IP or DNS A-Record /FQDN
Port: Typically 5060 (UDP/TCP) or 5061 (TLS)
Transport Protocol: UDP, TCP, or TLS (recommended for encryption)
Priority: Default is 1 (lowest number = highest priority for inbound routing)
Positive Test Scenarios (Expected Results) - Non-Registered Endpoint
Test
Expected Outcome
Verification
SIP signaling sent from allowed IP address
Sinch accepts SIP traffic from the configured IP
Confirm PBX/SBC public IP matches IP in Endpoint configuration
Inbound call A-record
Call completes successfully with two-way audio
Call appears in CDRs; trunks name and IP listed correctly
Inbound call to IP-auth endpoint
Call completes successfully with two-way audio
Call appears in CDRs; trunks name and IP listed correctly
IP authentication enforced
Only approved IPs can send signaling
Attempt call from allowed IP succeeds; call from non-allowed IP is blocked
Failover routing works (if multiple endpoints configured)
Calls route to highest-priority, reachable endpoint
Disable primary device → verify call delivered to secondary endpoint
Negative Test Scenarios (Failure Conditions) - Non-Registered Endpoint
Test
Possible Cause
SIP Response / Symptom
Resolution
SIP INVITE sent from unlisted IP
IP not in ACL / static endpoint list
403 Forbidden or call rejected
Add correct public IP to Sinch endpoint or ACL configuration
Outbound call fails
Incorrect trunk domain or transport
404 Not Found / 480 Temporarily Unavailable
Confirm PBX sends INVITE to correct domain (e.g., <domain>.pstn.sinch.com)
Inbound call fails
PBX/SBC not listening on expected port
INVITE not seen; call attempt times out
Ensure PBX listens on correct IP/port (5060/5061) and firewall permits traffic
Transport mismatch
PBX sending TLS but endpoint expects UDP/TCP
No response to SIP messages
Align transport: UDP/TCP/TLS must match Sinch endpoint settings
QA Checklist for Non-Registered
✅ Inbound call received Sinch can deliver inbound calls to the PBX/SBC, and the INVITE is visible in logs.
✅ Audio is two-way Both streams negotiated correctly; no one-way/no-audio issues.
✅ IP authentication successful SIP traffic originates from the correct public IP allowed in ACL or Endpoint configuration.
✅ Endpoint remains reachable over time Inbound calls stay consistent; no intermittent SIP timeouts.
Option 2 — Registered Endpoint
A Registered Endpoint is a SIP device (PBX, SBC, softphone, gateway, etc.) that sends a SIP REGISTER request to the provider to let the network know:
Select Registered from the Add Endpoint modal
Name: Descriptive name (e.g., “Softswitch A”)
Port: Typically 5060 (UDP/TCP) or 5061 (TLS)
Transport Protocol: UDP, TCP, or TLS
When configuring a SIP Register Endpoint, you can select or create a credential that defines your SIP username and password for authentication or assign existing. Correct credential setup ensures your PBX or SIP device can register successfully and send/receive calls through your Sinch Trunk.
Authenticate properly with the Sinch SIP platform
Maintain an active registration
Receive inbound calls
Place outbound
If credentials are incorrect or missing, the endpoint will not register and calls will fail.
Positive Test Scenarios (Expected Results) - Registered Endpoints
Test
Expected Outcome
Verification
SIP device registers using the correct username/password
Registration is successful (200 OK response)
Check your PBX status → Endpoint shows as Registered
Outbound call using registered endpoint
Call completes successfully, with two-way audio
Call appears in CDRs, correct trunk/endpoint listed
Inbound call to registered endpoint
Call reaches PBX, audio clear
INVITE seen on PBX; audio confirmed
Registration refresh (periodic re-registration)
Device remains registered over time
Registration timer resets as expected
Negative Test Scenarios (Failure Conditions) - Registered Endpoints
Test
Possible Cause
SIP Response / Symptom
Resolution
Incorrect username or password
Mismatch between device and Sinch credential
401 Unauthorized
Verify credentials in PBX and Sinch Dashboard match exactly
Registration request not reaching Sinch
Firewall, NAT, or incorrect domain
No SIP response / registration timeout
Ensure correct domain (e.g., mycompany.pstn.sinch.com) and open outbound SIP ports (UDP/TCP 5060/5061)
Successful registration but outbound calls fail
Wrong SIP domain in call setup
404 Not Found or 480 Temporarily Unavailable
Confirm call is sent to the same domain used for registration
Registration succeeds but inbound calls fail
PBX not listening or RTP blocked
INVITE not seen or one-way audio
Verify PBX is bound to correct interface/port; open RTP port range (10000–20000 UDP)
Frequent registration drops
Network instability or NAT timeout
PBX logs show registration loss
Set interval or enable keep-alive messages
Multiple devices using same credential
SIP collision (one device)
Registration flaps between devices
Assign unique credentials per device to avoid overwrite
QA Checklist for Registration
✅ Registration successful (200 OK)
✅ Outbound call completes
✅ System correctly maps credential username and password
✅ Inbound call received
✅ Audio is two-way
✅ Registration remains stable over time
✅ Endpoint becomes unregistered when credentials are removed/incorrect.
3. Outbound Digest Authentication
When you configure Outbound Credentials on your SIP Trunk, Sinch will challenge every outbound SIP INVITE you send with a 407 Authentication Required response. Your PBX or SIP application must resend the INVITE with the correct username and password. If ACLs are also enabled, both the IP and the credentials must be valid for the call to succeed.
Positive Test Scenarios (Expected Results) - Outbound Digest Authentication
Test
Expected Outcome
Verification
PBX sends INVITE and responds correctly to Sinch's 407 challenge
INVITE is resent with the correct Authorization header
Confirm PBX retries INVITE with username/password included
Correct outbound username/password configured
Sinch accepts the authenticated INVITE
Outbound call completes and appears in Sinch CDRs
Outbound call connects successfully
Call rings, connects, and has two-way audio
Verify audio path in both directions
Multiple outbound calls placed
Authentication remains stable over time
No repeated 407 loops or intermittent failures
Credentials remain consistent across calls
Calls complete without authentication drops
Review PBX logs and CDRs for successful authentication
Negative Test Scenarios (Failure Conditions) - Outbound Digest Authentication
Test
Possible Cause
SIP Response / Symptom
Resolution
Incorrect outbound username or password
Credential mismatch between PBX and Sinch
403 Forbidden or repeated 407 challenges
Verify outbound credentials match exactly in PBX and Sinch Dashboard
PBX does not resend INVITE after 407 challenge
PBX not configured for Digest/Proxy Authentication
INVITE → 407 → no follow-up INVITE
Enable Digest Authentication or Outbound Proxy Authentication in PBX settings
PBX sends malformed or incomplete Authorization header
SIP client failing to include required fields
Repeated 407 or immediate reject
Review PBX SIP logs and correct credential formatting
Stale or cached credentials used
PBX retains outdated Authorization headers after password change
Intermittent 407 loops
Clear cached credentials or restart PBX/SBC
Outbound credentials correct but domain incorrect
INVITE sent to wrong Sinch trunk domain
404 Not Found or 480 Temporarily Unavailable
Ensure INVITE is sent to the correct trunk domain (e.g., <domain>.pstn.sinch.com)
QA Checklist for Outbound Credential Validation
✅ PBX receives and responds to Sinch's 407 Authentication Required
✅ INVITE resent with valid Authorization header
✅ Outbound username and password match Sinch Dashboard
✅ Outbound call completes successfully
✅ Audio is two-way and stable
✅ Multiple outbound calls succeed consistently
✅ CDR logs confirm successful outbound routing
✅ No repeated 407 or 403 failures
4. Inbound Digest Authentication
When inbound credentials are configured on your SIP Endpoint, Sinch will authenticate to your PBX/SBC when delivering inbound calls. If your PBX challenges the call with 401/407, Sinch will resend the INVITE using the username and password you configured.
Positive Test Scenarios (Expected Results) - Inbound Digest Authentication
Test
Expected Outcome
Verification
PBX challenges inbound INVITE with 407
Sinch resends INVITE with correct Authorization header
PBX logs show second INVITE including credentials
Correct inbound username/password configured
PBX accepts authenticated INVITE
Inbound call rings and connects successfully
Inbound call completes with media
Two-way audio works as expected
Confirm audio both directions
Multiple inbound calls placed
Authentication remains stable across calls
No repeated 407 loops in PBX logs
Negative Test Scenarios (Failure Conditions) - Inbound Digest Authentication
Test
Possible Cause
SIP Response / Symptom
Resolution
Incorrect inbound username or password
Credential mismatch between PBX challenge and Sinch endpoint credentials
PBX rejects INVITE / repeated 407 loops
Update endpoint credentials in Sinch Dashboard to match PBX
PBX requires authentication but endpoint has no credentials configured
Missing credential on Sinch SIP Endpoint
PBX rejects call immediately
Add inbound credentials to the SIP Endpoint in Sinch
✅ Inbound credentials match exactly between PBX and Sinch Dashboard
5. Priority
When you configure multiple SIP Endpoints on your Elastic SIP Trunk, Sinch uses Endpoint Priorities to determine how inbound calls are routed to your PBX or SIP devices. Each endpoint is assigned a priority value, where lower numbers represent higher priority. The endpoint with the lowest priority number will receive all inbound calls first. If that endpoint is unavailable or fails to respond, Sinch will automatically route the call to the next available endpoint with a higher priority number. Endpoints that share the same priority value will receive calls in a round-robin pattern, allowing you to distribute traffic evenly across multiple systems.
Positive Test Scenarios (Expected Results) - Priority
Test
Expected Outcome
Verification
Multiple endpoints registered under same trunk with different priority levels
Primary endpoint handles calls first
Check Sinch Dashboard → both endpoints show “enabled”; confirm INVITE sent to highest priority endpoint
Negative Test Scenarios (Failure Conditions) - Priority
Test
Possible Cause
SIP Response / Symptom
Resolution
Incorrect or missing priority configuration
Priority field not set or misconfigured
Calls route unpredictably / failover not working
Set correct priority values (lower = higher priority) in Sinch Dashboard
All endpoints down
No active registered endpoints
503 Service Unavailable
Ensure at least one endpoint remains registered; validate registration timers
Secondary endpoint registered but unreachable (firewall or NAT)
INVITE sent but no response
408 Request Timeout
Verify network connectivity and open SIP/RTP ports
QA Checklist for Endpoint Priority
✅ Both endpoints registered and visible in dashboard
✅ Calls route to highest priority endpoint
✅ Failover to secondary endpoint works
✅ System reverts to primary after recovery
✅ Load sharing works for equal-priority endpoints
✅ Priority updates apply without service disruption
✅ SIP routing matches configured priority order
6. Access Control Lists (ACLs)
Allow you to control which IP addresses are permitted to send SIP traffic to your trunk. ACLs act as a security filter that accepts signaling only from approved IPs and rejects all others. This prevents unauthorized access, protects your trunk from fraud, and ensures that only trusted networks and PBXs can place or receive calls.
Positive Test Scenarios (Expected Results) - ACL
Test
Possible Cause (if fails)
SIP Response / Symptom
Resolution
Invite request from allowed IP
IP is correctly listed in ACL
200 OK
Confirm allowed IP in dashboard under API Access Control List.
SIP call from allowed IP (full INVITE flow)
ACL discrepancy different public IP
403 Forbidden from proxy
Verify actual IP and update ACL accordingly.
Negative Test Scenarios (Failure Conditions) - ACL
Test
Possible Cause (if passes)
SIP Response / Symptom
Resolution
SIP INVITE from non-whitelisted IP
IP incorrectly added to ACL or subnet too wide
Call completes unexpectedly
Review ACL entries — narrow subnet to /32 or specific range.
Call from IP recently removed from ACL
ACL cache not updated yet
Still allowed for 40 - 50 secs
Wait for ACL cache refresh (~50 secs) then retest.
QA Checklist for ACL
✅ SIP registration succeeds (200 OK)
✅ Outbound call completes successfully
✅ Inbound call received from Sinch to allowed IP
✅ Audio is two-way on both legs
✅ ACL propagation verified within 50 secs after adding IP
✅ SIP INVITE from IP denied (403 Forbitten)
✅ IP removed from ACL becomes blocked within expected propagation time
✅ No call setup or media from non-whitelisted IPs
✅ Logs correctly display denied source IP and reason
7. Country Permissions
Allow you to control which international destinations can receive outbound calls from your SIP trunk, and which countries are permitted to send inbound traffic. This feature provides an additional security layer to prevent unauthorized international calling, reduce fraud exposure, and ensure compliance with business or regulatory requirements.
Positive Test Scenarios (Expected Results) - Country Permissions
Test
Expected Outcome
Verification
Outbound call to an allowed country (e.g., UK, US, Canada)
Call completes successfully with two-way audio
Verify call appears in CDRs, correct country code and destination prefix