Sansay VSXi integration framework

TransNexus software products integrate well with Sansay products. For example, our software products use the trgp parameter in the Contact header, which contains the source trunk group ID used by the Sansay. This enables more granular control over call handling.

Integration basics

TransNexus software uses standard SIP messaging to integrate with Sansay solutions. Either ClearIP or NexOSS is set up as a resource and is set as the first route in the routing table.

When a SIP INVITE, either inbound or outbound, arrives at the Sansay, it sends the invite to the TransNexus software.

The TransNexus software performs the services configured for the call and replies to the Sansay according to the result of the services. Here are a few illustrative examples of typical SIP message communications:

ServicesResultReply (configurable)Sansay action
outbound fraud analysisno fraud foundSIP 404 Not Foundroute call using local policy
outbound fraud analysisfraud detectedSIP 603 Declinedo not route call, return decline to source
outbound routing and fraud analysisno fraud foundSIP 302 Moved Temporarilyroute call using Contact header
inbound robocall preventionnot a robocallSIP 404 Not Foundroute call using local policy
inbound robocall prevention with blockingrobocall detectedSIP 603 Declinedo not route call, return decline to source
inbound robocall prevention with diversionrobocall detectedSIP 302 Moved Temporarilyroute call to CAPTCHA gateway for call screening
SHAKEN authenticationauthenticated, attested and signedSIP 302 Moved Temporarily with Identity headercopy Identity header, route call using local policy
SHAKEN verificationidentity header and certificate are validatedSIP 302 Moved Temporarily with verstatcopy verstat, route call using local policy

Call handling

Select tabs to view call flows for various call handling scenarios:

Block the call

SIP ladder – block the call

If a TransNexus service determines that the call should be blocked, then it returns a SIP 603 Decline message to the SBC.

Diversion call flow

Divert the call to CAPTCHA

If you have scenarios where a call might be bad but you’d prefer a less severe alternative to call blocking, you can set up the software to divert the call instead. The default diversion is to the TransNexus CAPTCHA gateway. Here are the steps:

  1. The call arrives at the Sansay.
  2. The Sansay routes the call to the TransNexus software for services.
  3. If the TransNexus software determines the call should be diverted, it replies to the Sansay with a SIP 302 Moved Temporarily. The Sansay routes the call to the CAPTCHA gateway.
  4. The CAPTCHA gateway answers the call and prompts the caller to enter a random two-digit code. If the code is not entered correctly, the CAPTCHA gateway ends the call with a BYE.
  5. If the code is entered correctly, the CAPTCHA gateway sends a SIP REFER back to the Sansay.
  6. The Sansay receives the SIP REFER from the CAPTCHA gateway and sends an INVITE to the called party to complete the call. It also sends an INVITE to the calling party to enable audio codec renegotiation with the called party.

Alternative diversion destinations can be set up. For example, some customers have set up diversion to voicemail.

Route the call using local policy

SIP ladder – send the call with local routing

If there is no fraud detected and TransNexus software is not set up to perform routing services, then the software will return a SIP 404 Not Found to have the Sansay route the call using local policy.

Route the call using Contact header

SIP ladder – send the call with using routes from TransNexus

TransNexus software can provide a list of routes for the Sansay to use. The list of routes can either be set up as static routes or generated in the TransNexus software using jurisdictional least cost routing.

If there is no fraud detected and TransNexus software is set up to do routing, then the software will return a SIP 302 Moved Temporarily with a list of routes in preference order for the Sansay to use.

Similar call flow for both authentication and verification

SHAKEN call flow

TransNexus software can provide SHAKEN authentication, verification, and certificate management services.

Authentication

If SHAKEN authentication is requested, then the TransNexus Authentication Service (AS) will use policy controls to determine the attestation level to use, create a SIP Identity header and insert it into a SIP 302 response to the Sansay. The Sansay will copy the Identity header from the response into the outbound INVITE using a header manipulation rule.

If AS policies determine that the call should be blocked, then the AS will return a SIP 603 Decline.

Verification

If a call has a SHAKEN SIP Header and verification is requested, then the TransNexus Verification Service (VS) will use information in the SIP Header to fetch certificate information from Certificate Repositories for the Certificate Authority and the originating service provider that signed the call. The VS will validate the certificates and use the public key to verify that the call information has not be tampered with or replayed.

For call termination, the VS will generate a SIP 302 with verstat information in the P-Asserted-Identity field. The Sansay will copy the verstat information into the terminating INVITE using a header manipulation rule. Depending on the handset, this verstat information may be used to display information to the user about the verification results.

If VS policies determine that the call should be blocked or diverted, then the VS will return either a SIP 603 Decline or SIP 302 Moved Temporarily respectively.

Contact us

Please contact us for more information, assistance and guidance in connecting your Sansay to TransNexus software products.

Request info about our products and services

* required

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.