Bring inbound calls into your own infrastructure.
Connect inbound PSTN calls to the SIP destinations that serve your customers, queues and applications.
- 01PSTN CALLERPublic telephone network
- 02DID NUMBERCalled number
- 03ORIGINATING CARRIERInbound network
- 04VIRPHONEInbound SIP delivery
- 05CUSTOMER SBCPBX / application
Bring the inbound network into your service.
A number is the beginning of the call path
Origination carries incoming calls from the telephone network to your SIP destination. The service design connects the number, its routing assignment and the application that should answer. Keep those records aligned so a provisioning change does not send callers to an obsolete trunk or the wrong customer environment.
Start with the receiving SBC or platform, its addressing and the team that maintains it. Document the expected called-number format, incoming caller identity and the behavior required when the application cannot receive a call.
Test the caller experience through cutover
Test from more than one originating network where practical. Verify ringing, answer, two-way audio, DTMF, transfer behavior and disconnect. For ported numbers, prepare an agreed test window and a contact who can verify the destination application immediately after activation.
Separate a failed delivery path from an application that intentionally rejects or redirects a call. Keep example timestamps and call references available during migration. Number ownership, routing ownership and application support should each have a named contact.
Where it fits in your network
- 01Calling party
- 02Number / PSTN ingress
- 03VirPhone routing
- 04Your SIP destination
Plan the connection around your traffic
Destination ownership
Identify the SBC or PBX that will receive calls and the team responsible for reachability. Document primary and alternate destinations.
Number lifecycle
Plan provisioning, assignment and porting together. New and ported numbers can have different lead times and documentation requirements.
Inbound validation
Test caller identity, called-number formatting, DTMF and two-way media. Include an unavailable-destination test in acceptance.
Agree the details before production
| Parameter | Planning detail |
|---|---|
| Delivery | Confirm destination addressing and supported authentication. |
| Number format | Agree called-number and caller-ID formats. |
| Porting | Eligibility and dates require a service-specific review. |
| Failover | Document and test agreed alternate destination behavior. |
What to review with your team
| Review area | What to establish |
|---|---|
| Number assignment | Number-to-trunk mapping and customer or application owner. |
| Delivery | SIP destination, number format and approved alternate behavior. |
| Validation | External test calls, DTMF, audio and application handling. |
Before the next step
Does origination include a hosted PBX?
Origination supplies inbound voice connectivity. Your receiving platform provides extensions, queues and other application features. Hosted PBX is a separate Business Communications service.
Can existing numbers be used?
Portability depends on the number and market. Confirm eligibility, authorization and an agreed migration schedule before changing the existing service.
From a public number to the application that answers
Inbound voice joins two records that are often maintained by different teams: a telephone number and a receiving SIP destination. VirPhone origination is the carrier delivery part of that path. Your SBC, PBX or platform receives the call and applies the customer’s application logic. A number can be active while its receiving application is still misconfigured, so both states need to be checked.
Document the expected called-number format and how the platform maps it to a tenant, queue or extension. Include incoming caller identity where relevant. Display-name services such as CNAM should be confirmed separately for the market and service; do not treat a caller’s displayed name as guaranteed identity.
Number migration is an operational event
A porting project needs a number inventory, authorization, a receiving call flow and someone available to test. Confirm which existing services depend on the numbers before scheduling the change. A main number may also be referenced by forwarding rules, announcements or a customer directory. Moving it without those dependencies can leave a technically delivered call in the wrong place.
Keep the current provider’s service active until the agreed completion. Test after activation from representative external networks and verify the destination application, not just a SIP response. The number-porting checklist provides the handoff sequence.
Define what an unreachable endpoint should do
Different failures require different handling. A receiving system may be offline, may reject a request or may be reachable while its application cannot answer. Describe the required behavior for each relevant case and agree any alternate destination as part of the service design. A secondary address is not useful until it has been tested with the same call formats and media requirements.
Maintain routing ownership after launch. When an SBC address or tenant assignment changes, update the service record and repeat inbound tests. Use monitoring evidence to separate an unavailable delivery path from intentional customer call handling.
Questions about this service
What does the receiving SBC need to know?
The approved destination, authentication, transport, called-number format and media profile. Also identify how the application maps incoming numbers to users or queues.
Can incoming caller-name information be guaranteed?
Confirm any caller-name service for the selected market and product. Caller display information and authenticated identity are different matters.
What happens if my endpoint is unavailable?
The service design must specify the agreed failure and alternate-destination behavior. Test that scenario before relying on it for continuity.
Move one inbound service before a wider rollout
Imagine a provider moving a support number to a new receiving platform. The project starts with number eligibility and the agreed port or provisioning process. The receiving route is configured before the public number moves, and the team tests the destination using an approved method.
After the coordinated change, test a real inbound call, DTMF navigation, transfer and an unavailable-endpoint case. Verify that the right application receives the number and that records identify the event. Keep the existing service active until completion and check unrelated dependencies before cancellation. This is a planning scenario; port timing and alternate delivery depend on the actual service.