Oracle Acme Packet outbound configuration for ClearIP
This documentation provides instructions on how to configure an Oracle Acme Packet Session Border Controller (SBC) with ClearIP for outbound calls. After the SBC has been configured according to these instructions, then SIP INVITES can be sent to ClearIP.
The diagram below provides an overview of how ClearIP is configured as a SIP end point with an SBC. A SIP INVITE is sent from the CFS (Call Feature Server) to the SBC. Then the SBC forwards the INVITE to ClearIP for services, such as fraud and robocall control.
If no fraud is detected, ClearIP returns a SIP 404 No Route Found message and the SBC forwards the INVITE to the original destination. If fraud is detected, ClearIP responds with a SIP 603 Decline message indicating the call should be blocked. The SBC forwards the SIP 603 Decline message to the CFS. ClearIP can also return a SIP 302 Moved Temporarily message with an alternative destination if the call should be diverted.
Outbound network call flow
This documentation does not include SBC installation instructions, such as installing SBC VMware image, configuring network interfaces, etc. This work should be done by Oracle technical support.
We have provided separate instructions for Oracle Acme Packet SBC configuration for STIR/SHAKEN with ClearIP.
Contents
1. Outbound scenarios
ClearIP can be used for STIR/SHAKEN authentication, toll fraud prevention for outbound call scenarios and used for STIR/SHAKEN verification and robocall prevention for inbound call scenarios. In the inbound scenarios, SBC directly forwards the calls from source devices to ClearIP. In the outbound scenarios, SBC forwards the calls to ClearIP before sending them out to destinations. This documentation only discusses the outbound scenarios.
This section describes one outbound scenario that is commonly used by telephone service providers.
Original scenario without ClearIP
Key components
- Core Network — The network inside the domain of the telephone service provider.
- Access Network — The network outside the domain of the telephone service provider.
- Call Feature Server — The server of the telephone service provider that provides routing, billing, etc. features.
- SBC Internal Interface — The internal SIP interface configured on the SBC to connect to the Core Network.
- SBC External Interface — The external SIP interface configured on the SBC to connect to the Access Network.
- Network Gateway — The device in the Access Network that sends SIP calls from the telephone service provider.
Routing rules
- CFS-L — Local policies configured on the Call Feature Server.
- SBC-L1 — Local policies configured on the SBC for the SBC Internal Interface/Core Network.
- SBC-L2 — Local policies configured on the SBC for the SBC External Interface/Access Network.
Note: There may be only one set of SBC local policies. We separate it into two sets of policies logically.
Data flow
- F1 — The Call Feature Server sends calls to the SBC Internal Interface based on the local policies CFS-L configured on the Call Feature Server.
- F2 — The SBC Internal Interface forwards the calls to the SBC External Interface based on the local policies SBC-L1 configured on the SBC for the SBC Internal Interface.
- F3 — The SBC External Interface forwards the calls to the Network Gateway based on the local policies SBC-L2 configured on the SBC for the SBC External Interface.
Proposed scenario with ClearIP
Key components
- Core Network — The network inside the domain of the telephone service provider.
- Access Network — The network outside the domain of the telephone service provider. ClearIP is typically in the Access Network.
- Call Feature Server — The server of the telephone service provider that provides routing, billing, etc. features.
- SBC Internal Interface — The internal SIP interface configured on the SBC to connect to the Core Network.
- SBC External Interface — The external SIP interface configured on the SBC to connect to the Access Network.
- ClearIP — The TransNexus STIR/SHAKEN, toll fraud prevention, and robocall prevention solution.
- Network Gateway — The device in the Access Network that sends SIP calls from the telephone service provider.
Routing rules
- CFS-L — Local policies configured on the Call Feature Server.
- SBC-L1 — Local policies configured on the SBC for the SBC Internal Interface.
- SBC-L2’ + SBC-L2 — Local policies configured on the SBC for the SBC External Interface. It includes the routing policy SBC-L2’ for ClearIP and the original local policies SBC-L2 configured on the SBC for the SBC External Interface.
Note: It may not be necessary to change SBC-L1 and SBC-L2.
Data flow
- F1 — The Call Feature Server sends calls to the SBC Internal Interface based on the local policies CFS-L configured on the Call Feature Server.
- F2 — The SBC Internal Interface forwards the calls to the SBC External Interface based on the local policies SBC-L1 configured on the SBC for the SBC Internal Interface.
- F2’ — The SBC External Interface forwards the calls to ClearIP for fraud detection based on the local policies SBC-L2’ configured on the SBC for the SBC External Interface for ClearIP.
- F2’’ — ClearIP sends a response to the SBC External Interface. If fraud is detected, then a SIP 603 Decline is sent to the SBC. The SBC External Interface forwards the SIP 603 Decline to the Call Feature Server and finishes the calls. If fraud is not detected, then a SIP 404 Not Found is sent to the SBC.
- F3 — The SBC External Interface forwards the calls to the Network Gateway based on the local policies SBC-L2 configured on the SBC for the SBC External Interface.
2. Basic configuration
This section provides the basic standard configuration for an SBC.
Network diagram
Network interface configuration
To access ClearIP by its FQDN (Fully Qualified Domain Name), sip.clearip.com, there must be at least one DNS server configured. The DNS server should be configured in the network-interface.
Important configuration items:
| 1. | dns-ip-primary | 8.8.8.8 |
| 2. | dns-ip-backup1 | 8.8.4.4 |
In the sample configuration below, Google is used as the DNS service provider. Google Public DNS IPv4 servers are configured on the external network interface, M11, which connects to the Access Network. Other DNS servers can be used too. For example, an internal DNS server of the telephone service provider in the Core Network can be configured on the internal network interface, M10, which connects to the Core Network. The desired DNS server IP addresses should be configured.
A previously existing network interface should be configured as shown below.
Highlighted items should be different from the default values. Non-highlighted values can be left as the SBC default values. Some highlighted values such as the name, ip-address, etc. should be left as the previously existing values.
- Sample network configuration
network-interface name M10 sub-port-id 0 description hostname ip-address 172.16.4.157 pri-utility-addr sec-utility-addr netmask 255.255.0.0 gateway 172.16.4.1 sec-gateway gw-heartbeat state disabled heartbeat 0 retry-count 0 retry-timeout 1 health-score 0 dns-ip-primary dns-ip-backup1 dns-ip-backup2 dns-domain dns-timeout 11 hip-ip-list ftp-address icmp-address snmp-address telnet-address ssh-address signaling-mtu 0 network-interface name M11 sub-port-id 0 description hostname ip-address 192.168.1.157 pri-utility-addr sec-utility-addr netmask 255.255.0.0 gateway 192.168.1.1 sec-gateway gw-heartbeat state disabled heartbeat 0 retry-count 0 retry-timeout 1 health-score 0 dns-ip-primary 8.8.8.8 dns-ip-backup1 8.8.4.4 dns-ip-backup2 dns-domain clearip.com dns-timeout 11 hip-ip-list ftp-address icmp-address snmp-address telnet-address ssh-address signaling-mtu
Realm configuration
The SBC is configured with two realms, CoreRealm and AccessRealm. They are mapped to the Core Network and Access Network, respectively. The Core Network includes trusted devices of the telephone service provider. The Access Network includes the devices outside the trusted network, customer devices, and provider devices.
Note: ClearIP can be treated as a trusted device in the Core Network or as a normal device in the Access Network. For the outbound scenario, ClearIP is treated as a device in the Access Network. You can either create a new realm or use an existing realm for ClearIP.
- Sample realm configuration
realm-config identifier CoreRealm description addr-prefix 0.0.0.0 network-interfaces M10:0 mm-in-realm disabled mm-in-network enabled mm-same-ip enabled mm-in-system enabled bw-cac-non-mm disabled msm-release disabled qos-enable enabled generate-UDP-checksum disabled max-bandwidth 0 fallback-bandwidth 0 max-priority-bandwidth 0 max-latency 0 max-jitter 0 max-packet-loss 0 observ-window-size 0 parent-realm dns-realm media-policy media-sec-policy srtp-msm-passthrough disabled in-translationid out-translationid in-manipulationid out-manipulationid manipulation-string manipulation-pattern class-profile average-rate-limit 0 access-control-trust-level none invalid-signal-threshold 0 maximum-signal-threshold 0 untrusted-signal-threshold 0 nat-trust-threshold 0 deny-period 30 cac-failure-threshold 0 untrust-cac-failure-threshold 0 ext-policy-svr diam-e2-address-realm symmetric-latching disabled pai-strip disabled trunk-context early-media-allow enforcement-profile additional-prefixes restricted-latching none restriction-mask 32 accounting-enable enabled user-cac-mode none user-cac-bandwidth 0 user-cac-sessions 0 icmp-detect-multiplier 0 icmp-advertisement-interval 0 icmp-target-ip monthly-minutes 0 net-management-control disabled delay-media-update disabled refer-call-transfer disabled refer-notify-provisional none dyn-refer-term disabled codec-policy codec-manip-in-realm disabled constraint-name call-recording-server-id xnq-state xnq-unknown hairpin-id 0 stun-enable disabled stun-server-ip 0.0.0.0 stun-server-port 3478 stun-changed-ip 0.0.0.0 stun-changed-port 3479 match-media-profiles qos-constraint sip-profile sip-isup-profile block-rtcp disabled hide-egress-media-update disabled tcp-media-profile subscription-id-type END_USER_NONE realm-config identifier AccessRealm description addr-prefix 0.0.0.0 network-interfaces M11:0 mm-in-realm disabled mm-in-network enabled mm-same-ip enabled mm-in-system enabled bw-cac-non-mm disabled msm-release disabled qos-enable disabled generate-UDP-checksum disabled max-bandwidth 0 fallback-bandwidth 0 max-priority-bandwidth 0 max-latency 0 max-jitter 0 max-packet-loss 0 observ-window-size 0 parent-realm dns-realm media-policy media-sec-policy srtp-msm-passthrough disabled in-translationid out-translationid in-manipulationid out-manipulationid manipulation-string manipulation-pattern class-profile average-rate-limit 0 access-control-trust-level none invalid-signal-threshold 0 maximum-signal-threshold 0 untrusted-signal-threshold 0 nat-trust-threshold 0 deny-period 30 cac-failure-threshold 0 untrust-cac-failure-threshold 0 ext-policy-svr diam-e2-address-realm symmetric-latching disabled pai-strip disabled trunk-context early-media-allow enforcement-profile additional-prefixes restricted-latching none restriction-mask 32 accounting-enable enabled user-cac-mode none user-cac-bandwidth 0 user-cac-sessions 0 icmp-detect-multiplier 0 icmp-advertisement-interval 0 icmp-target-ip monthly-minutes 0 net-management-control disabled delay-media-update disabled refer-call-transfer disabled refer-notify-provisional none dyn-refer-term disabled codec-policy codec-manip-in-realm disabled constraint-name call-recording-server-id xnq-state xnq-unknown hairpin-id 0 stun-enable disabled stun-server-ip 0.0.0.0 stun-server-port 3478 stun-changed-ip 0.0.0.0 stun-changed-port 3479 match-media-profiles qos-constraint sip-profile sip-isup-profile block-rtcp disabled hide-egress-media-update disabled tcp-media-profile subscription-id-type END_USER_NONE
3. Media configuration
The SBC should be configured to bypass media traffic between the SBC and ClearIP. Call audio should not be sent to ClearIP.
4. Outbound call scenarios
After an outbound call has been processed by ClearIP, ClearIP responds in one of three ways:
- No fraud detected
- Fraud detected
- Diverted
These call flows are described below.
No fraud detected
- The CFS sends a call to the SBC core realm (a)
- The SBC forwards the call to ClearIP (b, c)
- ClearIP returns a SIP 404 if no fraud detected and no Identity header returned. If STIR/SHAKEN authentication is requested, ClearIP returns an Identity header in a SIP 302 (d).
- If the Identity header is returned, then the SBC should copy the Identity header into the outgoing SIP Invite using the embedded header apporach described in Oracle Acme Packet SBC configuration for STIR/SHAKEN with ClearIP.
- SBC tries to forward the call to the Destination, the original target device (e)
Fraud detected
- The CFS sends a call to the SBC core realm (a)
- The SBC forwards the call to ClearIP (b, c)
- ClearIP returns a SIP 603 (d)
- The SBC drops the call (e, f)
Diverted
- The CFS sends a call to the SBC core realm (a)
- The SBC forwards the call to ClearIP (b, c)
- ClearIP returns a SIP 302 with the destination of the diversion device (d)
- SBC tries to forward the call to the diversion device (e)
5. SBC configuration
This section provides details on the SBC configuration settings for operation with ClearIP for outbound call scenarios.
High-level description
- The basic idea is to insert ClearIP into the normal configuration.
- The SBC should be configured to perform hunting (route advance) if ClearIP returns a SIP 404. The call routing policy rule for this part should be:
- Try ClearIP first
- Try other destinations
- By default, the SBC will perform hunting when it receives SIP 404 messages.
- The SBC should drop the call if ClearIP returns a SIP 603. This is the default behavior of the SBC, so no configuration should be needed.
The session agent for ClearIP should be configured to handle SIP redirect messages.
Instructions
A. Configure the AccessRealm SIP interface to use TCP
Important configuration items:
| 1. | transport-protocol | TCP |
| 2. | trans-expire | 5 |
ClearIP only supports TCP and TLS, so the SIP interface must be configured to support TCP. Trans-expire should be configured to allow the SBC to quickly fail a call attempt. This is useful if ClearIP is unavailable and the SBC timeout for establishing TCP connection is long.
- Sample SIP interface configuration
sip-interface state enabled realm-id AccessRealm description sip-port address YOUR_PUBLIC_IP_HERE port 5060 transport-protocol TCP tls-profile multi-home-addrs allow-anonymous all ims-aka-profile carriers trans-expire 5 initial-inv-trans-expire 0 invite-expire 0 max-redirect-contacts 0 proxy-mode redirect-action contact-mode none nat-traversal none nat-interval 30 tcp-nat-interval 90 registration-caching disabled min-reg-expire 300 registration-interval 3600 route-to-registrar disabled secured-network disabled teluri-scheme disabled uri-fqdn-domain trust-mode all max-nat-interval 3600 nat-int-increment 10 nat-test-increment 30 sip-dynamic-hnt disabled stop-recurse 401,407 port-map-start 0 port-map-end 0 in-manipulationid out-manipulationid manipulation-string manipulation-pattern sip-ims-feature disabled subscribe-reg-event disabled operator-identifier anonymous-priority none max-incoming-conns 0 per-src-ip-max-incoming-conns 0 inactive-conn-timeout 0 untrusted-conn-timeout 0 network-id ext-policy-server default-location-string charging-vector-mode pass charging-function-address-mode pass ccf-address ecf-address term-tgrp-mode none implicit-service-route disabled rfc2833-payload 101 rfc2833-mode transparent constraint-name response-map local-response-map ims-aka-feature disabled enforcement-profile route-unauthorized-calls tcp-keepalive none add-sdp-invite disabled add-sdp-profiles sip-profile sip-isup-profile tcp-conn-dereg 0 register-keep-alive none kpml-interworking disabled tunnel-name msrp-delay-egress-bye disabled send-380-response session-timer-profile
B. Configure ClearIP (sip.clearip.com) as a session agent
Important configuration items:
| 1. | hostname | sip.clearip.com |
| 2. | port | 5060 |
| 3. | transport-method | DynamicTCP |
| 4. | redirect-action | Recurse |
| 5. | ping-method | OPTIONS |
| 6. | ping-interval | 10 |
| 7. | ping-send-mode | keep-alive |
| 8. | ping-all-addresses | enabled |
ClearIP’s FQDN (Fully Qualified Domain Name), port, and transport protocol must be configured. The redirect action must be configured as recurse to allow the SBC to handle SIP redirect messages directly. Ping options should be configured to allow the SBC to detect ClearIP status instead of waiting for a TCP connection issue timeout.
- Sample session agent configuration
session-agent hostname sip.clearip.com ip-address port 5060 state enabled app-protocol SIP app-type transport-method DynamicTCP realm-id AccessRealm egress-realm-id description carriers allow-next-hop-lp enabled constraints disabled max-sessions 0 max-inbound-sessions 0 max-outbound-sessions 0 max-burst-rate 0 max-inbound-burst-rate 0 max-outbound-burst-rate 0 max-sustain-rate 0 max-inbound-sustain-rate 0 max-outbound-sustain-rate 0 min-seizures 5 min-asr 0 time-to-resume 0 ttr-no-response 0 in-service-period 0 burst-rate-window 0 sustain-rate-window 0 req-uri-carrier-mode None proxy-mode redirect-action Recurse loose-routing enabled send-media-session enabled response-map ping-method OPTIONS ping-interval 10 ping-send-mode keep-alive ping-all-addresses enabled ping-in-service-response-codes out-service-response-codes load-balance-dns-query hunt media-profiles in-translationid out-translationid trust-me disabled request-uri-headers stop-recurse local-response-map ping-to-user-part ping-from-user-part li-trust-me disabled in-manipulationid out-manipulationid manipulation-string manipulation-pattern p-asserted-id trunk-group max-register-sustain-rate 0 early-media-allow invalidate-registrations disabled rfc2833-mode none rfc2833-payload 0 codec-policy enforcement-profile refer-call-transfer disabled refer-notify-provisional none reuse-connections NONE tcp-keepalive none tcp-reconn-interval 0 max-register-burst-rate 0 register-burst-window 0 sip-profile sip-isup-profile kpml-interworking inherit
Important notes:
- Using TLS instead of TCP is optional. If TLS is desired, then the port should be set to 5061.
- Do not configure the sip.clearip.com session agent with a static IP address. The IP addresses for ClearIP will change for load balancing and maintenance. Using a static IP address for ClearIP will cause a service interruption. Use hostname
sip.clearip.cominstead. - ClearIP does not respond to UDP messages.
C. Configure the destination (dest.carrier.com) session agent as the original target device
- Sample destination session agent configuration
session-agent hostname dest.carrier.com ip-address 192.168.1.19 port 5060 state enabled app-protocol SIP app-type transport-method UDP realm-id AccessRealm egress-realm-id description carriers allow-next-hop-lp enabled constraints disabled max-sessions 0 max-inbound-sessions 0 max-outbound-sessions 0 max-burst-rate 0 max-inbound-burst-rate 0 max-outbound-burst-rate 0 max-sustain-rate 0 max-inbound-sustain-rate 0 max-outbound-sustain-rate 0 min-seizures 5 min-asr 0 time-to-resume 0 ttr-no-response 0 in-service-period 0 burst-rate-window 0 sustain-rate-window 0 req-uri-carrier-mode None proxy-mode redirect-action loose-routing enabled send-media-session enabled response-map ping-method ping-interval 0 ping-send-mode keep-alive ping-all-addresses disabled ping-in-service-response-codes out-service-response-codes load-balance-dns-query hunt media-profiles in-translationid out-translationid trust-me disabled request-uri-headers stop-recurse local-response-map ping-to-user-part ping-from-user-part li-trust-me disabled in-manipulationid out-manipulationid manipulation-string manipulation-pattern p-asserted-id trunk-group max-register-sustain-rate 0 early-media-allow invalidate-registrations disabled rfc2833-mode none rfc2833-payload 0 codec-policy enforcement-profile refer-call-transfer disabled refer-notify-provisional none reuse-connections NONE tcp-keepalive none tcp-reconn-interval 0 max-register-burst-rate 0 register-burst-window 0 sip-profile sip-isup-profile kpml-interworking inherit
D. Set the ClearIP session agent as the first enabled destination in the existing local policy
- Sample local policy configuration
local-policy from-address * to-address * source-realm CoreRealm description activate-time N/A deactivate-time N/A state enabled policy-priority none policy-attribute next-hop sip.clearip.com realm AccessRealm action none terminate-recursion disabled carrier start-time 0000 end-time 2400 days-of-week U-S cost 0 app-protocol state enabled methods media-profiles lookup single next-key eloc-str-lkup disabled eloc-str-match policy-attribute next-hop dest.carrier.com realm AccessRealm action none terminate-recursion disabled carrier start-time 0000 end-time 2400 days-of-week U-S cost 0 app-protocol state enabled methods media-profiles lookup single next-key eloc-str-lkup disabled eloc-str-match
6. Sending SIP INVITEs to ClearIP
If the above configurations have been implemented successfully, then the SBC should be able to send a SIP INVITE to ClearIP.
The following is an example SIP INVITE message with the minimum number of SIP headers required by ClearIP. ClearIP will accept a SIP INVITE in any format, with no limit on additional headers and the SDP (Session Description Protocol) information.
INVITE sip:18001234567@sip.clearip.com:5060 SIP/2.0 Via: SIP/2.0/TCP sip.clearip.com:5060 From: <sip:14045266060@5.6.7.8:5060>;tag=123456789 To: sip:18001234567@1.2.3.4:5060 Call-ID: 1-12345@5.6.7.8 CSeq: 1 INVITE Max-Forwards: 70 Content-Length: 0
ClearIP should respond to the SIP Invite with a SIP 403 Forbidden until the SBC’s IP address has been defined in the ClearIP user interface. After the SBC’s IP address has been added to ClearIP, then ClearIP can respond to the SIP INVITE with a SIP 404, SIP 603, or SIP 302.
Appendix
CFS local routing policies
This documentation mentions Call Feature Server local routing policies in previous sections but does not show them explicitly in any of the above SBC configurations. Call Feature Server local routing policies play a very important role in the SBC outbound call scenario configuration. This section discusses the CFS local routing policies and how they influence the SBC configuration.
In outbound call scenarios, the Call Feature Server performs routing look up tasks. It sends SIP INVITE messages containing the routing information of the destinations to the SBC. Normally, there are three ways to do it:
- Send SIP INVITE messages to different SBC core network interfaces for different carriers/destinations.
- Send SIP INVITE messages to a single SBC core network interface. The SIP INVITE messages contain the routing information of the destinations, such as trunk group ID.
- Send SIP INVITE messages to the SBC working as an outbound proxy. The SIP INVITE messages directly contain the IP/FQDN of the destinations in the Request-URI.
The first routing approach is the simplest one. The routing logic on the SBC is clear and easy to implement. This documentation uses this approach. One thing that was not mentioned in previous sections is that for this approach, multiple core realms/sub-realms should be configured. Each core realm/sub-realm maps to one set of carriers/destinations. When the CFS sends a SIP INVITE to a certain SBC core realm, the SBC local policy forwards it to a certain set of destinations.
The second routing approach is also commonly used although it is a bit more complicated. The SBC must be configured to route the calls based on additional parameters such as the trunk group ID. The SBC has internal mechanisms to route calls based on the trunk group ID, which is not discussed in this documentation. If more general parameters are used for routing purpose, the SBC configuration will be more complicated.
The third approach is only supported by some call feature servers. It is also difficult for the SBC to insert ClearIP into its local policies. This documentation does not provide any details about this approach.
