Connect your network to VirPhone.
Define signaling, media, capacity and acceptance criteria for a controlled SIP interconnection.
- 01CUSTOMER SBCYour voice environment
- 02VIRPHONE EDGESIP interconnection
- 03CARRIER NETWORKPSTN connectivity
Turn a trunk into an operational connection.
Agree the demarcation before configuration
An interconnect needs a shared view of where each team’s responsibility starts. Identify the customer SBC, the service boundary and the destination applications. Document signaling, media, addressing, identity and capacity together so the implementation is consistent across engineering and operations.
Exchange production configuration through the approved technical process. A public diagram should help explain the architecture; it should not be used as a source of connection addresses, credentials or transport settings.
Build an acceptance matrix
A useful interop test set includes successful calls, rejected calls, cancellation, transfer behavior, DTMF and bidirectional media. Include representative destinations and the formats that will appear in production. Record both the expected behavior and the observed result.
Before increasing traffic, name the escalation contacts and agree the information needed for investigation. Define how configuration changes are approved, tested and reversed. Keep the accepted configuration with the operating documentation.
Where it fits in your network
- 01Your softswitch
- 02Your SBC
- 03VirPhone SIP edge
- 04Routing / destination
Plan the connection around your traffic
SIP peering
Exchange approved source and destination details through onboarding. Agree authentication, ports and transport before sending traffic.
Media path
Validate RTP in both directions with agreed codecs and DTMF. Distinguish NAT and SIP ALG issues from routing failures.
Acceptance criteria
Record CLI presentation, SIP responses, CANCEL/BYE behavior and timeouts. Test alternate paths before production approval.
Agree the details before production
| Parameter | Planning detail |
|---|---|
| Signaling | Agree E.164 normalization and SIP OPTIONS behavior. |
| Media | Confirm codec list, DTMF mode and RTP reachability. |
| Authentication | Confirm IP authentication or registration for your service. |
| Identity | Review STIR/SHAKEN and CLI requirements with the carrier team. |
| Capacity | Document CPS, concurrent calls and burst handling. |
| Security | Exchange approved addresses privately and confirm transport protections. |
What to review with your team
| Review area | What to establish |
|---|---|
| Signaling | Number formats, caller identity, response handling and session behavior. |
| Media | Codec agreement, DTMF and two-way reachability. |
| Acceptance | Test matrix, approved capacity and production decision. |
Before the next step
Which authentication method should I configure?
Use the method confirmed for your service in the approved interconnect guide. Do not assume IP authentication and registration are interchangeable.
When can production traffic begin?
After commercial and compliance review, technical acceptance and production approval. Completing a form does not automatically activate the interconnect.
A network-to-network engineering boundary
Carrier interconnection connects two operational environments. Each side has its own switching, routing and change process. The interconnect must establish how a call is admitted, how its destination and identity are represented, where media can flow and which team owns each fault domain. Those details matter more than a diagram that merely joins two clouds.
Identify the customer switch and SBC, the network path and the VirPhone service boundary. Record the selected authentication and transport, then agree how connection information is exchanged. The public topology is explanatory; actual addressing and credentials belong in the approved technical guide.
Prove more than the successful call
An acceptance matrix should contain both success and failure cases. Include rejection, cancellation, delayed progress, DTMF and disconnect from either end. Add transfers and forwarded calls when they are part of the intended service. Record the expected result before testing so different teams do not interpret the same trace differently.
OPTIONS can be part of a reachability or capability check, but a response to a probe does not prove every end-to-end call scenario. Separate trunk checks from application checks. Use the interop guide and response reference to keep the evidence organized.
Make handover part of acceptance
Production readiness includes capacity limits, escalation contacts and the process for changing routes or source addresses. Give commercial notices and technical incidents separate owners where appropriate. Confirm the maintenance and support commitments that apply to the selected service rather than assuming a universal arrangement.
Keep a copy of the accepted configuration and the test window’s call references. When a later change is made, select the affected cases from that matrix and repeat them. A controlled handover gives operations a practical way to distinguish a network problem from a new configuration dependency.
Questions about this service
What should an interop test prove?
The agreed signaling, media and call-handling behavior under representative success and failure cases, plus the capacity and operating boundaries required for launch.
Does an OPTIONS response prove voice quality?
No. A probe can help establish a signaling condition; it does not validate every destination, application flow or media path.
How are configuration changes handled?
Name the approving contacts and document the changed values, test cases and rollback decision. Retain the accepted configuration as the comparison baseline.
Accept the boundary, not just a successful call
An interconnect review can begin with a controlled set of destination and application cases. The teams exchange the approved parameters, identify signaling and media boundaries, and agree the evidence needed for each test. Rejections, unanswered calls and disconnects belong in the test record beside completed calls.
At the end, compare the observed behavior with the expected profile. Resolve exceptions or document them explicitly before increasing traffic. Retain the approved source addresses, formats and contacts in the handover record. A later change can then be evaluated against a known configuration. This is an example acceptance method; the actual cases and limits are agreed for the service.