1. Configuration Guide
  2. Session Plug-In Language
  3. Enterprise SPLs
  4. SIP Trunking SPLs for Specific Service Providers
  5. NTT Message Converter

NTT Message Converter

When required by your service provider, set spl-options to +NttMsgConverter.

  • ocNttMsgConverterTagging=opposite—Configure on the sip-interface facing the Unified Call Manager (CUCM) realm.
  • dyn-contact-start—Configure on the sip-interface facing the CUCM realm.
  • dyn-contact-method=randomseed—Configure on the sip-interface facing the NTT trunk.

To support these trunks, you load all of these SPLs on the appropriate sip-interface elements. When configured, these SPLs trigger the following functions by the ESBC:

  • As a part of the surrogate registration process, sends a unique, random user-info portion in every REGISTER request to the NTT SIP trunk as well as within outgoing INVITE messages for calls.
  • Applies validity check to an incoming INVITE from the SIP trunk before sending out 100 TRYING and subsequent 1xx, 2xx messages. It is expected that the incoming INVITE Request-URI user portion contains the same randomized value that the ESBC sent in the most recent REGISTER message to the trunk.
  • In compliance with NTT requirements, sets the tag size of From and To headers in the SIP messages to be less than 32 bytes. This resolves issues with, for example, the tags sent by Avaya in originating SIP messages, which are approximately 51 bytes.
  • In compliance with NTT requirements, sets the Rseq, Cseq, Session ID (in SDP) values less than 999900, and sets the SDP o line username character length to a maximum of 10 bytes. This resolves issues with, for example, messages from an Enterprise PBX with a large RSeq value in 18x messages. This also resolves issues with the SDP o line generated by some Enterprise PBXs, which have a username that is 19 bytes.
  • Checks the RURI user portion of incoming CANCEL request for the AoR and compares it with the AoR specified in the Request-URI of the initial INVITE received. If the value is different, the ESBC responds with a 481 Call/Transaction Does Not Exist.

Note:

These features make use of the SurrogateContact SPL. When using this SPL, triggered by the configurations described below, the system supports only one surrogate agent within the entire configuration.