Documentation

Connect any SIP switch to Open Voice Shield

Any switch, SBC, PBX or dialler that can send a SIP INVITE to a next hop can route calls through Open Voice Shield: whitelist your public IP on the Network page, point a route at sip.ovs.telecomsxchange.com port 5060 (UDP or TCP, G.711), and place a test call. It needs no registration and no credentials.

The two universal requirements#

Open Voice Shield is a SIP hop, so there is no integration to build. If your equipment can do these two things, it can send calls through us, whatever the vendor calls the knobs.

1. Send an initial INVITE, with SDP, to a next hop you choose. Any setting that takes a host and port (outbound proxy, trunk, peer, carrier, gateway, route) satisfies this. The offer must be early: an INVITE without SDP is answered 488.
2. Keep the media symmetric and unencrypted. Send RTP from the same port you expect to receive it on, as plain RTP without SRTP or ICE. Our media arrives from UDP 30000–40000 at the ingress address, in both directions, for the whole call.

Step 1: whitelist your server's IP#

Open the Network page in the portal and add the public address your switch sends from as a CIDR entry, a single host is a /32. The whitelist is the authentication: there are no credentials, and an INVITE from any other address is answered 403. Behind NAT, whitelist the address after NAT, the one the ingress sees.

Step 2: point a route at the ingress#

Every switch asks for the same ten values under different names. The block below is not a real configuration file. It is the answer sheet for whatever form your switch presents.

trunk / peer / gateway "ovs"
  host         sip.ovs.telecomsxchange.com
  port         5060
  transport    UDP or TCP
  register     no             # a REGISTER is answered 403
  credentials  none           # authorization is your whitelisted source IP
  codecs       PCMU, PCMA     # G.711 u-law / A-law first
  sdp          early offer, in the initial INVITE
  dtmf         RFC 2833 telephone-event (optional)
  media        plain RTP; ours arrives from UDP 30000-40000

Step-by-step versions of this page exist for Asterisk, FreeSWITCH, Kamailio and OpenSIPS, and for the commercial platforms, Ribbon SBC, PortaSwitch and AudioCodes, and for the CPaaS platforms, Twilio, Telnyx and Jambonz. For the full parameter-by-parameter treatment (routing order, tech prefix, every response code), see the SIP integration guide.

Route everything, or a sample#

You do not have to move all your traffic, sampling is a supported pattern. Any mechanism your switch already uses to spread calls across carriers can carve out a share for the analyzed hop: a weighted route set or trunk group on an SBC, a percentage-based routing policy on a class-4, a carrier mix on a dialler, a weighted distribution list or a random branch in a dialplan.

route-set "outbound"
  route "analyzed"   next-hop sip.ovs.telecomsxchange.com:5060   weight 10%
  route "direct"     next-hop your existing carrier              weight 90%

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

Or let the platform sample. Send everything and set the destination's sampling option under Network to one of two platform-side modes:

• 1 in N calls, relay the rest: every call is carried and recorded, one in N is analyzed, the rest can be analyzed on demand. A caller under a control, in an open case, or on a route with a recent alert is always analyzed.
• 1 in N calls, refuse the rest (SIP 503): one call in N is carried to the destination and analyzed. The others are refused with SIP 503 Service Unavailable, so your switch fails them over to its next route. Nothing is recorded or charged for a refused call and nothing widens the sample: you pay for exactly one call in N.

Step 3: place a test call#

Dial a real number over the new route and talk on both legs 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 your own SIP trace with the CIDR entries on the Network page.
• Rejected 488? The INVITE carried no SDP. Switch the trunk to early offer.
• One-way audio? A firewall rule on UDP 30000–40000, not a signalling problem.
• A recording but no verdict? The call negotiated a codec we do not decode (G.711, G.722, G.729 and G.723.1 are supported): put PCMU and PCMA at the top of the offer.

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.