Start with the network boundary.

SIP responses describe signaling progress and outcomes. A 100 response means the request is being processed; 180 indicates ringing; 200 can indicate successful acceptance of an INVITE. Authentication challenges and unsuccessful responses require interpretation in the context of the transaction. A single code is not a complete diagnosis.

Keep a timestamp with timezone, call direction, Call-ID and a sanitized trace. Compare the request, response sequence and final outcome. Separate failures created by the originating application from those returned downstream. Never include passwords or authorization secrets in an ordinary support message.

Standards reference: RFC 3261: Session Initiation Protocol.

A ringing call can still have a media problem. Signaling negotiates the session; the media path carries audio. Review the codec offer and answer, advertised media addresses and the firewall/NAT path. Codec support and encryption depend on the agreed service profile; do not infer them from a generic diagram.

Test two-way audio, hold and resume, transfer and DTMF using the real endpoints. Telephone-event handling is described in RFC 4733, but the supported payload and configuration must be agreed for the interconnect. A successful test to one endpoint does not validate every application flow.

Standards reference: RFC 4733: RTP telephone events.

When signaling succeeds but calls have one-way audio or intermittent setup failures, inspect address translation and the media path. A firewall helper or SIP ALG may modify messages. Record the current network topology and configuration before changing it, and follow the SBC and firewall vendor guidance for that environment.

Change one variable at a time in a controlled test. Compare signaling addresses, media addresses and packet flow on both sides of the boundary. A blanket instruction to disable a feature is not a replacement for understanding the specific topology.

Standards reference: RFC 6314: NAT traversal practices for SIP.

Document the source and destination systems, approved authentication method, signaling transport, number format and media profile. Test representative successful calls as well as busy, unanswered, rejected and unavailable destinations. Record the expected behavior and the result for each case.

Use a controlled allocation for capacity testing. Define the authorized test limits and stop conditions in advance. At completion, retain the accepted configuration, unresolved exceptions, named owners and the conditions under which a production change must be reviewed.

Standards reference: SIP protocol reference.

Consider a hypothetical answered call lasting 61 seconds. Under 60/60 billing, a 60-second minimum followed by 60-second increments gives 120 chargeable seconds. Under 6/6 billing, a six-second minimum followed by six-second increments gives 66 chargeable seconds. These are educational examples, not VirPhone rates or billing terms.

Apply the actual rate deck, currency, timezone and effective date to a representative set of calls. Reconcile using the agreed billable-duration definition. A lower per-minute rate does not always produce a lower charge when minimums and increments differ. See wholesale voice evaluation for the wider commercial review.

Create an inventory of numbers and their associated services. Obtain the account information and authorization required for the specific provider and market through the approved secure process. Confirm portability and any dependencies before committing to a cutover date.

Keep the losing service active until the coordinated completion. Configure the receiving destination before the agreed window and test inbound calls afterward. Investigate fax, alarm or other dependencies separately; moving a voice number does not prove that every attached service has migrated.

Caller display, caller-name services and authenticated identity solve different problems. Confirm the identity format and permitted usage for the service. Do not assume that successful presentation of a number demonstrates ownership, authorization or end-to-end authentication.

For the proposed traffic and jurisdictions, establish the responsibilities of each party and how identity is handled across the interconnect. Public standards explain the mechanism; the service agreement and technical profile define the supported implementation.

Standards reference: RFC 8224: authenticated identity in SIP.