<<They told me that the messages where being sent with DCS=216. They told me to set DCS to 1 if I'm sending 7-bit messages or DCS to 3 or 0 if I'm submitting ISO (8-bit message).>>
This is not really fully correct. Check out GSM 03.38 spec for values of DCS (http://www.3gpp.org/ftp/Specs/archive/03_series/03.38/0338-720.zip). Value 216 = binary 1101 100 Which stands for 1101 = Message Waiting Indication Group 1 = set Indication Active 0 = reserved 00 voicemail message waiting In other words this message will switch on the voicemail indicator. The voicemail indicator might not be supported on newer smartphones but older Nokias usually show a tape reel (something like 0_0). So this is a valid DCS message to go over the air. Note: the SMPP DCS representation might not be the same as the GSM DCS representation in some cases. For example your provider is saying DCS = 0 means 8 bit ISO but DCS=0 means default character set which is not ISO but GSM charset. DCS=1 means 8 bit data, DCS=2 means UCS2 (UTF-16) and DCS=3 is a reserved value. the SMPP specification lists this: Bits Meaning Notes 00000000 SMSCDefaultAlphabet 00000001 IA5(CCITTT.50)/ASCII(ANSIX3.4) b) 00000010 Octet unspecified (8-bit binary) b) 00000011 Latin1(ISO-8859-1) b) 00000100 Octet unspecified (8-bit binary) a) 00000101 JIS(X0208-1990) b) 00000110 Cyrllic(ISO-8859-5) b) 00000111 Latin/Hebrew (ISO-8859-8) b) 00001000 UCS2(ISO/IEC-10646) a) 00001001 PictogramEncoding b) 00001010 ISO-2022-JP(MusicCodes) b) 00001011 reserved 00001100 reserved 00001101 Extended Kanji JIS(X 0212-1990) b) 00001110 KSC5601 b) 00001111 reserved 10111111 reserved 1100xxxx GSMMWIcontrol-see[GSM03.38] d) 1101xxxx GSMMWIcontrol-see[GSM03.38] d) 1110xxxx reserved 1111xxxx GSMmessageclasscontrol-see[GSM03.38] e) Notes: a. These coding schemes are common to GSM, TDMA and CDMA. The SMPP protocol allows ESME applications to use the same DCS value (i.e. the GSM 03.38 value) for all three technologies. b. In cases where a Data Coding Scheme is defined for TDMA and/ or CDMA but not defined for GSM, SMPP uses GSM 03.38 reserved values. c. There is no default setting for the data_coding parameter. d. The data_coding parameter will evolve to specify Character code settings only. Thus the recommended way to specify GSM MWI control is by specifying the relevant settings in the optional parameters _ms_msg_wait_facilities and ms_validity. e. The data_coding parameter will evolve to specify Character code settings only. Thus the recommended way to specify GSM message class control is by specifying the relevant setting in the optional parameter dest_addr_subunit. On 03.01.2012, at 19:08, Jorge Raimundo wrote: > Hi Semion! > > Thanks for your reply! > > How exactly should I configure smsbox and sqlbox to act like you describe? > I'm sorry to ask you this, but I'm a newbie to kannel and I'm still > discovering how all the pieces fit together. > > Best regards, > Jorge > > On Tue, Jan 3, 2012 at 5:51 PM, Semion Spivak <[email protected]> wrote: > Hi Jorge, > > To check what should be put to the database, try to connect sqlbox as > following: > > Smsbox <-> sqlbox <-> bearerbox > > Then, send a test sms via http request to smsbox, providing it with > dlr-mask=31 and dlr-url containing url-encoded values. The sqlbox should > create a correct sql row in the db and pass the message to the bearerbox. > Also, turn on the sql logging in your db before you check it, to catch the > insert command. > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > > > Jorge Raimundo <[email protected]> wrote: > Hi all! > > I'm using sqlbox to send messages via SMPP, but I'm getting a very strange > problem. > > I've decided to use smsbox to handle the DLR via the dlr_url. > > So let me see if I can explain all the situations occurring. > > 1st insertion on the database: > INSERT INTO send_sms( momt, sender, receiver, msgdata, sms_type, dlr_mask, > dlr_url) VALUES ('MT', 'MV', '+3519******67', 'Hello world', 2, 31, > 'http://my_domain/services/teste.php?type=%d%destination=91******7'); > > As you can see, the URL has an error (it should have type=%d&destination > instead of type=%d%destination). This ended up in having a DLR with the > status of 8 (!?) not properly registered by the php script since the url is > malformed. > > 2nd insertion on the database: > INSERT INTO send_sms( momt, sender, receiver, msgdata, sms_type, dlr_mask, > dlr_url) VALUES ('MT', 'MV', '+3519******67', 'Hello world', 2, 31, > 'http://my_domain/services/teste.php?type=%d&destination=91******7'); > > This ended up in having a DLR with the status of 16 properly registered by my > php script (yes, it works with the dlr_url not encoded). > > At this point I contacted the support of my provider to know why they where > rejecting my messages. They told me that the messages where being sent with > DCS=216. They told me to set DCS to 1 if I'm sending 7-bit messages or DCS to > 3 or 0 if I'm submitting ISO (8-bit message). > > In fact on the smsc log I have this: data_coding: 216 = 0x000000d8 > > 3rd insertion on the database: > Wondering why the change on the dlr_url gave different DLR status, I made the > following > INSERT INTO send_sms( momt, sender, receiver, msgdata, sms_type, dlr_mask, > dlr_url) VALUES ('MT', 'MV', '+3519******67', 'Hello world', 2, 31, '7'); > > This ended up in having a DLR with the status of 0. Yes, I received the > message, but... the text was this: 䡥汬漠睯牬搀 > > The smsc log still gives: data_coding: 216 = 0x000000d8 > > 4th insertion on the database: > Testing what would happen if I passed a URL encoded dlr_url > INSERT INTO send_sms( momt, sender, receiver, msgdata, sms_type, dlr_mask, > dlr_url) VALUES ('MT', 'MV', '+3519******67', 'Hello world', 2, 31, > 'http%3A%2F%2Fmy_domain%2Fservices%2Fteste.php%3Ftype%3D%25d%26destination%3D91******7'); > > This ended up in having a DLR with the status of 0. I received the same text: > 䡥汬漠睯牬搀 > The smsc log still gives: data_coding: 216 = 0x000000d8 > The smsbox complains that: > ERROR: URL > <http%3A%2F%2Fmy_domain%2Fservices%2Fteste.php%3Ftype%3D%25d%26destination%3D91******7> > doesn't start with `http://' nor `https://' > ERROR: Couldn't send request to > <http%3A%2F%2Fmy_domain%2Fservices%2Fteste.php%3Ftype%3D%25d%26destination%3D91******7> > > Summarizing: > I don't know what's happening here. > Different values of the dlr_url cause different SMSC reactions to the request. > The DCS value is strange and I'm getting Chinese characters when I should > receive a "Hello world". > > Anyone could, please, point out what I am missing here? > > -- > > Jorge Raimundo > RAN Consultant | [email protected] > . > Rua António Albino Machado, Nº33, 2ºB. > S. Domingos de Benfica, 1600 - 870 Lisboa > Fixed PT: +351 21 155 20 53 | Mobile PT: +351 91 933 13 67 > www.multivision.pt > > > > > -- > > Jorge Raimundo > RAN Consultant | [email protected] > . > Rua António Albino Machado, Nº33, 2ºB. > S. Domingos de Benfica, 1600 - 870 Lisboa > Fixed PT: +351 21 155 20 53 | Mobile PT: +351 91 933 13 67 > www.multivision.pt >
