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  processingCOMPLETED 

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