search

opentelecoms-org / jsmpp

SMPP implemented in Java
Apache License 2.0
232 stars 164 forks source link

How to send and receive data_sm_resp with command_status != 0 and with message_id/optional parameters #163

Closed sana167 closed 10 months ago

sana167 commented 3 years ago

According to SMPP specification, a data_sm_resp can have message_id and optional parameters when command_status != 0. But in the JSMPP API, there is no way to generate or parse a data_sm_resp's message_id and optional parameters when command_status != 0.

For SMSC, the GenericMessageReceiverListener.onAcceptDataSm() method allows us to

  1. return a DataSmResult when command_status == 0
  2. throw a ProcessRequestException when command_status != 0

If we want to return a data_sm_resp with command_status != 0, ProcessRequestException does not allow us to pass the message_id or optional parameters back to the session so that it can be sent as part of data_sm_resp.

For ESME, DefaultDecomposer.dataSmResp() parses the message_id and optional parameters only when command_status is 0.

pmoerenhout commented 3 years ago

May I ask what the use-case is when the SMSC accepted the message, and has generated the message_id, but still want to report an error (command_status != 0) ? I could change the classes to the command_status can be set, but requires some rework.

sana167 commented 3 years ago

In our case, we have an external SMSC that returns a data_sm_resp with command_status set to ESME_RTHROTTLED and having a message_id in its body. Our product is a proxy which needs to receive this data_sm_resp, extract the message_id and forward it to to originating external ESME. External ESME <---> Proxy (our product) <---> External SMSC Apart from message_id, optional parameters like delivery_failure_reason and network_error_code could be returned in the failed data_sm_resp which need to be handled too.

pmoerenhout commented 3 years ago

Understood. When reading the spec, the ESME_RTHROTTLED is used when the threshold levels are EXCEEDED. If the message is accepted, it is a little ambiguous behaviour of the SMSC.

A change would be to use the command_status in the handling of the message and in the responses, giving more control. I will add this to the upcoming 3.0.0 release.

sana167 commented 3 years ago

OK, Thanks. On Tuesday, November 9, 2021, 06:03:17 PM GMT+5:30, Pim Moerenhout @.***> wrote:

Understood. When reading the spec, the ESME_RTHROTTLED is used when the threshold levels are EXCEEDED. If the message is accepted, it is a little ambiguous behaviour of the SMSC.

A change would be to use the command_status in the handling of the message and in the responses, giving more control. I will add this to the upcoming 3.0.0 release.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.