# Elastic SIP Trunking Test plan

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 |
| Credentials updated but PBX still rejecting | PBX caching old authentication data | Repeated rejects despite correct credentials | Clear PBX cache or restart SIP service |
| Multiple PBXs using same inbound credential | Credential collisions causing inconsistent behavior | Some calls accepted, others rejected | Assign unique inbound credentials per endpoint/device |


### QA Checklist for Inbound Credential Validation

- ✅ PBX issues a proper  407 challenge
- ✅ Sinch resends INVITE with correct Authorization header
- ✅ PBX accepts authenticated INVITE
- ✅ Inbound call rings and connects
- ✅ Two-way audio confirmed
- ✅ Multiple inbound calls authenticated successfully
- ✅ No repeated 407 loops
- ✅ 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 |
| Primary endpoint unavailable, secondary endpoint reachable | Calls automatically route to secondary endpoint | Simulate primary down (disable network); verify call completes through secondary |
| Restore primary endpoint after failover | System automatically reverts to primary endpoint for new calls	Observe call routing returns to primary; check SIP logs or CDR endpoint name | Equal-priority endpoints (load sharing) | Calls distributed evenly between endpoints | Verify call distribution pattern over multiple calls; CDRs show both endpoints in rotation |
| Priority change in configuration | Priority update applied without service disruption | Modify priority in dashboard; confirm next call follows new routing order |
| Endpoint prioritization persists after registration refresh | Correct priority order maintained post re-registration | Restart PBX devices; confirm routing logic remains consistent |


### 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 |
| Inbound call from an allowed country | Call is received and audio is clear | Check PBX logs → INVITE received; call connected successfully |
| Attempt outbound call to multiple allowed destinations | Each destination connects per your country permissions list | Verify each call completes with expected country code formatting (+44, +1, etc.) |
| Modify allowed country list (add/remove) | System updates permissions dynamically | Confirm update visible in Sinch Dashboard → test new call passes/fails as expected |


### Negative Test Scenarios (Failure Conditions) - Country Permissions

| **Test** | **Possible Cause** | **SIP Response / Symptom** | **Resolution** |
|  --- | --- | --- | --- |
| Outbound call to a blocked country | Destination not in allowed list | 480 Temporary Unavailable | Update country permissions in Sinch portal or contact admin to whitelist |
| Call blocked due to number format mismatch | Dialed number missing + or incorrect E.164 format | 480 Temporary Unavailable | Reformat numbers in PBX to E.164 (+countrycode + number) |


### Negative Test Scenarios (Failure Conditions) - Blocked Countries

| **Test** | **Possible Cause** | **SIP Response / Symptom** | **Resolution** |
|  --- | --- | --- | --- |
| Outbound call to a blocked country | Country not enabled in permissions | 480 Temporarily Unavailable | Enable the country in dashboard or update profile |
| Outbound call to restricted number | Number not permitted by number rules | 403 Forbidden or 404 Not Found | Adjust number rules or correct dialing format |
| Inbound call from blocked country | Traffic denied based on inbound rules | Call rejected | Update inbound country permissions if required |
| Outbound call when outbound traffic is disabled | Traffic type restricted in configuration | Call rejected with policy error | Enable outbound traffic in trunk settings |
| Number fails validation (not E.164) | Incorrect number formatting | 400 Bad Request / 404 Not Found | Correct number to +E.164 format |


### QA Checklist for Call Blocking

- ✅ A new call-blocking rule can be created successfully
- ✅ Rule name is unique and rejects duplicates
- ✅ Direction can be set to Inbound or Outbound
- ✅ “All Numbers” rule blocks all calls in the selected direction
- ✅ Inbound calls from PSTN/Sinch are blocked when “All Numbers” is enabled
- ✅ Outbound calls from infrastructure are blocked when “All Numbers” is enabled
- ✅ Prefix rule blocks all numbers starting with the specified pattern
- ✅ Full number rule blocks a single specific number
- ✅ Country selector loads correctly
- ✅ Outbound call to blocked country is rejected
- ✅ Country blocking overrides Country Permissions settings
- ✅ Inbound calls from a blocked country (if supported) are rejected