Overview

In RTR-generated CDRs, the submitTime / submitDate fields, or the equivalent Message_Submit_Time field, can sometimes appear later than terminTime / Message_Deliver_Time or later than the CDR file creation time.

This behavior is not always a clock or NTP problem. In many cases, it is the result of RTR's Service Center Time Stamp (SCTS) uniqueness handling.

Information

Why this happens

RTR can create unique Service Center Time Stamps for a recipient. If more than one message for the same recipient is processed within the same second, RTR can move the next timestamp one second into the future so the timestamps remain unique. If additional messages for the same recipient arrive before current time catches up, the timestamp can continue moving further into the future.

Because of that behavior, submitTime / submitDate can legitimately become later than:

• orglSubmitTime / orglSubmitDate
• terminTime / terminDate
• the CDR file time and date

Which timestamp should be used as the original submission time

The billing documentation describes submitTime / submitDate as potentially adjusted values. They should not be used to determine the original arrival/submission time of the message.

Where your CDR format includes them, use orglSubmitTime and orglSubmitDate instead.

What amsmediatedservicecentretimestampsenabled does

The amsmediatedservicecentretimestampsenabled parameter controls whether SCTS generation is coordinated through AMS across RTRs that share the same AMS.

• If it is set to false, SCTS generation is handled locally on each RTR.
• If it is set to true, RTR sends SCTS queries to AMS and the AMS mediates uniqueness across RTRs sharing that AMS.

This changes the scope of coordination. It does not remove the one-second uniqueness behavior itself. Timestamps can still be adjusted to remain unique.

Can this be prevented by enabling AMS-mediated SCTS?

No. Enabling amsmediatedservicecentretimestampsenabled is not a method to suppress or prevent SCTS adjustments. It changes where uniqueness is coordinated, not the requirement that timestamps remain unique.

What happens after a restart

A restart can temporarily clear the in-memory state used for accumulated future timestamps. However, if the same traffic pattern continues, the behavior can recur.

For that reason, a restart should be treated as a temporary reset only, not as a permanent fix for this behavior.

How to verify the active runtime values

Use tp_walkall and review the active runtime values rather than relying only on text in configuration files.

tp_walkall | egrep 'sysDescr\.0|smsPropAmsMediatedServiceCentreTimestampsEnabled\.0|smsPropMtMtUseUniqueScts\.0'

This is useful for confirming:

• the active runtime version from sysDescr.0
• whether AMS-mediated SCTS is enabled from smsPropAmsMediatedServiceCentreTimestampsEnabled.0
• the active value of smsPropMtMtUseUniqueScts.0

When to investigate something else instead

This article addresses future-looking or incremented submit timestamps.

If the abnormal timestamps are seen only around daylight saving time or NTP irregularities, first rule out server time synchronization issues by reviewing:

• Billing records with invalid SUBMITDATE during DST to Summer Time changes
• Are the Servers Prepared for the Start of Daylight Saving Time?

If the submit fields are 00/00/00 or 00:00:00 rather than future-looking values, that is a different symptom and should be investigated separately.

If you need Support to review a case

When opening a ticket, include:

• a sample decoded CDR showing the affected records
• the output of the runtime check above
• confirmation of whether the issue is limited to a specific recipient / short number / route
• confirmation of whether you need guidance for future records only, or for interpretation of already generated CDRs

If you need correction of already generated CDR files, please open a support ticket for review. This article does not describe a supported rewrite procedure for existing CDR files.