ClearIP In-Line Proxy
The ClearIP In-Line Proxy enables easy integration between a SIP telecommunications network and ClearIP.
This software is not required in all ClearIP deployments. Some ClearIP customers prefer to use it because it can make deployment easier with their telecom network equipment and software.
The ClearIP In-Line Proxy performs the following functions:
- Receives SIP messages from network elements within a telecommunications network
- Maintains a secure encrypted connection with ClearIP
- Sends information over this secure connection to ClearIP
- Receives information back from ClearIP based upon services performed
- Sends the formatted information to network elements.
In summary, the ClearIP In-Line Proxy acts as secure message relay. It works with any SIP-based telecom system.
The ClearIP In-Line Proxy can be configured in several different ways according to the preferences and requirements of the service provider. The following figure shows an illustrative configuration:
In this arrangement, the ClearIP In-Line Proxy receives SIP INVITEs, sends them to ClearIP, receives the replies and sends the message to the appropriate network elements (e.g., switch, SBC).
The following figure shows the call flow for when ClearIP returns a SIP 302 Redirect response for routing and/or STIR/SHAKEN authentication:
- A Subscriber sends a call to the Switch over SIP or TDM.
- The Switch sends a SIP INVITE to the In-Line Proxy.
- The In-Line Proxy sends the SIP INVITE to ClearIP for services (e.g., STIR/SHAKEN authentication, routing, toll fraud prevention, robocall mitigation, etc.).
- ClearIP responds to the In-Line Proxy with a SIP 302 Redirect message with STIR/SHAKEN Identity header and Contact header, including the IP address(es) of the Destination(s).
- The In-Line Proxy inserts the Identity header into the SIP INVITE and sends a redirected SIP INVITE with Identity header to the first Destination. If the first Destination is unable to complete the call, then the In-Line Proxy would route the call to the second Destination listed in the SIP 302 Contact header.
ClearIP In-Line Proxy installation and setup
1. Create Virtual Machines
Create Virtual Machines (VMs) inside your private network with 4 GB of RAM and 2 cores running CentOS 7.x or Redhat 7.x.
- The VMs must have access to the internet.
- The VMs should not have public IP addresses. We recommend that you set up them up with Network Address Translation (NAT) through a firewall.
- No ports should be opened for external access.
- All connections to ClearIP from your network will be initiated through proxies running in the VMs. They will connect to ClearIP using TLS 1.2, so all traffic will be encrypted.
- The proxies will accept SIP messages on all interfaces via UDP (5060), TCP (5060), and TLS 1.2 (5061).
2. Set up a firewall on the server
Only trusted devices should be able to send SIP messages to the proxies. If untrusted devices exist on the same network as the proxies, then you must use a firewall to limit access.
If you are using CentOS 7 as your operating system, then you can run these commands to close out port 5060:
firewall-cmd --zone=public --remove-port=5060/udp --permanent
Then, you can allow a specific source IP from your Switch to the In-Line Proxy with these commands:
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="x.x.x.x" port protocol="udp" port="5060" accept'
These rules only apply to inbound (source) traffic. Outbound traffic is unrestricted by these rules.
If you use a different operating system than CentOS 7, then the commands may be different.
3. Install the In-Line Proxy on each VM
To install the proxy on each VM, run this command:
curl https://files.transnexus.com/clearip/installProxy.sh | sh -s
The proxy starts when installed and whenever its VM is rebooted. There is no starting/stopping or further configuration required.
4. Configure the Switch to route calls to the In-Line Proxy
You should configure your switch to route calls directly to the In-Line Proxy for test calls that should be monitored by ClearIP. If the In-Line Proxy is not available, then the Switch should be configured to route advance the call directly to the Destination as a backup.
We recommend that you do not send outbound calls made to Public Safety Answering Points (PSAPs), for example, 911/933 calls, to ClearIP. If ClearIP configurations are not made carefully to account for emergency calls to PSAPs, then these critical calls could be inadvertently blocked. In your routing translations, you should split off emergency calls first so that emergency calls are not sent to ClearIP, but every other outbound call goes through ClearIP.
5. Notify carriers of In-Line Proxy IP address
To ensure call completion, you should contact your carriers to whitelist the proxy IP address to ensure they can accept receiving calls from or sending calls to the ClearIP In-line Proxy.
6. Add the In-Line Proxy as a ClearIP SBC
Add the proxy as an entry in the ClearIP SBCs page to whitelist the IP address in ClearIP.
7. Send a test call to the In-Line Proxy
When you send call traffic to ClearIP, the software will use the SIP INVITE and perform the services configured.
If the proxy IP address has not been whitelisted in the ClearIP SBCs page, then ClearIP returns a SIP 404 Not Found response to the proxy. Once the proxy IP address has been whitelisted, then ClearIP can be configured to return the following response codes:
- If the ClearIP services don’t result in a block or diversion and neither routing nor STIR/SHAKEN services were requested, then ClearIP will return a SIP 503 Service Unavailable message. Your telecom network will then route-advance to the next destination in your routing table and send the call.
- If routing is enabled or a service initiates a diversion, ClearIP will return a SIP 302 Moved Temporarily to redirect the call to specific routes or divert it (e.g., to the CAPTCHA gateway, which prompts for human response).
- If a ClearIP service initated a block, ClearIP will return a SIP 603 Decline message. The proxy forwards this SIP 603 response to your switch, which will then block the call to prevent a route advance.
8. Send production calls to the In-Line Proxy
Once your ClearIP account has been configured with the desired services and integration testing is successful, you can configure your switch to send production calls to the proxy.
Configure the Proxy to use TCP instead of TLS
If there are any connectivity issues to ClearIP using the default TLS transport, you can try to switch the transport to TCP and test the connection.
The In-Line Proxy can be configured to use either TLS or TCP when communicating with ClearIP. TLS encrypts the messages between the proxy and ClearIP. Switching transport to TCP also allows you to pull unencrypted call traces from the proxy for easier troubleshooting.
To do this, use any text editor as the root user to edit the config file located here:
The following line should be changed from
$du = "sip:sip.clearip.com:5061;transport=tls";
$du = "sip:sip.clearip.com:5060;transport=tcp";
Then run this command to restart the In-Line Proxy so the change takes effect:
sudo systemctl restart opensips
Capture a call trace using tcpdump
You can capture a call trace in your network traffic by running the tcpdump command with different parameters. First, you need to install tcpdump using this command:
yum -y install tcpdump
Then you can run tcpdump to view SIP messages on the default SIP port 5060 with messages displayed on the console:
tcpdump -A -s 0 -n -nn -i any port 5060
You can also choose to view all network traffic and save the messages to a pcap file:
tcpdump -w trace.pcap -i any
Contact us today for more information on ClearIP and the ClearIP In-Line Proxy.
This information will only be used to respond to your inquiry. TransNexus will not share your data with any third parties. We will retain your information for as long as needed to retain a record of your inquiry. For more information about how we use personal data, please see our privacy statement.
ClearIP delivers the fastest, easiest, most-precise prevention of toll fraud, robocalls and TDoS attacks. It’s ready-to-go with STIR/SHAKEN.Learn more