Reviewers (+ link to BA task):

  • PM  
  • Dev  
  • QA  
  • PO  
  • TW  

User Story

As a CSP, I want to configure an FQDN as the source identifier for a customer's inbound calls instead of manually maintaining a list of IP addresses, so that PortaSwitch can automatically resolve the FQDN to its current IP addresses and use them for call authorization, while still being able to differentiate between customers when their FQDNs resolve to the same IP address(es).

Example of use

A CSP has a customer, Aurora Retail Group, whose call center operates on a third-party cloud platform Genesys.
Genesys assigns the customer the FQDN aurora.mypurecloud.de. At the time of configuration, this FQDN resolves to four IP addresses:

  • 192.0.2.10
  • 192.0.2.11
  • 192.0.2.12
  • 192.0.2.13

Instead of manually entering these four IP addresses in the customer's inbound call authorization configuration, the CSP configures the customer account to be identified by the FQDN aurora.mypurecloud.de.
PortaSwitch periodically performs a DNS lookup for the configured FQDN and stores the resulting IP addresses for use in inbound call authorization.
Later, the cloud provider replaces 192.0.2.13 with 192.0.2.25. During the next DNS synchronization, PortaSwitch detects that the DNS resolution result has changed and updates the IP addresses used for Aurora's inbound call authorization.
As a result, incoming calls from 192.0.2.25 are authorized without the CSP manually updating the customer's configuration.

The CSP later signs up another customer, Baltic Hotels, who also uses Genesys Cloud. Baltic is provided with the FQDN baltic.mypurecloud.de. This FQDN resolves to the same IP addresses as Aurora's FQDN.
PortaSwitch supports correct differentiation of inbound traffic when different customer FQDNs resolve to the same IP address(es).

Business model

CloudPBX, SIP Trunking

Technology

Periodic DNS resolution of a customer-supplied FQDN, performed by PortaSwitch against public DNS to obtain the domain's current DNS-record IP address(es).

Current Solution

Currently, inbound call authorization relies on manually configured IP addresses.

  • The CSP obtains the IP addresses from the customer's cloud PBX/contact-center provider.
  • The CSP manually configures these IP addresses as authorized source addresses for the customer's inbound calls.
  • When the cloud provider changes its IP addresses, the CSP must identify the change and manually update the customer's configuration.
  • If a new source IP address is used before the CSP updates the configuration, an incoming call from that IP address does not match the existing authorization configuration and may therefore fail authorization.
  • Cloud providers such as Genesys Cloud or Twilio may change the IP addresses used by their infrastructure, making permanent manual IP configuration difficult to maintain.

For the cases when traffic from the same IP address needs to be differentiated between customers, PortaSwitch currently supports authentication by CLI/CLD Tech-Prefix and IP.
With FQDN-based inbound call authorization, different customer FQDNs may resolve to the same IP address(es). The new solution must therefore support differentiating traffic for such customers while using their configured FQDNs for inbound call authorization.

Stakeholders and their benefits

Who are the users / whom we bring value to?

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





Resellers / distributors





Network operations /
Support of CSP		✓✓✓
✓
Developer





3rd party





End user✓




Use Cases

Use case #1: FQDN-Based Automatic IP Resolution for Inbound Call Authorization

Roles: CSP Admin, PortaSwitch system, DNS system

Preconditions: 

  • CSP signs up a new customer Aurora Retail Group.
  • Aurora already uses a third-party cloud communication platform, Genesys Cloud, for its call center with the FQDN aurora.mypurecloud.de provided by Genesys Cloud for Aurora.
  • At 2026-09-04 10:00, DNS resolution of aurora.mypurecloud.de returns:
    • 192.0.2.10
    • 192.0.2.11
    • 192.0.2.12
    • 192.0.2.13
  • PortaSwitch is configured to perform periodic DNS resolution of FQDNs.

Use scenario #1.1: Configure an FQDN for a customer's inbound call authorization

  • At 2026-09-04 10:00, CSP Admin configured an account for the customer "Aurora Retail Group" identified by FQDN aurora.mypurecloud.de and saves the changes.
  • PortaSwitch performs a DNS lookup for aurora.mypurecloud.de and DNS returns four IP addresses:
    • 192.0.2.10
    • 192.0.2.11
    • 192.0.2.12
    • 192.0.2.13
  • PortaSwitch stores the resolved IP addresses for use in inbound call authorization.

Use scenario #1.2 Call authorization using FQDN

  • At 2026-09-04 11:00, PortaSwitch receives an inbound SIP INVITE from source IP 192.0.2.11.
  • 192.0.2.11 is present in the current DNS resolution result for aurora.mypurecloud.de.
  • The incoming call matches Aurora's inbound call authorization configuration.
  • PortaSwitch accepts the call.

Use scenario #1.3 Call authorization after IP adress change 

  • At 2026-09-10 02:00, the cloud provider changes its infrastructure and aurora.mypurecloud.de now resolves to:
    • 192.0.2.10
    • 192.0.2.11
    • 192.0.2.12
    • 192.0.2.25
  • At 2026-09-10 02:15 PortaSwitch performs a periodic DNS lookup and now stores the updated list of IP addresses for aurora.mypurecloud.de.
  • At 2026-09-10 13:00, PortaSwitch receives an inbound SIP INVITE from 192.0.2.25.
  • 192.0.2.25 is present in the current DNS resolution result for aurora.mypurecloud.de.
  • The incoming call matches Aurora's inbound call authorization configuration.
  • PortaSwitch accepts the call.

Use case #2: FQDN-Based Inbound Call Authorization with Overlapping IP Addresses

Roles: CSP Admin, PortaSwitch system, DNS system

Preconditions: 

  • CSP signs up a new customer, Baltic Hotels, who also uses Genesys Cloud for its call center with the FQDN baltic.mypurecloud.de.
  • Baltic Hotels FQDNs resolve to the same IP addresses that the existing CSP's customer account aurora.mypurecloud.de:
    • 192.0.2.10
    • 192.0.2.11
    • 192.0.2.12
    • 192.0.2.13

 Use scenario #2.1: Call authorization for accounts with overlapping IP addresses

  • At 2026-09-05 10:00, CSP Admin configures an account for Baltic Hotels using the FQDN baltic.mypurecloud.de and saves the changes.
  • PortaSwitch performs a DNS lookup for baltic.mypurecloud.de and stores the resolved IP addresses for inbound call authorization:
    • 192.0.2.10
    • 192.0.2.11
    • 192.0.2.12
    • 192.0.2.13
  • At 2026-09-05 11:00, PortaSwitch receives an inbound SIP INVITE from source IP 192.0.2.11.
  • PortaSwitch identifies 192.0.2.11 as one of the IP addresses currently resolved for the FQDN configured for the Baltic Hotels account, baltic.mypurecloud.de and customer Aurora Retail Group account aurora.mypurecloud.de.
  • PortaSwitch with the help of an additional identifier, correctly identifies this call as belonging to Baltic Hotels account baltic.mypurecloud.de.
  • PortaSwitch applies Baltic Hotels' inbound call authorization configuration and accepts the call.


Wireframes

  • This is an optional section. 
  • Wireframe is a quick illustration of an idea not the prototype itself.
  • Key point is that a final prototype might look completely different after the Solution Design stage.

Non-functional requirements

Peculiarities

  1. What is the expected behavior when DNS lookup for FQDN fails, PortaSwitch doesn't get any IP addresses ?
  2. Entities required to carry FQDN identifier: account
  3. PortaSwitch should perform periodic DNS resolution and cache the results until the next check. The way of performing periodic DNS lookups is to be defined during the design stage ( e.g., whether the frequency  would be defined by the TTL parameter from DNS, or configure PortaSwitch to perform checks with the desired frequency independent from TTL, etc.).

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