Binary DCS for MO messages not appearing to work

Binary DCS for MO messages not appearing to work SearchSearch
Author Message
Chris
Frequent Contributor
Username: Chrisc

Post Number: 69
Registered: 12-2008
Posted on Wednesday, October 29, 2014 - 02:17 pm:   

Hi Guys,

We seem to be having a slight issue with one of our providers in that any long MO message that arrives on our system is not being decoded properly with the given DCS. The data coding the provider is giving us upon receipt of an MO message is 2, and after a bit of a search I found that we can set the DCS ourselves by using the BinaryDCS=## setting in the SMSGW.ini file underneath the SMPP section for the given provider.

However, even after applying this config item, no change appears to have been made. Could you possibly point us (me) in the right direction?

Here's the configuration we have for the provider:

[SMPP - host.example.com:2775]
RouteName=SomeRandomRouteName
SMPPVersion=v3.4
UserName=SomeUsername
Password=SomePassword
SenderAddressOverride=Yes
Receive=Yes
ReceiveMMS=No
UseSSL=No
LongSMSAlt=Yes
TransmitterCount=0
BinaryDCS=2

Here's a sample packet of a long MO message (taken from Wireshark)
(Segment 1 of 2)
0000 00 15 5d 00 74 07 54 75 d0 a3 7f ed 08 00 45 00 ..].t.Tu ......E.
0010 00 ff 0d 69 00 00 f3 06 30 07 d4 3d a0 e6 0a 00 ...i.... 0..=....
0020 0a 65 0a d7 0a 48 13 15 ce 3f ed f1 9d 6e 50 18 .e...H.. .?...nP.
0030 16 74 5f c2 00 00 00 00 00 d7 00 00 00 05 00 00 .t_..... ........
0040 00 00 00 00 00 11 00 01 01 34 34 37 38 36 30 30 ........ .4478600
0050 30 33 31 30 32 00 02 01 33 31 36 34 32 35 30 30 03102... 31642500
0060 31 34 30 00 40 00 00 00 00 00 00 02 00 9f 05 00 140.@... ........
0070 03 cf 02 01 53 61 6d 70 6c 65 20 74 65 73 74 20 ....Samp le test
0080 6d 65 73 73 61 67 65 2e 20 50 6c 65 61 73 65 20 message. Please
0090 69 67 6e 6f 72 65 20 74 68 65 20 6d 65 73 73 61 ignore t he messa
00a0 67 65 2e 20 31 32 33 34 35 36 37 38 39 20 31 32 ge. 1234 56789 12
00b0 33 34 35 36 37 38 39 20 31 32 33 34 35 36 37 38 3456789 12345678
00c0 39 20 31 32 33 34 35 36 37 38 39 20 31 32 33 34 9 123456 789 1234
00d0 35 36 37 38 39 20 31 32 33 34 35 36 37 38 39 20 56789 12 3456789
00e0 31 32 33 34 35 36 37 38 39 20 31 32 33 34 35 36 12345678 9 123456
00f0 37 38 39 20 31 32 33 34 35 36 37 38 39 20 31 32 789 1234 56789 12
0100 33 34 35 36 37 38 39 20 31 32 33 34 35 3456789 12345

(Segment 2 of 2)
0000 00 15 5d 00 74 07 54 75 d0 a3 7f ed 08 00 45 00 ..].t.Tu ......E.
0010 00 6e 0e ba 00 00 f3 06 2f 47 d4 3d a0 e6 0a 00 .n...... /G.=....
0020 0a 65 0a d7 0a 48 13 15 cf 26 ed f1 9d 8f 50 18 .e...H.. .&....P.
0030 16 95 f0 e4 00 00 00 00 00 46 00 00 00 05 00 00 ........ .F......
0040 00 00 00 00 00 12 00 01 01 34 34 37 38 36 30 30 ........ .4478600
0050 30 33 31 30 32 00 02 01 33 31 36 34 32 35 30 30 03102... 31642500
0060 31 34 30 00 40 00 00 00 00 00 00 02 00 0e 05 00 140.@... ........
0070 03 cf 02 02 36 37 38 39 20 61 61 61 ....6789 aaa


We're using NowSMS version 2012.02.16
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 5096
Registered: 08-2008
Posted on Wednesday, October 29, 2014 - 08:24 pm:   

Hi Chris,

The content of the message is not binary. The actual over the air GSM DCS value would be 0.

data_coding 2 is wrong. I suspect the provider is just confused, and thinks data_coding should be set to binary because user data header (for segmentation) is present.

BinaryDCS=2 is going to apply to outbound/sending.

You could try BinaryDCSOverride=0, which will override all binary DCS values for received messages and convert to a value of 0. It would corrupt any true binary messages, but will probably allow these messages to be interpreted correctly.

--
Des
NowSMS Support
Chris
Frequent Contributor
Username: Chrisc

Post Number: 70
Registered: 12-2008
Posted on Thursday, October 30, 2014 - 08:45 am:   

Hi Des,

Thanks for looking into this, that's solved the issue for us.

Regards
Chris