Delivery algorithm improvement

[restcomm]

Delivery algorithm improvement

[vetss]

Terms for updating:

1. SMPP submit_sm message has a field "priority_flag" with values:
   0 - non-priority
   1 - priority level 1
   2 - priority level 2
   3 - priority level 3
   For SS7 or SIP originated messages we can assign a general SMSC GW level priority_flag value.
   For each priority level we can configure a separate
   subscriberBusyDueDelay
   firstDueDelay
   secondDueDelay
   maxDueDelay
   dueDelayMultiplicator
   parameter values
   If there are several messages with different priority level then the highest is used for all messages.
   If some messages are pending for delivery after a failure and a new message has come we can establish a new configurable value (for each new message priority level) "new_message_reschedule" (in seconds).
   If the pending messages are scheduled in a less time then "new_message_reschedule" then the new message will be scheduled into the due_slot along with the pending messages
   If the pending messages are scheduled in a more time then "new_message_reschedule" then the new message and the pending messages will be (re)scheduled into a firstDueDelay due_slot

2. a possibility for "double delivery attempt" of message delivery (SS7 destination only) inside a delivery attempt. This possibility must be configurable for each priority level. If it is allowed then the messages will be tried to delivery 2 times per an attept in a configurable interval (like 1 min)
   For this funcionality we need add fields into Sms table:
   "priority_level" int
   "delivery_attempt int" - 0 or 1 depending on which attempt has beeb scheduled

[vetss]

zz ***** Version 2 *****
Terms for updating:

1. SMPP submit_sm message has a field "priority_flag" with values:
   0 - non-priority
   1 - priority level 1
   2 - priority level 2
   3 - priority level 3
   For SS7 or SIP originated messages we can assign a general SMSC GW level priority_flag value.
   Each of
   I suggest to make the count of priority level configurable (with making effect after SMSC GW is restarted)
   For each priority level we can configure a separate
   subscriberBusyDueDelay
   firstDueDelay
   secondDueDelay
   maxDueDelay
   dueDelayMultiplicator
   new_message_reschedule (new parameter)
   parameter values.
   We will config only for levels that are activated
   For each level we will establish a separate set of tables DST_SLOT_TABLE_YYYY_MM_DD and SLOT_MESSAGES_TABLE_YYYY_MM_DD.
   For low priority - the old names: DST_SLOT_TABLE_YYYY_MM_DD and SLOT_MESSAGES_TABLE_YYYY_MM_DD
   For more priority - the name for priority 1 is like : DST_SLOT_TABLE_YYYY_MM_DD_1 and SLOT_MESSAGES_TABLE_YYYY_MM_DD_1 etc
   Messages with priority level X will be processed independed of messages to the same destination except of one possible feature. If we have just successfully delivered messages to SS7 destination for dest address XX - then we try to load messages for address XX with other priorities.
   When SMSC GW is fetching messages from database for delivering:
   it has each separate processing due_slot for each priority
   firstly SMSC GW fetches messages for the highest priority due_slot
   if no more messages for the highest priority due_slot - then it looks for lower level.
   this leads that the highest priority due_slot may be always without delay but lower priotiry levels with delays if hight SMSC load

[vetss]

2. If some messages are pending for delivery for a priority level X after a failure and a new message for this priority level has come - then we can establish a new configurable value (for each new message priority level) "new_message_reschedule" (in seconds).
   If the pending messages are scheduled in a less time then "new_message_reschedule" then the new message will be scheduled into the due_slot along with the pending messages
   If the pending messages are scheduled in a more time then "new_message_reschedule" then the new message and the pending messages will be (re)scheduled into a firstDueDelay due_slot

[vetss]

3. a possibility for "double delivery attempt" of message delivery (SS7 destination only) inside a delivery attempt. This possibility must be configurable for each priority level. If it is allowed then the messages will be tried to delivery 2 times per an attept in a configurable interval (like 1 min)
   For this funcionality we need add a field into Sms table:
   "delivery_attempt int" - 0 or 1 depending on which attempt has beeb scheduled

[vetss]

we need to think of how to make some restrictions of pending messages for one destination in one due_slot. We can write already stored message count and then if it is too big - shift to some next due_slot for next messages.