SMS command_status for long MT messages

Discussion:

Jeff Thorn

2018-05-30 18:50:21 UTC

Hi group,
Looking for a little help on this.... The DLR command status flag (%A)
appears blank when the original MT message was a long message ( > 160
chars).

Is there a solution to this issue? Here is an example from our logs.....

2018-04-11 19:00:38 [30573] [6] ERROR: SMPP[xxxx]: SMSC returned error code
0x0000000b (Invalid Destination Address) in response to submit_sm PDU.
2018-04-11 19:00:38 [30573] [6] DEBUG: Set split msg status to 3
2018-04-11 19:00:38 [30573] [6] DEBUG: Parts of concatenated message failed.
2018-04-11 19:00:38 [30573] [6] DEBUG: SMSC[xxxx]: creating DLR message
2018-04-11 19:00:38 [30573] [6] DEBUG: SMSC[xxxx]: DLR =
https://myurl/api/dlr?status=%d&code=%A&id=123456&dt=%t

Normally for rejected messages the value of the %A parameter is something
like:

NACK/0x0000000b/Invalid Destination Address

However, when the original MT message is a long message that gets split,
the %A parameter in the DLR url looks like this:

NACK/

Any feedback is appreciated. Thanks!

Jeff Thorn
CEO / Principal Software Architect
Thorn Technologies, LLC
www.thorntech.com
@thorntech <http://twitter.com/thorntech> | LinkedIn
<http://www.linkedin.com/in/jeffthorn> | Facebook
<http://www.facebook.com/thorntechnologies>

a***@kannel.org

2018-06-02 12:09:06 UTC

Permalink

Hi,

this is expected behaviour because we have to put all statuses into one DLR message.
Just imagine if you have 3 parts and each of this part will be rejected with different error code,
would you expect all 3 error codes in the status?

Thanks,
Alex

Post by Jeff Thorn
Hi group,
Looking for a little help on this.... The DLR command status flag (%A) appears blank when the original MT message was a long message ( > 160 chars).
Is there a solution to this issue? Here is an example from our logs.....
2018-04-11 19:00:38 [30573] [6] ERROR: SMPP[xxxx]: SMSC returned error code 0x0000000b (Invalid Destination Address) in response to submit_sm PDU.
2018-04-11 19:00:38 [30573] [6] DEBUG: Set split msg status to 3
2018-04-11 19:00:38 [30573] [6] DEBUG: Parts of concatenated message failed.
2018-04-11 19:00:38 [30573] [6] DEBUG: SMSC[xxxx]: creating DLR message
2018-04-11 19:00:38 [30573] [6] DEBUG: SMSC[xxxx]: DLR = https://myurl/api/dlr?status=%d& <https://myurl/api/dlr?status=%d&>code=%A&id=123456&dt=%t
NACK/0x0000000b/Invalid Destination Address
NACK/
Any feedback is appreciated. Thanks!
Jeff Thorn
CEO / Principal Software Architect
Thorn Technologies, LLC
www.thorntech.com <https://www.thorntech.com/>
@thorntech <http://twitter.com/thorntech> | LinkedIn <http://www.linkedin.com/in/jeffthorn> | Facebook <http://www.facebook.com/thorntechnologies>

Jeff Thorn

2018-06-02 13:26:58 UTC

Permalink

Hi Alex,
Thanks for explaining, makes sense.

The most common status we get is invalid destination address (0x0000000b).
In this case all 3 parts in your example would have the same status. Would
it make sense to include the status of it was the same for all parts?

Jeff Thorn
CEO
Thorn Technologies, LLC
https://www.thorntech.com

Post by a***@kannel.org
Hi,
this is expected behaviour because we have to put all statuses into one DLR message.
Just imagine if you have 3 parts and each of this part will be rejected
with different error code,
would you expect all 3 error codes in the status?
Thanks,
Alex
Hi group,
Looking for a little help on this.... The DLR command status flag (%A)
appears blank when the original MT message was a long message ( > 160
chars).
Is there a solution to this issue? Here is an example from our logs.....
2018-04-11 19:00:38 [30573] [6] ERROR: SMPP[xxxx]: SMSC returned error
code 0x0000000b (Invalid Destination Address) in response to submit_sm PDU.
2018-04-11 19:00:38 [30573] [6] DEBUG: Set split msg status to 3
2018-04-11 19:00:38 [30573] [6] DEBUG: Parts of concatenated message failed.
2018-04-11 19:00:38 [30573] [6] DEBUG: SMSC[xxxx]: creating DLR message
2018-04-11 19:00:38 [30573] [6] DEBUG: SMSC[xxxx]: DLR =
https://myurl/api/dlr?status=%d&code=%A&id=123456&dt=%t
NACK/0x0000000b/Invalid Destination Address
However, when the original MT message is a long message that gets split,
NACK/
Any feedback is appreciated. Thanks!
Jeff Thorn
CEO / Principal Software Architect
Thorn Technologies, LLC
www.thorntech.com
@thorntech <http://twitter.com/thorntech> | LinkedIn
<http://www.linkedin.com/in/jeffthorn> | Facebook
<http://www.facebook.com/thorntechnologies>

a***@kannel.org

2018-06-04 09:02:11 UTC

Permalink

Hi Jeff,

it makes maybe sense for your case but not for all cases, therefore I donât see a sense to invest time into it.

Thanks,
Alex

Post by Jeff Thorn
Hi Alex,
Thanks for explaining, makes sense.
The most common status we get is invalid destination address (0x0000000b). In this case all 3 parts in your example would have the same status. Would it make sense to include the status of it was the same for all parts?
Jeff Thorn
CEO
Thorn Technologies, LLC
https://www.thorntech.com <https://www.thorntech.com/>
Hi,
this is expected behaviour because we have to put all statuses into one DLR message.
Just imagine if you have 3 parts and each of this part will be rejected with different error code,
would you expect all 3 error codes in the status?
Thanks,
Alex