Reliable SMS delivery depends on more than routing a message from one network to another. When subscribers are unreachable, network connections fail or routes become unavailable, the SMSC must determine how to retry delivery, handle charging and process messages containing multiple segments.

PAiCore SMSC CT v3.3.0+cte introduces new capabilities that give telecom operators greater control over these decisions. The latest release focuses on three key areas: configurable SMS retry profiles, Diameter ECUR online charging, and flexible multipart message retry.

Built for the operational demands of modern messaging networks, PAiCore SMSC combines an open-source approach with standards-based telecom interoperability and configurable message processing. Version 3.3 builds on this foundation with more granular control over message delivery, charging transactions and failure handling.

With 14 improvements and 2 bug fixes, SMSC CT v3.3 also enhances SS7 delivery reporting, CDR analysis, deployment flexibility and platform stability.

What’s New in PAiCore SMSC CT v3.3?

The three major enhancements address different stages of the SMS delivery lifecycle:

• Configurable Retry Profiles: Define how failed messages are retried, delayed, rerouted or processed through recovery policies.
• Diameter ECUR Online Charging: Reserve charging units before delivery and complete or release the charging transaction based on the outcome.
• Multipart Retry Control: Choose whether to resend every segment of a multipart SMS or only the segments still pending delivery.

Additional improvements provide more control over SS7 delivery-status reporting, better CDR filtering, Redis deployment options and more reliable message processing after SMPP reconnections.

1. Configurable SMS Retry Profiles: More Control Over Message Delivery

SMS delivery failures do not always require the same response. A temporary subscriber issue, a network interruption and an unavailable destination route can call for different retry strategies.

PAiCore SMSC CT v3.3 introduces Configurable Retry Profiles, enabling operators to define reusable policies for handling different delivery failures.

A Retry Profile can include:

• Multiple retry steps: Configure the number of attempts and delay for each step.
• Maximum Due Delay: Limit the time a message remains in the retry cycle.
• Recovery profile chaining: Hand over to another retry profile when the current profile is exhausted.
• Alternate destination routing: Reroute messages to another destination network.
• Retry-time message modifications: Change source or destination addresses, add or remove prefixes, or adjust message priority.

Profiles can be mapped to gateways using criteria such as origin network, destination network, protocol and error code. Additional conditions can use message fields or custom parameters to refine the matching rules.

This allows operators to tailor retry behaviour to the circumstances of a delivery failure instead of applying a single retry policy to every message.

Improved Retry Traceability and Error Handling

Configurable retry policies are more useful when operators can identify which policy was applied to an individual message.

SMSC CT v3.3 records the Retry Profile ID in the Call Detail Record (CDR), helping operations teams investigate retry decisions and trace message processing.

The release also introduces gateway-specific error-code classification lists for SS7 and Diameter gateways:

• Auto Retry: Identify errors that should trigger another delivery attempt.
• No Retry: Identify errors that should not trigger another attempt.
• Retry Alternate Destination: Identify errors that should trigger routing to another destination.

Together, these features provide more granular retry control, clearer troubleshooting information and greater visibility into message delivery behaviour.

2. Diameter ECUR Online Charging: Align Charging with Delivery Outcomes

Online charging is an important part of monetising messaging services. Operators need to manage charging transactions consistently, including when delivery is retried or ultimately fails.

PAiCore SMSC CT v3.3 adds support for Diameter ECUR (Event Charging with Unit Reservation) alongside the existing IEC (Immediate Event Charging) model.

ECUR introduces a reservation-based charging workflow. Rather than immediately completing the charging transaction, the system can reserve charging units before delivery and then complete or release the reservation according to the applicable transaction outcome.

The process uses two key Diameter Credit-Control messages:

• CCR-Initial: Initiates the charging transaction and requests a reservation of units.
• CCR-Termination: Terminates the transaction and completes or releases the reservation as applicable.

Charging Support for Retries and Multipart Messages

The ECUR implementation also supports multipart messages and retry attempts, including reservation handling across retries.

If delivery ultimately fails, the charging reservation is automatically terminated according to the implemented charging flow.

This helps operators align charging transactions with message-processing outcomes and manage reserved units more consistently across delivery attempts.

For operators integrating SMS delivery with an online charging system (OCS), ECUR adds another option for controlling how charging is handled throughout the messaging lifecycle.

3. Multipart SMS Retry: Resend All Segments or Only Pending Segments

Long SMS messages are commonly divided into multiple segments before transmission. If delivery fails for only some segments, the SMSC needs to determine whether to resend the entire multipart message or retry only the segments that remain undelivered.

SMSC CT v3.3 introduces a Retry All Parts option at the routing-rule level, allowing operators to select the required retry behaviour.

Retry all parts

Resend the complete multipart message when a retry is triggered.

Retry pending parts only

Resend only the segments that have not been delivered.

This distinction gives operators more flexibility when handling concatenated SMS traffic. Depending on the selected policy and delivery scenario, retrying pending segments can avoid unnecessary retransmissions, while retrying all parts remains available when the configured delivery strategy requires it.

For networks processing long messages, this provides more control over segment-level retry behaviour and message delivery handling.

Additional SMSC CT v3.3 Improvements

Beyond retry management and online charging, the release includes enhancements to SS7 handling, CDR reporting, deployment configuration and platform stability.

4. Configurable SS7 Delivery Reporting

SMSC CT v3.3 adds configurable Report-SM-Delivery-Status (RSDS) behaviour for individual SS7 gateways.

Operators can enable or disable this behaviour according to the requirements of each gateway and its associated network.

When enabled, delivery-related conditions such as Absent Subscriber, MNRF, MCEF and Memory Capacity Exceeded can continue to trigger notification to the HLR. When disabled, the relevant messages follow the standard retry flow.

This gateway-level configuration helps operators adapt delivery-status handling to different network environments and interconnect requirements.

5. Improved CDR Filtering and Delivery-Status Reporting

Call Detail Records provide essential information for investigating delivery failures, analysing traffic and supporting operational reporting.

SMSC CT v3.3 introduces delivery-status-based CDR filtering, enabling operators to filter reports using the delivery status returned by the provider.

The release also improves detailed report visibility by displaying the DLR status, reads network names directly from the CDR, and adds an index to the relevant database column to support faster filtering.

These changes make it easier to investigate message outcomes and work with delivery records across high-volume messaging environments.

6. Flexible Redis Deployment Options

The release adds support for Redis standalone mode alongside Redis Cluster mode.

Standalone deployments can be useful for laboratories, testing environments and smaller installations where a Redis cluster is not required.

This additional option gives deployment teams greater flexibility when selecting infrastructure that matches their environment and operational requirements.

7. HTTP Service Provider Configuration Without a DLR Callback URL

SMSC CT v3.3 also allows HTTP Service Providers to be configured without a Delivery Receipt (DLR) callback URL.

When no callback URL is configured, the DLR health check is not started and pending DLRs are drained automatically.

This supports HTTP Service Provider configurations that do not require a callback endpoint, simplifying deployment for applicable integration scenarios.

8. Home Routing for MT ForwardSM

The release fixes an issue affecting Home Routing for MT ForwardSM.

MAP v1/v2 ForwardSM messages are now correctly classified as mobile-originated (MO) or mobile-terminated (MT), with Home Routing applied to MT traffic when the feature is enabled.

This improves message classification and helps ensure that the configured Home Routing behaviour is applied to the intended traffic.

9. Improved SMPP Client Reconnection

SMPP sessions can be disrupted by connection failures, remote endpoint restarts or other network events. Re-establishing the session is only part of recovery; dependent message-processing components must also resume correctly.

SMSC CT v3.3 fixes an issue in which Kafka consumers were not properly recreated when an SMPP session rebound.

The improvement helps prevent message processing from stalling after a connection disruption and supports more reliable recovery following SMPP reconnection.

Why SMSC CT v3.3 Matters for Telecom Operators

The latest release focuses on giving operators more control over the complete SMS delivery lifecycle.

More flexible delivery recovery: Configurable Retry Profiles allow delivery policies to be adapted to network conditions, error codes and routing requirements.

More controlled online charging: Diameter ECUR adds a reservation-based charging option that supports retries and multipart messages.

More precise multipart handling: Operators can configure whether all segments or only pending segments should be retried.

Better operational visibility: Retry Profile IDs, delivery-status filtering and improved reporting help teams investigate message outcomes.

More deployment flexibility: Redis standalone support and optional DLR callback configuration accommodate additional deployment scenarios.

Together, these improvements strengthen the operational capabilities of PAiCore SMSC CT for messaging environments where delivery reliability, charging control and network interoperability are important.

An Open-Source, Standards-Based SMSC for Evolving Messaging Networks

Modern messaging infrastructure must accommodate different network protocols, changing traffic patterns and diverse operator requirements. Configurable delivery handling and transparent operational behaviour are important parts of that challenge.

PAiCore’s open-source SMSC approach gives operators and integration teams a foundation they can explore and adapt, with protocol interworking and configurable message processing at the centre of the platform.

SMSC CT v3.3 extends these capabilities through more granular retry management, Diameter ECUR online charging, multipart retry control and improvements to reporting and platform stability.

With 14 improvements and 2 bug fixes, the release continues the development of PAiCore SMSC for the operational needs of telecom operators, MVNOs, SMS aggregators and messaging service providers.

Explore PAiCore SMSC CT v3.3

Want to explore the latest capabilities or review the implementation details?

• Explore the product
• PAiCore SMSC on GitHub
• Review the release details

Interested in open-source telecom infrastructure, standards-based messaging and flexible SMS delivery management? Explore PAiCore SMSC and discover how configurable routing, retry policies and charging integration can support your messaging environment.

 

page.