Documentation

Connect Jambonz to Open Voice Shield

One routing change per direction. Inbound: have your carrier send your numbers to sip.ovs.telecomsxchange.com port 5060, with your Jambonz server as the destination on the Network page. Outbound: point the Carrier's SIP gateway at the same ingress and have your terminating carrier accept calls from the egress address the Network page shows.

Before you start#

• An Open Voice Shield account. Signup is self-serve and starts you with US$5 of credit.
• A running Jambonz deployment, self-hosted or in your own cloud, with access to its console or API to define Carriers and applications.
• The public IP address your Jambonz server 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 Jambonz and the rest of your traffic, and each direction is one configuration. Inbound, a call from the PSTN reaches your number, your carrier sends it to the ingress, and we analyze it and relay it on to the destination you configure on the Network page: your Jambonz server, which accepts the hop through an inbound SIP gateway on its Carrier. Outbound, Jambonz sends the call to the ingress, and we relay it on to your terminating carrier. That carrier must then accept calls arriving from our egress address, which the Network page shows you.

A platform built on Jambonz 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 outbound calls that means your own Jambonz server's public egress address, a single host is a /32. Because Jambonz is self-hosted, this is simpler than the hosted-CPaaS case: there is no vendor's published IP-range list to track, the address you whitelist is your own server's, and you control it. Inbound calls your carrier sends straight to the ingress need that carrier's signalling addresses whitelisted instead.

Step 2: point inbound calls at the ingress#

Inbound, the analyzed hop sits in front of Jambonz: have the carrier that delivers your numbers send them to the ingress. 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 Jambonz server. On the Jambonz side, a Carrier, its BYOC trunk, carries an inbound SIP gateway for each address it accepts calls from: add one for the Open Voice Shield egress address so the relayed calls are admitted, and route the number to your application as usual.

Names follow Jambonz documentation conventions. Consoles change, so check the current docs.

• The INVITE must carry SDP, an early offer. An INVITE without SDP is answered 488.
• Offer G.711 (PCMU or PCMA) first, Jambonz carries it, and leave secure media (SRTP) off towards the ingress: plain RTP. Anything else is relayed but produces no transcript and no verdict.
• Send no REGISTER at 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: give the Carrier an outbound SIP gateway, where Jambonz sends its calls, naming sip.ovs.telecomsxchange.com:5060 over UDP or TCP, and the destination you set on the Network page becomes your terminating carrier, so each analyzed call is relayed on to the PSTN. One more setting makes the far side accept the hop: your carrier must allow calls from our egress address.

Names follow Jambonz documentation conventions. Consoles change, so check the current docs.

From the application, the same hop is one verb, your webhook answers the call and dials on through the ingress with a sip target:

{
  "verb": "dial",
  "target": [
    {"type": "sip", "sipUri": "sip:+15551234567@sip.ovs.telecomsxchange.com"}
  ]
}

Or route a sample#

You do not have to move all your traffic, sampling is a supported pattern, and Jambonz gives you two ways in. In the webhook application, it is one if around the dial:

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 keep two Carriers, your direct one, and a dedicated Carrier whose outbound SIP gateway is the ingress, and pick the analyzed Carrier for the sampled share when your application places the call.

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.