User Story

As a CSP, I want to configure an FQDN as the source identifier for a customer's inbound calls to PortaSwitch 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).

I also want PortaSwitch to use an FQDN as the destination for outbound calls, resolving it to the current IP addresses for call delivery while preserving the FQDN and called number in the SIP Request-URI.

Example of use

A CSP has a customer, Aurora Retail Group, that uses Genesys Cloud to send and receive calls through the CSP's PortaSwitch. Genesys provides the customer with the FQDN aurora.mypurecloud.de to identify the source of its traffic.

The DNS configuration for aurora.mypurecloud.de results in the following IP addresses being associated with the FQDN:

• 192.0.2.10
• 192.0.2.11
• 192.0.2.12
• 192.0.2.13

Instead of manually configuring and maintaining these IP addresses, the CSP configures aurora.mypurecloud.de for the customer's account.

PortaSwitch periodically resolves the configured FQDN and uses the obtained IP addresses for inbound call authorization.

Later, Genesys Cloud changes its infrastructure, and 192.0.2.13 is replaced by 192.0.2.25. During the next DNS synchronization, PortaSwitch detects the change and updates the IP addresses used for Aurora Retail Group's inbound call authorization.

An inbound call from 192.0.2.25 is then successfully authorized without the CSP manually updating the customer's configuration.

The CSP also has another customer, Baltic Hotels, that uses the FQDN baltic.mypurecloud.de. DNS resolution of this FQDN results in the same IP addresses as for Aurora Retail Group. PortaSwitch uses an additional identifier configured for the customer to correctly determine whether an inbound call belongs to Aurora Retail Group or Baltic Hotels.

For outbound FQDN support, account aurora.mypurecloud.de is configured to forward calls to SIP URI destination aurora.mypurecloud.de, keeping the original called number. When a call arrives for Aurora’s number 2712345678, configured as an alias under this account, PortaSwitch applies the main account’s forwarding settings. It resolves the destination FQDN and sends the call to Genesys Cloud at a resolved IP address, keeping 2712345678@aurora.mypurecloud.de in the Request-URI.

Business model

CloudPBX, SIP Trunking

Technology

Periodic DNS resolution of a customer-supplied FQDN, performed by PortaSwitch against public DNS to determine the current network addresses associated with the configured FQDN.

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.

For outbound calls, CSP currently uses an SBC to deliver calls from PortaSwitch to customers’ cloud PBXs, such as Genesys Cloud. PortaSwitch forwards these calls to the SBC’s IP address. The SBC handles DNS resolution and delivers the calls to the cloud PBX using the customer-specific FQDN in the SIP Request-URI, such as 2712345678@aurora.mypurecloud.de.

Stakeholders and their benefits

Who are the users / whom we bring value to?

Use Cases

Use case #1: FQDN-Based Automatic IP Resolution

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 configuration for aurora.mypurecloud.de results in the following IP addresses being associated with the FQDN:
  • 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 with alias 2712345678 and saves the changes.
• PortaSwitch resolves aurora.mypurecloud.de and DNS returns the IP addresses currently associated with the FQDN.
• PortaSwitch stores the resolved IP addresses for use in inbound call authorization.

Use scenario #1.2 Inbound call authorization using FQDN

• At 2026-09-04 11:00, an Aurora Retail Group call-center agent uses Genesys Cloud to call an external phone number.
• 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 Inbound call authorization after IP adress change 

• At 2026-09-10 02:00, Genesys Cloud changes its infrastructure so that 192.0.2.13 is replaced by 192.0.2.25 in the DNS configuration associated with aurora.mypurecloud.de.
• During the next DNS synchronization, PortaSwitch resolves aurora.mypurecloud.de and obtains the updated IP addresses.
• PortaSwitch updates the IP addresses used for Aurora Retail Group's inbound call authorization.
• 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 scenario #1.4: Inbound call authorization for accounts with overlapping IP addresses

• 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
• 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 resolves baltic.mypurecloud.de and obtains and stores the IP addresses currently associated with the FQDN.
• 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.

 Use scenario #1.5: Outbound call delivery using FQDN

• CSP Admin configures account aurora.mypurecloud.de to forward calls to the SIP URI destination aurora.mypurecloud.de keeping the original CLD.

• An external caller calls Aurora’s number 2712345678.

• PortaSwitch receives and authorizes the call according to the existing inbound call authorization rules.

• PortaSwitch matches the called number to alias 2712345678, and applies its main account’s SIP URI forwarding settings - forward to aurora.mypurecloud.de.

• PortaSwitch obtains the destination IP address(es) through DNS resolution of the configured FQDN.

• PortaSwitch sends the SIP INVITE to Genesys Cloud at a resolved IP address, preserving the original called number and the configured FQDN in the Request-URI:
  sip:2712345678@aurora.mypurecloud.de.

• Genesys Cloud identifies Aurora using the customer-specific domain and routes the call to the appropriate destination within Aurora’s call center.

Wireframes

N/A

Non-functional requirements

N/A

Peculiarities

1. Entities required to carry FQDN identifier: account
2. 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.).
3. An FQDN can be associated with one or multiple IP addresses. For example, in the BRS use cases, aurora.mypurecloud.de is associated with four IP addresses. The feature design must take into account how different DNS configurations (e.g., A/AAAA, SRV, or their combination) and DNS caching should be handled to obtain the IP addresses required for inbound call authorization and outbound call delivery.

4. The behavior if DNS resolution fails is to be defined during the design stage

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

N/A