# SIP identity headers: P-Asserted-Identity and Diversion and History-Info Canonical: https://warmtransfer.net/knowledge/sip-identity-headers Last verified: 2026-10-02 RFC 3261 defines the From header as the logical identity of the request initiator, supplied by the user agent rather than asserted by the network, while RFC 3325 defines P-Asserted-Identity and P-Preferred-Identity in an Informational RFC published in November 2002[^13][^30]. RFC 5806 documents the Diversion header with Historic status, and RFC 7044 (Standards Track, February 2014) defines History-Info and obsoletes RFC 4244[^6][^32]. ## The headers and their standing | Header | Definition and status | |---|---| | P-Asserted-Identity | RFC 3325, Informational, November 2002[^30] | | Remote-Party-ID | draft-ietf-sip-privacy-04, an Internet-Draft dated February 2002 that expired and never became an RFC[^34] | | Diversion | RFC 5806, Historic, March 2010[^6] | | History-Info | RFC 7044 (Standards Track, February 2014)[^32] | | Identity | RFC 8224 (Standards Track, February 2018)[^33] | ## From versus asserted identity In RFC 3261 the From header indicates the logical identity of the request initiator, possibly the user's address-of-record, and the user agent supplies it[^13]. WarmTransfer's reading of the sources is that From is a user-supplied, displayable identity and PAI is the network-asserted identity, which is why platforms can show an anonymous or main-number From while carrying the real caller in PAI for billing or attestation[^25]. ## P-Asserted-Identity and the Trust Domain RFC 3325 asserted identity is only meaningful inside a Trust Domain whose members follow a shared specification called Spec(T)[^23]. Spec(T) covers authentication, inter-node security, membership and default privacy handling[^23]. A P-Asserted-Identity header may carry 1 value, which is a SIP, SIPS or tel URI[^21]. It may instead carry 2 values, in which case 1 is a SIP or SIPS URI and the other is a tel URI[^21]. A proxy in the Trust Domain that receives P-Preferred-Identity from a user agent uses it only as a hint for which identity to assert[^26]. That proxy removes P-Preferred-Identity from any message it forwards[^26]. Under RFC 3325 a proxy must not pass on a P-Asserted-Identity as-is when it received that header from an element it does not trust[^24]. The proxy either replaces the asserted value with its own or removes the header[^24]. ## Privacy handling RFC 3323 (Standards Track, November 2002) defines the Privacy header priv-values header, session, user, none and critical[^29]. The id priv-value is defined by RFC 3325, not RFC 3323[^27]. It requests that the network-asserted identity be kept private from entities outside the Trust Domain[^27]. When a request carries `Privacy: id`, a Trust Domain proxy must remove all P-Asserted-Identity headers before forwarding to elements that are not trusted[^22]. The RFC 5379 privacy guidelines state that a privacy service must delete P-Asserted-Identity headers when user privacy is requested with `Privacy: id`[^31]. An RFC 3323 privacy service is a network intermediary that obscures identity-revealing headers a user agent cannot hide itself[^28]. Where needed, it acts as a back-to-back user agent[^28]. The recommended anonymous From header uses the display name Anonymous with the URI `sip:anonymous@anonymous.invalid`[^1]. ## Remote-Party-ID Remote-Party-ID comes from draft-ietf-sip-privacy-04[^34]. Remote-Party-ID carries the following parameters[^36]: - party, which is calling or called[^36]. - screen, which is yes or no and defaults to no[^36]. - privacy, which is full, name, uri or off[^36]. - id-type, which is subscriber, user or term[^36]. The draft explicitly says it does not offer a general privacy or identity model suitable for inter-domain or Internet-wide use[^35]. ## Diversion The RFC 5806 IESG Note says Diversion was an early proposal that was not chosen for standardization[^7]. The same note says the standard solution chosen is History-Info (RFC 4244)[^7]. RFC 6044 states that new implementation and deployment of the Diversion header is strongly discouraged[^5]. When a call is diverted, the added Diversion header must contain the Request-URI the request had before the diversion[^10]. RFC 5806 says existing Diversion headers received in a request or response must not be removed or changed when the message is forwarded[^9]. Diversion reason values include unknown, user-busy, no-answer, unavailable, unconditional, time-of-day, do-not-disturb, deflection, follow-me, out-of-service and away[^11]. Besides reason, the header defines these parameters[^8]: - counter[^8]. - limit[^8]. - privacy, which is full, name, uri or off[^8]. - screen, which is yes or no[^8]. ## History-Info Each History-Info entry carries an index made of dot-separated nonnegative integers, for example 1.1.2[^14]. The index encodes forward hops and retargets as a tree[^14]. The rc parameter marks an entry where the Request-URI changed but the target user stayed the same[^18]. The mp parameter marks an entry where the request was retargeted to a different user than the one targeted by the incoming Request-URI[^16]. That mp case is the forwarded-call case[^16]. An RFC 7044 intermediary forwarding a request must include all cached hi-entries[^15]. As a result, History-Info accumulates rather than being replaced hop by hop[^15]. The reason a request was retargeted is carried as a Reason header embedded in the hi-targeted-to-uri[^19]. That Reason header reflects the non-100, non-2xx SIP response that triggered the retarget[^19]. See also [SIP response codes and failure interpretation](https://warmtransfer.net/knowledge/sip-response-codes). RFC 7044 adds the Privacy priv-value history, which requests anonymization of History-Info entries when they leave the domain[^17]. A SIP entity must not include History-Info in a response if both of the following are true for the request: it had no hi-entries, and it did not carry the histinfo option tag in Supported[^20]. ## Interworking Diversion and History-Info Diversion entries are in reverse chronological order, so the first entry is the last diverting user[^12]. History-Info entries are in chronological order[^12]. RFC 6044 maps these Diversion reasons to History-Info causes[^4]: - unconditional maps to 302[^4]. - user-busy maps to 486[^4]. - no-answer maps to 408[^4]. ## Signed identity and PAI RFC 8224 defines the SIP Identity header, which carries a PASSporT signature, and obsoletes RFC 4474[^33]. RFC 8224 says its guidance also applies when local policy takes the originator's identity from P-Asserted-Identity instead of From[^41]. The SHAKEN PASSporT attest claim takes A (full), B (partial) or C (gateway) as its value[^37]. ## Platform differences ### Microsoft Teams Phone Direct Routing On inbound Direct Routing calls, Microsoft uses the From header to check the callee's blocked-number list and to look up the caller's name[^46]. That From header must carry a number with a + prefix[^46]. The gateway parameter ForwardPai controls whether P-Asserted-Identity is sent toward the SBC, and it defaults to False[^45]. Microsoft states that setting ForwardPai to True renders the From header anonymous, and it cites RFC 5379 and RFC 3325 for this[^44]. With ForwardPai enabled, Direct Routing reports the calling user's TEL URI and SIP address in P-Asserted-Identity[^51]. Microsoft describes this as useful for billing when the displayed caller ID is Anonymous or a company main number[^51]. The gateway parameter ForwardCallHistory defaults to False[^42]. When it is enabled, the PSTN proxy sends History-Info and Referred-By headers[^42]. Direct Routing adds History-Info for simultaneous ring and call forwarding[^47]. It rebuilds those entries as phone-number URIs on sip.pstnhub.microsoft.com with user=phone[^47]. Direct Routing does not add History-Info for call transfer cases[^49]. See also [Call transfer semantics REFER and Replaces](https://warmtransfer.net/knowledge/call-transfer-semantics). Microsoft says inbound History-Info is preserved when ForwardCallHistory is enabled[^48]. Microsoft also says History-Info should be used for loop prevention on forwarded calls[^48]. See also [SIP call forwarding and routing loops](https://warmtransfer.net/knowledge/sip-forwarding-loops). Microsoft forwards History-Info entries marked private to the SIP trunk provider as-is[^50]. Microsoft does this because it treats that provider as a trusted peer[^50]. WarmTransfer's reading of the sources is that an SBC facing a carrier that requires Diversion probably has to synthesize Diversion from History-Info[^43]. We infer this from the fact that the Direct Routing protocol page documents History-Info but not Diversion for forwarded calls[^43]. See also [Teams Phone Direct Routing and SBC certification](https://warmtransfer.net/knowledge/teams-direct-routing). ### Twilio Elastic SIP Trunking On Twilio Elastic SIP Trunking termination, Twilio uses Remote-Party-ID or P-Asserted-Identity when the INVITE From field contains no caller ID number[^54]. Termination requires the caller ID number to be either a Twilio DID on the account or a verified caller ID[^52]. See also [Wrong or missing caller ID on outbound calls](https://warmtransfer.net/knowledge/caller-id-presentation-problems). On origination, Twilio adds a Diversion header that notes the Twilio number that was dialed[^53]. On termination, Twilio forwards received Diversion headers to carriers[^55]. Twilio removes any Diversion header that contains the Twilio domain and fails Twilio's ownership check[^55]. ## Applicability Applies to: Microsoft Teams Phone Direct Routing and Twilio Elastic SIP Trunking. Deployments: on-premises and multi-tenant. Sources checked 2026-10-02. The standards evidence comes from these documents[^13][^30][^29][^31][^6][^5][^32][^33][^37][^34]: - RFC 3261[^13]. - RFC 3323[^29]. - RFC 3325[^30]. - RFC 5379[^31]. - RFC 5806[^6]. - RFC 6044[^5]. - RFC 7044[^32]. - RFC 8224[^33]. - RFC 8588[^37]. - draft-ietf-sip-privacy-04[^34]. The Microsoft evidence covers the Teams Phone Direct Routing gateway parameters ForwardPai and ForwardCallHistory[^45][^42]. The Twilio evidence covers Elastic SIP Trunking origination and termination[^53][^55]. ## What remains uncertain How US carriers use PAI, From and Diversion for billing and caller ID on forwarded calls is not covered by the sources below. Microsoft states that setting ForwardPai to True renders the From header anonymous[^44]. Whether that happens on every call or only on privacy-restricted calls is not covered by the sources below. STIR/SHAKEN attestation of anonymous or `Privacy: id` calls is not covered by the sources below. RFC 6044 documents a mapping between Diversion and History-Info[^4]. SBC configuration for Diversion to History-Info interworking on specific SBC products is not covered by the sources below. The P-Charge-Info billing header is not covered by the sources below. The section locators for a STIR diversion extension and for response-code handling in RFC 8224 are not covered by the sources below. RFC 5379 requires a privacy service to delete P-Asserted-Identity when `Privacy: id` is requested[^31]. Its per-priv-value header actions for other headers, including History-Info, are not covered by the sources below. P-Asserted-Identity handling in IMS networks under 3GPP specifications is not covered by the sources below. ## Sources [^1]: The recommended anonymous From header is display name Anonymous with URI sip:anonymous@anonymous.invalid. Source: [RFC 3323: A Privacy Mechanism for the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc3323.html), Section 4.1.1.3. Checked 2026-10-02. [^2]: An RFC 8946 retargeting entity must not remove the original Identity header when it adds a div PASSporT, so both travel together. Source: [RFC 8946: Personal Assertion Token (PASSporT) Extension for Diverted Calls](https://www.rfc-editor.org/rfc/rfc8946.html), Authentication service behaviour for div (section not confirmed). Checked 2026-10-02. [^3]: RFC 8946 (February 2021) defines a div PASSporT so that a retargeted call can show that the original called number no longer matches the new destination, distinguishing legitimate forwarding from replayed tokens. Source: [RFC 8946: Personal Assertion Token (PASSporT) Extension for Diverted Calls](https://www.rfc-editor.org/rfc/rfc8946.html), Section 1 (Introduction). Checked 2026-10-02. [^4]: RFC 6044 maps Diversion reason unconditional to History-Info cause 302, user-busy to 486 and no-answer to 408. Source: [Mapping and Interworking of Diversion Information between Diversion and History-Info Headers in SIP](https://www.rfc-editor.org/rfc/rfc6044.html), Section 5 (Diversion Header to History-Info Header), mapping table. Checked 2026-10-02. [^5]: RFC 6044 states that new implementation and deployment of the Diversion header is strongly discouraged. Source: [Mapping and Interworking of Diversion Information between Diversion and History-Info Headers in SIP](https://www.rfc-editor.org/rfc/rfc6044.html), Section 1.1 (Overview). Checked 2026-10-02. [^6]: RFC 5806, which documents the Diversion header, was published in March 2010 with Historic status. Source: [RFC 5806: Diversion Indication in SIP](https://www.rfc-editor.org/rfc/rfc5806.html), RFC header (Category: Historic). Checked 2026-10-02. [^7]: The RFC 5806 IESG Note says Diversion was an early proposal not chosen for standardization, and that the standard solution chosen is History-Info (RFC 4244). Source: [RFC 5806: Diversion Indication in SIP](https://www.rfc-editor.org/rfc/rfc5806.html), IESG Note. Checked 2026-10-02. [^8]: Besides reason, the Diversion header defines counter, limit, privacy (full, name, uri, off) and screen (yes, no) parameters. Source: [RFC 5806: Diversion Indication in SIP](https://www.rfc-editor.org/rfc/rfc5806.html), Section 4 (Extension Syntax). Checked 2026-10-02. [^9]: RFC 5806 says existing Diversion headers received in a request or response must not be removed or changed when the message is forwarded. Source: [RFC 5806: Diversion Indication in SIP](https://www.rfc-editor.org/rfc/rfc5806.html), Section 3.1 (When Is the Diversion Header Used?). Checked 2026-10-02. [^10]: When a call is diverted, the added Diversion header must contain the Request-URI the request had before the diversion. Source: [RFC 5806: Diversion Indication in SIP](https://www.rfc-editor.org/rfc/rfc5806.html), Section 3.1. Checked 2026-10-02. [^11]: Diversion reason values include unknown, user-busy, no-answer, unavailable, unconditional, time-of-day, do-not-disturb, deflection, follow-me, out-of-service and away. Source: [RFC 5806: Diversion Indication in SIP](https://www.rfc-editor.org/rfc/rfc5806.html), Section 4 (Extension Syntax). Checked 2026-10-02. [^12]: Diversion entries are in reverse chronological order (the first entry is the last diverting user), whereas History-Info entries are chronological. Source: [Mapping and Interworking of Diversion Information between Diversion and History-Info Headers in SIP](https://www.rfc-editor.org/rfc/rfc6044.html), Section 1.2 (Background). Checked 2026-10-02. [^13]: In RFC 3261 the From header indicates the logical identity of the request initiator, possibly the user's address-of-record, and is supplied by the user agent rather than asserted by the network. Source: [RFC 3261 — SIP: Session Initiation Protocol](https://www.rfc-editor.org/rfc/rfc3261.html), Section 8.1.1.3 (From). Checked 2026-10-02. [^14]: Each History-Info entry carries an index made of dot-separated nonnegative integers (for example 1.1.2) that encodes forward hops and retargets as a tree. Source: [RFC 7044: An Extension to the Session Initiation Protocol (SIP) for Request History Information](https://www.rfc-editor.org/rfc/rfc7044.html), Section 5 (History-Info Header Field Protocol Structure). Checked 2026-10-02. [^15]: An RFC 7044 intermediary forwarding a request must include all cached hi-entries, so History-Info accumulates rather than being replaced hop by hop. Source: [RFC 7044: An Extension to the Session Initiation Protocol (SIP) for Request History Information](https://www.rfc-editor.org/rfc/rfc7044.html), Section 9.2. Checked 2026-10-02. [^16]: The History-Info mp parameter marks an entry where the request was retargeted to a different user than the one targeted by the incoming Request-URI, which is the forwarded-call case. Source: [RFC 7044: An Extension to the Session Initiation Protocol (SIP) for Request History Information](https://www.rfc-editor.org/rfc/rfc7044.html), Section 5 (mp parameter). Checked 2026-10-02. [^17]: RFC 7044 adds the Privacy priv-value history, which requests anonymization of History-Info entries when they leave the domain. Source: [RFC 7044: An Extension to the Session Initiation Protocol (SIP) for Request History Information](https://www.rfc-editor.org/rfc/rfc7044.html), Section 10.1 and Section 14.2 (registration). Checked 2026-10-02. [^18]: The History-Info rc parameter marks an entry where the Request-URI changed but the target user stayed the same. Source: [RFC 7044: An Extension to the Session Initiation Protocol (SIP) for Request History Information](https://www.rfc-editor.org/rfc/rfc7044.html), Section 5 (rc parameter). Checked 2026-10-02. [^19]: The reason a request was retargeted is carried as a Reason header embedded in the hi-targeted-to-uri, reflecting the non-100, non-2xx SIP response that triggered the retarget. Source: [RFC 7044: An Extension to the Session Initiation Protocol (SIP) for Request History Information](https://www.rfc-editor.org/rfc/rfc7044.html), Section 10.2. Checked 2026-10-02. [^20]: A SIP entity must not include History-Info in a response if the request had no hi-entries and did not carry the histinfo option tag in Supported. Source: [RFC 7044: An Extension to the Session Initiation Protocol (SIP) for Request History Information](https://www.rfc-editor.org/rfc/rfc7044.html), Section 9.4. Checked 2026-10-02. [^21]: A P-Asserted-Identity header may carry one value (a SIP, SIPS or tel URI) or two values, in which case one is a SIP or SIPS URI and the other a tel URI. Source: [RFC 3325: Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks](https://www.rfc-editor.org/rfc/rfc3325.html), Section 9.1 (The P-Asserted-Identity Header). Checked 2026-10-02. [^22]: When a request carries Privacy: id, a Trust Domain proxy must remove all P-Asserted-Identity headers before forwarding to elements that are not trusted. Source: [RFC 3325: Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks](https://www.rfc-editor.org/rfc/rfc3325.html), Section 7. Checked 2026-10-02. [^23]: RFC 3325 asserted identity is only meaningful inside a Trust Domain whose members follow a shared specification called Spec(T) that covers authentication, inter-node security, membership and default privacy handling. Source: [RFC 3325: Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks](https://www.rfc-editor.org/rfc/rfc3325.html), Section 1 (Applicability Statement, Spec(T) list). Checked 2026-10-02. [^24]: Under RFC 3325 a proxy must not pass on a P-Asserted-Identity received from an element it does not trust as-is; it either replaces the asserted value with its own or removes the header. Source: [RFC 3325: Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks](https://www.rfc-editor.org/rfc/rfc3325.html), Section 5 (Proxy behavior). Checked 2026-10-02. [^25]: Taken together, the sources show From as a user-supplied, displayable identity and PAI as the network-asserted identity, which is why platforms can show an anonymous or main-number From while carrying the real caller in PAI for billing or attestation (inferred). Source: [RFC 3325: Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks](https://www.rfc-editor.org/rfc/rfc3325.html), Sections 1 and 9.1, read with RFC 3261 8.1.1.3 and Microsoft ForwardPai Example 2. Checked 2026-10-02. [^26]: A proxy in the Trust Domain that receives P-Preferred-Identity from a user agent removes that header from any message it forwards, using it only as a hint for which identity to assert. Source: [RFC 3325: Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks](https://www.rfc-editor.org/rfc/rfc3325.html), Section 6 (Proxy behavior) and Section 9.2. Checked 2026-10-02. [^27]: The id priv-value for the Privacy header is defined by RFC 3325, not RFC 3323, and requests that the network-asserted identity be kept private from entities outside the Trust Domain. Source: [RFC 3325: Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks](https://www.rfc-editor.org/rfc/rfc3325.html), Section 9.3. Checked 2026-10-02. [^28]: An RFC 3323 privacy service is a network intermediary, acting as a back-to-back user agent where needed, that obscures identity-revealing headers a user agent cannot hide itself. Source: [RFC 3323: A Privacy Mechanism for the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc3323.html), Section 5. Checked 2026-10-02. [^29]: RFC 3323 (Standards Track, November 2002) defines the Privacy header priv-values header, session, user, none and critical. Source: [RFC 3323: A Privacy Mechanism for the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc3323.html), Section 4.2. Checked 2026-10-02. [^30]: RFC 3325, which defines P-Asserted-Identity and P-Preferred-Identity, is an Informational RFC published in November 2002, not a Standards Track document. Source: [RFC 3325: Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks](https://www.rfc-editor.org/rfc/rfc3325.html), RFC header (Category: Informational). Checked 2026-10-02. [^31]: RFC 5379 privacy guidelines state that a privacy service must delete P-Asserted-Identity headers when user privacy is requested with Privacy: id. Source: [Guidelines for Using the Privacy Mechanism for SIP](https://www.rfc-editor.org/rfc/rfc5379.html), Section 5.1.8 (P-Asserted-Identity). Checked 2026-10-02. [^32]: RFC 7044 (Standards Track, February 2014) defines History-Info and obsoletes RFC 4244. Source: [RFC 7044: An Extension to the Session Initiation Protocol (SIP) for Request History Information](https://www.rfc-editor.org/rfc/rfc7044.html), RFC header (Obsoletes: 4244; Category: Standards Track). Checked 2026-10-02. [^33]: RFC 8224 (Standards Track, February 2018) defines the SIP Identity header carrying a PASSporT signature and obsoletes RFC 4474. Source: [RFC 8224: Authenticated Identity Management in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc8224.html), RFC header and Section 1. Checked 2026-10-02. [^34]: Remote-Party-ID comes from draft-ietf-sip-privacy-04, an IETF Internet-Draft dated February 2002 that expired and never became an RFC. Source: [draft-ietf-sip-privacy-04 (IETF SIP WG Internet-Draft defining Remote-Party-ID)](https://datatracker.ietf.org/doc/html/draft-ietf-sip-privacy-04), Datatracker document status and header. Checked 2026-10-02. [^35]: The Remote-Party-ID draft explicitly says it does not offer a general privacy or identity model suitable for inter-domain or Internet-wide use. Source: [draft-ietf-sip-privacy-04 (IETF SIP WG Internet-Draft defining Remote-Party-ID)](https://datatracker.ietf.org/doc/html/draft-ietf-sip-privacy-04), Section 2. Checked 2026-10-02. [^36]: Remote-Party-ID carries a party parameter (calling or called), screen (yes or no, default no), privacy (full, name, uri or off) and id-type (subscriber, user or term). Source: [draft-ietf-sip-privacy-04 (IETF SIP WG Internet-Draft defining Remote-Party-ID)](https://datatracker.ietf.org/doc/html/draft-ietf-sip-privacy-04), Section 6.1. Checked 2026-10-02. [^37]: The SHAKEN PASSporT attest claim takes A (full), B (partial) or C (gateway) as its value. Source: [RFC 8588: Personal Assertion Token (PaSSporT) Extension for Signature-based Handling of Asserted information using toKENs (SHAKEN)](https://www.rfc-editor.org/rfc/rfc8588.html), Section 4 (attest claim). Checked 2026-10-02. [^38]: RFC 8588 itself does not specify whether the signed orig number comes from From or P-Asserted-Identity; that choice is left to RFC 8224 local policy and the SHAKEN profile (inferred). Source: [RFC 8588: Personal Assertion Token (PaSSporT) Extension for Signature-based Handling of Asserted information using toKENs (SHAKEN)](https://www.rfc-editor.org/rfc/rfc8588.html), Whole document (absence of header-selection text, as reported by fetch). Checked 2026-10-02. [^39]: RFC 8224 defines response codes 428 Use Identity Header, 436 Bad Identity Info, 437 Unsupported Credential and 438 Invalid Identity Header. Source: [RFC 8224: Authenticated Identity Management in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc8224.html), Response code definitions (Section 6.2.2 area; section not confirmed). Checked 2026-10-02. [^40]: In ordinary RFC 8224 operation the originating identity signed is taken from the addr-spec of the From header, and the destination from the addr-spec of the To header. Source: [RFC 8224: Authenticated Identity Management in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc8224.html), Sections 4 and 8 (identity extraction; PASSporT orig and dest). Checked 2026-10-02. [^41]: RFC 8224 says its guidance also applies when local policy takes the originator's identity from P-Asserted-Identity instead of From. Source: [RFC 8224: Authenticated Identity Management in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc8224.html), Section 8 (Identity Types). Checked 2026-10-02. [^42]: The Direct Routing gateway parameter ForwardCallHistory defaults to False and, when enabled, makes the PSTN proxy send History-Info and Referred-By headers. Source: [Set-CsOnlinePSTNGateway (MicrosoftTeams)](https://learn.microsoft.com/en-us/powershell/module/microsoftteams/set-csonlinepstngateway), Parameters > -ForwardCallHistory. Checked 2026-10-02. [^43]: Because the Direct Routing protocol page documents History-Info but not Diversion for forwarded calls, an SBC facing a carrier that requires Diversion probably has to synthesize it from History-Info (inferred). Source: [Teams Phone System Direct Routing: SIP protocol](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-protocols-sip), Call forwarding; History-Info header (absence of Diversion). Checked 2026-10-02. [^44]: Microsoft states that setting ForwardPai to True renders the From header anonymous, citing RFC 5379 and RFC 3325. Source: [Set-CsOnlinePSTNGateway (MicrosoftTeams)](https://learn.microsoft.com/en-us/powershell/module/microsoftteams/set-csonlinepstngateway), Parameters > -ForwardPai. Checked 2026-10-02. [^45]: The Direct Routing gateway parameter ForwardPai controls whether P-Asserted-Identity is sent toward the SBC and defaults to False. Source: [Set-CsOnlinePSTNGateway (MicrosoftTeams)](https://learn.microsoft.com/en-us/powershell/module/microsoftteams/set-csonlinepstngateway), Parameters > -ForwardPai. Checked 2026-10-02. [^46]: On inbound Direct Routing calls Microsoft uses the From header, which must carry a + prefixed number, to check the callee's blocked-number list and to look up the caller's name. Source: [Teams Phone System Direct Routing: SIP protocol](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-protocols-sip), Processing the incoming request > From Header. Checked 2026-10-02. [^47]: Direct Routing adds History-Info for simultaneous ring and call forwarding, rebuilding entries as phone-number URIs on sip.pstnhub.microsoft.com with user=phone. Source: [Teams Phone System Direct Routing: SIP protocol](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-protocols-sip), History-Info header. Checked 2026-10-02. [^48]: Microsoft says inbound History-Info is preserved when ForwardCallHistory is enabled and that History-Info should be used for loop prevention on forwarded calls. Source: [Teams Phone System Direct Routing: SIP protocol](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-protocols-sip), Call forwarding; History-Info header. Checked 2026-10-02. [^49]: Direct Routing does not add History-Info for call transfer cases. Source: [Teams Phone System Direct Routing: SIP protocol](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-protocols-sip), History-Info header. Checked 2026-10-02. [^50]: Microsoft forwards History-Info entries marked private as-is to the SIP trunk provider because it treats that provider as a trusted peer. Source: [Teams Phone System Direct Routing: SIP protocol](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-protocols-sip), History-Info header (Note). Checked 2026-10-02. [^51]: With ForwardPai enabled, Direct Routing reports the calling user's TEL URI and SIP address in P-Asserted-Identity, which Microsoft describes as useful for billing when the displayed caller ID is Anonymous or a company main number. Source: [Set-CsOnlinePSTNGateway (MicrosoftTeams)](https://learn.microsoft.com/en-us/powershell/module/microsoftteams/set-csonlinepstngateway), Examples > Example 2. Checked 2026-10-02. [^52]: Twilio Elastic SIP Trunking termination requires the caller ID number to be a Twilio DID on the account or a verified caller ID. Source: [Elastic SIP Trunking](https://www.twilio.com/docs/sip-trunking), Allowed Caller ID Numbers in Termination calls. Checked 2026-10-02. [^53]: On Twilio Elastic SIP Trunking origination, Twilio adds a Diversion header noting the Twilio number that was dialed. Source: [Elastic SIP Trunking](https://www.twilio.com/docs/sip-trunking), SIP Diversion Headers > Trunking Origination. Checked 2026-10-02. [^54]: On Twilio Elastic SIP Trunking termination, if no caller ID number is in the INVITE From field, Twilio uses Remote-Party-ID or P-Asserted-Identity instead. Source: [Elastic SIP Trunking](https://www.twilio.com/docs/sip-trunking), Allowed Caller ID Numbers in Termination calls. Checked 2026-10-02. [^55]: On Twilio termination, received Diversion headers are forwarded to carriers, but any Diversion header containing the Twilio domain that fails Twilio's ownership check is removed. Source: [Elastic SIP Trunking](https://www.twilio.com/docs/sip-trunking), SIP Diversion Headers > Trunking Termination. Checked 2026-10-02.