Thank you Semion and Andreas for your replies. I used the configuration suggested by Semion to check how would be a query inserted by smsbox on sqlbox. The result is:
INSERT INTO send_sms ( sql_id, momt, sender, receiver, udhdata, msgdata, time, smsc_id, service, account, sms_type, mclass, mwi, coding, compress, validity, deferred, dlr_mask, dlr_url, pid, alt_dcs, rpi, charset, boxc_id, binfo, meta_data ) VALUES ( NULL, 'MT', 'MV', '351919331367', NULL, 'Hello+world', 1325675923, NULL, 'tester', NULL, 2, NULL, NULL, 0, NULL, NULL, NULL, 31, ' http://easymessage.multivision.pt/services/teste.php?type=%d&destination=919331367', NULL, NULL, NULL, NULL, 'SMSBOX', NULL, NULL); With this query the message is sent and received properly. So the problem was that MySQL had 0 as a default value for the unspecified columns, since this query specifies them all including those that are meant to be NULL, this worked fine. I changed my table to have NULL as a default value and I reinserted the query I was using yesterday: 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'); and it worked fine. Thanks for your help. Best regards, Jorge On Wed, Jan 4, 2012 at 7:28 AM, Andreas Fink <[email protected]> wrote: > > <<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? >>> >>> -- >>> >>> [image: Multivision] *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 >>> >>> > > > -- > > [image: Multivision] *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 > > > -- [image: Multivision] *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
