I 3 Forum CLI Delivery in International Voice

I 3 Forum CLI Delivery in International Voice Networks

Introduction • • • Issue 1 CLI Privacy Issue Description Issue 1 CLI Privacy Issue Proposal Issue 2 CLI Presentation Issue Description Issue 2 CLI Presentation Issue Proposal Issue 3 PAI Population Issue Description Issue 3 PAI Population Issue Proposal

Issue 1 – CLI Privacy - Issue As a communications provider, International Carriers have privileged access to CLI, which is personal data under EU legislation. CLIs that are withheld/restricted by user/CLIR are only passed between networks under special privileges granted to communications providers – by restricting the CLI, the user has told the originating network that they don’t want their CLI released to third parties, and the originator is only able to pass that restricted CLI to subsequent networks because there are special rules, that all EU communications providers are bound by.

Issue 1 – CLI Privacy - Issue The relevant regulation/guideline is: 9. 1 On Calls received from Electronic Communications Networks not covered by the Guidelines (eg international calls) the CLI information shall be classified by the receiving network as follows: 9. 1. 1 If an explicit indication is received that the calling party has wishes that his CLI should not be made available at the called customer’ access, then the CLI information shall be classified as ‘withheld’; 9. 1. 2 If an explicit indication is received that the originating network has restricted the CLI on behalf of the calling party, and that his CLI should not be made available at the called customer’s access, then the CLI information shall be classified as ‘unavailable’; 9. 1. 3 Otherwise, if CLI information is available, then it shall be classified as ‘available'. 9. 2 When a Call is routed to an Electronic Communications Network not covered by the Guidelines, e. g. international calls, the Communications Provider may not be in a position to guarantee that the caller’s wishes with regard to his CLI privacy will be respected by a subsequent network or the terminating network. 9. 3 Consequently, in order to avoid a caller’s identity being displayed to a called party in this case, the gateway exchange should delete all CLI information from the Call, if the CLI information has been classified as ‘withheld’ or ‘unavailable’. 9. 4 Alternatively, if it is known that the subsequent or terminating networks will respect the caller’s privacy wishes, then the CLI information may be passed in an appropriate format. A consequence of this is that if a call is passed to a network outside the EU, the last EU communications provider is only able to pass withheld CLIs if they can be sure that subsequent networks are governed by equivalent information privacy legislation to the EU – otherwise the CLI information should be removed.

Issue 1 – CLI Privacy - Proposal As an international carrier removal of the CLI will open the carrier up to A number surcharging (see issue 1) due to the lack of valid CLI in either the From or PAI fields. Proposal: • Utilise the privacy field within SIP to indicate that privacy has been requested • Change the from header to sip: anonymous@ and populate the PAI field with the correct A number Questions for an international network to consider with any proposal • How do they determine from the SIP message that a CLI is marked as ‘available’, ‘withheld’ or ‘unavailable’ (per regulation 9. 1) ? • How do they determine if the downstream carriers or networks comply with the regulations and will respect the callers wishes? • If an international network removes all CLI information from From and PAI they will be exposed to A number surcharging that they cannot pass on, should an international carrier worry?

Issue 2 – CLI Presentation - Issue International carriers are receiving SIP calls with different CLI’s in the From and PAI. For these two CLI’s in the SIP messages, one CLI is the actual network number that the call originates from that is included in the PAI field of the SIP message, the second is a presentation number for customer call back i. e. a local number that is being sent in the FROM field of the SIP message. This local number is and call back to this number back to the call centre is normally provided by ITFS products. The types of scenarios that are generating these include: • Call-centre customers present a display CLI relevant to the market to which the call is being placed i. e. a local call back number • Enterprise customers with multiple sites egressing to the public network via a single trunk pass a display CLI representing the caller/site that made the call • Call-centres serving multiple customer present a display CLI according to the client on whose behalf the call is placed • In-house call-centres present a different display CLI according to the department making the call The presentation of the number is governed by commercial and regulatory requirements for the UK Local Market under UK specs ND 1016 (CLI Requirements), ND 1035 (SIP Interface signalling) and ND 1017 (ISUP to SIP-I interworking). Similar requirements must exist in other markets.

Issue 2 – CLI Presentation - Proposals SIP presentation rule • Is From present? • If Yes and is a valid e 164 number and is present then use this for presentation • If Yes and contains sip: anonymous@ and the privacy setting is set then do not present a CLI • If No or it is not a valid e 164 number or sip: anonymous@ then continue below • Is PAI present? • If PAI is populated then use this for presentation • If PAI is not populated then do not present a CLI SIP to TDM translation and associated presentation as recommended in specification 3 GPP TS 29. 163 • Presentation CLI = Generic Number in TDM and From in SIP • Network CLI = ISUP Calling Party Number in TDM and PAI in SIP • What about privacy? Will moving across sip: anonymous@ work on TDM? Changes to SIP message to ensure correct presentation for call centres etc • If From is a valid e 164 number and distinct from PAID � • replace PAID with FROM number to ensure presentation? • Question: what if this impacts A number surcharging? Is presentation more important than billing?

Issue 3 – PAI Population - Issue SIP invite messages contain two fields that can be populated with the A or from number of the caller, the From field and the PAI field. The from field is always populated but can contain any alpha numeric values and can also be used to provide a display number that is not the real A number i. e. a local number for call centre calls. The PAI field if populated always contains the A number and is assured. Population of the PAI field is not mandatory within SIP protocol. The A Number is important internationally due to the implementation of A number surcharging and resulting A number routing that carriers will begin exploring in the near future if they are not already doing so. The issue is what do we do with SIP invites where we have no PAI populated? • Do we simply pass transit as received • Do we implement rules to try and populate • If we decide to populate the PAI is there any issue with this for A Number Surcharging

Issue 3 – PAI Population - Proposal Proposed Logic for PAI population: • If PAI is present do nothing • If PAI is not present: • Is the FROM a valid e 164 number? • Yes: generate PAI with FROM information • No: do nothing • For carriers that wish to reject this traffic do we recommend a set SIP response? Is there a proposal for which A number to use for A number surcharging? For A number billing does the following generic rule get applied: • If PAI is populated then use this as the A number for billing • If PAI is not populated check if From field contains a valid e 164 number • If From has a valid e 164 number then use this as the A number for billing • If From does not contain a valid e 164 number then treat SIP message as having no A number and bill accordingly