Support for privacy flags

A user may sometimes indicate that he wants privacy for a particular outgoing call, e.g., the other party should not see his phone number. This can be done by either activating the privacy settings on the IP phone itself (in this case, the IP phone will include the corresponding RPID header in the SIP INVITE), or by activating the Hide CLI feature for a caller’s account in PortaSwitch. So when sending the call to a third-party carrier, PortaSIP must show the call information in such a way as to ensure the desired privacy.

Even if an end user requests that his identity be hidden from the called party, some vendors still request that his identification information be sent to them (so they can record this information for various purposes, such as abuse prevention or law enforcement). They will then take care of hiding it from the final recipient.

This actually means that PortaSwitch must send normal caller information along with a privacy flag that tells the vendor to withhold caller info from the final call recipient.

However, many other vendors do not have the capability to process privacy flags properly. In this case, PortaSwitch must remove the Caller ID from the call information before sending the call to such a carrier’s network. Since a vendor’s capabilities in this respect cannot be determined at the time a call is routed to his network, the desired method should be selected in the vendor’s connection configuration beforehand.

In addition, you must configure the service policy for that vendor connection to instruct PortaSIP to properly process call information whenever a call with a “privacy” request is sent to that particular carrier.

The basic Caller ID mechanism works much as it does in the case of email. The caller information has a ‘From’ header field, including the address. For example:

From: "John Smith" <sip:1234@sip.example.com>;tag=0099-8877

which means that user John Smith with phone number 1234 is trying to initiate an outgoing call using the ‘sip.example.com’ server.

When the caller requests privacy (the Hide CLI feature is enabled) and the call recipient (the vendor or customer where the call is sent) is marked as “untrusted” (the Supply identity attribute is set to “No”), PortaSIP:

• adds an extra header (e.g., PAI, RPID or none) based on the service policy configuration, and
• replaces the display name in the ‘From’ header field of the outgoing INVITE request (“John Smith” in the example above) with “Anonymous”.

So the ‘From’ header field will look like this:

From: Anonymous <sip:sip.example.com>;tag=0099-8877

Alternatively, if the recipient is marked as “trusted” (the Supply identity attribute is set to “Yes”), PortaSIP adds an extra header the recipient requires based on their service policy configuration. The ‘From’ field is still anonymized; however, an extra header ‘Privacy: id’ indicating the request for privacy is added to the SIP packet according to the RFC 3323:

From: "John Smith" <sip:1234@sip.example.com>;tag=0099-8877,
Privacy: id
P-Asserted-Identity: <sip:1234@sip.example.com> 

Also, when someone other than the caller uses the PortaBilling web interface to view call records for calls where privacy has been requested, he will not see the actual phone number.

According to some European countries’ regulations (e.g., France’s legal requirements), service providers must send caller location information to their termination partners.

This information contains the operator’s code who processes the call and the code of the city where the call originates (the INSEE code in France) and is passed by PortaSwitch within the PANI (P-Access-Network-Info) SIP header in outgoing INVITE requests. Thus, PortaSwitch either generates the PANI value for an account or relays the value received during an incoming call.

Note that caller location information is sensitive. Therefore, your vendors who send/receive the PANI header must adhere to privacy regulations and be capable of correctly processing privacy information.

Support for PANI is determined by the service policy attribute geo_location_method. When combined with further system configurations, it determines how to process a call.

Let’s have a closer look at how it works:

To supply the PANI to a vendor when an account makes a call, the administrator configures the service policy and assigns it to this vendor’s outgoing connection. The connection that correctly processes privacy information is therefore marked as “trusted” (its Caller Identity option is set to Supply).

The administrator also defines the location within the account’s configuration by using the GSTNR1R2C1C2C3C4C5XX pattern, where: GSTN is the network definition, R1R2 is the service provider’s individual code, C1C2C3C4C5 is the city code, and XX are auxiliary digits (00 by default).

So then, when John Doe makes an outgoing call, the INVITE request to the vendor will contain the extra PANI header:

From: "John Doe" <sip:33045558909@sip.example.com>; 
tag=53qq3i7fo6eymuap.o
P-Access-Network-Info: GSTN;operator-specific-GI="771234500";
network-provided

where GSTN and 771234500 values are taken from John’s location information.

In wholesale service provisioning, calls that arrive to your network already contain PANI that is supplied by your customers. In these cases, PortaSwitch must obtain the PANI and relay it to the vendor.

To do this, the administrator configures a service policy and assigns it to a corresponding call handling rule.

Then the customer’s location is defined and the account is configured to trust the caller’s identity (the CLI Trust option is set to Caller only).

When the customer’s account makes a call, PortaSIP extracts the PANI and adds it to the outgoing INVITE request:

From: Amanda Smith <sip:33089123000@11.22.33.45>;
tag=y6reils4nf5oqkol.o
P-Access-Network-Info: GSTN;operator-specific-
GI="887854200";network-provided

If, for some reason, the customer is unable to provide the PANI, the administrator defines the default value for the customer:

In this case, PortaSwitch generates the PANI and sends it to the vendor, as described above.

When an incoming call arrives from an external network, it already contains the PANI provided by the vendor. Therefore, PortaSwitch must be configured to detect and process the PANI, or, if the PANI is absent or invalid, override it with a valid one.

This is done by adding a primary_location value to the service policy for the incoming vendor connection.

As with outgoing requests, the connection to deliver incoming calls must properly process privacy information (set the Caller Identity option to Accept).

When someone calls John Doe, PortaSwitch receives the following INVITE:

From: Jane Smith <sip:33129990215@sip.mycompany.com>; 
tag=qlxm7q4vitbfg6ew.o
P-Access-Network-Info: GSTN;operator-specific-
GI="886854200";network-provided

If John Doe does not answer the incoming call and has forwarding correctly configured, PortaSwitch will forward the call with the PANI to John’s mobile phone.

This enhancement ensures legitimate service provisioning for service providers in the European Union.