RTP / MOS check safety

The rtp_mos check places a real call. Everything below follows from that one fact.

Point it at a dedicated echo extension

Configure an extension whose only job is to be called by a robot: it answers immediately and echoes the audio it receives. Most platforms ship one.

Never point it at a number a person answers. A monitor on a five-minute interval calls that number 288 times a day, forever.

Never point it at a PSTN destination you pay for. The check has no idea what a call costs.

Bar the test account from making real calls

This is the control that matters most, and it is not cryptographic.

The credential you give us can register. On most platforms, anything that can register can also originate calls, so a leaked credential is not an information disclosure: it is toll fraud, billed to you, typically to premium-rate or international destinations, typically overnight.

Configure the test account so that a stolen copy is worth nothing:

• no outbound PSTN permission at all, or at minimum no international and no premium-rate destinations
• no concurrent-call allowance beyond what the check needs (one)
• restricted to the extensions the check actually uses
• its own account, never shared with a phone, a trunk or a person

We encrypt credentials with AES-256-GCM, never return them from any endpoint, never log them, and only decrypt them server-side to hand to a probe over WSS. None of that helps if the account on the other end can dial Lagos at 3 AM. Bar it.

Why an echo, and not an announcement

Playback (a tone or a recorded message) gives one-way media only: jitter and loss on the inbound stream, and nothing about the path back. An echo returns what we sent, which is the only way to measure round-trip delay without clock sync between the probe and the far end. The delay term of the E-model is a large part of the score, so on a playback target it would be guesswork.

What we send

Near-silent G.711. The payload carries a four-byte counter in its first bytes and is otherwise codec silence, so a call that does reach a human is inaudible. The counter is how a returning packet is matched to the one that produced it: real echo applications re-originate the stream with their own SSRC, sequence numbers and timestamps, so nothing in the RTP header survives to correlate on.

We offer exactly one codec. Negotiating a list would mean measuring whatever the far end picked; offering one keeps the measurement comparable between runs and keeps the audio path a passthrough, which is what lets the counter survive.

Cleanup

The call is always hung up, including on every error path. A BYE that fails is reported in the result detail but never masks the measurement. If the probe dies mid-call the far end’s own session timer ends it.

Firewalling

The probe needs no inbound port. It sends RTP first from the same socket it listens on, so symmetric RTP gives any NAT or firewall in front of it a mapping before the far end replies. This is the same outbound-only posture as every other check.

If your SBC filters media by source address, allowlist the probe addresses as you would for signaling. A check that reports no RTP received when signaling is healthy usually means exactly this: the call set up fine and the media was dropped.

What the score means

The check reports an estimate from the ITU-T G.107 E-model, computed from measured delay, jitter and packet loss. It is not a listening test. It cannot see echo, codec transcoding beyond the payload type, or the far end’s own jitter buffer. Treat it as a comparable number that moves when the network moves, not as an absolute verdict on how a call sounded.

Rough bands, and the reason min_mos defaults to 3.6: