Earlier implementation details relevant for <=Sippy 2020 version could be found here:
https://support.sippysoft.com/a/solutions/articles/84156
The feature works based on RFC-3325 and draft-ietf-sip-privacy-04
Rationale
Existing privacy support consists of many often unrelated features which provide a very limited subset of privacy functionality and this creates a big and constant demand from customers for new and new scenarios.
The goals of refactoring are:
Make the privacy support consistent across multiple existing standards such as P-Asserted-Identity from RFC3325 and Remote-Party-Id from
draft-ietf-sip-privacy-04
Make it possible to convert from one standard to another. For example, receive a P-Asserted-Identity but send a Remote-Party-Id.
Streamline the Sippy configuration.
Add missing features requested by customers.
To achieve these goals a notion of protocol-independent Privacy ID should be introduced in Sippy. The Identity is neither P-Asserted-Identity nor Remote-Party-Id, but an internal generalized entity which exists for a session. The idea is to be able to receive the Identity using any protocol and also send it using any protocol.
The Identity of a session consists of:
ID of the caller (the username from P-Asserted-Identity or Remote-Party-Id)
the anonymity attribute
The anonymity attribute is conveyed by the Privacy: SIP header from RFC3325 or the ‘privacy’ parameter from the Remote-Party-Id: header which may be accompanied by the RPID-Privacy: header as stated in the corresponding standard.
Proposed Architecture
Features
The main features are:
Receive Identity
Authentication with the Identity
Send the received or generated Identity
Rewrite outgoing CLI based on Identity
CLI in the below documentation means username of From: header
Identity should never be sent to a registered account or trunk. The scenarios above are related to calls to vendors - as mentioned in SS-2728: Privacy header support and processing
Receive Identity
An Identity can be received from the caller. For that purpose an Account has Identity Schemas attribute which contains a list of acceptable protocols in the order of preference. For example:
Identity Schemas = P-Asserted-Identity means that Sippy accepts P-Asserted-Identity and creates a session Identity based on received values.
Identity Schemas = Remote-Party-Id, P-Asserted-Identity means that Sippy accepts either P-Asserted-Identity or Remote-Party-Id but prefers the Remote-Party-Id over P-Asserted-Identity.
Identity Schemas = Disabled means that Sippy ignores any Identity headers.
Authentication with the Identity
Sippy should be able to use the received Identity for authentication. An Account has a new attribute Trust Identity Headers which allows to use the received Identity instead of CLI when looking for Account or DID authentication rule.
Parameter Identity Auth Mode in System Parameters/ SIP, Media, LRN controls how the authentication should be performed:
Relaxed - try to authenticate against Identity first and then CLI and use whichever is successful
Strict - if Identity is received then do not try to use CLI for authentication. Default for old systems and new environments.
Mandatory - never use CLI and always rely only on Identity for authentication
Send the received or generated Identity
A Vendor Connection has Send Identity As attribute which dictates which standard is to be used to send the privacy information to the Vendor. Possible values are:
P-Asserted-Identity
Remote-Party-Id
Off
If the Identity has not been received from the caller then Sippy may generate it. A Connection should have a Use CLI as Identity parameter for that purpose.
Hide Own CLI parameter from Account’s preferences - Anonymous Calling section enforces the anonymity attribute in the IdentityD of the session.
The outgoing ‘P-Asserted-Identity’ and ‘Remote-Party-Id’ SIP headers are not sent if the Trusted Privacy Domain parameter on Connection is unchecked.
Headers that indicate privacy are sent if Send Identity As is set to non-off values:
case of P-Asserted-ID header Privacy with value id would be sent, even if Trusted Privacy Domain parameter on Connection is unchecked and no PAI is sent
case of Remote-Party-Id header Rpid-privacy with value party=calling;privacy=full would be sent, even if Trusted Privacy Domain parameter on Connection is unchecked and no RPID is sent
Rewrite outgoing CLI based on Identity
A Vendor Connection has Use Identity As CLI parameter in Advanced Parameters section.
Old scenarios that should be covered
Pass incoming PAI to Connection, then translate and send to Vendor
Set Identity Schemas on Account to P-Asserted-Identity, set checkbox for Pass Identity on Account, apply needed translation on Account and Connection for Identity Tr. Rule and choose on Connection Send Identity As = P-Asserted-Identity, set checkbox Trusted Privacy Domain on Connection.
Do not pass incoming PAI to Connection (Pass Identity on Account unchecked), generate it there instead based on the username of From: header (set checkbox Use CLI As Identity)
Unset Pass Identity checkbox on Account, set checkbox Use CLI As Identity on Connection, set Send Identity As = P-Asserted-Identity on Connection, set checkbox Trusted Privacy Domain on Connection
Translate From: header based on PAI received on Account
Set Identity Schemas on Account to P-Asserted-Identity, set checkbox for Pass Identity on Account, set checkbox Use Identity As CLI on Connection
Translate From: header based on Remote-Party-Id received on Account
Set Identity Schemas on Account to Remote-Party-Id, set checkbox for Pass Identity on Account, set checkbox Use Identity As CLI on Connection
New scenarios that should be covered
Authenticate call via received P-Asserted-Id, not From
Set checkbox Trust Identity Headers on Account, set Identity Schemas on Account to P-Asserted-Identity, in System Parameters/ SIP, Media, LRN set Identity Auth Mode to one of the options according to the requirement: relaxed/strict/mandatory
Authenticate call via received Remote-Party-Id, not From
Set checkbox Trust Identity Headers on Account, set Identity Schemas on Account to Remote-Party-Id, in System Parameters/ SIP, Media, LRN set Identity Auth Mode to one of the options according to the requirement: relaxed/strict/mandatory
Add to outgoing INVITE for Vendor a Privacy header with value = id when call was authenticated with one of the above methods
Set checkbox Trust Identity Headers on Account, set Identity Schemas on Account to P-Asserted-Identity, in System Parameters/ SIP, Media, LRN set Identity Auth Mode to one of the options according to the requirement: relaxed/strict/mandatory, set Send Identity ID As = P-Asserted-Identity on Connection
Do not pass incoming Remote-Party-Id to Connection, generate it there instead based on username of From: header
Unset Pass Identity Id checkbox on Account, set checkbox Use CLI As Identity on Connection, set Send Identity As = Remote-Party-Id on Connection, set checkbox Trusted Privacy Domain on Connection
Send Privacy: id when checkbox Hide Own CLI on Account is set or no CLI/Anonymous was received in incoming INVITE
Set Send Identity As = P-Asserted-Id on Connection, unset checkbox Trusted Privacy Domain on Connection. Note - P-Asserted-Id header would NOT be generated in this case, however Privacy header with value id would be added to outgoing INVITE
Send RPID-privacy when checkbox Hide Own CLI on Account is set or no CLI/Anonymous was received in incoming INVITE
Set Send Identity As = Remote-Party-Id , unset checkbox Trusted Privacy Domain on Connection. Note - Remote-Party-Id header would NOT be generated in this case, however RPID-Privacy header with value party=calling;privacy=full would be added to outgoing INVITE