Documentation

Connect Telnyx to Open Voice Shield

One routing change per direction. Inbound: a SIP Connection with FQDN authentication pointing at sip.ovs.telecomsxchange.com port 5060, your numbers routed to it, your platform as the destination on the Network page. Outbound: send calls to the same ingress with sip.telnyx.com as the destination, and add the Network page's egress address to an IP-authenticated Telnyx connection.

Before you start#

• An Open Voice Shield account. Signup is self-serve and starts you with US$5 of credit.
• A Telnyx account with at least one number and permission to create SIP Connections and Outbound Voice Profiles.
• For outbound calls, the public IP address your platform sends SIP from, the egress address after any NAT, not the one on its interface.
• Firewall: UDP or TCP 5060 to the ingress, and UDP 30000–40000 open in both directions for the RTP your media endpoints exchange with our relay. See the firewall rules.

One relay, two directions#

Open Voice Shield sits between Telnyx and the rest of your platform, and each direction is one configuration. Inbound, a call from the PSTN reaches your Telnyx number, Telnyx sends it to the ingress, and we analyze it and relay it on to the destination you configure on the Network page: your application or switch. Outbound, your platform sends the call to the ingress, and we relay it on to Telnyx for termination. Telnyx must then accept calls arriving from our egress address, which the Network page shows you.

A platform built on Telnyx gets fraud and route monitoring, sampled or full, in one routing change, without touching its application architecture.

Step 1: whitelist the sending addresses#

Open the Network page in the portal and add the addresses that will send SIP to the ingress as CIDR entries. The whitelist is the authentication: there are no credentials, and an INVITE from any other address is answered 403. For inbound calls that means Telnyx's published signalling IP ranges, taken from Telnyx's current documentation. For outbound calls it means your own platform's public egress address (a single host is a /32).

Step 2: route inbound numbers to the ingress#

On Telnyx, a number rings whatever connection it routes to. Create a SIP Connection whose FQDN authentication names the ingress, route the numbers you want analyzed to it, and Telnyx sends each of their calls straight to us. The dialled number and caller ID pass through unchanged, and we relay each accepted call on to the destination you set on the Network page, your own platform.

Names follow Telnyx documentation conventions. Consoles change, so check Telnyx's current docs.

• The INVITE must carry SDP, an early offer. An INVITE without SDP is answered 488.
• Offer G.711 (PCMU or PCMA) first. Anything else is relayed but produces no transcript and no verdict.
• Do not send REGISTER to the ingress: it is answered 403. Calls are authorized by source IP alone.

Step 3: send outbound calls through the ingress#

Outbound is the mirror image: your platform routes its calls to sip.ovs.telecomsxchange.com:5060 over UDP or TCP, and the destination you set on the Network page becomes sip.telnyx.com, the Telnyx termination URI, so each analyzed call is relayed on to Telnyx for the PSTN. One more setting makes Telnyx accept the hop: a connection must recognize our egress address, and carry an Outbound Voice Profile so it may dial out.

Names follow Telnyx documentation conventions. Consoles change, so check Telnyx's current docs.

Or route a sample#

You do not have to move all your traffic. Sampling is a supported pattern. If a call-control application drives your calls, the sample is one if around the dial: for the sampled share it dials the Open Voice Shield SIP URI instead of the direct route:

if random(10) = 1                # one call in ten takes the analyzed hop
  dial sip:{number}@sip.ovs.telecomsxchange.com
else
  dial {number}                  # your existing direct route

Or sample deterministically with a subset: route one number range to the FQDN connection and leave the rest where they are, or send just one connection's traffic through the ingress while the others stay direct.

Both paths deliver the call: the analyzed share reaches the same destination through one extra hop, and every sampled call comes back with a recording, per-channel transcript and verdict.

Step 4: place a test call#

Send a real call through each direction you configured and keep both parties talking for at least 30 seconds. A leg that never speaks produces a one-sided transcript. After hang-up the call appears in Calls in the console with its recording, per-channel transcript and verdict, usually within a minute.

• Rejected 403? The source address is not whitelisted. Compare the sending address with the CIDR entries on the Network page.
• Rejected 488? The INVITE carried no SDP, or offered SRTP. Send an early offer as plain RTP.
• One-way audio? A firewall rule on UDP 30000–40000 between your media endpoints and the ingress, not a signalling problem.

Anything else: Troubleshooting lists every rejection code and the check that clears it.

Frequently asked questions#

Ready to try it? Create an account. Signup is self-serve and comes with US$5 of credit, enough to analyze your first test calls.