Connect outbound traffic to the destination network.
Route domestic and international calls from your softswitch, SBC or communications platform through VirPhone termination services.
- 01CUSTOMER SBCOutbound traffic
- 02ROUTING ENGINEPolicy & selection
- 03ROUTE ACost policy
- 04ROUTE BQuality policy
- 05ROUTE CAlternate path
- 06PSTNDestination
Outbound voice, evaluated destination by destination.
From your SBC to the called party
Termination is the outbound leg between your voice infrastructure and the destination telephone network. Your platform creates the call; the carrier path delivers it toward the called number. The integration boundary needs to cover addressing, caller identity, signaling responses and media so both teams can distinguish an application issue from a delivery issue.
Map your dial plan to the agreed number format before testing. Include representative fixed, mobile and other permitted destinations in the test set. A successful call to one destination does not establish the behavior of every prefix in a rate deck.
Read quality in context
ASR describes the share of attempts answered under the reporting definition. ACD describes the duration of answered calls. PDD measures the delay before progress or alerting under the measurement used. None of these metrics alone explains why a call failed; review call records and signaling alongside the aggregate.
Agree what happens when a preferred path is unavailable, which responses permit another attempt and how retries are limited. Route selection, customer cancellation and destination rejection should not be mixed into one unexplained failure count.
Where it fits in your network
- 01Your softswitch / SBC
- 02VirPhone ingress
- 03Route selection
- 04Destination network
Plan the connection around your traffic
Destination planning
Build a prefix profile before requesting a rate deck. Separate fixed, mobile and special-service traffic so commercial comparisons reflect the calls you actually send.
Quality evaluation
Review ASR, ACD and PDD together. A single aggregate metric can hide differences between destinations and traffic types.
Traffic controls
Agree peak CPS and concurrent calls before production. Include burst behavior and retry policy in the interop plan.
Agree the details before production
| Parameter | Planning detail |
|---|---|
| Rate deck | Request current A–Z and USA rates, effective dates and change-notice terms. |
| Billing | Confirm minimum duration, billing increments and chargeable call treatment. |
| Caller identity | Agree E.164 formatting, CLI presentation and identity requirements. |
| Capacity | CPS and simultaneous calls are agreed for your traffic profile. |
What to review with your team
| Review area | What to establish |
|---|---|
| Dial plan | Called-number format and treatment of unsupported destinations. |
| Identity | Permitted caller identity and agreed presentation requirements. |
| Traffic behavior | Peak attempts, concurrency, retry policy and acceptable use. |
Before the next step
How should termination quality be compared?
Use matching destination groups, traffic types and time windows. Examine individual failures and media behavior as well as aggregate ASR, ACD and PDD.
Are all destinations priced the same way?
No. Request the current rate deck and review destination prefixes, billing increments, effective dates and any exclusions before sending production traffic.
Where outbound termination fits
Use voice termination when your application or switching platform already creates calls and needs a carrier path to the PSTN. This applies to providers operating subscriber services, enterprises retaining their voice estate and platforms with a defined outbound calling use case. The service boundary begins with the traffic handed to the agreed interconnect; it does not replace your subscriber or application features.
Separate termination from origination, which delivers incoming calls, and from numbering, which manages the numbers assigned to a service. Buying those functions together can simplify a project, but they still need distinct requirements and acceptance tests.
Normalize once, then preserve the evidence
Before calls enter the trunk, identify where your platform converts dialed digits into the agreed destination format. Review caller identity and forwarding scenarios at the same time. Inconsistent formatting can make one customer or destination fail while the rest of a trunk appears healthy. Record the transmitted value in the approved troubleshooting workflow.
Keep signaling outcomes with the call reference and the route used. A rejected request, an unanswered destination and a canceled attempt describe different events. The SIP response guide explains the categories; the actual response must still be interpreted with the surrounding exchange.
Capacity and recovery are separate tests
A sustained set of conversations tests concurrency. A burst of short attempts tests setup rate. Both matter, and a retry storm can increase CPS even when the number of answered calls remains low. Include representative durations and attempted-call behavior in the engineering review rather than deriving every requirement from monthly minutes.
For alternate-route testing, identify the specific failure condition and expected response. Confirm whether a new attempt is permitted, how long it may take and how duplicate attempts are prevented. Then compare resulting call records with the original call. Those details turn a generic failover requirement into an observable acceptance case.
Questions about this service
How do I request a destination rate deck?
Send the major prefixes, traffic type and approximate monthly volume. Include expected CPS and concurrency when known. The response should identify the applicable deck and commercial terms.
What codecs should I offer?
Use the codec and DTMF profile confirmed in the interconnect guide. A codec supported by your SBC is not automatically accepted on every service path.
How are billing increments applied?
The agreed minimum and subsequent increment determine chargeable duration. Review them with the rate deck and compare representative calls before accepting a blended estimate.
Compare two destination allocations
Suppose a provider is evaluating a new route for one destination group. It keeps the originating application and dialing behavior unchanged, sends an agreed test allocation and retains a comparison sample. The team examines setup failures and answered calls separately, then checks whether the result differs by destination prefix.
If ASR falls while call attempts increase, investigate the changed traffic before blaming the route. If setup time rises only on one prefix, narrow the evidence to that group. Acceptance should explain the result and its limits: which traffic was tested, which window was used and which exceptions remain. This hypothetical example is a method for evaluation, not a VirPhone performance result.