Reviewers (YT:PMD-3632):

User Story

As a CSP operating in South Africa, I want PortaSwitch to:

  • check the CLI on inbound calls from vendors, using the vendor prefix list (defining what number prefixes belong to what vendor) and the Local Number Portability (LNP) database, to prevent spoofed calls – calls where the CLI doesn't belong to that vendor's network (natively or via a confirmed port) but to a competing ECNS-licensed provider in South Africa. A call with a spoofed CLI should be rejected.
  • check the CLI on outbound calls from my customers and resellers to vendors, using the same vendor prefix list and LNP database, so that CLI presentation stays ICASA-compliant: no customer or reseller can present a number that belongs to another ECNS-licensed provider, unless that number has been legally ported into my network.

As a CSP Admin, I want to set up CLI validation on outbound calls at the vendor connection level, so that I don't have to configure the existing "Override identity" feature to send valid CLIs for hundreds of resellers and thousands of accounts manually. I also want the rejection reason to show clearly in the call trace, so that I can find the cause without extra troubleshooting.

As a vendor or CSP customer/reseller, I want a rejected call to return a clear reason, so that I know why it failed without extra troubleshooting.


Example of use

CLI validation on Incoming call (From Vendor)

CSP has a 'From Vendor' connection for calls arriving from MTN into the CSP network. A call arrives on this connection with a CLI of 27731234567. The 2773 prefix is defined as covering MTN's numbers, but under South African LNP rules, individual numbers in this range may have been ported to another operator such as Cell C, or a transit vendor may be sending calls through the MTN connection with a CLI that differs from MTN's own range. PortaBilling checks the CLI against the vendor prefix list (which maps number prefixes to their originally allocated South African operator), the Number_Portability_Local table (populated nightly from the SA LNP authority), and the authorized transit vendor prefixes configured on the MTN connection. If any of these checks confirms the number belongs to MTN's network, was ported to MTN, or belongs to an authorized transit partner, the CLI is valid and the call proceeds. If none of the checks confirm a legitimate association with MTN, the call is rejected with SIP 603 Declined.

CLI validation on Outbound call (To Vendor)

CSP has a business customer, Acme Logistics, whose office PBX is registered on PortaSwitch. Acme Logistics places an outbound call from 27825559900  — a Vodacom mobile number that was never assigned to Acme Logistics or ported into the CSP network. 

PortaBilling checks 27825559900 against the vendor prefix list and the Number_Portability_Local table before the call is sent out. The prefix list confirms 2782 is allocated to Vodacom, and the NP table confirms the number has not been ported into the CSP network. The call is rejected with SIP 603 Declined.


Business model

VoIP and Mobile

Technology

  • Billing
  • SIP
  • Number portability

  • Number range allocation for operator: A list of number prefixes allocated to each licensed South African operator by ICASA, maintained by the CSP and defined per billing environment. For example, prefix 2783 is allocated to MTN and prefix 2782 is allocated to Vodacom.

Current Solution

PortaSwitch currently provides partial CLI validation through the following mechanisms:

1. Outbound (Customer → Vendor) via SIP Identity / Override Identity feature

  • If "Override Identity" feature is disabled - a customer may present any CLI
  • If "Override Identity" feature is enabled, Admin defines in what case CLI should be overriden: 
    • If different from all customer accounts
    • If different from account ID and aliases
    • If different from all accounts in the specified batch
    • If different from all accounts in the specified hunt group
    • If different from all accounts in the specified site
    • Always
  • Invalid CLI is overriden either by the "Identity" value, or account ID (if "Identity" value is not defined)
  • Limitations: 
    • Validation is static, based on numbers explicitly assigned in PortaBilling. 
    • The “Override Identity” feature requires manual configuration on a per-customer/account basis. For CSPs managing hundreds of resellers and thousands of customers, maintaining such configuration is operationally challenging.

2. Outbound Format Validation per Vendor Connection — CLI Validation Engine + 'Route Calls with Valid CLI Only'

  • Enabled via CallerIdValidation.Enable on the Configuration Server.

  • CLI is checked against configurable rules (allow/deny patterns); unmatched CLIs are validated by Google's libphonenumber library for E.164 compliance.

  • Per vendor connection, 'Route calls with valid CLI only' toggle blocks calls with invalid-format CLI.

  • Limitations:

    • Validates format and number validity only — not authorisation or ownership. A spoofed but well-formed E.164 number passes validation.

    • Available only for "To Vendor" connections. No CLI validation on incoming calls.

3. Number Portability Lookups

  • Used to identify whether the destination number has been ported to ensure that calls are routed to the correct operator and charged at the correct rate.
  • Limitations: 
    • PortaBilling checks only CLD against the configured number portability lookup rules. There is an exeception for zone rating: CLI is currently being looked up if  [ChargingZone]UsePortedNumberHome option is enabled.

South African VoIP providers using PortaSwitch could potentially perform CLI ownership validation using 3rd party solutions — an SBC with ENUM/LNP lookup capability, but it is not affordable for many providers and requires dedicated infrastructure. 

4. Origin-Based Routing/Rating — Forbidden CLI Origins

  • Allows tariffs to match the CLI against configurable prefix code groups and apply different prices, routing decisions, or a Forbidden flag per origination group. By marking specific CLI prefix ranges as Forbidden in a tariff assigned to a vendor connection, calls where the CLI matches a non-permitted prefix range can be rejected on both inbound and outbound calls.
  • Limitations:
    • Matches CLI against static prefix code groups only — no awareness of the Number_Portability_Local table. A ported number retains its original prefix and would be incorrectly blocked or allowed based on that prefix rather than its current network ownership.
    • Requires the CSP to manually maintain complete and up-to-date prefix code group and any change in number range allocations — new prefixes issued by ICASA, ranges transferred between operators — requires a manual tariff update, carrying the risk of stale data causing false rejections or missed spoofing.
    • Does not provide a descriptive SIP 603 Reason header identifying the specific CLI validation failure — the rejection reason is not self-explanatory in call traces.
    • Requires migration from regular tariffs to new tariffs with code groups.

The current solution doesn't support:

  • vendor prefix list defining the number ranges owned by vendors and CLI validation against this list for incoming and outgoing calls (defiend on a billing environment level)
  • transit vendor prefix list defining the number ranges allowed to be carried by vendor and CLI validation against this list for incoming and outgoing calls (defined on a vendor connection level)
  • CLI validation against Number_Portability_Local table for incoming and outgoing calls

Stakeholders and their benefits

Who are the users / whom we bring value to?

Benefit /
Stakeholders		More
Comfort		Increased
Efficiency		Saves
Time		Tighter
Control		Regulatory
Requirement
CSP✓
✓✓✓
Sales/marketing of CSP



✓
Resellers✓
✓✓✓
Network operations /
Support of CSP		✓✓✓✓
Vendors



✓
End user✓

✓

Use Cases

Use case #1: CLI validation on incoming calls from Vendor

Roles: CSP Admin, PortaSIP, PortaBilling, Vendor, End users

Preconditions: 

  • CSP "Star Telecom" has active "From vendor" connections of MTN SA, Vodacom SA.

  • CSP has an active "To vendor" connection of Cell C South Africa.
  • CLI validation to be in E.164 format is enabled for each vendor connection (both "From vendor" and "To vendor").

  • The vendor prefix list with prefix ranges for each South African operator is configured in PortaBilling on environment 1 that is managed by the CSP. (new functionality)

    PrefixVendor
    2783MTN
    2782Vodacom
    2784Cell C
    2787Star Telecom
  • The MTN From Vendor connection has 2789 (Lil SA) and 2790 (Poco SA) configured by Admin as authorised transit CLI prefixes, as MTN has a transit agreement to carry Lil SA's traffic to the CSP network. (new functionality)

  • Number portability lookup of inbound CLI against Number_Portability_Local table is enabled for each vendor connections. (new functionality)

  • The Number_Portability_Local table is updated daily from the SA LNP authority and contains information about all South African ported numbers.

  • Destination account: CSP's customer "Acme Logistics", account ID 27875501000.

Use scenario #1.1 Vendor Sends Inbound Call with Its Own Legitimate CLI (Pass)

  1. MTN sends an inbound SIP INVITE to PortaSwitch from 27834112233 to the account 27875501000.

  2. PortaSIP sends an authorization request to PortaBilling including CLI 27834112233.

  3. PortaBilling checks if 27834112233 is a valid E.164 South African mobile number and validation is passed.

  4. PortaBilling checks 27834112233 against the vendor prefix list. The number matches the MTN prefix range (2783).

  5. PortaBilling performs number portability lookup for 27834112233 in the Number_Portability_Local table and the number is not found.

  6. PortaBilling returns successful authorisation to PortaSIP.

  7. PortaSIP routes the call to destination account 27875501000.

Use scenario #1.2 Vendor Sends Inbound Call with CLI Belonging to Another Operator (Reject)

  1. Vodacom sends an inbound SIP INVITE to PortaSwitch from 27834112234 to the account 27875501000.

  2. PortaSIP sends an authorization request to PortaBilling including CLI 27834112234.
  3. PortaBilling checks if 27834112234 is a valid E.164 South African mobile number and validation is passed.

  4. PortaBilling checks 27834112234 against the vendor prefix list. The number matches the MTN prefix range (2783), not the Vodacom prefix range (2782).

  5. PortaBilling performs number portability lookup for 27834112234 in the Number_Portability_Local table and the number is not found. Since there is no porting record confirming the number moved to Vodacom, it cannot legitimately appear as CLI on the Vodacom connection.

  6. PortaBilling returns rejected authorization to PortaSIP.

  7. PortaSIP sends SIP 603 Declined to Vodacom with Reason header: 'CLI 27834112234 does not match Vodacom South Africa network — LNP validation failed'.

Use Scenario #1.3 Vendor Sends Inbound Call with CLI of a Number Ported into Its Network (Pass)

  1. MTN sends an inbound INVITE to PortaSwitch from 27849876543 to account 27875501000.

  2. PortaSIP sends an authorization request to PortaBilling including CLI 27849876543.
  3. PortaBilling checks if 27849876543 is a valid E.164 South African mobile number and validation is passed.

  4. PortaBilling checks 27849876543 against the vendor prefix list. The number matches the Cell C prefix range (2784), not the MTN prefix range.

  5. PortaBilling performs number portability lookup for 27849876543 in the Number_Portability_Local table and finds that it was ported.
  6. PortaBilling checks if the routing number prefix 2783 taken from Number_Portability_Local table matches MTN prefix in the vendor prefix list or transit vendor prefix list on MTN From Vendor connection and validation is passed.
  7. PortaBilling returns successful authorisation to PortaSIP.

  8. Call is routed to destination account 27875501000.

Use Scenario #1.4 — Inbound Call from Authorised Transit Vendor, non-ported CLI (Pass)

  1. MTN sends an inbound INVITE to PortaSwitch from 27891234567 to account 27875501000.
  2. PortaSIP sends an authorisation request to PortaBilling including CLI 27891234567.
  3. PortaBilling checks if 27891234567 is a valid E.164 South African mobile number and validation is passed.
  4. PortaBilling checks 27891234567 against the vendor prefix list. The number does not match the MTN prefix range (2783).
  5. PortaBilling performs number portability lookup for 27891234567 in the Number_Portability_Local table and the number is not found.
  6. PortaBilling checks whether 2789 is configured as an authorised transit prefix on the MTN From Vendor connection. The check passes.
  7. PortaBilling returns successful authorisation to PortaSIP.
  8. PortaSIP routes the call to destination account 27875501000.

Use Scenario #1.5 — Inbound Call from Unauthorised Transit Vendor, non-ported CLI (Reject)

  1. MTN sends an inbound INVITE to PortaSwitch from 27821009900 to account 27875501000.
  2. PortaSIP sends an authorisation request to PortaBilling including CLI 27821009900.
  3. PortaBilling checks if 27821009900 is a valid E.164 South African mobile number and validation is passed.
  4. PortaBilling checks 27821009900 against the vendor prefix list. The number matches the Vodacom prefix range (2782), not the MTN prefix range (2783).
  5. PortaBilling performs number portability lookup for 27821009900 in the Number_Portability_Local table and the number is not found, it has never been ported.
  6. PortaBilling checks whether 2782 is configured as an authorised transit prefix on the MTN From Vendor connection. The check fails.
  7. PortaBilling returns rejected authorisation to PortaSIP.
  8. PortaSIP sends SIP 603 Declined to MTN with Reason header: 'CLI 27821009900 does not match MTN South Africa network or authorised transit vendor network — LNP validation failed'.

Use Scenario #1.6 — Inbound Call from Authorised Transit Vendor, ported CLI (Pass)

  1. MTN sends an inbound INVITE to PortaSwitch from 27821005500 to account 27875501000. The CLI has a 2782 prefix (originally Vodacom) but has been ported to Lil SA.
  2. PortaSIP sends an authorisation request to PortaBilling including CLI 27821005500.
  3. PortaBilling checks if 27821005500 is a valid E.164 South African mobile number and validation is passed.
  4. PortaBilling checks 27821005500 against the vendor prefix list. The CLI matches the Vodacom prefix range (2782), not the MTN prefix range (2783).
  5. PortaBilling performs number portability lookup for 27821005500 in the Number_Portability_Local table and finds that it was ported. 
  6. PortaBilling checks if the routing number prefix 2789 taken from the Number_Portability_Local table matches MTN prefix in the vendor prefix list or transit vendor prefix list on the MTN From Vendor connection. The check passes.
  7. PortaBilling returns successful authorisation to PortaSIP.
  8. PortaSIP routes the call to destination account 27875501000.

Use Scenario #1.7 — Inbound Call from Unauthorised Transit Vendor, ported CLI (Reject)

  1. MTN sends an inbound INVITE to PortaSwitch from 27891009900 to account 27875501000. The CLI has a 2789 prefix (originally Lil SA) but has been ported to Vodacom.
  2. PortaSIP sends an authorisation request to PortaBilling including CLI 27891009900.
  3. PortaBilling checks if 27891009900 is a valid E.164 South African mobile number and validation is passed.
  4. PortaBilling checks 27891009900 against the vendor prefix list. The CLI prefix (2789) does not match any entry in the vendor prefix list.
  5. PortaBilling performs number portability lookup for 27891009900 in the Number_Portability_Local table and finds that it was ported. 
  6. PortaBilling checks if the routing number prefix 2782 taken from the Number_Portability_Local table matches MTN prefix in the vendor prefix list or transit vendor prefix list on the MTN From Vendor connection. The check fails.
  7. PortaBilling returns rejected authorisation to PortaSIP.
  8. PortaSIP sends SIP 603 Declined to MTN with Reason header: 'CLI 27891009900 does not match MTN South Africa network or authorised transit vendor network — LNP validation failed'.

Use case #2: CLI validation on outgoing calls from Customer

Roles: CSP Admin, PortaSIP, PortaBilling, Vendor, End users

Preconditions: 

  • CSP's customer "Acme Logistics" has a primary PBX account 27872004000 and assigned aliases 27872004001, 27872004002. 

  • SIP Identity / Override Identity on Acme Logistics' account 27872004000: Enabled 'If Different From Account ID and Aliases'.
  • CSP has active "To vendor" connections of MTN South Africa and Vodacom.
  • CLI validation to be in E.164 format is enabled for the MTN vendor connection .

  • The vendor prefix list with prefix ranges for each South African operator is configured in PortaBilling on environment 1 that is managed by the CSP.

    PrefixVendor
    2783MTN
    2782Vodacom
    2784Cell C
    2787CSP Star Telecom
  •  CSP lease a range of numbers from MTN and a range of numbers from Vodacom, so CSP Admin configured those number ranges as authorized valid CLIs on the corresponding MTN and Vodacom "To Vendor" connections.
    This is a new requirment that came on 01.09.2026 from an FR voter, and the detailed requirements for the expected behavior are being discussed.
  • Number portability lookup of CLI against Number_Portability_Local table is enabled for the MTN vendor connections.
  • The Number_Portability_Local table is updated daily from the SA LNP authority and contains information about all South African ported numbers.

Use Scenario #2.1 — Customer Sends a valid non-ported CLI (Pass via NP)

  1. Acme Logistics' PBX originates an outbound call and sends a SIP INVITE to PortaSIP with CLI 27872004001.

  2. PortaSIP sends an authorisation request to PortaBilling with CLI 27872004001.

  3. PortaBilling checks if 27872004001 is a valid South African number and validation passed. 

  4. PortaBilling checks 27872004001 against the vendor prefix list. The number matches the CSP's own prefix range (2787).

  5. PortaBilling looks up 27872004001 in the Number_Portability_Local table. The number is not found and belongs to the CSP network. 

  6. PortaBilling finds that 27872004001 is in Acme Logistics' assigned aliases.
  7. PortaBilling checks "Override identity" settings of the alias's account 27872004000. The CLI matches the account alias, no override is applied.

  8. PortaBilling returns successful authorisation. PortaSIP routes the call with CLI 27872004001 intact.

Use Scenario #2.2 — Customer Sends CLI Belonging to Another Provider (Reject via NP)

  1. Acme Logistics' PBX places an outbound call using 27825559900 as the CLI. This is a Vodacom mobile number that has never been assigned to Acme Logistics or ported into the CSP network.

  2. PortaSIP sends an authorisation request to PortaBilling with CLI 27825559900.

  3. PortaBilling checks if 27825559900 is a valid South African number and validation is passed.

  4. PortaBilling checks 27825559900 against the vendor prefix list. The number matches the Vodacom prefix range (2782) — not the CSP's prefix range.

  5. PortaBilling looks up 27825559900 in the Number_Portability_Local table. The number is not found. 

  6. PortaBilling checks if 27825559900 is in Acme Logistics' assigned aliases. Check fails, there is no such alias.

  7. PortaBilling returns rejected authorisation to PortaSIP without checking account's "Override identity" rules.

  8. PortaSIP sends SIP 603 Declined to Acme Logistics' PBX with reason: 'CLI 27825559900 does not match CSP network — LNP validation failed'. The PBX administrator can identify the cause directly from the rejection reason without escalating to CSP support.

Use Scenario #2.3 — Customer Sends CLI Ported Into CSP Network but Not Yet Added as Alias (Pass via 2-stage validation)

  1. Acme Logistics' PBX places an outbound call using 27848835500 as CLI.

  2. PortaSIP sends an authorisation request to PortaBilling with CLI 27848835500.

  3. PortaBilling checks if 27848835500 is a valid South African number and validation is passed.

  4. PortaBilling checks 27848835500 against the vendor prefix list. The number matches the Cell C prefix range (2784) — not the CSP's prefix range.

  5. PortaBilling looks up 27848835500 in the Number_Portability_Local table. The number is found and belongs to the CSP network. NP validation passes.

  6. PortaBilling checks Override Identity settings of the account 27872004000. Since CLI 27848835500 is different from account ID and aliases, CLI is translated to account ID 27872004000.

  7. PortaBilling starts the second stage of CLI validation, checks if 27872004000 is a valid South African number and validation passes.

  8. PortaBilling checks 27872004000 against the vendor prefix list. The number matches the CSP's prefix range.

  9. PortaBilling looks up 27872004000 in the Number_Portability_Local table. The number is not found and belongs to the CSP network. 

  10. PortaBilling returns successful authorisation to PortaSIP.

  11. PortaSIP routes the call with CLI 27872004000.

Use Scenario #2.4 — Customer Sends CLI Ported Into CSP Network but Not Yet Added as Alias -  alternative to US#2.3 (Pass via 1-stage validation)

  1. CSP Admin configures PortaBilling not to apply "Override identity" rules to CLI for Acme Logistics' PBX account 27872004000 if prior LNP validation is successful.
  2. Steps 1-6 from US#2.3
  3. Because the LNP check confirmed the CLI 27848835500 belongs to the CSP network, Override Identity is not applied and the original CLI 27848835500 is preserved.
  4. PortaBilling returns successful authorisation to PortaSIP.
  5. PortaSIP routes the call with CLI 27848835500.

Use Scenario #2.5 - Customer Sends CLI Ported Into CSP Network but Not Yet Added as Alias - alternative to US#2.3 (Reject after 2-stage validation)

  1. Continues after US#2.3 step 6.
  2. PortaBilling checks Override Identity settings of account 27872004000. Since CLI 27848835500 is different from account ID and aliases, CLI is translated to the Identity value configured on the account — 27821005500. CSP Admin managing the customer mistakenly added a wrong number as Identity.
  3. PortaBilling starts the second stage of CLI validation, checks if 27821005500 is a valid South African number and validation passes.
  4. PortaBilling checks 27821005500 against the vendor prefix list. The number matches the Vodacom prefix range (2782) — not the CSP's prefix range.
  5. PortaBilling looks up 27821005500 in the Number_Portability_Local table. The number is not found — it has not been ported into the CSP network.
  6. PortaBilling returns rejected authorisation to PortaSIP.
  7. PortaSIP sends SIP 603 Declined to Acme Logistics' PBX with reason: 'CLI 27821005500 does not match CSP network — LNP validation failed'.

Use case #3: CLI Validation on Forwarded Calls

Roles: PortaSIP, PortaBilling, Vendor, End users

Preconditions: Same as Use Case #1 and Use Case #2.

Use Scenario #3.1 Outgoing CLI Validation of Inbound Call Forwarded by Customer (Pass)

  1. Starts with Use scenario #1.1 (successful CLI validation on inbound call with CLI 27834112233 and routing the call to the destination account 27875501000).

  2. Account 27875501000 has a call forward configured to external number 27844567890 (a Cell C number) with the setting 'display original caller number', meaning the outbound INVITE to Cell C will carry the original caller's CLI (27834112233) and a Diversion header: 27875501000. 

  3. PortaBilling performs outbound validation for CLI 27834112233 for E.164 format, provider prefix and number portability.

  4. PortaBilling detects the Diversion header (27875501000) and verifies that this number is a valid CSP account with configured call forwarding. 

  5. Because this is an authorized forwarded call, PortaBilling applies the forwarded calls exception, which allows the original CLI belonging to a different operator (27834112233) to bypass the strict outbound ownership check, confirming only its E.164 format and global validity.

  6. PortaSIP successfully routes the call to Cell C with CLI 27834112233.

Use Scenario #3.2 Outgoing CLI Validation of Outbound Call initially Forwarded on Vendor Network (Pass)

  1. Starts with Use scenario #2.1 (successful CLI validation on outbound call with CLI 27872004001 and routing the call to MTN number 27834009900).
  2. MTN's subscriber 27834009900 has a call forward configured to redirect to 27844567890 (a Cell C number).
  3. MTN redirects the call and sends it back to PortaSwitch on the MTN "From Vendor connection", now destined for 27844567890, carrying the original CLI 27872004001 and a Diversion header referencing 27834009900.
  4. PortaSIP sends an authorisation request to PortaBilling for the incoming leg with CLI 27872004001 on the MTN From Vendor connection.
  5. PortaBilling performs successful validation for CLI 27872004001 for E.164 format, vendor prefix and number portability. 
  6. PortaBilling detects the Diversion header referencing 27834009900 and verifies that it is a valid MTN number that was the original destination of the outbound call. 
  7. PortaSwitch routes the call onward to Cell C "To Vendor" connection with CLI 27872004001 preserved.

Use Scenario #3.3 Outgoing CLI Validation of Outbound Call Forwarded by Vendor (Reject) - alternative to US#3.2

  1. Starts with Use Scenario #2.1 (successful CLI validation on outbound call with CLI 27872004001 and routing the call to MTN number 27834009900).
  2. MTN's subscriber 27834009900 has a call forward configured to redirect to 27844567890 (a Cell C number).
  3. MTN redirects the call and sends it back to PortaSwitch on the MTN From Vendor connection, now destined for 27844567890, carrying the original CLI 27872004001 and a Diversion header referencing 27821002200. The Diversion header contains a wrong number — 27821002200 belongs to Vodacom, not MTN.
  4. PortaSIP sends an authorisation request to PortaBilling for the incoming leg with CLI 27872004001 on the MTN From Vendor connection.
  5. PortaBilling performs validation for CLI 27872004001 for E.164 format, vendor prefix and number portability. The number matches the CSP prefix range (2787). Validation passes.
  6. PortaBilling detects the Diversion header and checks whether 27821002200 is a valid MTN number. PortaBilling checks 27821002200 against the vendor prefix list — the number matches the Vodacom prefix range (2782), not the MTN prefix range (2783).
  7. PortaBilling performs number portability lookup for 27821002200 in the Number_Portability_Local table. The number is not found — there is no record confirming it was ported to MTN.
  8. PortaBilling cannot confirm 27821002200 as a valid MTN number. The bypass is not granted.
  9. PortaBilling returns rejected authorisation to PortaSIP.
  10. PortaSIP sends SIP 603 Declined to MTN with reason: 'Diversion header references a number not belonging to MTN South Africa network — call forward validation failed'.

Wireframes

N/A

Non-functional requirements

  1. The system must record the following data for every outbound call processed through CLI validation:

    • original CLI as received from the customer
    • result of CLI validation performed before Override Identity is applied
    • result of validation performed after Override Identity and any other CLI modifications (like translation rules) have been applied

    This information must be stored in the system for auditing and troubleshooting purposes.

Peculiarities

  1. Vendor prefix list is used as the primary ownership check for numbers that have never been ported. The list must be:
    • configurable per billing environment because environments are rent out to different service providers who have their own vendors and corresponding vendor prefix lists; if no vendor prefix list is set up for an environment, it should use the global vendor prefix list;
    • updatable without system downtime or service interruption, as allocations may change on a monthly or even weekly basis.

  2. CLI validation using vendor prefix lists and LNP should be enabled at the vendor connection level (both "From vendor" and "To vendor").

  3. CSP must be able to add or remove authorised transit prefixes easily for each vendor connection. These changes should take effect without requiring maintenance, a service restart or any downtime.

  4. SIP Error Signalling: On CLI validation failure, PortaSIP should return SIP 603 Declined with a Reason header that includes: the CLI that failed, the vendor connection name, and the reason (e.g. 'SPID mismatch' or 'no NP record'). The Reason text must use the vendor connection's configured display name (e.g. 'MTN South Africa', 'Vodacom SA') so that the rejection is self-explanatory in call traces. SIP 607 and 608 are under evaluation by CSP's technical team (Teuns Moolman) and may be added as configurable alternatives in a future iteration. Additional info about SIP headers provided by the CSP: 

    1. https://calleridreputation.com/blog/call-blocking-notifications-what-are-sip-codes-603-607-and-608/ 

    2. https://www.bandwidth.com/support/en/articles/13778049-sip-603-faq
  5. CLI validation using LNP should be bypassed for calls to emergency numbers.
  6. Outbound CLI validation is performed in two stages. Stage 1 validates the original CLI exactly as received from the customer's PBX, before Override Identity and any other CLI modifications (like translation rules) are applied. If Stage 1 fails, the call is rejected immediately and Override Identity is not applied. If Stage 1 passes, Override Identity and translation rules are applied and Stage 2 validates the final CLI before it is sent to the vendor. If Stage 2 fails, the call is rejected. Both stages must be configurable by the CSP administrator and cannot be disabled or bypassed by the reseller.
  7. Forwarded Calls Exception: Authorized forwarded calls must bypass the strict outbound CLI ownership validation (described in Use Case #2). If a call includes a valid Diversion header, and PortaBilling successfully verifies that the number in the Diversion header belongs to the CSP network and is authorized to forward calls, the original third-party CLI is allowed to pass.\
  8. For outgoing calls where the routing list contains multiple connections, the behavior should be the same as for the existing "Route calls with valid CLI only" feature: if the CLI is identified as invalid, vendor connections that have this option enabled will be excluded from the routing list for this call.
  9. A wishlist item with the requested behavior simalar to the case with leased numbers described in UC 2: YT:WSHLST-246 

Performance / Clustering, Geo Redundancy/ Dual-Version, Porter / Call Control API / ESPF / Monitoring

N/A