Validating the Request-URIs in INVITEs and re-INVITEs

This validation compares the contact header in the 200 OK of the sender's REGISTRATION with the RURI of the INVITE message from NTT. You configure the following spl-options to generate an effective random contact value in the ESBC.

  • access-realm: dyn-contact-start
  • core-realm: dyn-contact-method=randomseed

If you do not configure the ntt-request-valid option, the ESBC drops a call without any response when the effective random contact generated in the 200 OK’s contact header does not match the RURI of the INVITE message from NTT. When you configure this option and the validation fails, however, the ESBC sends a 404 response to NTT without a reason header.

If the values match, the ESBC continues to process the call.

Note:

Based on standard ESBC operation, when the top via and the sender do not match, the ESBC adds a "received= <source ip>" to the via header internally. In a scenario where the L3 source IP is NTT and the top via is not NTT IP, the via header check still passes because the “received=” field contains and NTT IP.