WarmTransfer
sip media · published

SIP identity headers: P-Asserted-Identity and Diversion and History-Info

Verified 2026-10-02 · 55 sources · tier 1–2

Also known as p-asserted-identity, remote-party-id, sip-diversion-header, sip-history-info-header.

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.

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.

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.

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.

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.

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.

See also

Related to

Referenced by

Sources

  1. 1
    The recommended anonymous From header is display name Anonymous with URI sip:anonymous@anonymous.invalid.
    RFC 3323: A Privacy Mechanism for the Session Initiation Protocol (SIP) · Section 4.1.1.3 · Checked 2026-10-02
  2. 2
    An RFC 8946 retargeting entity must not remove the original Identity header when it adds a div PASSporT, so both travel together.
    RFC 8946: Personal Assertion Token (PASSporT) Extension for Diverted Calls · Authentication service behaviour for div (section not confirmed) · Checked 2026-10-02
  3. 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.
    RFC 8946: Personal Assertion Token (PASSporT) Extension for Diverted Calls · Section 1 (Introduction) · Checked 2026-10-02
  4. 4
    RFC 6044 maps Diversion reason unconditional to History-Info cause 302, user-busy to 486 and no-answer to 408.
    Mapping and Interworking of Diversion Information between Diversion and History-Info Headers in SIP · Section 5 (Diversion Header to History-Info Header), mapping table · Checked 2026-10-02
  5. 5
    RFC 6044 states that new implementation and deployment of the Diversion header is strongly discouraged.
    Mapping and Interworking of Diversion Information between Diversion and History-Info Headers in SIP · Section 1.1 (Overview) · Checked 2026-10-02
  6. 6
    RFC 5806, which documents the Diversion header, was published in March 2010 with Historic status.
    RFC 5806: Diversion Indication in SIP · RFC header (Category: Historic) · Checked 2026-10-02
  7. 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).
    RFC 5806: Diversion Indication in SIP · IESG Note · Checked 2026-10-02
  8. 8
    Besides reason, the Diversion header defines counter, limit, privacy (full, name, uri, off) and screen (yes, no) parameters.
    RFC 5806: Diversion Indication in SIP · Section 4 (Extension Syntax) · Checked 2026-10-02
  9. 9
    RFC 5806 says existing Diversion headers received in a request or response must not be removed or changed when the message is forwarded.
    RFC 5806: Diversion Indication in SIP · Section 3.1 (When Is the Diversion Header Used?) · Checked 2026-10-02
  10. 10
    When a call is diverted, the added Diversion header must contain the Request-URI the request had before the diversion.
    RFC 5806: Diversion Indication in SIP · Section 3.1 · Checked 2026-10-02
  11. 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.
    RFC 5806: Diversion Indication in SIP · Section 4 (Extension Syntax) · Checked 2026-10-02
  12. 12
    Diversion entries are in reverse chronological order (the first entry is the last diverting user), whereas History-Info entries are chronological.
    Mapping and Interworking of Diversion Information between Diversion and History-Info Headers in SIP · Section 1.2 (Background) · Checked 2026-10-02
  13. 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.
    RFC 3261 — SIP: Session Initiation Protocol · Section 8.1.1.3 (From) · Checked 2026-10-02
  14. 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.
    RFC 7044: An Extension to the Session Initiation Protocol (SIP) for Request History Information · Section 5 (History-Info Header Field Protocol Structure) · Checked 2026-10-02
  15. 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.
    RFC 7044: An Extension to the Session Initiation Protocol (SIP) for Request History Information · Section 9.2 · Checked 2026-10-02
  16. 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.
    RFC 7044: An Extension to the Session Initiation Protocol (SIP) for Request History Information · Section 5 (mp parameter) · Checked 2026-10-02
  17. 17
    RFC 7044 adds the Privacy priv-value history, which requests anonymization of History-Info entries when they leave the domain.
    RFC 7044: An Extension to the Session Initiation Protocol (SIP) for Request History Information · Section 10.1 and Section 14.2 (registration) · Checked 2026-10-02
  18. 18
    The History-Info rc parameter marks an entry where the Request-URI changed but the target user stayed the same.
    RFC 7044: An Extension to the Session Initiation Protocol (SIP) for Request History Information · Section 5 (rc parameter) · Checked 2026-10-02
  19. 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.
    RFC 7044: An Extension to the Session Initiation Protocol (SIP) for Request History Information · Section 10.2 · Checked 2026-10-02
  20. 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.
    RFC 7044: An Extension to the Session Initiation Protocol (SIP) for Request History Information · Section 9.4 · Checked 2026-10-02
  21. 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.
    RFC 3325: Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks · Section 9.1 (The P-Asserted-Identity Header) · Checked 2026-10-02
  22. 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.
    RFC 3325: Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks · Section 7 · Checked 2026-10-02
  23. 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.
    RFC 3325: Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks · Section 1 (Applicability Statement, Spec(T) list) · Checked 2026-10-02
  24. 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.
    RFC 3325: Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks · Section 5 (Proxy behavior) · Checked 2026-10-02
  25. 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
    RFC 3325: Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks · Sections 1 and 9.1, read with RFC 3261 8.1.1.3 and Microsoft ForwardPai Example 2 · Checked 2026-10-02
  26. 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.
    RFC 3325: Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks · Section 6 (Proxy behavior) and Section 9.2 · Checked 2026-10-02
  27. 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.
    RFC 3325: Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks · Section 9.3 · Checked 2026-10-02
  28. 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.
    RFC 3323: A Privacy Mechanism for the Session Initiation Protocol (SIP) · Section 5 · Checked 2026-10-02
  29. 29
    RFC 3323 (Standards Track, November 2002) defines the Privacy header priv-values header, session, user, none and critical.
    RFC 3323: A Privacy Mechanism for the Session Initiation Protocol (SIP) · Section 4.2 · Checked 2026-10-02
  30. 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.
    RFC 3325: Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks · RFC header (Category: Informational) · Checked 2026-10-02
  31. 31
    RFC 5379 privacy guidelines state that a privacy service must delete P-Asserted-Identity headers when user privacy is requested with Privacy: id.
    Guidelines for Using the Privacy Mechanism for SIP · Section 5.1.8 (P-Asserted-Identity) · Checked 2026-10-02
  32. 32
    RFC 7044 (Standards Track, February 2014) defines History-Info and obsoletes RFC 4244.
    RFC 7044: An Extension to the Session Initiation Protocol (SIP) for Request History Information · RFC header (Obsoletes: 4244; Category: Standards Track) · Checked 2026-10-02
  33. 33
    RFC 8224 (Standards Track, February 2018) defines the SIP Identity header carrying a PASSporT signature and obsoletes RFC 4474.
    RFC 8224: Authenticated Identity Management in the Session Initiation Protocol (SIP) · RFC header and Section 1 · Checked 2026-10-02
  34. 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.
    draft-ietf-sip-privacy-04 (IETF SIP WG Internet-Draft defining Remote-Party-ID) · Datatracker document status and header · Checked 2026-10-02
  35. 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.
    draft-ietf-sip-privacy-04 (IETF SIP WG Internet-Draft defining Remote-Party-ID) · Section 2 · Checked 2026-10-02
  36. 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).
    draft-ietf-sip-privacy-04 (IETF SIP WG Internet-Draft defining Remote-Party-ID) · Section 6.1 · Checked 2026-10-02
  37. 37
    The SHAKEN PASSporT attest claim takes A (full), B (partial) or C (gateway) as its value.
    RFC 8588: Personal Assertion Token (PaSSporT) Extension for Signature-based Handling of Asserted information using toKENs (SHAKEN) · Section 4 (attest claim) · Checked 2026-10-02
  38. 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
    RFC 8588: Personal Assertion Token (PaSSporT) Extension for Signature-based Handling of Asserted information using toKENs (SHAKEN) · Whole document (absence of header-selection text, as reported by fetch) · Checked 2026-10-02
  39. 39
    RFC 8224 defines response codes 428 Use Identity Header, 436 Bad Identity Info, 437 Unsupported Credential and 438 Invalid Identity Header.
    RFC 8224: Authenticated Identity Management in the Session Initiation Protocol (SIP) · Response code definitions (Section 6.2.2 area; section not confirmed) · Checked 2026-10-02
  40. 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.
    RFC 8224: Authenticated Identity Management in the Session Initiation Protocol (SIP) · Sections 4 and 8 (identity extraction; PASSporT orig and dest) · Checked 2026-10-02
  41. 41
    RFC 8224 says its guidance also applies when local policy takes the originator's identity from P-Asserted-Identity instead of From.
    RFC 8224: Authenticated Identity Management in the Session Initiation Protocol (SIP) · Section 8 (Identity Types) · Checked 2026-10-02
  42. 42
    The Direct Routing gateway parameter ForwardCallHistory defaults to False and, when enabled, makes the PSTN proxy send History-Info and Referred-By headers.
    Set-CsOnlinePSTNGateway (MicrosoftTeams) · Parameters > -ForwardCallHistory · Checked 2026-10-02
  43. 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
    Teams Phone System Direct Routing: SIP protocol · Call forwarding; History-Info header (absence of Diversion) · Checked 2026-10-02
  44. 44
    Microsoft states that setting ForwardPai to True renders the From header anonymous, citing RFC 5379 and RFC 3325.
    Set-CsOnlinePSTNGateway (MicrosoftTeams) · Parameters > -ForwardPai · Checked 2026-10-02
  45. 45
    The Direct Routing gateway parameter ForwardPai controls whether P-Asserted-Identity is sent toward the SBC and defaults to False.
    Set-CsOnlinePSTNGateway (MicrosoftTeams) · Parameters > -ForwardPai · Checked 2026-10-02
  46. 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.
    Teams Phone System Direct Routing: SIP protocol · Processing the incoming request > From Header · Checked 2026-10-02
  47. 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.
    Teams Phone System Direct Routing: SIP protocol · History-Info header · Checked 2026-10-02
  48. 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.
    Teams Phone System Direct Routing: SIP protocol · Call forwarding; History-Info header · Checked 2026-10-02
  49. 49
    Direct Routing does not add History-Info for call transfer cases.
    Teams Phone System Direct Routing: SIP protocol · History-Info header · Checked 2026-10-02
  50. 50
    Microsoft forwards History-Info entries marked private as-is to the SIP trunk provider because it treats that provider as a trusted peer.
    Teams Phone System Direct Routing: SIP protocol · History-Info header (Note) · Checked 2026-10-02
  51. 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.
    Set-CsOnlinePSTNGateway (MicrosoftTeams) · Examples > Example 2 · Checked 2026-10-02
  52. 52
    Twilio Elastic SIP Trunking termination requires the caller ID number to be a Twilio DID on the account or a verified caller ID.
    Elastic SIP Trunking · Allowed Caller ID Numbers in Termination calls · Checked 2026-10-02
  53. 53
    On Twilio Elastic SIP Trunking origination, Twilio adds a Diversion header noting the Twilio number that was dialed.
    Elastic SIP Trunking · SIP Diversion Headers > Trunking Origination · Checked 2026-10-02
  54. 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.
    Elastic SIP Trunking · Allowed Caller ID Numbers in Termination calls · Checked 2026-10-02
  55. 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.
    Elastic SIP Trunking · SIP Diversion Headers > Trunking Termination · Checked 2026-10-02

Documents

tier 1 standards and regulators

draft-ietf-sip-privacy-04 (IETF SIP WG Internet-Draft defining Remote-Party-ID)

IETF Datatracker · 2002-02-27 · accessed 2026-10-02

tier 1 standards and regulators

Guidelines for Using the Privacy Mechanism for SIP

IETF / RFC Editor · 2010-02-01 · accessed 2026-10-02

tier 1 standards and regulators

Mapping and Interworking of Diversion Information between Diversion and History-Info Headers in SIP

IETF / RFC Editor · 2010-10-01 · accessed 2026-10-02

tier 1 standards and regulators

RFC 3261 — SIP: Session Initiation Protocol

IETF / RFC Editor · 2002-06 · accessed 2026-09-04

tier 1 standards and regulators

RFC 3323: A Privacy Mechanism for the Session Initiation Protocol (SIP)

IETF / RFC Editor · 2002-11-01 · accessed 2026-09-25

tier 1 standards and regulators

RFC 3325: Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks

IETF / RFC Editor · 2002-11-01 · accessed 2026-09-25

tier 1 standards and regulators

RFC 5806: Diversion Indication in SIP

IETF / RFC Editor · 2010-03-01 · accessed 2026-09-25

tier 1 standards and regulators

RFC 7044: An Extension to the Session Initiation Protocol (SIP) for Request History Information

IETF / RFC Editor · 2014-02-01 · accessed 2026-09-25

tier 1 standards and regulators

RFC 8224: Authenticated Identity Management in the Session Initiation Protocol (SIP)

IETF / RFC Editor · 2018-02-01 · accessed 2026-09-25

tier 1 standards and regulators

RFC 8588: Personal Assertion Token (PaSSporT) Extension for Signature-based Handling of Asserted information using toKENs (SHAKEN)

IETF / RFC Editor · 2019-05-01 · accessed 2026-09-25

tier 1 standards and regulators

RFC 8946: Personal Assertion Token (PASSporT) Extension for Diverted Calls

IETF / RFC Editor · 2021-02-01 · accessed 2026-10-02

tier 2 current vendor documentation

Elastic SIP Trunking

Twilio · 2026-07-21 · accessed 2026-09-24

tier 2 current vendor documentation

Set-CsOnlinePSTNGateway (MicrosoftTeams)

Microsoft · 2026-04-27 · accessed 2026-09-25

tier 2 current vendor documentation

Teams Phone System Direct Routing: SIP protocol

Microsoft · 2026-08-21 · accessed 2026-09-23

Cite this page

APA

WarmTransfer. (2026, October 2). SIP identity headers: P-Asserted-Identity and Diversion and History-Info. WarmTransfer. https://warmtransfer.net/knowledge/sip-identity-headers

BibTeX

@misc{warmtransfer-sip-identity-headers,
  title  = {SIP identity headers: P-Asserted-Identity and Diversion and History-Info},
  author = {{WarmTransfer}},
  year   = {2026},
  url    = {https://warmtransfer.net/knowledge/sip-identity-headers},
  note   = {Verified 2026-10-02}
}