Additional Notes

The following are additional notes that describe the digest authentication process:

• The Oracle Communications Session Border Controller always challenges the first LOGIN request, and initial authentication begins with that request. The recalculated authorization key — the credentials — are then included in every subsequent request.
• If the Oracle Communications Session Border Controller does not receive any communication from the client within the expiration period, the Oracle Communications Session Border Controller logs the client out and tears down the transport connection. Faced with interface loss, the Oracle Communications Session Border Controller default behavior is to flush all warrant information from the target database. This response necessitates that the client first login/re-register with the Oracle Communications Session Border Controller, and then repopulate the empty database using a series of ADD requests. This behavior ensures that client and Oracle Communications Session Border Controller target databases are synchronized. 

Alternatively, when faced with interface loss, the Oracle Communications Session Border Controller can retain all warrant information within the target database. This response necessitates only that the client first login/re-register with the Oracle Communications Session Border Controller. After successful registration the client should, but is not required to, use a series of GET, ADD, and DELETE requests to ensure that the Oracle Communications Session Border Controller and client target databases are synchronized.
• The Oracle Communications Session Border Controller ignores the Authentication-Info header that comes in the 200OK response after digest authentication is complete. The Oracle Communications Session Border Controller receives a 401/407 response from the client. However, some surrogate-agents may process the Authentication-Info header in a single challenge.