VoIP–PSTN Gateways: Test Call Paths

Map both sides of every call

Document source and destination number format, port role, routing rule, signalling, negotiated media and disconnect behaviour. A port for a telephone and a port for a line have different electrical expectations.

SIP and SDP have distinct documented session-control and session-description roles. RFC 4733 separately describes an RTP payload for DTMF, tones and telephony events; test the required call behaviours rather than treating setup as proof of every function.

Use a real acceptance test

Test inbound and outbound calls, answer and release, two-way audio, required DTMF, recovery after loss of power or network, and only features authorised by the connected service.

Record gateway configuration, address plan, firmware version and cable map locally. Agree emergency-call and power-failure behaviour with responsible operator and site owner; do not assume a generic gateway preserves every traditional-line feature.

State the service boundary

A gateway cannot create a telephone service that the connected line or provider does not supply. Keep commercial, regulatory and routing responsibilities outside the device feature list.

When replacing a gateway, test the replacement in parallel where possible and preserve the old configuration securely until the new call path is accepted.

Map the call as two linked paths

A gateway call has a signalling path and a media path, plus a telephone-side path through a port and line or handset. For each direction, identify the called number form, the incoming interface, the route selected by the gateway, the outgoing interface, and the expected result. This map makes a simple distinction visible: a number can be accepted for routing while the audio path still fails later.

Use a controlled example. For an outbound call, note what number the caller dials, how the gateway transforms or presents it, which port or SIP route is used, and where the call should end. For an inbound call, reverse the map. If only one direction fails, do not begin by changing every codec or cable. Compare the two maps to find the first step that differs: number handling, route selection, port state, session setup, or media.

Keep analogue port roles unambiguous

An analogue port that supplies telephone service has a different role from one that receives a line. The connected cable may look familiar in both cases, but the electrical expectation is not interchangeable. Before connecting a live line or handset, identify the port role from the documentation for the exact gateway and confirm that the connected device is intended for that role.

This matters in troubleshooting as well as installation. If an analogue device has no dial tone, first establish whether the gateway port is meant to provide a line or accept one. If a line-facing port is connected where a telephone-facing port was expected, changing SIP credentials will not solve the basic mismatch. Starting at the physical interface prevents a software investigation from hiding an incorrect connection.

Read SIP setup and RTP media separately

SIP is used for creating, modifying, and terminating sessions; session descriptions communicate the media arrangement. An answered call therefore shows that some signalling exchange succeeded, not that the media stream is flowing in both directions. The far party may answer while the caller hears nothing, or one party may hear audio while the other does not. Treat those as media-path observations, not as contradictory reports of the same result.

Run the call test in stages: dial, ringing, answer, two-way speech, and release. State the expected outcome before each stage. If ringing and answer work but speech is one-way, preserve the successful signalling result and inspect the media path separately. If release fails after speech works, keep the media result separate from the release result. This staging prevents an engineer from losing the narrow fault by summarising the entire call as “failed.”

Test the offered media, not only the configured media

Session description can offer and agree media parameters, but an operational test still needs actual speech across the completed path. Test both directions with a deliberate spoken prompt, not only silence or a call timer. If one direction is absent, compare the packet-side and telephone-side boundaries in that direction before changing multiple settings. An asymmetrical symptom is useful evidence because it limits which paths must have failed.

Use the same endpoints and call route for a before-and-after check. Change one candidate condition, repeat the same spoken prompt, and record whether caller-to-callee and callee-to-caller audio changed independently. A broad reset may make the symptom disappear temporarily, but it removes the relation between the change and the result. Controlled repetition is especially important where a gateway joins a local packet network to a separate telephone interface.

Verify DTMF at the service boundary

DTMF digits, tones, and telephony events can be carried as RTP telephony events rather than relying on a voice codec to reproduce them for automatic recognition. A call that has clear speech can therefore still fail at an IVR, voicemail menu, or remote-control system when a required digit is sent. The test must include the actual menu step or destination behaviour that depends on the digit.

Build the check around the required sequence, such as a menu selection followed by the expected prompt or action. Test it after two-way audio is established and in both call directions if both are used. If speech works but the menu ignores input, retain that result as a DTMF-specific fault. Do not “prove” the digits by hearing them in audio: the useful outcome is whether the receiving service recognises the intended event.

Design acceptance around the real service

Acceptance is more than placing one successful call. Test authorised inbound and outbound calls, number presentation where it is part of the design, answer, release, two-way audio, required DTMF, and the chosen recovery behaviour after a permitted network or power interruption. Each test should identify the port or route involved so that a failure can be assigned to a path rather than to the gateway name alone.

Traditional-line expectations must not be assumed at this boundary. Emergency handling, behaviour during loss of power, caller identity, and provider features depend on the connected service and installation. Treat them as explicit acceptance questions, not properties implied by a VoIP–PSTN label. That boundary keeps acceptance tied to the conditions of the installed call path, rather than attributing untested behaviour to the gateway alone.