Fixing STP SMS Failures Caused by Oversized SCCP UDT Payloads (NewNet RTR/TextPass)

Symptoms and Indicators

Typical signs in traces/PCAPs when this issue is present:

• SCCP message type is UDT (0x09).
• SCCP user data exceeds the UDT maximum (examples observed include ~259 bytes and ~287 bytes).
• Standards reference (ITU‑T Q.713): “The maximum length of the data parameter in a UDT message is 255 octets.”
• Downstream STP rejection may appear as “cause 7 unqualified”.

Example observation: A provided PCAP showed an MO Forward SM flow where the SMS Router (RTR) forwarded an SCCP UDT whose SCCP user data was ~259 bytes (above the 255‑octet limit), and the STP rejected it.

Note: Payloads above 255 bytes should be sent using XUDT (0x0a) and/or appropriate segmentation. If they are sent as UDT, many STPs will reject them.

Why This Happens

RTR/TextPass can segment transactions at the TCAP level using:

• sccpmaxpdulengthfortcapsegmentation

If this value is set greater than 255 (for example, 268):

• An SCCP user data payload such as 259 bytes can remain below the TCAP segmentation threshold, so no segmentation occurs.
• At the same time, 259 bytes is above the SCCP UDT maximum (255), resulting in an oversized UDT.
• The downstream STP may reject the message due to the UDT size constraint (for example returning cause 7 unqualified).

No product defect fix is required for this scenario; the mitigation is a configuration change on the RTR/TextPass side to ensure segmentation occurs at or before 255 bytes.

Solution (Configuration Mitigation)

Set TCAP segmentation to trigger at 255 bytes so SCCP UDT payloads remain within the UDT constraint.

Step 1 — Update configuration on the MGR node

1. Log in to the MGR node as the textpass user.
2. Go to the configuration directory:

cd /usr/TextPass/etc

1. Back up the current config:

cp common_config.txt common_config.<yyyymmdd>

1. Edit the file:

vi common_config.txt

1. Add (or update) the following parameter between the <tpconfig> and </tpconfig> tags:

sccpmaxpdulengthfortcapsegmentation="255"

1. Save and exit (for vi: :wq).

Note: If your environment uses per-domain common config files, apply the same change to the relevant domain’s common_config.txt.

Step 2 — Apply on each traffic node (restart required)

On each traffic node/instance (as textpass):

1. Record the current value:

tp_walkall | grep -i sccpmaxpdulengthfortcapsegmentation

1. Stop TextPass:

tp_stop --textpass

1. Start TextPass:

tp_start --textpass

1. Confirm services are healthy:

tp_status

1. Verify the new value is active:

tp_walkall | grep -i sccpmaxpdulengthfortcapsegmentation

Expected result: the command output reports 255.

Operational note: Restarting TextPass causes a brief service interruption. Perform this during a maintenance window or low-traffic period.

Validation (Confirm the Fix)

1. Re-run the previously failing MO SMS flow.
2. Capture a fresh trace/PCAP on the RTR-to-STP leg.
3. Confirm one (or more) of the following outcomes:
   • The RTR segments earlier so SCCP UDT user data does not exceed 255 bytes, and/or
   • The downstream STP no longer rejects messages with “cause 7 unqualified” related to oversized UDT payloads.
4. If the STP still reports SCCP size violations, verify:
   • The config change was applied to the correct domain(s).
   • All traffic nodes were restarted and are using the updated value.
   • The oversized UDT is not originating upstream from a different peer sending malformed SCCP (UDT with >255 bytes) into the network; that peer must conform to Q.713 and/or use XUDT/segmentation appropriately.