Configuration for CAPTCHA Authentication – 302 Redirect with Transnexus' ClearIP service

Introduction

This document provides instructions to configure ProSBC to operate with the TransNexus/ClearIP server for Verification with CNAM and Robocall Analytics. TransNexus/ClearIP is a SIP redirect server that provides advanced Least Cost Routing (LCR), fraud control and STIR (Secure Telephony Identity Revisited) / SHAKEN (Secure Handling of Asserted information using toKENs) features.

ProSBC 3.0.90 or a later version is needed to support Verification with CNAM and Robocall Analytics with TransNexus.

• For simple Robocall Mitigation, please check the instruction here.

Typical Call Scenarios

This section provides the simplified network diagram with typical call flows.

Captcha Call Flow

1. Source of ServiceProvider sends a call to ProSBC.

2. ProSBC forwards the call to ClearIP for Verification with CNAM and Robocall Analytics

3. ClearIP performs Verification, CNAM lookup, Robocall Analytics, then sends one of the following responses to ProSBC

• 3a. SIP 404 Not Found: No fraud is detected, not a robocall.

• 3b. SIP 503 Service unavailable: No fraud is detected, not a robocall.

• 4c. SIP 603 Decline: Fraud is detected, block the call.

• 4d. SIP 302 with CNAM ( [V] prefix) in PAI header (P-Asserted-Identity )

4. Upon receiving 404 or 503

    4a: - ProSBC returns SIP 503 (or mapping to the TDM cause code) to the Source switch to perform route advance  
    Call Source (TDM or SIP) --------Invite or SETUP or IAM ---------> ProSBC/TMG ----Invite--> ClearIP
    Call Source (TDM or SIP) <---SIP 503 or REL with 41 or 34 -------- ProSBC/TMG < ----503---- ClearIP

    4b: - ProSBC route advances on SIP 503 and sends call to next destination, does not return response to the Source switch  
    Call Source (TDM or SIP) ---Invite or SETUP or IAM ---> ProSBC/TMG ----Invite--> ClearIP
                                                            ProSBC/TMG < ----503---- ClearIP
                                                            ProSBC/TMG  ----Invite---Next Routes

Upon receiving 603

  4c: ProSBC returns SIP 603 (or mapping to the TDM cause code) to the Source switch, then release the call 
   Call Source (TDM or SIP) -----Invite or SETUP or IAM ------> ProSBC/TMG ----Invite--> ClearIP
   Call Source (TDM or SIP) <---SIP 603 or REL with 21 -------- ProSBC/TMG < ----603---- ClearIP

Upon receiving 302

  4d: 302 with the captcha.clearip.com in the contact header

ProSBC will send the call the CAPTCHA NAP- captcha.clearip.com Captcha will request the caller to enter the code:

       -- Code entered correctly within the timer; Captcha returns 503. ProSBC will do advance route
       -- Code entered incorrectly 3 times or timeout, Captcha returns 603, call will be dropped

ProSBC Configuration

This section provides the ProSBC configuration procedures for the solution. They are grouped into 4 main sections.

• Initial Common Procedures: The procedures in this section are common to any scenario. You must follow them.

• Scenario 1, One ClearIP NAP: Follow this section to learn how to configure ProSBC with one ClearIP NAP without a need to differentiate between Inbound and Outbound calls.

• Scenario 2, More than one ClearIP NAP: Follow this section to learn how to configure ProSBC in which you have more than one ClearIP NAP and you need to differentiate between Inbound and Outbound calls.

• Final Common Procedures: The procedures in this section are common to all scenarios.

Initial Common Procedures

Configure Routing Script

ProSBC is configured to use routing scripts to send some SIP headers to ClearIP to identify the source of the call.

1. Enable routing script

Gateway->Use script: choose the right main script

2. Load routing scripts

3KB

ClearIP_Query.zip

archive

Open

• Import the filter script:

Gateway->Routes->Routing Script->Import Script File
   File->ClearIP_Query.rb
   ScriptType->filter
   Load on startup->checked

• Include the filter script in the main script, default is simple_routing_sbc.rb.

Note: Only one "main" script should show the set of the Scripts:

Gateway->Routes->Routing Script->Edit the main script:

- Add the "require 'ClearIP_Query' unless defined?(ClearIPQuery)" statement at the top of the main script.
- Add the "include ClearIPQuery" statement in the main routing class.
- Add the filter "  before_filter :method => :ClearIP_query" in the main routing class.

• Note: if label routing or other before_filter script are used, please place ClearIP_query last

2KB

Main_ClearIP.zip

archive

Open

Add service_type in NAPs Column

NAPs Columns->Create New NAPs Column
    Name->service_type
    Type attributes -> NORMAL|AUTHENTICATION|VERIFICATION
    Default ->NORMAL

• Set the value to "AUTHENTICATION" for CLEARIP NAPs

Scenario 1:One ClearIP NAP

Follow the procedures in this scenario of you will only have one ClearIP NAP and do not need to differentiate between inbound and outbound calls.

Create Transport Server for ClearIP NAP

 SIP -> Create New Transport Server
    Name->SIP_TS_CLEARIP
    Port Type->TCP
    Port->5060
    IP Interface-> Select the IP interface which can reach to ClearIP on the public network

Create ClearIP NAP

NAPs->Create New NAP
    Name->NAP_CLEARIP
    SIP Transport Servers->SIP_TS_CLEARIP
    Proxy address->sip.clearip.com (Or appropriate Domain provided by ClearIP)
    Port range->[Select port range of IP interface above)

Set service_type to "AUTHENTICATION" for NAP_CLEARIP

NAP Columns -> select NAP_CLEARIP
service_type: AUTHENTICATION

Add Route to NAP_CLEARIP

Routes -> Create New Route
Name: To_ClearIP
NAP: (Any)  (or you can choose specific NAPs - you may need to create multiple routes in this case)
Remapped NAP: NAP_CLEARIP
Priority: 10

Scenario 2: More than one ClearIP NAP

Follow the procedures in this scenario if you have more than one ClearIP NAP and must differentiate between inbound and outbound calls.

Create 2 TCP transport servers: one for inbound and one for outbound

 SIP -> Create New Transport Server
    Name->SIP_TS_CLEARIP_IN
    Port Type->TCP
    Port->5060
    IP Interface-> Select the IP interface which can reach to ClearIP on the public network
 
 SIP -> Create New Transport Server
    Name->SIP_TS_CLEARIP_OUT
    Port Type->TCP
    Port->5060
    IP Interface-> Select the IP interface which can reach to ClearIP on the public network

Create Inbound ClearIP NAP and Outbound ClearIP NAP

NAPs->Create New NAP
    Name->NAP_CLEARIP_IN
    SIP Transport Servers->SIP_TS_CLEARIP_IN
    Proxy address->sip.clearip.com (Or appropriate Domain provided by ClearIP)
    Port range->[Select port range of IP interface above)
NAPs->Create New NAP
    Name->NAP_CLEARIP_OUT
    SIP Transport Servers->SIP_TS_CLEARIP_OUT
    Proxy address->sip.clearip.com (Or appropriate Domain provided by ClearIP)
    Port range->[Select port range of IP interface above)

Set service_type to "AUTHENTICATION" for NAP_CLEARIP_IN and NAP_CLEARIP_OUT

NAP Columns -> select NAP_CLEARIP_IN
service_type: AUTHENTICATION
NAP Columns -> select NAP_CLEARIP_OUT
service_type: AUTHENTICATION

Add Routes to NAP_CLEARIP_IN and NAP_CLEARIP_OUT

Routes -> Create New Route
Name: To_ClearIP_IN
NAP: specific NAPs which carry the inbound traffic
Remapped NAP: NAP_CLEARIP_IN
Priority: 10 
Routes -> Create New Route
Name: To_ClearIP_OUT
NAP: specific NAPs which carry the outbound traffic
Remapped NAP: NAP_CLEARIP_OUT
Priority: 10

Final Common Procedures

Follow these procedures to wrap up the ProSBC configuration work. They apply to both previously described scenarios.

Configure other Routes

You need to configure other routes after the ClearIP routes if you want ProSBC to perform route advances upon receiving 503 or 302.

 Check the below link for the detail instruction to create static routes:
 

 It could also combine with other Routeset routing:
 

Configure Route Retry Action for the related Reason Cause Code

Route retry action of 3xx, 404 and 603 must be configured to allow ProSBC to perform failover, fraud control and SHAKEN AS/VS request.

Profiles->Edit Reason Cause Mapping
    404 Not found->Route retry action->Continue call
    503 Service unavailable->Route retry action->Continue call
    603 Decline->Route retry action->Stop call
    302 Moved Temporarily-> Route retry action: Process call routing

Note:

• The default route retry action of 404 is Stop call.

• The default route retry action of 603 is Continue call.