The Glade 4.0

Or, a left leaning cause which already had contact information for the people they intended to call did this to stir up some ****.

In comic strips the person on the left always speaks first. - George Carlin

People who are already predisposed to be against gun rights you mean?

More likely, NRA farmed a survey out to an incompetent company or someone spent thousands of dollars to run a campaign to reach out to a handful of people and convince them that the NRA REEEEALLLY supports gun rights?

I fail to see how this is either more likely or better satisfies Occam's Razor.

In comic strips the person on the left always speaks first. - George Carlin

I'm sure this is all true, and it's hardly impossible that what you're saying is the case, but again, I don't see how it's any greater strain of credibility to think perhaps someone was just pretending to be other than who they are on the phone. It doesn't need to have been any grand conspiracy, maybe just one or a few people crusading against the evil NRA in their free time.

In comic strips the person on the left always speaks first. - George Carlin

In comic strips the person on the left always speaks first. - George Carlin

What is involved in Spoofing caller ID?

P-Asserted-Identity
The P-Asserted-Identity header field can be used to convey the proven identity of the originator of a request within a trusted network. Since the From header field is populated by the originating UA it may not necessarly contain the actual identity. It usually is established by means of authentication between the originating UA and its outgoing proxy. The outgoing proxy then adds a P-Asserted-Identity header field to assert the identity of the originator to other proxies.

This header field has only meaning within what is called a trusted network by mutual aggreement on the requirements for its use by the parties involved.

The P-Asserted-Identity header field is defined in RFC 3325.

Construction Summary
The P-Asserted-Identity header field consists of one or two address specifications (a URI with an optional display name). If there is one address, it MUST contain a sip, sips or tel URI. If there are two, then one MUST contain a sip or sips URI and the other a tel URI.

Usage
Usage Summary

The P-Asserted-Identity header field is optional in requests and responses with the methods BYE, INVITE, NOTIFY, OPTIONS, REFER, and SUBSCRIBE. Usage with the methods MESSAGE and PUBLISH is not defined though likely to be permitted as well.

Use in Proxies

The P-Asserted-Identity header field is added optionally to a message by a proxy to identify the actual identity of the originator of the message it has established by certain means (for instance by digest authentication).

If a proxy receives a message that already has a P-Asserted-Identity header field, behavior depends on whether it trusts the last hop. If it does, it may use the identity stated in the header field for its own purposes. Otherwise it removes the header field.

Use in UAS

If a UAS trusts the proxy it received a request from and this request contains a P-Asserted-Identity header field, then the UAS can use the identity given in the header field to present it to the user.

Otherwise it has to disregard the header field completely.

Encryption

Due to its use by proxies, the P-Asserted-Identity header field cannot be encrypted.

References
Syntax and Semantics

RFC 3325, section 9.1 "P-Asserted-identity Header"

The P-Asserted-Identity header field is used among trusted SIP entities (typically intermediaries) to carry the identity of the user sending a SIP message as it was verified by authentication.

[...]

A P-Asserted-Identity header field value MUST consist of exactly one name-addr or addr-spec. There may be one or two P-Asserted-Identity values. If there is one value, it MUST be a sip, sips, or tel URI. If there are two values, one value MUST be a sip or sips URI and the other MUST be a tel URI.

Proxy Behavior

Summary
RFC 3325, section 5 "Proxy Behavior"

A proxy in a Trust Domain can receive a message from a node that it trusts, or a node that it does not trust. When a proxy receives a message from a node it does not trust and it wishes to add a P- Asserted-Identity header field, the proxy MUST authenticate the originator of the message, and use the identity which results from this authentication to insert a P-Asserted-Identity header field into the message.

If the proxy receives a message (request or response) from a node that it trusts, it can use the information in the P-Asserted-Identity header field, if any, as if it had authenticated the user itself.

RFC 3325, section 6 "Hints for Multiple Identities

If a P-Preferred-Identity header field is present in the message that a proxy receives from an entity that it does not trust, the proxy MAY use this information as a hint suggesting which of multiple valid identities for the authenticated user should be asserted. If such a hint does not correspond to any valid identity known to the proxy for that user, the proxy can add a P-Asserted-Identity header of its own construction, or it can reject the request (for example, with a 403 Forbidden). The proxy MUST remove the user-provided P-Preferred- Identity header from any message it forwards.

Adding a P-Asserted-Identity Header Field
RFC 3325, section 5 "Proxy Behavior"

If there is no P-Asserted-Identity header field present, a proxy MAY add one containing at most one SIP or SIPS URI, and at most one tel URL. If the proxy received the message from an element that it does not trust and there is a P-Asserted-Identity header present which contains a SIP or SIPS URI, the proxy MUST replace that SIP or SIPS URI with a single SIP or SIPS URI or remove this header field. Similarly, if the proxy received the message from an element that it does not trust and there is a P-Asserted-Identity header present which contains a tel URI, the proxy MUST replace that tel URI with a single tel URI or remove the header field.

Forwarding of Messages
RFC 3325, section 5 "Proxy Behavior"

When a proxy forwards a message to another node, it must first determine if it trusts that node or not. If it trusts the node, the proxy does not remove any P-Asserted-Identity header fields that it generated itself, or that it received from a trusted source. If it does not trust the element, then the proxy MUST examine the Privacy header field (if present) to determine if the user requested that asserted identity information be kept private.

Removing Header Field Before Forwarding Outside the Trusted Network
RFC 3325, section 7 "Requesting Privacy"

Parties who wish to request the removal of P-Asserted-Identity header fields before they are transmitted to an element that is not trusted may add the "id" privacy token defined in this document to the Privacy header field. The Privacy header field is defined in [6]. If this token is present, proxies MUST remove all the P-Asserted- Identity header fields before forwarding messages to elements that are not trusted. If the Privacy header field value is set to "none" then the proxy MUST NOT remove the P-Asserted-Identity header fields.

When a proxy is forwarding the request to an element that is not trusted and there is no Privacy header field, the proxy MAY include the P-Asserted-Identity header field or it MAY remove it. This decision is a policy matter of the Trust Domain and MUST be specified in Spec(T). It is RECOMMENDED that the P-Asserted-Identity header fields SHOULD NOT be removed unless local privacy policies prevent it, because removal may cause services based on Asserted Identity to fail.

However, it should be noted that unless all users of the Trust Domain have access to appropriate privacy services, forwarding of the P- Asserted-Identity may result in disclosure of information which the user has not requested and cannot prevent. It is therefore STRONGLY RECOMMENDED that all users have access to privacy services as described in this document.

[...]

If multiple P-Asserted-Identity header field values are present in a message, and privacy of the P-Asserted-Identity header field is requested, then all instances of the header field values MUST be removed before forwarding the request to an entity that is not trusted.

UAS Behavior

RFC 3325, section 8 "User Agent Server Behavior"

Typically, a user agent renders the value of a P-Asserted-Identity header field that it receives to its user. It may consider the identity provided by a Trust Domain to be privileged, or intrinsically more trustworthy than the From header field of a request. However, any specific behavior is specific to implementations or services. This document also does not mandate any user agent handling for multiple P-Asserted-Identity header field values that happen to appear in a message (such as a SIP URI alongside a tel URL).

However, if a User Agent Server receives a message from a previous element that it does not trust, it MUST NOT use the P-Asserted- Identity header field in any way.

If a UA is part of the Trust Domain from which it received a message containing a P-Asserted-Identity header field, then it can use the value freely but it MUST ensure that it does not forward the information to any element that is not part of the Trust Domain, if the user has requested that asserted identity information be kept private.

If a UA is not part of the Trust Domain from which it received a message containing a P-Asserted-Identity header field, then it can assume this information does not need to be kept private.

ABNF
XXX Will follow

Despite the ABNF, only one or two PAssertedID-value fields are allowed as per the text of RFC 3325