1. Configuration Guide
  2. Session Plug-In Language
  3. Enterprise SPLs
  4. Request Validation SPL

Request Validation SPL

You can configure the ESBC to validate a specific set of requests and respond to these requests with the behaviors presented here when you enable the ntt-request-valid SPL option. This validation works using Surrogate Register SPL options within SurrogateRegister.spl and in conjunction with other NTT Message Converter SPL options. This processing compares values within the request, and only processes the call if they match. If they do not match, the ESBC replies with responses specific to each scenario.

To implement this feature, you use your preferred configuration method to enable the following mandatory options in the applicable realm, which are available from the SurrogateRegister.spl:

  • access realm—dyn-contact-start
  • core realm—dyn-contact-method=randomseed, ntt-request-valid

You enable the ntt-request-valid option in the core realm-config to validate requests and, if that validation fails, reject requests within the following scenarios:

  • An INVITE or re-INVITE received from NTT has a different user part in the Request-URI user info than the ESBC received in the contact header of the 200 OK in the most recent REGISTER from NTT. If this check fails, the ESBC sends a 404 response to the sender.
  • Any of the following requests received from NTT have a different user part in the Request- URI user info than the ESBC received in the 200 OK of the most recent REGISTER from NTT:
    • PRACK
    • CANCEL
    • ACK
    • BYE

    If this check fails, the ESBC drops the call without any response.

  • The top Via header in an INVITE or re-INVITE received from NTT does not use the IP to which surrogate registration was sent. If this check fails, the ESBC responds with 403 response.

Additional detail on each of these request scenarios is provided below.

INVITE and Re-INVITE Check Priority

In addition to the checks implemented as a part of this feature, the ESBC performs an IP check on the layer 3 source IP address. When configured, the ESBC performs these checks on INVITEs and Re-INVITEs in a specific order, and takes action based on whether or not the IPs match.

  1. Top Via header check—If this check fails, the ESBC drops the call without any response.
  2. L3 source IP check—If the layer 3 source address is not the IP to which surrogate registration was sent, the ESBC sends a 403 response to the sender.
  3. Request-URI check—If this check fails, the ESBC sends a 404 response to the sender.

If all checks succeed, the ESBC proceeds with the call.

Configuration

You enable this feature by setting the following three spl-options:

  • access realm: dyn-contact-start
  • core-realm: dyn-contact-method=randomseed, ntt-request-valid
ORACLE(realm-config)#spl-options +ntt-request-valid
ORACLE(realm-config)#spl-options +dyn-contact-start
ORACLE(realm-config)#spl-options +dyn-contact-method=randomseed