Creating a Reason Header During Verification

You can configure the SBC to create and insert SIP reason headers into applicable SIP INVITEs based on information received from an STI-VS during verification attempts. These headers provide insight into the reason the STI-VS could not or did not verify the request. You can use this feature to provide visibility into the reasoncode, reasontext and the verstat parameters downstream within the SIP INVITE and in CDRs. This feature applies to both ATIS and 3GPP modes.

For each verification scenario, if a server response indicates a failure or no validation with reasoncode and/or reasontext in the JSON body, the SBC looks up the associated sti-server for the presence of the string reason-json-sip-translation enabled in the options parameter. If enabled, the SBC creates a Reason header using the values received in the JSON claims, reasoncode and reasontext and adds the reason header to the egress INVITE before forwarding it to the next hop. The syntax follows RFC 3326.

This setting is also available as a parameter in the sti-config. If the sti-server parameter is not set, the SBC refers to the global parameter setting. The sti-server setting takes precedence.

If the INVITE already includes a reason header, the SBC appends the header with the parameters it retrieves from the STI-VS to the original reason parameters, as shown in the example below:

Reason: SIP ;cause=438 ;text="Invalid Identity Header" ;cause=403 ;text="Stale Date"

If the STI-VS is unavailable due to timeout or because it is unreachable, the SBC does not provide static mapping between reason related json claims (reasoncode and reasontext) and the reason header. Although it does not add a new Reason header, it does, per existing behavior, add a verstat with No-TN-Validation to the From/PAI header(s).

To enable this functionality on a per-server basis, you set the reason-json-sip-translation value as an parameter within a sti-server element, as shown below. You should consider the sti-server as having three settings, including enabled, disabled and empty. The default is empty.

ORACLE(sti-server)#options +reason-json-sip-translation=enabled

To enable this functionality on a global basis, you use the reason-json-sip-translation parameter within the sti-config, as shown below. The default is disabled.

ORACLE(sti-config)#reason-json-sip-translation enabled

The SBC only refers to the global parameter in the sti-config if the sti-server parameter is empty. This allows you to, for example, enable the sti-config parameter, and enable the feature across the SBC by leaving sti-server parameters empty. You could then explicitly disable the feature on a per-server basis by setting the server parameter to disabled.

ORACLE(sti-server)#options +reason-json-sip-translation=disabled

Additional feature behavior to consider includes:

If you have enabled this feature, but the JSON body of the response from STI-VS does not contain reasoncode and reasontext claims, the SBC does not add a reason header to the egress INVITE.
The ATIS specification defines JSON claims, reasontext and reasoncode as optional. If there is only a reasoncode or reasontext in the response from STI-VS and you have configured this feature, the system adds the reason object presented and does not address the missing object.
For example, if there is no reasoncode but there is reasontext, the translation may be:
```
Reason: SIP ;text="Stale Date"
```
If there is a failure or timeout at the STI-VS, the SBC performs no action on the claims and adds the No-TN-Validation verstat, per standard behavior.
The 3GPP specification does not include JSON claims reasoncode and reasontext. Therefore, the SBC creates the Reason header from the Reason Phrase and HTTP return code.
For example, consider the sample HTTP Response Received below.
```
HTTP/1.0 400 Missing request body
Date: Tue, 28 Apr 2020 02:14:29 GMT
Content-Type: application/json
```
The SBC adds the below to the egress INVITE.
```
Reason: SIP ;cause=400 ;text="Missing request body"
```
Furthermore, if there is no reason phrase in the response, the SBC adds the following Reason header without text to the egress INVITE.
```
Reason: SIP ;cause=400
```
For 3GPP deployments, the SBC appends new data to an existing SIP Reason header at the end of the existing line after a semi-colon.
For example, consider the sample SIP header below as present.
```
Reason: SIP ;cause=580 ;text="Precondition Failure"
```
The SBC appends that header with the new cause and text as shown below.
```
Reason: SIP ;cause=580 ;text="Precondition Failure"; cause=400 ;text="Missing request body"
```
Note:
The SBC also does this when adding a Reason header to responses, including 2xx and 5xx.