# Troubleshooting SIP 404 Not Found and 484 Address Incomplete call failures

Canonical: https://warmtransfer.net/knowledge/sip-404-484-troubleshooting

Last verified: 2026-10-02

The IANA SIP Response Codes registry lists 404 Not Found and 484 Address Incomplete, both referencing RFC 3261[^18]. RFC 3398 maps ISUP cause 1 (unallocated number) and causes 2, 3 and 26 to SIP 404 Not Found, and maps cause 28 (address incomplete / invalid number format) to SIP 484 Address Incomplete[^22][^26][^24].

## How it works

The IANA SIP Response Codes registry lists 404 Not Found and 484 Address Incomplete with RFC 3261 as the reference[^18]. The same registry lists the following codes, all referencing RFC 3261[^19]:

- 410 Gone[^19]
- 416 Unsupported URI Scheme[^19]
- 485 Ambiguous[^19]
- 604 Does Not Exist Anywhere[^19]

RFC 6432 allows any SIP response other than 100 Trying to carry a Reason header field with a Q.850 cause code[^39].

## PSTN cause mapping

RFC 3398 and Cisco IOS SIP gateway defaults map PSTN causes to SIP responses as shown below[^22][^11].

| ISUP / PSTN cause | RFC 3398 SIP response | Cisco IOS default SIP response |
|---|---|---|
| 1 (unallocated number) | 404 Not Found[^22] | 404 Not Found[^11] |
| 2 (no route to network) | 404 Not Found[^26] | 404 Not Found[^11] |
| 3 (no route to destination) | 404 Not Found[^26] | 404 Not Found[^11] |
| 22 (number changed) | 410 Gone, or 301 Moved Permanently when a diagnostic carrying the new number is present[^23] | 410 Gone[^12] |
| 26 (non-selected user clearing) | 404 Not Found[^26] | 404 Not Found[^12] |
| 28 (address incomplete) | 484 Address Incomplete[^24] | 484 Address Incomplete[^13] |

In the reverse direction, Cisco IOS SIP gateways by default map a received SIP 404 Not Found to PSTN cause 1 (unallocated number)[^8]. They also map SIP 410 Gone, 485 Ambiguous and 604 Does Not Exist Anywhere to PSTN cause 1 by default[^9]. They map a received SIP 484 Address Incomplete to PSTN cause 28 by default[^10].

FreeSWITCH maps a received SIP 404 Not Found to hangup cause UNALLOCATED_NUMBER rather than NO_ROUTE_DESTINATION[^16]. FreeSWITCH maps a received SIP 484 Address Incomplete to hangup cause INVALID_NUMBER_FORMAT[^17].

WarmTransfer's reading of the sources is that standards and gateway defaults collapse several distinct PSTN causes into 404, so the SIP code alone cannot tell an unassigned number from a routing failure, and the Q.850 cause in a Reason header, where present, is the better discriminator[^2].

## Overlap dialling and 484

RFC 3398 places overlap dialling mechanisms, meaning use of the ISUP Subsequent Address Message, outside its scope[^27]. RFC 3398 advises gateways facing overlap dialling to implement timers so that all digits are collected before an INVITE is transmitted[^25].

RFC 3578 prefers converting ISUP overlap signalling to en-bloc SIP, where the gateway waits for all parts of the called number before generating a single INVITE[^30]. In RFC 3578 en-bloc conversion, the gateway sends an INVITE with the digits collected so far when ISUP timer T10 expires[^34].

When overlap signalling is carried in SIP under RFC 3578, the gateway sends a new INVITE as digits arrive[^31]. Each new INVITE carries all digits received so far in the Request-URI and has a higher CSeq[^31]. RFC 3578 states that in overlap operation all INVITEs except one typically receive 4xx responses such as 484 Address Incomplete[^28]. RFC 3578 says the gateway should not CANCEL a previous overlap INVITE transaction when sending a new one, to avoid race conditions[^32].

RFC 3578 warns that successive overlap INVITEs may be routed to different gateways, so that more than one gateway generates an ISUP IAM[^29]. RFC 3578 also warns against SIP overlap where a number and a shorter prefix of the same number can both be valid PSTN addresses[^33].

WarmTransfer's reading of the sources is that a 484 on a trunk configured for overlap dialling is expected signalling for a partial number, whereas a 484 on an en-bloc trunk indicates that the sender truncated or malformed the dialled number[^4].

## Number format in the Request-URI

RFC 3966 identifies globally unique telephone numbers by a leading plus and requires them to consist of a country code and national number per E.164[^35]. RFC 3966 says globally unique numbers are unambiguous everywhere and SHOULD be used[^36]. RFC 3966 requires local (non-global) numbers to carry a phone-context parameter that identifies the scope in which they are valid[^37].

We infer that when a cloud or carrier returns 404 for a number that is provisioned, the first check is whether the Request-URI user part matches the provisioned format (typically +E.164), because documented lookups key on the Request-URI[^40].

## Platform differences

### Microsoft Teams Direct Routing

For inbound Direct Routing calls, the Microsoft SIP proxy performs a reverse number lookup of the phone number in the Request-URI within the tenant identified from the SBC FQDN[^51]. Microsoft states that for inbound Direct Routing calls the phone number in the Request-URI must contain a plus sign[^52]. Microsoft recommends always adding user=phone to the Request-URI[^53]. Without user=phone, the Direct Routing SIP proxy applies heuristics to decide whether the user part is a phone number or a SIP address[^53]. Microsoft does not support a third-party SIP proxy or UAS between the Microsoft SIP proxy and the paired SBC that might modify the Request-URI the SBC created[^50].

In Teams Direct Routing, Microsoft response code 511404 accompanies SIP 404 and means the user could not be found during the reverse number lookup, with the description 'Getting user info by number from RuntimeAPI failed'[^42]. For 511404, Microsoft advises making the callee number format from the SBC or PSTN trunk provider match the format assigned to the user or resource account, which is usually E.164 including the country code[^43].

Microsoft response code 10202 with SIP 404 means a replacement call was not found[^41]. Microsoft associates 10202 with call merge and consultative transfer when the SBC retries after a failed first attempt[^41].

Microsoft response code 560484 with SIP 484 means invalid number format, with the SBC rejecting the call[^45]. For 560484, Microsoft advises reviewing call records with CallEndSubReason 560484 for called-number trends by country/region[^46]. Microsoft says this review helps decide whether to add normalization rules for extension dialling or to educate users[^46]. Microsoft notes that 560484 failures may be ignorable when users dial invalid numbers[^47]. Microsoft also notes that 560484 can come from missing SBC configuration in a call transfer scenario with CallType ByotOutUserForwarding[^47].

### Twilio Elastic SIP Trunking

Twilio requires phone numbers sent via SIP to Elastic SIP Trunking to be in E.164 format including the leading plus[^54]. Twilio Elastic SIP Trunking rejects termination calls that do not use E.164 format with SIP 400 Bad Request, not 404 or 484[^55].

### FreeSWITCH

FreeSWITCH documentation says that when an upstream provider answers an INVITE with 404, the fix lies upstream, because the 404 means the provider does not recognise the number[^15].

### Asterisk

Asterisk res_pjsip endpoints have an allow_overlap option that enables RFC 3578 overlap dialling support, and the documented default is yes[^6]. The Asterisk res_pjsip overlap_context option names the dialplan context used to decide whether a full number has been received[^7]. If overlap_context is unset, the endpoint's context is used[^7].

### Kamailio

Kamailio's default kamailio.cfg replies 404 Not Found when the location lookup for the Request-URI fails with return code -1 or -3[^20]. Kamailio's default route[PSTN] treats a Request-URI user as a PSTN number only if it starts with + or 00, followed by a non-zero digit and 3 to 20 more digits[^21].

## Diagnosing it

- Find out which element generated the response. In Teams Direct Routing, a Microsoft response code that starts with 560 means the SBC generated the final SIP response, and the last 3 digits give the SIP code[^44]. Any other Microsoft response code means a Microsoft service generated the response[^44]. Microsoft reports the Direct Routing SIP response code (CallEndReason) and the Microsoft response code (CallEndSubReason) in the Teams admin center and the Power BI QER for PSTN[^48].
- Check for a Reason header with a Q.850 cause, which RFC 6432 allows on any SIP response other than 100 Trying[^39]. WarmTransfer's reading of the sources is that this cause separates an unassigned number from a routing failure better than the 404 code alone[^2].
- Compare the Request-URI user part with the provisioned number format. We infer that this is the first check when a cloud or carrier returns 404 for a provisioned number[^40]. RFC 3966 says globally unique numbers with a leading plus SHOULD be used[^36].
- For a 484, check whether the trunk uses overlap or en-bloc dialling. WarmTransfer's reading of the sources is that 484 is expected for partial numbers on overlap trunks, but on en-bloc trunks it points to a truncated or malformed number[^4]. RFC 3578 notes that an en-bloc gateway sends an INVITE with the digits collected so far when ISUP timer T10 expires[^34].
- If an upstream provider returns the 404, FreeSWITCH documentation places the fix with the provider[^15].

## See also

- [SIP response codes and failure interpretation](https://warmtransfer.net/knowledge/sip-response-codes)
- [ITU-T Q.850 call clearing cause values](https://warmtransfer.net/knowledge/q850-cause-codes)
- [E.164 numbering and dial string normalization](https://warmtransfer.net/knowledge/e164-numbering)
- [Troubleshooting Teams Direct Routing](https://warmtransfer.net/knowledge/teams-direct-routing-troubleshooting)
- [SIP trace capture and ladder analysis](https://warmtransfer.net/knowledge/sip-trace-analysis)
- [Call transfer semantics REFER and Replaces](https://warmtransfer.net/knowledge/call-transfer-semantics)
- [Troubleshooting SIP 403 Forbidden from a carrier](https://warmtransfer.net/knowledge/sip-403-forbidden-troubleshooting)

## Applicability

Applies to: Cisco IOS SIP gateway, SignalWire FreeSWITCH, Microsoft Teams Phone Direct Routing, Twilio Elastic SIP Trunking, Sangoma Asterisk, and Kamailio project. Deployments: on-premises, multi-tenant, and any. Sources checked 2026-10-02. Microsoft states that its SIP 404 and SIP 484 response-code guidance applies to Teams Direct Routing PSTN calls and not to Calling Plan or Operator Connect deployments[^49]. RFC 3398 places overlap dialling outside its scope[^27].

## What remains uncertain

- The response and cause a Cisco call-control platform returns when an inbound SIP trunk called number matches no configured pattern is not covered by the sources below.
- Whether a hosted calling service's local gateway returns 404 because of number format is not covered by the sources below.
- Whether Teams Direct Routing inbound translation rules can convert called numbers to E.164 is not covered by the sources below.
- Whether Cisco IOS SIP gateways continue hunting to other dial peers after receiving 404 for an unassigned number is not covered by the sources below.
- How other contact-centre carrier-connection offerings respond with 404 and what E.164 requirements they impose is not covered by the sources below.
- The response Twilio returns on origination for a number that is not provisioned is not covered by the sources below.
- Whether later Cisco gateway software documents cause-code mappings that differ from the Cisco IOS defaults cited here is not covered by the sources below.
- The contents of RFC 3398's SIP-to-ISUP reverse mapping table are not covered by the sources below.

## Sources

[^1]: RFC 3261 defines 404 Not Found as the server having definitive information that the user does not exist at the domain specified in the Request-URI. Source: [RFC 3261 — SIP: Session Initiation Protocol](https://www.rfc-editor.org/rfc/rfc3261.html), Section 21.4.5 (404 Not Found). Checked 2026-10-02.
[^2]: Because standards and gateway defaults collapse several distinct PSTN causes into 404, the SIP code alone cannot tell an unassigned number from a routing failure; the Q.850 cause in a Reason header, where present, is the better discriminator (inferred). Source: [RFC 3398: Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping](https://www.rfc-editor.org/rfc/rfc3398.html), Section 7.2.4.1 table, read together with RFC 6432 section 3. Checked 2026-10-02.
[^3]: RFC 3261 defines 484 Address Incomplete as a response indicating that the Request-URI was incomplete. Source: [RFC 3261 — SIP: Session Initiation Protocol](https://www.rfc-editor.org/rfc/rfc3261.html), Section 21.4.22 (484 Address Incomplete). Checked 2026-10-02.
[^4]: A 484 seen on a trunk configured for overlap dialling is expected signalling for a partial number, whereas a 484 on an en-bloc trunk indicates the sender truncated or malformed the dialled number (inferred). Source: [RFC 3578: Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap Signalling to the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc3578.html), Sections 2 and 3.3, read together. Checked 2026-10-02.
[^5]: RFC 3261 states that the 484 status code allows overlapped dialling, in which a client that does not know the dial string length sends strings of increasing length until it no longer receives 484. Source: [RFC 3261 — SIP: Session Initiation Protocol](https://www.rfc-editor.org/rfc/rfc3261.html), Section 21.4.22 (484 Address Incomplete). Checked 2026-10-02.
[^6]: Asterisk res_pjsip endpoints have an allow_overlap option enabling RFC 3578 overlap dialling support, documented with default yes. Source: [res_pjsip - Asterisk Documentation](https://docs.asterisk.org/Latest_API/API_Documentation/Module_Configuration/res_pjsip/), Configuration object 'endpoint', option allow_overlap. Checked 2026-10-02.
[^7]: Asterisk res_pjsip overlap_context names the dialplan context used to decide whether a full number has been received; if unset the endpoint's context is used. Source: [res_pjsip - Asterisk Documentation](https://docs.asterisk.org/Latest_API/API_Documentation/Module_Configuration/res_pjsip/), Configuration object 'endpoint', option overlap_context. Checked 2026-10-02.
[^8]: Cisco IOS SIP gateways by default map a received SIP 404 Not Found to PSTN cause 1 (unallocated number). Source: [SIP Configuration Guide, Cisco IOS Release 15M&T - Configuring SIP Message Timer and Response Features](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/sip/configuration/15-mt/sip-config-15-mt-book/voi-sip-timer.html), Table 3: Default SIP Event to PSTN Cause Code Mapping. Checked 2026-10-02.
[^9]: Cisco IOS SIP gateways by default also map SIP 410 Gone, 485 Ambiguous and 604 Does Not Exist Anywhere to PSTN cause 1 (unallocated number). Source: [SIP Configuration Guide, Cisco IOS Release 15M&T - Configuring SIP Message Timer and Response Features](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/sip/configuration/15-mt/sip-config-15-mt-book/voi-sip-timer.html), Table 3: Default SIP Event to PSTN Cause Code Mapping. Checked 2026-10-02.
[^10]: Cisco IOS SIP gateways by default map a received SIP 484 Address Incomplete to PSTN cause 28. Source: [SIP Configuration Guide, Cisco IOS Release 15M&T - Configuring SIP Message Timer and Response Features](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/sip/configuration/15-mt/sip-config-15-mt-book/voi-sip-timer.html), Table 3: Default SIP Event to PSTN Cause Code Mapping. Checked 2026-10-02.
[^11]: Cisco IOS SIP gateways by default map PSTN cause codes 1, 2 and 3 to SIP 404 Not Found. Source: [SIP Configuration Guide, Cisco IOS Release 15M&T - Configuring SIP Message Timer and Response Features](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/sip/configuration/15-mt/sip-config-15-mt-book/voi-sip-timer.html), Table 2: Default PSTN Cause Code to SIP Event Mappings. Checked 2026-10-02.
[^12]: Cisco IOS SIP gateways by default map PSTN cause 26 (non-selected user clearing) to SIP 404 Not Found and cause 22 (number changed) to 410 Gone. Source: [SIP Configuration Guide, Cisco IOS Release 15M&T - Configuring SIP Message Timer and Response Features](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/sip/configuration/15-mt/sip-config-15-mt-book/voi-sip-timer.html), Table 2: Default PSTN Cause Code to SIP Event Mappings. Checked 2026-10-02.
[^13]: Cisco IOS SIP gateways by default map PSTN cause 28 (address incomplete) to SIP 484 Address Incomplete. Source: [SIP Configuration Guide, Cisco IOS Release 15M&T - Configuring SIP Message Timer and Response Features](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/sip/configuration/15-mt/sip-config-15-mt-book/voi-sip-timer.html), Table 2: Default PSTN Cause Code to SIP Event Mappings. Checked 2026-10-02.
[^14]: Cisco IOS SIP gateways allow the default cause-to-SIP mappings to be overridden with the set sip-status and set pstn-cause commands. Source: [SIP Configuration Guide, Cisco IOS Release 15M&T - Configuring SIP Message Timer and Response Features](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/sip/configuration/15-mt/sip-config-15-mt-book/voi-sip-timer.html), Section 'Configuring SIP - Configurable PSTN Cause Code Mapping'. Checked 2026-10-02.
[^15]: FreeSWITCH documentation says that when an upstream provider answers an INVITE with 404 the fix lies upstream, as the 404 is a number the provider does not recognise. Source: [Chapter 42: Call-Setup Failures](https://developer.signalwire.com/freeswitch/troubleshooting/call-setup/), Section 'Symptom: upstream returns 403, 404, 480, or 503', fix guidance. Checked 2026-10-02.
[^16]: FreeSWITCH maps a received SIP 404 Not Found to hangup cause UNALLOCATED_NUMBER rather than NO_ROUTE_DESTINATION. Source: [Chapter 42: Call-Setup Failures](https://developer.signalwire.com/freeswitch/troubleshooting/call-setup/), Section 'Symptom: upstream returns 403, 404, 480, or 503' and SIP response mapping table. Checked 2026-10-02.
[^17]: FreeSWITCH maps a received SIP 484 Address Incomplete to hangup cause INVALID_NUMBER_FORMAT. Source: [Chapter 42: Call-Setup Failures](https://developer.signalwire.com/freeswitch/troubleshooting/call-setup/), SIP response mapping table, 484 row. Checked 2026-10-02.
[^18]: The IANA SIP Response Codes registry lists 404 Not Found and 484 Address Incomplete with RFC 3261 as the reference. Source: [Session Initiation Protocol (SIP) Parameters](https://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml), Response Codes registry, rows 404 and 484. Checked 2026-10-02.
[^19]: The IANA SIP Response Codes registry also lists 410 Gone, 416 Unsupported URI Scheme, 485 Ambiguous and 604 Does Not Exist Anywhere, all referencing RFC 3261. Source: [Session Initiation Protocol (SIP) Parameters](https://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml), Response Codes registry, rows 410, 416, 485 and 604. Checked 2026-10-02.
[^20]: Kamailio's default kamailio.cfg replies 404 Not Found when the location lookup for the Request-URI fails with return code -1 or -3. Source: [kamailio/etc/kamailio.cfg (default configuration, master branch)](https://raw.githubusercontent.com/kamailio/kamailio/master/etc/kamailio.cfg), route[LOCATION] block. Checked 2026-10-02.
[^21]: Kamailio's default route[PSTN] only treats a Request-URI user as a PSTN number if it starts with + or 00 followed by a non-zero digit and 3 to 20 more digits. Source: [kamailio/etc/kamailio.cfg (default configuration, master branch)](https://raw.githubusercontent.com/kamailio/kamailio/master/etc/kamailio.cfg), route[PSTN] block, $rU regex test. Checked 2026-10-02.
[^22]: RFC 3398 maps ISUP cause 1 (unallocated number) received from the PSTN to SIP 404 Not Found. Source: [RFC 3398: Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping](https://www.rfc-editor.org/rfc/rfc3398.html), Section 7.2.4.1 (ISDN Cause Code to SIP Status Code mapping table). Checked 2026-10-02.
[^23]: RFC 3398 maps ISUP cause 22 (number changed) to 410 Gone, or to 301 Moved Permanently when a diagnostic carrying the new number is present. Source: [RFC 3398: Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping](https://www.rfc-editor.org/rfc/rfc3398.html), Section 7.2.4.1 (ISDN Cause Code to SIP Status Code mapping table), cause 22 rows. Checked 2026-10-02.
[^24]: RFC 3398 maps ISUP cause 28 (address incomplete / invalid number format) to SIP 484 Address Incomplete. Source: [RFC 3398: Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping](https://www.rfc-editor.org/rfc/rfc3398.html), Section 7.2.4.1 (ISDN Cause Code to SIP Status Code mapping table). Checked 2026-10-02.
[^25]: RFC 3398 advises gateways facing overlap dialling to implement timers so that all digits have been collected before an INVITE is transmitted. Source: [RFC 3398: Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping](https://www.rfc-editor.org/rfc/rfc3398.html), Section 4 (discussion following the overlap scope note). Checked 2026-10-02.
[^26]: RFC 3398 maps ISUP causes 2 (no route to network), 3 (no route to destination) and 26 (non-selected user clearing) to SIP 404 Not Found. Source: [RFC 3398: Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping](https://www.rfc-editor.org/rfc/rfc3398.html), Section 7.2.4.1 (ISDN Cause Code to SIP Status Code mapping table). Checked 2026-10-02.
[^27]: RFC 3398 places overlap dialling mechanisms (use of the ISUP Subsequent Address Message) outside its scope. Source: [RFC 3398: Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping](https://www.rfc-editor.org/rfc/rfc3398.html), Section 4 (scope note on overlap dialling). Checked 2026-10-02.
[^28]: RFC 3578 states that in overlap operation all INVITEs except one typically receive 4xx responses such as 484 Address Incomplete. Source: [RFC 3578: Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap Signalling to the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc3578.html), Section 3.3. Checked 2026-10-02.
[^29]: RFC 3578 warns that successive overlap INVITEs may be routed to different gateways, so that more than one gateway generates an ISUP IAM. Source: [RFC 3578: Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap Signalling to the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc3578.html), Section 3.1. Checked 2026-10-02.
[^30]: RFC 3578 prefers converting ISUP overlap signalling to en-bloc SIP, where the gateway waits for all parts of the called number before generating a single INVITE. Source: [RFC 3578: Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap Signalling to the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc3578.html), Sections 1 and 2 (en-bloc conversion). Checked 2026-10-02.
[^31]: When overlap signalling is carried in SIP under RFC 3578, the gateway sends a new INVITE as digits arrive, each carrying all digits received so far in the Request-URI and a higher CSeq. Source: [RFC 3578: Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap Signalling to the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc3578.html), Section 3.2. Checked 2026-10-02.
[^32]: RFC 3578 says the gateway should not CANCEL a previous overlap INVITE transaction when sending a new one, to avoid race conditions. Source: [RFC 3578: Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap Signalling to the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc3578.html), Section 3.4. Checked 2026-10-02.
[^33]: RFC 3578 warns against SIP overlap where a number and a shorter prefix of the same number can both be valid PSTN addresses. Source: [RFC 3578: Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap Signalling to the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc3578.html), Applicability discussion (Section 3). Checked 2026-10-02.
[^34]: In RFC 3578 en-bloc conversion the gateway sends an INVITE with the digits collected so far when ISUP timer T10 expires. Source: [RFC 3578: Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap Signalling to the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc3578.html), Section 2.2. Checked 2026-10-02.
[^35]: RFC 3966 identifies globally unique telephone numbers by a leading plus and requires them to be composed of country code and national number per E.164. Source: [RFC 3966: The tel URI for Telephone Numbers](https://www.rfc-editor.org/rfc/rfc3966.html), Section 5.1.4 (Global Numbers). Checked 2026-10-02.
[^36]: RFC 3966 says globally unique numbers are unambiguous everywhere and SHOULD be used. Source: [RFC 3966: The tel URI for Telephone Numbers](https://www.rfc-editor.org/rfc/rfc3966.html), Section 5.1.4 (Global Numbers). Checked 2026-10-02.
[^37]: RFC 3966 requires local (non-global) numbers to carry a phone-context parameter identifying the scope in which they are valid. Source: [RFC 3966: The tel URI for Telephone Numbers](https://www.rfc-editor.org/rfc/rfc3966.html), Section 5.1.5 (Local Numbers). Checked 2026-10-02.
[^38]: RFC 6432 states that the presence of a Reason header field in a response does not affect the treatment of the response. Source: [RFC 6432: Carrying Q.850 Codes in Reason Header Fields in SIP (Session Initiation Protocol) Responses](https://www.rfc-editor.org/rfc/rfc6432.html), Sections 3-4 (exact section unconfirmed). Checked 2026-10-02.
[^39]: RFC 6432 allows any SIP response other than 100 Trying to carry a Reason header field with a Q.850 cause code. Source: [RFC 6432: Carrying Q.850 Codes in Reason Header Fields in SIP (Session Initiation Protocol) Responses](https://www.rfc-editor.org/rfc/rfc6432.html), Section 3. Checked 2026-10-02.
[^40]: When a cloud or carrier returns 404 for a number that is provisioned, the first check is whether the Request-URI user part matches the provisioned format (typically +E.164), since documented lookups key on the Request-URI (inferred). Source: [SIP 404 and Microsoft response codes - Microsoft Teams](https://learn.microsoft.com/en-us/microsoftteams/troubleshoot/phone-system/direct-routing/microsoft-sip-response-codes-404), Section '511404 ...', generalised with ms-learn-dr-protocols-sip 'Request-URI' section. Checked 2026-10-02.
[^41]: Teams Direct Routing Microsoft response code 10202 with SIP 404 means a replacement call was not found, seen in call merge and consultative transfer when the SBC retries after a failed first attempt. Source: [SIP 404 and Microsoft response codes - Microsoft Teams](https://learn.microsoft.com/en-us/microsoftteams/troubleshoot/phone-system/direct-routing/microsoft-sip-response-codes-404), Section '10202 404 Replacement call was not found'. Checked 2026-10-02.
[^42]: Teams Direct Routing Microsoft response code 511404 with SIP 404 ('Getting user info by number from RuntimeAPI failed') means the user could not be found during the reverse number lookup. Source: [SIP 404 and Microsoft response codes - Microsoft Teams](https://learn.microsoft.com/en-us/microsoftteams/troubleshoot/phone-system/direct-routing/microsoft-sip-response-codes-404), Section '511404 404 Getting user info by number from RuntimeAPI failed'. Checked 2026-10-02.
[^43]: For 511404, Microsoft advises making the callee number format from the SBC or PSTN trunk provider match the format assigned to the user or resource account, usually E.164 including country code. Source: [SIP 404 and Microsoft response codes - Microsoft Teams](https://learn.microsoft.com/en-us/microsoftteams/troubleshoot/phone-system/direct-routing/microsoft-sip-response-codes-404), Section '511404 404 Getting user info by number from RuntimeAPI failed', suggested actions. Checked 2026-10-02.
[^44]: In Teams Direct Routing, a Microsoft response code starting with 560 means the final SIP response was generated by the SBC, with the last three digits giving the SIP code; other codes mean a Microsoft service generated it. Source: [Microsoft and SIP response codes](https://learn.microsoft.com/en-us/troubleshoot/microsoftteams/phone-system/direct-routing/microsoft-sip-response-codes), Section 'Direct Routing error codes'. Checked 2026-10-02.
[^45]: Teams Direct Routing Microsoft response code 560484 with SIP 484 means 'Invalid number format. SBC rejected the call'. Source: [SIP 484 and Microsoft response codes - Microsoft Teams](https://learn.microsoft.com/en-us/troubleshoot/microsoftteams/phone-system/direct-routing/microsoft-sip-response-codes-484), Section '560484 484 Invalid number format. SBC rejected the call'. Checked 2026-10-02.
[^46]: For 560484 Microsoft advises reviewing call records with CallEndSubReason 560484 for called-number trends by country/region to decide on extra normalization rules for extension dialling or user education. Source: [SIP 484 and Microsoft response codes - Microsoft Teams](https://learn.microsoft.com/en-us/troubleshoot/microsoftteams/phone-system/direct-routing/microsoft-sip-response-codes-484), Section '560484 ...', suggested actions paragraph 1. Checked 2026-10-02.
[^47]: Microsoft notes 560484 failures may be ignorable when users dial invalid numbers, but can also come from missing SBC configuration in a call transfer scenario (CallType ByotOutUserForwarding). Source: [SIP 484 and Microsoft response codes - Microsoft Teams](https://learn.microsoft.com/en-us/troubleshoot/microsoftteams/phone-system/direct-routing/microsoft-sip-response-codes-484), Section '560484 ...', suggested actions paragraph 2. Checked 2026-10-02.
[^48]: Microsoft reports the Direct Routing SIP response code (CallEndReason) and Microsoft response code (CallEndSubReason) in the Teams admin center and the Power BI QER for PSTN. Source: [Microsoft and SIP response codes](https://learn.microsoft.com/en-us/troubleshoot/microsoftteams/phone-system/direct-routing/microsoft-sip-response-codes), Introductory section before 'Direct Routing error codes'. Checked 2026-10-02.
[^49]: Microsoft states its SIP 404 and SIP 484 response-code guidance applies to Teams Direct Routing PSTN calls and not to Calling Plan or Operator Connect deployments. Source: [SIP 404 and Microsoft response codes - Microsoft Teams](https://learn.microsoft.com/en-us/microsoftteams/troubleshoot/phone-system/direct-routing/microsoft-sip-response-codes-404), Note at top of article. Checked 2026-10-02.
[^50]: Microsoft does not support a third-party SIP proxy or UAS between the Microsoft SIP proxy and the paired SBC that might modify the Request-URI created by the SBC. Source: [Teams Phone System Direct Routing: SIP protocol](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-protocols-sip), Section 'Processing the incoming request: finding the tenant and user', step 5. Checked 2026-10-02.
[^51]: For inbound Direct Routing calls the Microsoft SIP proxy performs a reverse number lookup of the phone number in the Request-URI within the tenant identified from the SBC FQDN. Source: [Teams Phone System Direct Routing: SIP protocol](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-protocols-sip), Section 'Processing the incoming request: finding the tenant and user', step 4. Checked 2026-10-02.
[^52]: Microsoft states that for inbound Direct Routing calls the phone number in the Request-URI must contain a plus sign. Source: [Teams Phone System Direct Routing: SIP protocol](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-protocols-sip), Section 'Detailed requirements for Contact header and Request-URI' > 'Request-URI'. Checked 2026-10-02.
[^53]: Microsoft recommends always adding user=phone to the Request-URI; without it the Direct Routing SIP proxy applies heuristics to decide whether the user part is a phone number or a SIP address. Source: [Teams Phone System Direct Routing: SIP protocol](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-protocols-sip), Section 'Use of Request-URI parameter user=phone'. Checked 2026-10-02.
[^54]: Twilio requires phone numbers sent via SIP to Elastic SIP Trunking to be E.164-formatted including the leading plus. Source: [Elastic SIP Trunking](https://www.twilio.com/docs/sip-trunking), Termination settings section (E.164 note). Checked 2026-10-02.
[^55]: Twilio Elastic SIP Trunking rejects termination calls not using E.164 format with SIP 400 Bad Request, not 404 or 484. Source: [Elastic SIP Trunking](https://www.twilio.com/docs/sip-trunking), Termination settings section (E.164 note). Checked 2026-10-02.
[^56]: Under RFC 3261 a UAS whose Request-URI does not identify an address it is willing to accept should reject the request with 404 Not Found. Source: [RFC 3261 — SIP: Session Initiation Protocol](https://www.rfc-editor.org/rfc/rfc3261.html), Section 8.2.2.1 (To and Request-URI). Checked 2026-10-02.