# Call flow examples Successful outbound call setup differs according to the trunk's authentication method. **Credentials & IP-Based** trunks validate the source IP address and use a SIP Digest challenge before call routing continues. **IP-Only** trunks identify and authenticate the trunk from the source IP address without a Digest challenge. Each diagram follows the signaling sequence from the originating SIP endpoint, through the DIDWW outbound trunk, to the destination network. Expand a numbered stage below a diagram to view representative SIP request and response lines. Note The diagrams and SIP messages are simplified examples. The IP addresses, telephone numbers, credentials, and Digest values are illustrative only. Each example includes only the message lines needed to explain the flow and omits unrelated headers and SDP bodies. For the complete SIP Digest exchange and authentication rules, see [Authentication flow](../authentication-security.html#outbound-trunk-authentication-flow). ## Credentials & IP-Based trunk The originating SIP endpoint first sends an `INVITE` without credentials. DIDWW challenges the request, and the endpoint acknowledges the challenge before retrying the `INVITE` with an `Authorization` header. After DIDWW accepts the request, call setup continues. ``` %%{init: { "theme": "base", "themeVariables": { "fontSize": "14px", "actorBkg": "#e0f2fe", "actorBorder": "#38bdf8", "actorTextColor": "#1f2d3d", "actorLineColor": "#38bdf8", "signalColor": "#0066cc", "signalTextColor": "#1f2d3d", "noteBkgColor": "#fef3c7", "noteBorderColor": "#facc15", "noteTextColor": "#1f2d3d", "labelBoxBkgColor": "#ccfbf1", "labelBoxBorderColor": "#2dd4bf", "labelTextColor": "#1f2d3d", "loopTextColor": "#1f2d3d", "sequenceNumberColor": "#ffffff" } }}%% sequenceDiagram autonumber participant ORIGIN as Originating SIP endpoint participant DIDWW as DIDWW outbound trunk participant PSTN as Destination network (PSTN) ORIGIN->>DIDWW: INVITE without Authorization DIDWW-->>ORIGIN: 100 Trying DIDWW-->>ORIGIN: 401 Unauthorized with WWW-Authenticate ORIGIN->>DIDWW: ACK ORIGIN->>DIDWW: INVITE with Authorization DIDWW-->>ORIGIN: 100 Trying DIDWW->>PSTN: Route call PSTN-->>DIDWW: 18x provisional response DIDWW-->>ORIGIN: 18x provisional response PSTN-->>DIDWW: 200 OK DIDWW-->>ORIGIN: 200 OK with SDP ORIGIN->>DIDWW: ACK Note over ORIGIN,DIDWW: RTP media follows the negotiated path ORIGIN->>DIDWW: BYE DIDWW->>PSTN: BYE PSTN-->>DIDWW: 200 OK DIDWW-->>ORIGIN: 200 OK ``` Expand a stage to view its representative SIP messages. 1. Initial INVITE The originating SIP endpoint sends the first `INVITE` without an `Authorization` header: ``` INVITE sip:12025550199@out.didww.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bK-example-1;rport From: ;tag=example-from-tag To: Call-ID: example-call-id@sbc.example.com CSeq: 102 INVITE Contact: Content-Type: application/sdp ``` DIDWW checks the source IP address against the trunk's **Allowed SIP IP addresses** before continuing with SIP Digest authentication. 2. Authentication challenge and ACK DIDWW responds with `401 Unauthorized` and provides the realm, nonce, and quality-of-protection value in `WWW-Authenticate`. DIDWW may first send `100 Trying` while it processes the initial `INVITE`: ``` SIP/2.0 401 Unauthorized From: ;tag=example-from-tag To: ;tag=example-to-tag Call-ID: example-call-id@sbc.example.com CSeq: 102 INVITE WWW-Authenticate: Digest realm="out.didww.com", qop="auth", nonce="example-nonce" Content-Length: 0 ``` The originating SIP endpoint acknowledges the final response to the first transaction: ``` ACK sip:12025550199@out.didww.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bK-example-1;rport From: ;tag=example-from-tag To: ;tag=example-to-tag Call-ID: example-call-id@sbc.example.com CSeq: 102 ACK Content-Length: 0 ``` 3. Authenticated INVITE The originating SIP endpoint calculates the digest response using the trunk's SIP username and password, then sends a new `INVITE` with an `Authorization` header. The new transaction uses a new branch value and increments the `CSeq` number: ``` INVITE sip:12025550199@out.didww.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bK-example-2;rport From: ;tag=example-from-tag To: Call-ID: example-call-id@sbc.example.com CSeq: 103 INVITE Contact: Authorization: Digest username="example-username", realm="out.didww.com", nonce="example-nonce", uri="sip:12025550199@out.didww.com", response="00000000000000000000000000000000", qop=auth, cnonce="example-cnonce", nc=00000001 Content-Type: application/sdp ``` The Digest values above are syntactically valid placeholders, not working credentials. The originating SIP endpoint must calculate the actual response from the challenge and the trunk's credentials. 4. Call establishment After DIDWW validates the source IP address and digest credentials, it accepts the transaction and routes the call. The provisional and final responses use the same `Call-ID` and `CSeq` as the authenticated `INVITE`: ``` SIP/2.0 100 Trying Call-ID: example-call-id@sbc.example.com CSeq: 103 INVITE SIP/2.0 180 Ringing Call-ID: example-call-id@sbc.example.com CSeq: 103 INVITE SIP/2.0 200 OK Call-ID: example-call-id@sbc.example.com CSeq: 103 INVITE Content-Type: application/sdp ``` The originating SIP endpoint confirms the established dialog with an `ACK`. RTP media then follows the path negotiated in the SDP offer and answer: ``` ACK sip:12025550199@out.didww.com SIP/2.0 Call-ID: example-call-id@sbc.example.com CSeq: 103 ACK ``` After `100 Trying`, the originating SIP endpoint waits for another provisional or final response. Depending on the destination network, it may receive `180 Ringing`, `183 Session Progress`, another provisional response, or a final response without an additional provisional response. 5. Call termination Either endpoint can end the call by sending `BYE`. The receiving endpoint confirms the request with `200 OK`: ``` BYE sip:12025550199@out.didww.com SIP/2.0 Call-ID: example-call-id@sbc.example.com CSeq: 104 BYE SIP/2.0 200 OK Call-ID: example-call-id@sbc.example.com CSeq: 104 BYE ``` ## IP-Only trunk For an **IP-Only** trunk, DIDWW identifies and authenticates the trunk from the source IP address. The originating SIP endpoint sends the initial `INVITE` without an `Authorization` header, and DIDWW does not issue a SIP Digest challenge. Note IP-Only authentication is not available for self-service selection. To request it, contact [DIDWW Customer Support](mailto:support%40didww.com). ``` %%{init: { "theme": "base", "themeVariables": { "fontSize": "14px", "actorBkg": "#e0f2fe", "actorBorder": "#38bdf8", "actorTextColor": "#1f2d3d", "actorLineColor": "#38bdf8", "signalColor": "#0066cc", "signalTextColor": "#1f2d3d", "noteBkgColor": "#fef3c7", "noteBorderColor": "#facc15", "noteTextColor": "#1f2d3d", "labelBoxBkgColor": "#ccfbf1", "labelBoxBorderColor": "#2dd4bf", "labelTextColor": "#1f2d3d", "loopTextColor": "#1f2d3d", "sequenceNumberColor": "#ffffff" } }}%% sequenceDiagram autonumber participant ORIGIN as Originating SIP endpoint participant DIDWW as DIDWW outbound trunk participant PSTN as Destination network (PSTN) ORIGIN->>DIDWW: INVITE without Authorization DIDWW->>DIDWW: Match the source IP to an IP-Only trunk DIDWW-->>ORIGIN: 100 Trying DIDWW->>PSTN: Route call PSTN-->>DIDWW: 18x provisional response DIDWW-->>ORIGIN: 18x provisional response PSTN-->>DIDWW: 200 OK DIDWW-->>ORIGIN: 200 OK with SDP ORIGIN->>DIDWW: ACK Note over ORIGIN,DIDWW: RTP media follows the negotiated path ORIGIN->>DIDWW: BYE DIDWW->>PSTN: BYE PSTN-->>DIDWW: 200 OK DIDWW-->>ORIGIN: 200 OK ``` Expand a stage to view its representative SIP messages. 1. Initial INVITE The originating SIP endpoint sends an `INVITE` from an IP address configured for the trunk. No `Authorization` header is required: ``` INVITE sip:12025550198@out.didww.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.20:5060;branch=z9hG4bK-ip-only;rport From: ;tag=ip-only-from-tag To: Call-ID: ip-only-call-id@sbc.example.com CSeq: 201 INVITE Contact: Content-Type: application/sdp ``` 2. Source-IP validation and call establishment After DIDWW matches `192.0.2.20` to the IP-Only trunk, it accepts the transaction without a `401 Unauthorized` response or authenticated `INVITE` retry. Call setup then continues with the normal provisional and final responses: ``` SIP/2.0 100 Trying Call-ID: ip-only-call-id@sbc.example.com CSeq: 201 INVITE SIP/2.0 180 Ringing Call-ID: ip-only-call-id@sbc.example.com CSeq: 201 INVITE SIP/2.0 200 OK Call-ID: ip-only-call-id@sbc.example.com CSeq: 201 INVITE Content-Type: application/sdp ``` The originating SIP endpoint confirms the established dialog with an `ACK`. RTP media then follows the path negotiated in the SDP offer and answer: ``` ACK sip:12025550198@out.didww.com SIP/2.0 Call-ID: ip-only-call-id@sbc.example.com CSeq: 201 ACK ``` After `100 Trying`, the originating SIP endpoint waits for another provisional or final response. It does not send another request until a response requires one, such as the `ACK` sent after `200 OK`. 3. Call termination Call termination is the same for both authentication methods. Either endpoint can send `BYE`, and the receiving endpoint confirms it with `200 OK`: ``` BYE sip:12025550198@out.didww.com SIP/2.0 Call-ID: ip-only-call-id@sbc.example.com CSeq: 202 BYE SIP/2.0 200 OK Call-ID: ip-only-call-id@sbc.example.com CSeq: 202 BYE ``` ## Related resources - [Authentication and security](../authentication-security.html) - Understand authentication methods, source-IP matching, and SIP Digest requirements. - [Outbound SIP information](../outbound-sip-information.html) - Find signaling endpoints, transports, and media requirements. - [RFC 3261](https://datatracker.ietf.org/doc/html/rfc3261) - Defines SIP transactions, dialogs, requests, and responses. On this page