Creating Detailed Call Rejection Information

You can configure the SBC can provide more specific reasons for rejecting a call towards the caller. You configure these reason-code and reason-text entries within your sti-response-treatment-config configurations. This feature applies to the messages sent by the SBC to the caller after it has completed its STI verification process.

By default, the SBC sends generalized reason detail to applicable stations for rejecting a call based on an STI-VS response. These responses are normalized verstats, presenting a standardized string for both ATIS and 3GPP deployments within the applicable SIP messages. As a result, the verstat information provided by the SBC may not be as specific as desired about the reason a call failed.

For example, without this feature the SBC tags the following call failure scenarios with the same verstat, No-TN-Validation:

STI-VS no request
STI-VS no answer
Answer with no verstat

The SBC, however, allows you to configure your sti-response-treatment-config to provide more specific reason information for specific call fail scenarios, including:

No-TN-Validation-Timeout—STI-VS does not answer
No-TN-Validation-StiInvalid—STI-VS answer is meaningless (JSON missing or malformed)
No-TN-Validation-IdentityMissing—SIP Identity is missing (no request sent to STI-VS)
No-TN-Validation-TNMissing—TN is missing (no request sent to STI-VS)
No-TN-Validation-StiConstraints—STI constraints are exceeded (no request sent to STI-VS)
No-TN-Validation-Unreachable—STI-VS circuit-breaker is open (no request sent to STI-VS)
No-TN-Validation-ClientError—SBC internal failure (no request sent to STI-VS)
No-TN-Validation-Bypass—The STIR requests that are bypassed

No-TN-Validation-Timeout—STI-VS does not answer

When you configure a sti-response-treatment-entry with a verstat of No-TN-Validation-Timeout and a reason-code that is “empty" or "0”, the SBC rejects applicable calls when there is a response timeout on the STI-VS server.

When these requests to STI-VS servers time out, the SBC uses the verstat key “No-TN-Validation-Timeout” to find matches for rejecting these calls.

This first configuration example demonstrates the SBC providing a less accurate response.

ORACLE(sti-response-treatment-entry)show
verstat No-TN-Validation-Timeout 
reason-code
role STI-VS
sip-reason-code
sip-reason-text

In this case, the SBC rejects the call with:

A “403 Forbidden” Response
STI-VS-REASON "" (Field left empty)
Reason Headers:
- ATIS SIP Reason header—SIP;cause=403;text=Forbidden
- 3GPP SIP Reason header—Empty - No reason header included
The verstat No-TN-Validation in the FROM header

This second configuration example demonstrates the SBC providing a more accurate response.

ORACLE(sti-response-treatment-entry)show
verstat No-TN-Validation-Timeout 
reason-code
role STI-VS
sip-reason-code 404
sip-reason-text NoValidationTimeout

In this case, the SBC rejects the call with:

“404 NoValidationTimeout” Response
STI-VS-REASON empty
Reason Headers:
- ATIS SIP Reason header—SIP;cause=403;text=Forbidden
- 3GPP SIP Reason header—Empty - No reason header included
The verstat No-TN-Validation in the FROM header

No-TN-Validation-StiInvalid/No-TN-Validation-MalformedStiResponse—STI-VS answer is meaningless (JSON missing or malformed)

When you configure a sti-response-treatment-entry with a verstat of No-TN-Validation-StiInvalid and a reason-code that is “empty" or "0”, the SBC rejects applicable calls when there is a malformed response or missing JSON body from STI-VS server. The system matches the Verstat key “No-TN-Validation-StiInvalid” for this call rejection.

This first configuration example demonstrates the SBC providing a less accurate response.

ORACLE(sti-response-treatment-entry)show
sti-response-treatment-entry
verstat No-TN-Validation-MalformedStiResponse
reason-code
role STI-VS
sip-reason-code
sip-reason-text

In this case, the SBC rejects the call with:

A “403 Forbidden” Response
STI-VS-REASON, composed of the HTTP status code plus status text
Reason Headers:
- ATIS SIP Reason header—SIP;cause=403;text=Forbidden
- 3GPP SIP Reason header—SIP;cause=HTTP status code;text=HTTP status phrase
The verstat No-TN-Validation in the FROM header

This second configuration example demonstrates the SBC providing a more accurate response.

(sti-response-treatment-entry)show
sti-response-treatment-entry
verstat No-TN-Validation- MalformedStiResponse
reason-code
role STI-VS
sip-reason-code 404
sip-reason-text NoValidationStiInvalid

In this case, the SBC rejects the call with:

A “404 NoValidationStiInvalid” Response
STI-VS-REASON includes http reason code + reason text
Reason Headers:
- ATIS SIP Reason header—SIP;cause=403;text=Forbidden
- 3GPP SIP Reason header—SIP;cause=403;text="4xx/5xx"
The verstat No-TN-Validation in the FROM header

Oracle considers a verification response as an invalid STI response based on the following:

200 OK case
- From an ATIS perspective, meaningless answer:
  - no JSON body
  - JSON body but no verificationResponse
  - JSON body and verificationResponse but no verstat
- From a 3GPP perspective, meaningless answer:
  - no JSON body
  - JSON body but no verificationResponse
  - if SHAKEN verification: JSON body and verificationResponse but no verstatValue
  - if DIV verification:
  - JSON body and verificationResponse but no divResult
  - JSON body and verificationResponse and divResult but no verstatValue
4xx/5xx case—Within 4xx/5xx responses from the STI-VS, there is no "invalid sti response" possible. The SBC, therefore, populates the SIP Reason Header as follows:
- cause:
  - reasonCode if included in JSON body
  - HTTP response status-code if reasonCode is not available in JSON body
- text:
  - reasonText if included in JSON body
  - OR error included in JSON body if reasonText is not available in JSON body
  - OR HTTP reason phrase if reasonText nor error is available in JSON body

No-TN-Validation-IdentityMissing—SIP Identity is missing (no request sent to STI-VS)

Consider this scenario to be the same as the second configuration examples above, differing in your sip-reason-text and verstat configurations, which the SBC uses to find matches for rejecting these calls.

verstat No-TN-Validation-IdentityMissing
sip-reason-text NoValidationIdentityMissing

Here, the system provides a “404 NoValidationIdentityMissing” Response, and a adds "No-TN-Validation" in the FROM.

No-TN-Validation-TNMissing—TN is missing (no request sent to STI-VS)

Consider this scenario to be the same as the second configuration examples above, but differing in your sip-reason-text and verstat configurations, which the SBC uses to find matches for rejecting these calls.

verstat No-TN-Validation-TNMissing
sip-reason-text NoValidationTNMissing

Here, the system provides a “404 NoValidationTNMissing” Response, and a adds "No-TN-Validation" in the FROM.

No-TN-Validation-StiConstraints—STI constraints are exceeded (no request sent to STI-VS)

verstat No-TN-Validation-StiConstraints
sip-reason-text NoValidationStiConstraints

Here, the system provides a “404 NoValidationStiConstraints” Response, and adds "No-TN-Validation" in the FROM.

No-TN-Validation-Unreachable—STI-VS circuit-breaker is open (no request sent to STI-VS)

verstat No-TN-Validation-Unreachable
sip-reason-text NoValidationStiUnreachable

Here, the system provides a “404 NoValidationStiConstraints” Response, and adds "No-TN-Validation" in the FROM.

No-TN-Validation-ClientError—SBC internal failure (no request sent to STI-VS)

verstat No-TN-Validation-ClientError
sip-reason-text NoValidationClientError

Here, the system provides a “404 NoValidationStiConstraints” Response, and adds "No-TN-Validation" in the FROM.

No-TN-Validation-Bypass—The STIR requests that are bypassed

If the entry has a verstat of “No-TN-Validation-Bypass”, and a reason-code that is “empty" or "0”, the system rejects the call when the STIR request is bypassed.

verstat No-TN-Validation-Bypass
sip-reason-text Null

The Verstat match key for call rejection is “No-TN-Validation-Bypass”.

In this case, the SBC rejects the call with:

A “403 Forbidden” Response
STI-VS-REASON empty
Reason Headers:
- ATIS SIP Reason header—SIP;cause=403;text=Forbidden
- 3GPP SIP Reason header—empty
The verstat No-TN-Validation in the FROM header

Reason-code Missing from the Response Body

For cases in which the system receives STI-VS responses in which the reason-code is not present in the verificationResponse of the JSON body, you can configure a sti-response-treatment-entry that causes the system to populate the reason-code from the HTTP body based on operation mode and response:

For ATIS—When receiving 4xx or 5xx responses from the STI-VS, use the reason-code from the HTTP response code, which the system gets from the response's status line.
For 3GPP—When receiving any response from the STI-VS, use the reason-code from the HTTP response code, which the system gets from the response's status line.

Consider the following sti-response-treatment-entry:

(sti-response-treatment-entry)show
sti-response-treatment-entry
verstat No-TN-Validation-None
reason-code 400
role STI-VS
sip-reason-code
sip-reason-text

This behavior would take effect when the system receives an HTTP response, as shown below, that triggers the sti-response-treatment-entry above.

HTTP/1.1 400 Bad Request
X-RequestID: AA97B177-9383-4934-8543-0F91A7A02836
Content-Type: application/json
Content-Length: … 
{             
“requestError”: {             
“serviceException”: 
           {“messageId”: “SVC4001”
              “text”: “Error: Missing mandatory parameter ‘%1’”,
           “variables”: [“iat”]
}            
}
}

In this case the SBC rejects the call with a “400 Bad Request” response. In addition, the STI-VS-REASON is "SIP ;cause=400 ;text="Bad Request".