As a rule, EXPIRED is a delivery report that is returned by a vendor. In case no delivery report is received from the vendor, the message remains in SENT status. However, there are several cases when the EXPIRED status can be assigned by the System.
- The Block expired messages System setting:
EXPIRED status can be generated by the System according to the client validity period (which is retrieved from submit_sm signal) only if the option Block expired messages is enabled in SMS channels or applied on the system level. The option serves to block messages received with an expired validity period. Possible values are: Default, Yes, No. The Default value means 'use the value from the respective System parameter'. The parameter set in the SMS channels interface has priority over the System parameter. If the setting is set as No, the system doesn't check the validity period value. If a message with an expired validity period is received, it is rejected with the VALIDITY PERIOD IS EXPIRED internal status.
Otherwise, the system does not check client validity period for applying delivery reports from vendors. Delivery won't be applied only if the value in the setting Delivery waiting period is exceeded. The system setting Delivery waiting period, sec defines the period during which delivery reports are expected from the vendor; after that, the reports will be ignored. Note that the parameter does not invoke generation of EXPIRED delivery status once the period is expired. The default value is 172800 seconds (2 days). The maximum value can be defined based on the server parameters (available disk space).
- Rerouting based on SENT status:
If rerouting based on the internal SENT status is configured, the EXPIRED status can be assigned by the System if no delivery report was obtained from the vendor within an interval set up internally. If the route is the last (or the only one) on the list, the delivery report timeout is defined, as before, by the System parameter Delivery waiting period, sec. So, if no delivery report is received after the interval, an EDR with the EXPIRED status will be generated, which allows ignoring subsequent delivery reports from the vendor.
To configure the feature contact the Alaris technical support team and communicate the code BZ29102, provide a list of client channels for which the feature must be enabled (it can be enabled for all client channels) and the interval after which rerouting will be performed (in seconds; each channel can have its own value).
Vendor channel IDs can also be set in the internal configuration together with the interval (in seconds) after which the message will be sent to the next in line route if no delivery report is received from the vendor. To configure the feature, contact the Alaris technical support and communicate the code BZ63554.
- EXPIRED for concatenated messages:
The system parameter Concatenated messages: Delivery waiting period for stateful processing, sec. defines time (in seconds) to wait for delivery reports for segments of the same message. The default value is 86400 seconds. If no DLRs were received, the SMS remains in the SENT status. By default, a delivery report for each part is processed and sent to a client separately. To change the System logic, contact the Alaris technical support team and communicate code BZ33220. The logic will be as follows:
- if DLRs were received for some segments and not received for others, the EXPIRED status is sent to the client for the entire message (after 24 hours from the receipt of the source message)
- if different reports were received for different segments (for example, DELIVRD for some and UNDELIV for other), the UNDELIV status is returned to the client
- if the DELIVRD reports were received for all the segments, the DELIVRD status is returned to the client.
In case no delivery report was received for a concatenated message within the period specified in Concatenated messages: Delivery waiting period for stateful processing, sec. the system generates EXPIRED status, sends it to the client and writes down to EDR. However, the EXPIRED status cannot be generated if the system receives submit_sm signals with identical parameters (including UDH ID) within a short period of time (if the period from Concatenated messages: Delivery waiting period for stateful processing, sec. is not passed yet), the internal information about the previous messages is overwritten by the new one. This breaks correct traffic processing, as it is needed to use unique UDH identifiers for traffic sent within the delivery waiting period.
The SMS switch checks if the EXPIRED status must be generated every minute, that is, on the 60th second, the 120th second, the 180th second etc. Therefore, if a vendor sends a delivery report within the interval, the vendor's report - and not the EXPIRED status - will be sent to the client. For example, if the parameter is set to 70, delivery reports (with the DELIVRD status) are received on the 75th second, and the DELIVRD status will be sent to the client since the check-up will be carried out only on the 120th second.
System settings -> Delivery waiting period & Concatenated messages: Delivery waiting period for stateful processing:
If you have any questions left - do not hesitate to contact the Alaris technical support team and provide examples of EDRs, which should be checked.
AKBSMS - Alaris Knowledge Base
Related Questions:
EXPIRED status
rerouting based on SENT status
Delivery waiting period
Block expired messages
VALIDITY PERIOD IS EXPIRED
Link to this Article: https://helpdesk.alarislabs.com/en/knowledge_base/article/252/category/131/