Start a conversation Sign in
Start a conversation
  1. NewNet
  2. NewNet Articles
  3. Articles

Lithium/RTR Segmented MT SMS (TP‑MMS=0): New SRI‑SM / New TCAP BEGIN While a Prior Dialogue Is Still Active

Contents

Overview

In Lithium/RTR segmented (concatenated) MT SMS delivery using TP‑MMS=0, you may observe a subsequent segment/attempt triggering a new SRI‑SM and a new TCAP BEGIN while the previous TCAP dialogue toward the MSC is still active (i.e., no TC‑END / TC‑U‑ABORT has occurred yet).

This typically happens when the next segment/attempt arrives after the internal SRI‑SM routing-result cache validity window (commonly ~3 seconds in the reported setup) has expired. This behavior is consistent with current Lithium/RTR design and documentation and is not treated as a defect.

Key Information

  • How it appears in traces (symptom): first segment triggers SRI‑SM and starts a TCAP dialogue; a later segment/attempt triggers a new SRI‑SM and a new TCAP BEGIN even though the earlier dialogue is still open (no TC‑END/TC‑U‑ABORT observed at that moment).
  • Typical trigger condition: the next segment/attempt occurs after the internal SRI‑SM routing-result cache validity window expires (often configured around ~3 seconds in affected deployments), and/or the MT‑ForwardSM ACK timing crosses that caching window.
  • Documented design behavior: the RTR Operator Manual describes that:
    • Within the cache window: cached SRI‑SM results can be reused and segments can remain on the same dialogue when timing conditions allow.
    • After the cache window: the stored SRI‑SM result is cleared and a new SRI‑SM is performed, which commonly results in a new TCAP BEGIN, even if the earlier MAP/TCAP transaction is still open.
  • Cache expiry is independent of TCAP dialogue lifetime: the SRI‑SM cache timer does not control TCAP dialogue termination. Dialogue closure is driven by TCAP-layer events (peer End/Abort, stack timeout, peer disconnect), not by the cache-expiry timer.
  • No forced closure on cache expiry: Lithium/RTR does not send TC‑END or TC‑U‑ABORT solely because an internal SRI‑SM cache entry expires, and there is no configuration option to force-close the prior dialogue on cache timeout.
  • Protocol perspective: TCAP permits multiple simultaneous dialogues between the same peers; therefore, “overlapping dialogues” can occur and are not automatically TCAP non-compliance.
  • Defect vs limitation: no known defect record was identified for “overlapping TCAP dialogues after SRI‑SM cache expiry” as a bug; this is best categorized as current design / limitation and expected behavior in this timing scenario.
  • TP‑MMS semantics (clarification):
    • TP‑MMS = 0 → “more messages are waiting in the Service Center”
    • TP‑MMS = 1 → “no more messages are waiting in the Service Center”

  • TP‑MMS indicates message-waiting status; it does not guarantee that all segments remain under a single TCAP dialogue regardless of timing/caching behavior.

  • Common context: this is often observed when segmented MT delivery is driven via an external store/forward component (for example, AMS) with MMS enabled, and segment timing crosses the cache window.

Customer Impact

No corrective action is required if the goal is to confirm whether the observed “new SRI‑SM / new TCAP BEGIN while prior dialogue is still active” is normal for Lithium/RTR in this cache-expiry timing scenario.

If your MSC/network requirement is “explicitly close the old dialogue before starting a new one when the cache times out”, Lithium/RTR does not provide a configuration option to do this; achieving that behavior would require a product enhancement / feature request through your normal account/product engagement process.

Validation Steps (to confirm the behavior in your traces)

  1. Capture MAP/TCAP traces for the affected delivery, including both SRI‑SM and MT‑ForwardSM operations for the same destination (redact MSISDN/IMSI as needed).
  2. Measure timing vs the cache window:
    • Measure time between the initial SRI‑SM result being cached (or first segment delivery start) and the subsequent segment/attempt.
    • Confirm whether the subsequent segment occurs before vs after the configured cache validity (commonly ~3 seconds).
  3. Compare dialogue behavior:
    • Within cache window: verify whether subsequent segments reuse the routing result and may remain on the same dialogue (depending on call flow).
    • After cache window: verify a new SRI‑SM occurs and a new TCAP BEGIN is started, potentially overlapping with the still-open prior dialogue.
  4. Confirm no forced closure on cache expiry: verify that no TC‑END/TC‑U‑ABORT is emitted solely at the cache-expiry moment; termination happens later via normal TCAP completion/timeout behavior.

Frequently Asked Questions

1. How do I know if I’m hitting this exact issue/behavior?
You’ll see a subsequent MT segment/attempt trigger a new SRI‑SM and a new TCAP BEGIN while an earlier TCAP dialogue toward the MSC is still open (i.e., no TC‑END/TC‑U‑ABORT yet). This typically correlates with the next segment occurring after the internal SRI‑SM cache validity window (often ~3 seconds in affected setups).
2. Is this a defect or TCAP non-compliance?
In the described timing scenario, it is consistent with current Lithium/RTR design and documentation (not treated as a defect). TCAP permits multiple simultaneous dialogues, and the product’s SRI‑SM caching timer is not designed to control TCAP dialogue termination.
3. Can I configure Lithium/RTR to send TC‑END or TC‑U‑ABORT when the SRI‑SM cache expires?
No. Lithium/RTR does not send TC‑END/TC‑U‑ABORT solely due to SRI‑SM cache expiry, and there is no documented configuration option to force-close the prior dialogue on cache timeout.
4. What verification should I provide if I want a definitive confirmation on my specific trace interpretation?
Provide decoded MAP/TCAP trace excerpts showing (1) the first segment’s SRI‑SM/MT‑ForwardSM and the open dialogue, (2) timing relative to the cache window, and (3) the subsequent segment’s new SRI‑SM/new TCAP BEGIN while the earlier dialogue is still active. Redact subscriber identifiers and replace them with placeholders.
5. Does TP‑MMS=0 guarantee that all segments stay in one TCAP dialogue?
No. TP‑MMS indicates message-waiting status (0 = more messages waiting; 1 = no more messages waiting). It does not guarantee a single TCAP dialogue will be used for all segments regardless of timing/caching behavior.
Choose files or drag and drop files
ai_initiated
atlas_studio
kb_automation
Was this article helpful?
Yes
No

  1. Mohammed Amer

  2. Posted

Comments