In TS 24.229 (clause 7.2A.2.3) there are several new values defined for "integrity-protected" parameter:

auth-param = "integrity-protected" EQUAL ("yes" / "no" / "tls-pending" / "tls-yes" / "ip-assoc-pending" / "ip-assoc-yes")

The values in the "integrity-protected" field are defined as follows:
"yes": indicates that a REGISTER request received in the P-CSCF is protected using an IPsec security association and IMS AKA is used as authentication scheme.
"no": indicates that a REGISTER request received in the P-CSCF is not protected using an IPsec security association and IMS AKA is used as authentication scheme, i.e. this is an initial REGISTER request with the Authorization header not containing a challenge response.
"tls-yes": indicates that a REGISTER request is received in the P-CSCF protected over a TLS connection and the Session ID, IP address and port for the TLS connection are already bound to a private user identity. The S-CSCF will decide whether or not to challenge such a REGISTER request based on its policy. This is used in case of SIP digest with TLS.
"tls-pending": indicates that a REGISTER request is received in the P-CSCF protected over a TLS connection and the Session ID, IP address and port for the TLS connection are not yet bound to a private user identity. The S-CSCF shall challenge such a REGISTER request if it does not contain an Authorization header with a challenge response or if the verification of the challenge response fails. This is used in case of SIP digest with TLS.
"ip-assoc-yes": indicates that a REGISTER request received in the P-CSCF does map to an existing IP association in case SIP digest is used without TLS.
"ip-assoc-pending": indicates that a REGISTER request received in the P-CSCF does not map to an existing IP association, and does contain a challenge response in case SIP digest is used without TLS.

NOTE 1: In case of SIP digest is used with TLS, but the REGISTER request was not received over TLS, the P-CSCF does not include an "integrity-protected" field in the auth-param to indicate that an initial REGISTER request was received not over an existing TLS session. The S-CSCF will always challenge such a REGISTER request.
NOTE 2: In case of SIP digest is used without TLS, but the REGISTER request was not received over TLS, the P-CSCF does not include an "integrity-protected" field in the auth-param to indicate that the REGISTER request does not map to an existing IP association, and does not contain a challenge response. The S-CSCF will always challenge such a REGISTER request.
NOTE 3: The value "yes" is also used when an initial REGISTER request contains an Authorization header with a challenge response as in this case the IPsec association is already in use, and its use by the UE implicitly authenticates the UE. This is a difference to TLS case where the use of TLS alone does not yet implicitly authenticates the UE. Hence in the TLS case, for an initial REGISTER request containing an Authorization header with a challenge response the value "tls-pending" and not "tls-yes" is used.