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.
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:
|Services||Result||Reply (configurable)||Sansay action|
|outbound fraud analysis||no fraud found||SIP 404 Not Found||route call using local policy|
|outbound fraud analysis||fraud detected||SIP 603 Decline||do not route call, return decline to source|
|outbound routing and fraud analysis||no fraud found||SIP 302 Moved Temporarily||route call using Contact header|
|inbound robocall prevention||not a robocall||SIP 404 Not Found||route call using local policy|
|inbound robocall prevention with blocking||robocall detected||SIP 603 Decline||do not route call, return decline to source|
|inbound robocall prevention with diversion||robocall detected||SIP 302 Moved Temporarily||route call to CAPTCHA gateway for call screening|
|SHAKEN authentication||authenticated, attested and signed||SIP 302 Moved Temporarily with Identity header||copy Identity header, route call using local policy|
|SHAKEN verification||identity header and certificate are validated||SIP 302 Moved Temporarily with verstat||copy verstat, route call using local policy|
Select tabs to view call flows for various call handling scenarios:
If a TransNexus service determines that the call should be blocked, then it returns a SIP 603 Decline message to the SBC.
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:
- The call arrives at the Sansay.
- The Sansay routes the call to the TransNexus software for services.
- 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.
- 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.
- If the code is entered correctly, the CAPTCHA gateway sends a SIP REFER back to the Sansay.
- 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.
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.
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.
TransNexus software can provide SHAKEN authentication, verification, and certificate management services.
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.
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.
Please contact us for more information, assistance and guidance in connecting your Sansay to TransNexus software products.
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.
SIP Analytics® inspects each call before it begins. It’s the fastest, most precise method available to detect and prevent telecom fraud.Learn more