User Story

According to the new legislation in France all the providers must pass the information about operator who handles the call and city from which the call is made. This information must be passed in the P-Access-Network-Info (PANI) header.  Providers are to communicate 
P-Access-Network-Info to upstream providers, and relay P-Access-Network-Info from partners to upstream providers if exist.

The content of the PANI header should be as follows:

 P-Access-Network-Info: GSTN;operator-specific-GI="<R1R2C1C2C3C4C5XX>";network-provided

where R1R2C1C2C3C4C5XX:

• R1R2 are the 2 digits of the Operator Code; R1R2 value is static per operator and in case of Customer equals to 77
• C1C2C3C4C5 are the 5 digits of the Location Area Code (INSEE) from where the call is made;
• XX 2 digits between 0 to 9 (e.g. 00) for future use. At the moment it should contain 00.

Example: P-Access-Network-Info: GSTN;operator-specific-GI="552913900";network-provided

There are two types of Customers at the moment:

1) Direct Customers: the value for the PANI will be set by the Administrator according to the knowledge of the city they are located at. The INSEE value is also used for the Emergency Numbers. It is is available in Emergency Numbers system of the Service Provider for every Account. So the value for PANI for already created Accounts will be 'migrated' by means of API.

2) Service Providers which are created as Customers in the system. There are providers not capable of PANI generation, so some static value (as for the case of first type of Customers) should be passed in PANI header. If the provider is capable of PANI generation - simply relay passed value. In case the service provider did not inform that the passed PANI header is incorrect/missing, the bill from vendor will be greater thus it will be clear that there are issues on Customer side.

Use Cases

Use case #1:PANI header generation

Roles: Admin, Customer

Preconditions: PANI header generation is supported by PortaSwitch. 

There is API method to control PANI

Use scenario #1.1: Admin enables PANI header generation for Customer via web

Scenario:

• The administrator creates ABC Customer and enables PANI header generation for him. He knows that this Customer is from Paris and C1C2C3C4C5 of Paris is 12345. So he enters that 771234500 value will be passed in PANI.

• An Account of ABC Customer makes a call.

• The INVITE message sent to Vendor contains:

P-Access-Network-Info: GSTN;operator-specific-GI="771234500";network-provided

Use scenario #1.2: PANI header in case of forwarded call is not changed by the forwarder

• Continued after 1.1
• ABC Customer sets forward from his Account to external number.
• There is incoming call with the following PANI:
  P-Access-Network-Info: GSTN;operator-specific-GI="771234500";network-provided;
• Nobody picks up the phone so the call is forwarded with the same PANI:
  P-Access-Network-Info: GSTN;operator-specific-GI="771234500";network-provided;

Use scenario #1.3: Admin enables PANI header generation for Customer via API

• The administrator creates ABC Customer via external interface (API) and enables PANI header generation for him. Customer is created in PortaBilling. He knows that this Customer is from Paris and C1C2C3C4C5 of Paris is 12345. So he enters that 771234500 value will be passed in PANI. Information is passed and saved in PB.

• An Account of ABC Customer makes a call.

• The INVITE message sent to Vendor contains:

P-Access-Network-Info: GSTN;operator-specific-GI="771234500";network-provided

Use case #2:PANI header optional generation 

Roles: Admin, Customer

Preconditions: PANI header generation and relay is supported by PortaSwitch. 

There is provider ABCD who is created as Customer in the system.

Use scenario #2.1: Admin enables PANI header relay for Customer

• ABCD provider contacts Service Provider and informs that they will pass the PANI header from their side.

• The administrator opens ABCD Customer and marks that the received PANI should be simply relayed.

• The call is received from one of the ABCD Customer Accounts, it contains: 887854200

• The INVITE message sent to vendor contains:

P-Access-Network-Info: GSTN;operator-specific-GI="887854200";network-provided

Use scenario #2.2: Admin enables PANI header relay for Customer via API

• The same as in scenario 2.1 via API
  
  

Use scenario #2.3: Admin enables PANI header override for Customer 

• ABCD provider contacts Service Provider and informs that they will pass the PANI header from their end but as they can not manage it on their side, it should be always replaced with 887854200 value.

• The administrator opens ABCD Customer and marks that the received PANI should be always replaced with 887854200 value.

• The call is received from one of the ABCD Customer Accounts, it contains: 447854200

• The INVITE message sent to Vendor contains:

P-Access-Network-Info: GSTN;operator-specific-GI="887854200";network-provided

Use scenario #2.4: Admin enables PANI header relay for Customer via API

• The same as in scenario 2.3 via API
  
  

Use scenario #2.5: PANI header relay, if PANI is not present - default value is used

• ABCD provider contacts Service Provider and informs that they will pass the PANI header from their side.

• The administrator opens ABCD Customer and marks that the received PANI should be relayed.

• For the case when the call comes without PANI, Admin configures default value for the customer - 887854200

• The call is received from one of the ABCD Customer Accounts, it does not contain PANI 

• PortaSwitch uses default value configured for the customer

• The INVITE message sent to vendor contains:

P-Access-Network-Info: GSTN;operator-specific-GI="887854200";network-provided

 Use case #3:Calls coming through VfV connection

Roles: Admin, Customer

Preconditions: PANI header generation and relay is supported by PortaSwitch. 

There is provider EFG who is configured as Vendor with VfV connection in the system.

Use scenario #3.1: Admin enables PANI relay for the VfV connection, if value is not present - default value is used

• EFG provider contacts Service Provider and informs that they will pass the PANI header from their side.

• The administrator opens VfV connection of EFG and marks that the received PANI should be relayed.

• For the case when PANI is not present - Admin configures default value for VfV connection - 997854200

• The call is received via the VfV connection, it does not contain PANI 

• PortaSwitch uses default value, configured for VfV connection  - 997854200
• Call comes to an account, which has a forward to PSTN

• The outgoing INVITE message sent to vendor contains:

P-Access-Network-Info: GSTN;operator-specific-GI="997854200";network-provided

Other requirements / constraints

Customer sees the implementation like the one present for the "PAI" header.