3GPP Behaviors Related to Errors
When you use 3GPP mode, the SBC introduces specific error condition behaviors that apply to 3GPP STIR/SHAKEN operation only.
The SBC can respond to the same errors conditions during both authentication and verification procedures. The errors are divided in two categories:
- Service Error - The server provides a service error when the server is unable to process the request
- Policy Error - The server provides a policy error when the server is able to process the request, but not able to complete the service execution due to a policy restriction.
The following are the different types of Service errors that the SBC could receive:
| Exception text | HTTP status code | Description |
|---|---|---|
| Exception text | HTTP status code | Description |
| Error: Missing request body. | 400 | The request could not be processed due to missing request body. |
| Error: Missing mandatory parameter. | 400 | The request could not be processed due to missing parameters. |
| Error: Requested response body type is not supported. | 406 | The request could not be processed due to a not supported message body format. |
| Error: Requested resource not found. | 404 | The request could not be processed due to no resource available related to the Request-URI |
| Error: Unsupported request body type. | 415 | The request could not be processed due to not supported message body. |
| Error: Invalid parameter value. | 400 | The request could not be processed due to invalid parameter value. |
| Error: Failed to parse message body. | 400 | The request could not be processed due to failure to parse the message body. |
| Error: Missing mandatory Content-Length headers | 411 | The request could not be processed due to a missing Content-Length header. |
The following are the different types of Policy errors that the SBC could receive:
| Exception text | HTTP status code | Description |
| Method not allowed | 405 | The resource was invoked with unsupported operation |
| Internal server error. | 500 | The request failed due to internal error |
Important error behaviors include:
- If the SBC receives an error (4xx or 5xx) HTTP response from the STI-AS server for a SHAKEN or DIV request, the system continues processing the call without adding any SHAKEN or DIV passport.
- The SBC increments the
following counters associated with the response when it receives a Policy error:
- STI-AS Unsuccessful Responses
- STI-AS Policy Exception
- The SBC increments the
following counters associated with the response when it receives a Service error:
- STI-AS Unsuccessful Responses
- STI-AS Service Exception
- If it receives an INVITE that does not contain an identity header during verification procedures, the SBC includes a SIP REASON header with the code 436 and the text of “Bad Identity Info” in provisional and final responses it sends in the reverse direction.
- If it receives an error (4xx or 5xx) response from the STI-VS server for a SHAKEN or DIV verification request, the SBC adds the vertstat="No-TN-Validation" parameter to the appropriate PAI and FROM and continue processing the call.
- If it receives an error (4xx or 5xx) response from the STI-VS server for
a SHAKEN or DIV verification request, the SBC adds the SIP Reason header to the responses (1xx, 2xx, etc.) and
sends it in the reverse direction. It also places the cause information taken from
the HTTP status-code and text value from the HTTP reason-phrase (if present) in the
SIP header.
The SBC gets the cause value it puts in the SIP header from the HTTP status-code (e.g. 400). If the HTTP\REST response from the STI-VS has a reason-phrase, such as “Missing request body”, the SBC includes it. If the HTTP\REST response from the STI-VS does not have a reason-phrase, the SBC does not include a text value in the SIP Reason header.
The SBC sends the following Reason header in responses sent to the originator: Reason: SIP ;cause=400 ;text="Missing mandatory parameter"
When there is no reason phrase in the response, the SBC sends the Reason header without text. If there is reason header in the SIP response already, the SBC appends the new reason parameters into the header at the end after a semi-colon.
The example below shows a new reason added by the SBC after an existing 580/Precondition Failure reason.
-Reason: SIP ;cause=580 ;text="Precondition Failure"; cause=400 ;text="Missing mandatory parameter"