Implemented according to RFC-3325

For Sippy 2021 and up the following documentation should be used:

https://support.sippysoft.com/a/solutions/articles/3000114366


The Sippy Softswitch processes Asserted Identity headers as follows.

  1. The softswitch can pass the P-Asserted-Identity SIP header from the incoming to the outgoing call leg.
  2. In case when no P-Asserted-Identity header is received, the softswitch can generate it based on the CLI value.
  3. The P-Preferred-Identity header is always removed.
  4. Support for the Privacy header was added starting from Sippy 2021

The username part in the URI of the Asserted Identity can be edited with a translation rule before sending the call out.


There are several configuration options for the Asserted Identity processing.

  • Account -> Pass P-Asserted-Id - controls if the P-Asserted-Identity SIP header is allowed to be passed to the outgoing call leg.
  • Account -> P-Asserted-Id Tr. Rule - translation rule which rewrites the username part of SIP URI of the received Asserted Identity.
  • Vendor Connection -> Use CLI As P-Asserted-Id - turns on generation of the P-Asserted-Identity header when no PAI received on the incoming call leg. If the Pass P-Asserted-Id option is turned off and this option is turned on then the PAI is always generated based on CLI.
  • Vendor Connection -> P-Asserted-Id Tr. Rule - translation rule which allows to edit the outgoing Asserted Identity. The translation rule is always applied to the Asserted Identity no matter whether it was received on the incoming call leg or it was generated locally. If the translation results in an empty string then the P-Asserted-Identity header is not sent at all.


Replace CLI with a number received from caller in either P-Asserted-Identity or Remote-Party-ID header (starting from 5.1 version)

Configuration is performed using Connection -> Privacy Mode. There are three modes:

  • Off - neither number from P-Asserted-Identity, nor Remote-Party-ID headers would affect the CLI that is sent to vendor
  • P-Asserted-Identity - CLI would be replaced with the number from P-Asserted-Identity header. If CLI translation rule is configured on Connection, it will be applied to the number from P-Asserted-Identity before sending INVITE to vendor. Case more then one P-Asserted-Identity headers were received, the number from last header would be used.
  • Remote-Party-ID - CLI would be replaced with the number from Remote-Party-ID header. If CLI translation rule is configured on Connection, it will be applied to the number from Remote-Party-ID before sending INVITE to vendor


Prioritize username part in the URI of the P-Asserted-Id header to username received in From header for call authentication (starting from 2021 version):

Case trust_privacy_hdrs is set to True on Account, incoming INVITE would be checked for P-Asserted-ID header presence, if found, the username part of URI in it would be used to look for match in Authentication Rules - Incoming CLI and DID Authentication Rules - Incoming CLI. 

When no match was found, regular check would be done using From header.


Another check would be done for Privacy header, if it was present, and contained id value, the outgoing INVITE to Vendor would have username part of URI in From header replaced with Anonymous value