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 Flysip configuration.
-
Add missing features requested by customers.
To achieve these goals a notion of protocol-independent Privacy ID should be introduced in Flysip . 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 Flysip accepts P-Asserted-Identity and creates a session Identity based on received values.
-
Identity Schemas = Remote-Party-Id, P-Asserted-Identity means that Flysip accepts either P-Asserted-Identity or Remote-Party-Id but prefers the Remote-Party-Id over P-Asserted-Identity.
-
Identity Schemas = Disabled means that Flysip ignores any Identity headers.
Authentication with the Identity
Flysip 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 Flysip 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