Call delivery in Dual Version PortaSwitch

For the successful operation of Dual Version PortaSwitch, it is essential that customers do not notice being moved from one system to another. That is, if John Doe is already in the target system, he must be able to make and receive calls as if nothing has changed.

To deliver calls to accounts in either system PortaSwitch uses the dispatching SBC. This is a dedicated PortaSIP node that operates as the inter-system proxy and dispatches call initiation requests across systems. It operates in high-availability mode and presents a single point of entry to both your termination partners and your wholesale, SIP trunking, residential and other customers.

Let’s take a closer look at how PortaSwitch processes calls for John: first, when his record is still provisioned in source system A and then, when it is moved to target system B. To make and receive calls, the dispatching SBC’s IP address is used to register John’s phone.

Let’s say John calls his friend Harry in the UK.

1. John’s phone sends an INVITE request to the dispatching SBC (1).

2. The dispatching SBC searches for John’s account in the database and detects that it belongs to system A.

3. The dispatching SBC routes the INVITE request to PortaSIP on system A (2).

4. Within system A, PortaSIP sends the authorization request to PortaBilling.

5. PortaBilling authorizes the call and provides PortaSIP with the routing results.

6. PortaSIP sends the call to the vendor to establish the call with Harry (3).

7. When the call finishes, PortaSIP sends accounting information to PortaBilling to calculate the charges and produce xDRs.

Consider this example when John receives a call from abroad.

1. The vendor receives the call from the PSTN network and sends it to the dispatching SBC (1).

2. The dispatching SBC searches the database for the DID number that matches the destination number.

3. The dispatching SBC detects that the destination number corresponds to John’s account and that it belongs to system A.

4. The dispatching SBC routes the call to system A’s PortaSIP (2).

5. PortaSIP sends an authorization request to the respective PortaBilling.

6. PortaBilling authorizes the call and detects that the destination number matches the local account so it returns the result to PortaSIP.

7. PortaSIP checks that the account’s IP phone is registered via the dispatching SBC, and therefore, it sends the call to the dispatching SBC (3).

8. When the dispatching SBC delivers the call to John’s phone (4) it starts ringing.

9. When the call ends, PortaSIP in system A sends accounting information to PortaBilling to calculate the charges and create an xDR for John.

The administrator has transferred John’s record to the target system.

So now when John makes another call to his friend Harry in the UK, the following occurs:

1. The call request from John’s phone arrives to the dispatching SBC (1).

2. The dispatching SBC searches John’s account in the database and detects that it is provisioned in system B.

3. The dispatching SBC routes the call to system B’s PortaSIP (2).

4. PortaSIP sends the authorization request to the respective PortaBilling.

5. PortaBilling authorizes the call and provides PortaSIP with the routing results.

6. PortaSIP sends the call to the vendor and establishes the call with Harry (3).

7. When the call ends, PortaSIP sends accounting information to PortaBilling to calculate the charges and produce xDRs.

When Jane dials John’s number, the following occurs:

1. The vendor receives the call from the PSTN network and sends it to the dispatching SBC (1).

2. The dispatching SBC searches the database for the DID number that matches the destination number.

3. The dispatching SBC determines that the destination number corresponds to John’s account and is provisioned in system B.

4. The dispatching SBC routes the call request to system B’s PortaSIP (2).

5. PortaSIP sends the authorization request to the respective PortaBilling.

6. PortaBilling authorizes the call and notifies PortaSIP that the call is intended for the local account.

7. PortaSIP checks that John’s IP phone is registered via the dispatching SBC, and therefore sends the call to the dispatching SBC (3).

8. The dispatching SBC delivers the call to John’s phone and John and Jane begin their conversation (4).

9. Once the call ends, PortaSIP in system B sends accounting information to PortaBilling to calculate the charges and create an xDR for John.

When customers are moved from one system to another, they must be reachable both from the external network and from the previous system. One way to deliver calls to such customers is to use the PSTN network. However, this is impractical since it adds hops in the call path and imposes additional charges.

To optimize call delivery and eliminate excessive charges, Dual Version PortaSwitch has the inter-system routing mechanism as the direct path for calls throughout the whole network.

Calls between systems are delivered using special rate codes. These codes represent the billing environments of either system and are derived from their unique IDs. This distinguishes this routing system from intra-system routing.

Thus, if Jane, from source system A, calls Mary, who is already in the target system B, the following occurs:

• The call from Jane’s phone arrives to the dispatching SBC (1)

• The dispatching SBC sends a call request to PortaSIP at the source system A for processing (2).

• PortaSIP in system A authorizes the call in PortaBilling.

• PortaBilling detects that the destination number belongs to the account that has been moved to the target system and therefore instructs PortaSIP to send the call to the system B.

• PortaSIP on the system A routes the call to PortaSIP on the system B, bypassing the dispatching SBC (3).

• Upon call authorization in the system B’s PortaBilling, PortaSIP sends the call to the dispatching SBC (4), which delivers the call to Mary’s phone (5).

• When the call finishes, each PortaSIP instance sends accounting requests to PortaBilling. Then PortaBilling in system A creates an xDR for Jane’s account while PortaBilling in system B creates an xDR for Mary’s account.

To find which system to route an incoming call to in Dual Version PortaSwitch, the dispatching SBC matches first the destination number and then the source number against the account/DID list in the database.

If the dispatching SBC cannot find the target system for some reason (e.g., there is no record in the database to match the destination number), it sends the call to a fallback system. In that system, PortaSIP authorizes the call in PortaBilling and receives the correct routing to deliver the call to the recipient. The target system is the fallback system by default.

You can configure a fallback system for the dispatching SBC to send calls. For example, if you have just deployed Dual Version PortaSwitch and haven’t yet migrated customers to the target system, define the source system as the fallback one. Select a billing environment from the source system in the ForwardingRegistry.fallback_env option on the Configuration server.

Then when the dispatching SBC cannot identify where to dispatch an incoming request, it routes this request to the source system for further processing.

Fallback call delivery increases the call success rate in Dual Version PortaSwitch and therefore improves customer experience.