Re: Kannel / sendsms.php mobile phone (CMS ERROR: Unknown error. - maybe Sim storage is full? I'll have a look at it. (500))
Hi, Were you able to get any SMS from this mobile? Add at+CMEE=1 or 2 to your init string to get more detailed errors. Please attach your modem/smsc configuration. BR, Nikos - Original Message - From: Emmanuel CHANSON To: users@kannel.org Sent: Monday, October 19, 2009 4:59 AM Subject: Kannel / sendsms.php mobile phone (CMS ERROR: Unknown error. - maybe Sim storage is full? I'll have a look at it. (500)) Hello, I try to send SMS from the PHP script sendsms.php through a NOKIA 6230 connected to my server but I got this on the bearerbox: 2009-10-19 12:30:31 [29472] [9] DEBUG: boxc_receiver: sms received 2009-10-19 12:30:31 [29472] [9] DEBUG: send_msg: sending msg to box: 127.0.0.1 2009-10-19 12:30:33 [29472] [6] DEBUG: AT2[nokia6230]: TP-Validity-Period: 24.0 hours 2009-10-19 12:30:33 [29472] [6] DEBUG: AT2[nokia6230]: -- AT+CMGS=13^M 2009-10-19 12:30:33 [29472] [6] DEBUG: AT2[nokia6230]: -- 2009-10-19 12:30:33 [29472] [6] DEBUG: AT2[nokia6230]: send command status: 1 2009-10-19 12:30:33 [29472] [6] DEBUG: AT2[nokia6230]: -- 001100098186870558 2009-10-19 12:30:33 [29472] [6] DEBUG: AT2[nokia6230]: -- F0A700 2009-10-19 12:30:43 [29472] [6] DEBUG: AT2[nokia6230]: -- 2009-10-19 12:30:43 [29472] [6] DEBUG: AT2[nokia6230]: -- +CMS ERROR: 500 2009-10-19 12:30:43 [29472] [6] ERROR: AT2[nokia6230]: CMS ERROR: +CMS ERROR: 500 2009-10-19 12:30:43 [29472] [6] ERROR: AT2[nokia6230]: CMS ERROR: Unknown error. - maybe Sim storage is full? I'll have a look at it. (500) 2009-10-19 12:30:43 [29472] [6] DEBUG: AT2[nokia6230]: send command status: 1 2009-10-19 12:30:43 [29472] [7] DEBUG: sms_router: handling message (0x97d9838 vs 0x97d9838) 2009-10-19 12:30:43 [29472] [7] DEBUG: re-queing SMS not-yet-to-be resent 2009-10-19 12:30:43 [29472] [7] DEBUG: sms_router: handling message (0x97d9838 vs 0x97d9838) 2009-10-19 12:30:43 [29472] [7] DEBUG: re-queing SMS not-yet-to-be resent 2009-10-19 12:30:43 [29472] [7] DEBUG: sms_router: time to sleep 30.00 secs. 2009-10-19 12:30:43 [29472] [7] DEBUG: sms_router: gwlist_len = 1 2009-10-19 12:30:43 [29472] [7] DEBUG: sms_router: handling message (0x97d9838 vs 0x97d9838) 2009-10-19 12:30:43 [29472] [7] DEBUG: re-queing SMS not-yet-to-be resent 2009-10-19 12:30:43 [29472] [7] DEBUG: sms_router: handling message (0x97d9838 vs 0x97d9838) 2009-10-19 12:30:43 [29472] [7] DEBUG: re-queing SMS not-yet-to-be resent 2009-10-19 12:30:43 [29472] [7] DEBUG: sms_router: time to sleep 30.00 secs. 2009-10-19 12:30:49 [29472] [8] DEBUG: Dumping 1 messages to store 2009-10-19 12:31:13 [29472] [7] DEBUG: sms_router: gwlist_len = 1 2009-10-19 12:31:13 [29472] [7] DEBUG: sms_router: handling message (0x97d9838 vs 0x97d9838) 2009-10-19 12:31:13 [29472] [7] DEBUG: re-queing SMS not-yet-to-be resent 2009-10-19 12:31:13 [29472] [7] DEBUG: sms_router: handling message (0x97d9838 vs 0x97d9838) 2009-10-19 12:31:13 [29472] [7] DEBUG: re-queing SMS not-yet-to-be resent 2009-10-19 12:31:13 [29472] [7] DEBUG: sms_router: time to sleep 30.00 secs. I already saw this error at the beginnng and the solution I found on internet was to set the parameter enable-mms to false in modems.conf file But I still have this issue. Do you know how to check the SIM card using gnooki with this mobile? Regards, -- Emmanuel
GENERIC: ERROR when openning device
Hi all, i'm having trouble with Kannel and Nokia N70 Music Edition. I wonder if Kannel can read that phone or not? :(. Here is my situation: 2009-10-17 01:13:21 [7238] [6] INFO: AT2[N70]: opening device 2009-10-17 01:13:21 [7238] [0] INFO: Adding interface * 2009-10-17 01:13:21 [7238] [0] INFO: 2009-10-17 01:13:21 [7238] [0] INFO: Kannel bearerbox II version 1.4.3 starting 2009-10-17 01:13:21 [7238] [0] INFO: MAIN: Start-up done, entering mainloop 2009-10-17 01:13:22 [7238] [6] INFO: AT2[N70]: speed set to 115200 2009-10-17 01:13:24 [7238] [6] INFO: AT2[N70]: Closing device 2009-10-17 01:13:24 [7238] [6] INFO: AT2[N70]: detect speed is 115200 2009-10-17 01:13:24 [7238] [6] INFO: AT2[N70]: opening device 2009-10-17 01:13:25 [7238] [6] INFO: AT2[N70]: speed set to 115200 2009-10-17 01:13:27 [7238] [6] INFO: AT2[N70]: Closing device 2009-10-17 01:13:27 [7238] [6] INFO: AT2[N70]: opening device 2009-10-17 01:13:28 [7238] [6] INFO: AT2[N70]: Logging in 2009-10-17 01:13:29 [7238] [6] INFO: AT2[N70]: init device 2009-10-17 01:13:29 [7238] [6] INFO: AT2[N70]: speed set to 115200 2009-10-17 01:13:30 [7238] [6] ERROR: AT2[N70]: Generic error: ERROR 2009-10-17 01:13:30 [7238] [6] ERROR: AT2[N70]: Initialization of device failed. 2009-10-17 01:13:30 [7238] [6] INFO: AT2[N70]: Closing device 2009-10-17 01:13:30 [7238] [6] ERROR: AT2[N70]: Couldn't connect (retrying in 10 seconds). It seems that Kannel entered mainloop and could listen to mobile phone, but when it set speed for mobile, there is and error occured. Is there any way to configure or install package for my phone to detect kannel? Or any way to update kannel to detect my phone co'z it's Nokia N70 Music Edition, not N70. Here is my Kannel.conf file: group = core admin-port = 13000 admin-password = hoanggia admin-deny-ip = *.*.*.* admin-allow-ip = 127.0.0.1 smsbox-port = 13001 wapbox-port = 13002 wdp-interface-name = * log-file = /var/log/kannel/bearerbox.log box-deny-ip = *.*.*.* box-allow-ip = 127.0.0.1 group = wapbox bearerbox-host = localhost log-file = /var/log/kannel/wapbox.log #group = smsc #smsc = at #modemtype = auto #device=/dev/ttyACM0 #my-number = 123123123123 #The my-number field contains the number of #your GSM modem’s SIM chip ##log-level = 0 group = smsc smsc = at smsc-id = N70 device = /dev/ttyACM0 my-number = 0983040785 modemtype = nokiaphone # phone type speed = 0 connect-allow-ip = 127.0.0.1 #sms-center = +84980200030 group = modems id = nokiaphone name = Nokia N70 detect-string = Nokia init-string = ATQ0 V1 E1 S0=0 C1 D2 +FCLASS=0 #use sudo wvdialconf /etc/wvdial.conf keepalive-cmd = AT+CBC;+CSQ #detect-string2 = N70 speed = 0 need-sleep = true #pin = group = modems id = wavecome name = Wavecom detect-string = WAVECOM group = smsbox bearerbox-host = 127.0.0.1 sendsms-port = 13013 sendsms-chars = 0123456789+ log-file = /etc/kannel/smsbox.log #global-sender = 123123123123 log-level = 0 group = sendsms-user username = baochau password = hoanggia concatenation= true max-messages = 10 group = sms-service keyword = keyword-regex = .* catch-all = yes max-messages = 0 get-url = http://localhost/php.php?phone=%ptext=%a; -- View this message in context: http://www.nabble.com/GENERIC%3A-ERROR-when-openning-device-tp25930608p25930608.html Sent from the Kannel - User mailing list archive at Nabble.com.
TLV with null separated string
Hi, First off, I'm using cvs snapshot downloaded 17th October. I have a problem that I've not been able to solve. As the subject says, I need to be able to pass kannel a TLV where the value is an octetstring that consists of data that includes null characters, the string is then terminated by a null character. The URL call to sendsms looks something like this .meta-data%3Fsmpp%3F%26mytlv%3D1234%00testing%00anotherparam%00undefined%00%00 What I see in bearerbox log is: 2009-10-17 22:28:26 [16340] [6] DEBUG: mytlv: 1234 What I expected to see was an octet string dump with nulls and all parameters included. Is there a solution to this problem? Thanks, Andrew
Re: Kannel / sendsms.php mobile phone (CMS ERROR: Unknown error. - maybe Sim storage is full? I'll have a look at it. (500))
Thanks Nikos for your answer. In fact I think I found the reason of this. It is because in my PHP script I did not use the PHP function * urlencode($text)*, then when I tried to send a SMS with several word it did not work cause of the space between each word. Now it is working but thanks to tell me to add at+CMEE=1 or 2 in order to get more debug information ! BR, Emmanuel 2009/10/19 Nikos Balkanas n...@amdtelecom.net Hi, Were you able to get any SMS from this mobile? Add at+CMEE=1 or 2 to your init string to get more detailed errors. Please attach your modem/smsc configuration. BR, Nikos - Original Message - *From:* Emmanuel CHANSON emmanuelchan...@gmail.com *To:* users@kannel.org *Sent:* Monday, October 19, 2009 4:59 AM *Subject:* Kannel / sendsms.php mobile phone (CMS ERROR: Unknown error. - maybe Sim storage is full? I'll have a look at it. (500)) Hello, I try to send SMS from the PHP script sendsms.php through a NOKIA 6230 connected to my server but I got this on the bearerbox: *2009-10-19 12:30:31 [29472] [9] DEBUG: boxc_receiver: sms received 2009-10-19 12:30:31 [29472] [9] DEBUG: send_msg: sending msg to box: 127.0.0.1 2009-10-19 12:30:33 [29472] [6] DEBUG: AT2[nokia6230]: TP-Validity-Period: 24.0 hours 2009-10-19 12:30:33 [29472] [6] DEBUG: AT2[nokia6230]: -- AT+CMGS=13^M 2009-10-19 12:30:33 [29472] [6] DEBUG: AT2[nokia6230]: -- 2009-10-19 12:30:33 [29472] [6] DEBUG: AT2[nokia6230]: send command status: 1 2009-10-19 12:30:33 [29472] [6] DEBUG: AT2[nokia6230]: -- 001100098186870558 2009-10-19 12:30:33 [29472] [6] DEBUG: AT2[nokia6230]: -- F0A700 2009-10-19 12:30:43 [29472] [6] DEBUG: AT2[nokia6230]: -- 2009-10-19 12:30:43 [29472] [6] DEBUG: AT2[nokia6230]: -- +CMS ERROR: 500 2009-10-19 12:30:43 [29472] [6] ERROR: AT2[nokia6230]: CMS ERROR: +CMS ERROR: 500 2009-10-19 12:30:43 [29472] [6] ERROR: AT2[nokia6230]: CMS ERROR: Unknown error. - maybe Sim storage is full? I'll have a look at it. (500) 2009-10-19 12:30:43 [29472] [6] DEBUG: AT2[nokia6230]: send command status: 1 2009-10-19 12:30:43 [29472] [7] DEBUG: sms_router: handling message (0x97d9838 vs 0x97d9838) 2009-10-19 12:30:43 [29472] [7] DEBUG: re-queing SMS not-yet-to-be resent 2009-10-19 12:30:43 [29472] [7] DEBUG: sms_router: handling message (0x97d9838 vs 0x97d9838) 2009-10-19 12:30:43 [29472] [7] DEBUG: re-queing SMS not-yet-to-be resent 2009-10-19 12:30:43 [29472] [7] DEBUG: sms_router: time to sleep 30.00 secs. 2009-10-19 12:30:43 [29472] [7] DEBUG: sms_router: gwlist_len = 1 2009-10-19 12:30:43 [29472] [7] DEBUG: sms_router: handling message (0x97d9838 vs 0x97d9838) 2009-10-19 12:30:43 [29472] [7] DEBUG: re-queing SMS not-yet-to-be resent 2009-10-19 12:30:43 [29472] [7] DEBUG: sms_router: handling message (0x97d9838 vs 0x97d9838) 2009-10-19 12:30:43 [29472] [7] DEBUG: re-queing SMS not-yet-to-be resent 2009-10-19 12:30:43 [29472] [7] DEBUG: sms_router: time to sleep 30.00 secs. 2009-10-19 12:30:49 [29472] [8] DEBUG: Dumping 1 messages to store 2009-10-19 12:31:13 [29472] [7] DEBUG: sms_router: gwlist_len = 1 2009-10-19 12:31:13 [29472] [7] DEBUG: sms_router: handling message (0x97d9838 vs 0x97d9838) 2009-10-19 12:31:13 [29472] [7] DEBUG: re-queing SMS not-yet-to-be resent 2009-10-19 12:31:13 [29472] [7] DEBUG: sms_router: handling message (0x97d9838 vs 0x97d9838) 2009-10-19 12:31:13 [29472] [7] DEBUG: re-queing SMS not-yet-to-be resent 2009-10-19 12:31:13 [29472] [7] DEBUG: sms_router: time to sleep 30.00 secs. *I already saw this error at the beginnng and the solution I found on internet was to set the parameter *enable-mms* to false in *modems.conf*file But I still have this issue. Do you know how to check the SIM card using gnooki with this mobile? Regards, -- Emmanuel -- Emmanuel CHANSON Emmanuel Mobile Nouvelle-Calédonie: +687 850.850 Mobile France: +33 (0) 6.68.03.89.56 @email : emmanuelchan...@gmail.com
Re: getting delivery report: delivery failure
Apologies for not sending the complete PDU before. Kindly review the complete PDU and guide. Thanks. ... [7] DEBUG: SMPP[abc1]: Got PDU: [7] DEBUG: SMPP PDU 8174bc0 dump: [7] DEBUG: type_name: enquire_link_resp [7] DEBUG: command_id: 2147483669 = 0x8015 [7] DEBUG: command_status: 0 = 0x [7] DEBUG: sequence_number: 201551 = 0x0003134f [7] DEBUG: SMPP PDU dump ends. [11] DEBUG: SMPP[abc3]: Sending enquire link: [11] DEBUG: SMPP PDU 8174bc0 dump: [11] DEBUG: type_name: enquire_link [11] DEBUG: command_id: 21 = 0x0015 [11] DEBUG: command_status: 0 = 0x [11] DEBUG: sequence_number: 201628 = 0x0003139c [11] DEBUG: SMPP PDU dump ends. [11] DEBUG: SMPP[abc3]: Got PDU: [11] DEBUG: SMPP PDU 8174bc0 dump: [11] DEBUG: type_name: enquire_link_resp [11] DEBUG: command_id: 2147483669 = 0x8015 [11] DEBUG: command_status: 0 = 0x [11] DEBUG: sequence_number: 201628 = 0x0003139c [11] DEBUG: SMPP PDU dump ends. [11] DEBUG: SMPP[abc3]: Got PDU: [11] DEBUG: SMPP PDU 8174bc0 dump: [11] DEBUG: type_name: deliver_sm [11] DEBUG: command_id: 5 = 0x0005 [11] DEBUG: command_status: 0 = 0x [11] DEBUG: sequence_number: 2453831019 = 0x92427d6b [11] DEBUG: service_type: NULL [11] DEBUG: source_addr_ton: 1 = 0x0001 [11] DEBUG: source_addr_npi: 1 = 0x0001 [11] DEBUG: source_addr: 989352034309 [11] DEBUG: dest_addr_ton: 0 = 0x [11] DEBUG: dest_addr_npi: 1 = 0x0001 [11] DEBUG: destination_addr: 8601001 [11] DEBUG: esm_class: 4 = 0x0004 [11] DEBUG: protocol_id: 0 = 0x [11] DEBUG: priority_flag: 0 = 0x [11] DEBUG: schedule_delivery_time: NULL [11] DEBUG: validity_period: NULL [11] DEBUG: registered_delivery: 0 = 0x [11] DEBUG: replace_if_present_flag: 0 = 0x [11] DEBUG: data_coding: 0 = 0x [11] DEBUG: sm_default_msg_id: 0 = 0x [11] DEBUG: sm_length: 70 = 0x0046 [11] DEBUG: short_message: [11] DEBUG:Octet string at 8129850: [11] DEBUG: len: 70 [11] DEBUG: size: 71 [11] DEBUG: immutable: 0 [11] DEBUG: data: 69 64 3a 32 34 35 31 37 33 33 31 33 34 20 73 75 id:2451733134 su [11] DEBUG: data: 62 6d 69 74 20 64 61 74 65 3a 30 39 31 30 31 33 bmit date:091013 [11] DEBUG: data: 30 37 30 34 20 64 6f 6e 65 20 64 61 74 65 3a 30 0704 done date:0 [11] DEBUG: data: 39 31 30 31 33 30 39 35 31 20 73 74 61 74 3a 44 910130951 stat:D [11] DEBUG: data: 45 4c 49 56 52 44 ELIVRD [11] DEBUG:Octet string dump ends. [11] DEBUG: SMPP PDU dump ends. [11] DEBUG: SMPP[abc3] handle_pdu, got DLR [11] DEBUG: SMPP[abc3]: Couldnot parse DLR string sscanf way,fallback to old way. Please report! [11] DEBUG: DLR[internal]: Looking for DLR smsc=abc3, ts=2451733134, dst=491733114042, type=2 [11] DEBUG: DLR[internal]: created DLR message for URL http://192.xxx.xxx.xxx:80/DServlet?dlrStatus=%ddlrData=%A [11] DEBUG: SMPP[abc3]: Sending PDU: [11] DEBUG: SMPP PDU 81772b8 dump: [11] DEBUG: type_name: deliver_sm_resp [11] DEBUG: command_id: 2147483653 = 0x8005 [11] DEBUG: command_status: 0 = 0x [11] DEBUG: sequence_number: 2453831019 = 0x92427d6b [11] DEBUG: message_id: NULL [11] DEBUG: SMPP PDU dump ends. ... 2009/10/16 Nikos Balkanas nbalka...@gmail.com Hmm. Interesting. I misspelled DLR to DKR and I think this caused the problem. When asking for detailed DLR excerpt from bb logs, I didn't have half a PDU in mind! Are you trying to save lines on copy and paste? Please resubmit the whole PDU entry from bb logs. Nikos - Original Message - *From:* Latitude Test latitude...@googlemail.com *To:* users users@kannel.org *Sent:* Friday, October 16, 2009 11:21 AM *Subject:* getting delivery report: delivery failure This is what I see in the log: DEBUG: data: 69 64 3a 32 34 35 31 37 33 33 31 33 34 20 73 75 id:2451733134 su DEBUG: data: 62 6d 69 74 20 64 61 74 65 3a 30 39 31 30 31 33 bmit date:091013 DEBUG: data: 30 37 30 34 20 64 6f 6e 65 20 64 61 74 65 3a 30 0704 done date:0 DEBUG: data: 39 31 30 31 33 30 39 35 31 20 73 74 61 74 3a 44 910130951 stat:D DEBUG: data: 45 4c 49 56 52 44 ELIVRD DEBUG: Octet string dump ends. DEBUG: SMPP PDU dump ends. DEBUG: SMPP[abc3] handle_pdu, got DLR DEBUG: SMPP[abc3]: Couldnot parse DLR string sscanf way,fallback to old way. Please report! DEBUG: DLR[internal]: Looking for DLR smsc=abc3, ts=2451733134, dst=491733114042, type=2 DEBUG: DLR[internal]: created DLR message for URL http://192.xxx.xxx.xxx:80/DServlet?dlrStatus=%ddlrData=%A 2009/10/13 Nikos Balkanas nbalka...@gmail.com Hi, Please post detailed bb logs with the respond_sm PDU from your SMSc. I suspect that your SMSc is sending the wrong DKR. BR, Nikos - Original Message - *From:* Latitude Test latitude...@googlemail.com *To:* users users@kannel.org *Sent:* Tuesday, October 13, 2009 2:15 PM *Subject:* getting delivery report: delivery failure Hi all, My kannel is
Re: Message Queue :: Clarification
Thank you Abdulraheem, Betwise, shall i configure the throughput to what my operator is slowing down to ? (1 sms/s) Regards, On Mon, Oct 19, 2009 at 3:27 AM, Abdulraheem Obaisi aopa...@hotmail.comwrote: Hi, I have faced same issue month ago (throughput problem) , last CVS has solved this issue please try to install the latest one with configuring the throughput in your SMSC connection. ... Best Regards Eng: Abdulraheem Ali Obaisi Software Engineer -- Date: Sun, 18 Oct 2009 13:07:17 +0100 Subject: Re: Message Queue :: Clarification From: fou...@gmail.com To: cornejo.alv...@gmail.com CC: users@kannel.org Thank you for this information. I have an issue with Kannel, am sending some 10K sms-mt campaign, in the normal behaviour i have a decreasing store and increasing sent message counter. But suddenly, the store stops to be decreased, the sent in queue counter starts increasing till getting the same value than store and they both keep that for some hours. The logs are in debug, and i have nothing saying the smsc is rejecting or something like that ... i realy dont know how to resolve such a problem. On Sat, Oct 17, 2009 at 3:37 PM, Alvaro Cornejo cornejo.alv...@gmail.comwrote: the values shown in the specific smsc correspond to messages queues in that specific SMSC. Messages in store size are messages that were not yet assigned to an smsc. kind of global queue. Regards Alvaro On Mon, Sep 7, 2009 at 6:09 AM, Jinson jin...@mobme.in wrote: Hello Group, Below is my http admin view of kannel. I'm not able to understand the exact differnce between message in stored queue and ones shown in each smsc connection. SMS: received 18762 (0 queued), sent 12983 (0 queued), store size 20 SMS: inbound (0.50,7.02,3.44) msg/sec, outbound (0.13,3.37,2.38) msg/sec DLR: 67291 queued, using mysql storage Box connections: smsbox:smsbox, IP 127.0.0.1 (0 queued), (on-line 0d 1h 30m 44s) SMSC connections: xSMPP:xxx: (online 2266s, rcvd 6920, sent 6920, failed 0, queued 0 msgs) xSMPP:xxx: (online 5447s, rcvd 0, sent 0, failed 0, queued 0 msgs) xSMPP:xxx: (online 5447s, rcvd 2102, sent 952, failed 2, queued 716 msgs) xSMPP:xxx: (online 5447s, rcvd 2060, sent 909, failed 3, queued 593 msgs) xSMPP:xxx: (online 5447s, rcvd 2363, sent 1216, failed 1, queued 228 msgs) xSMPP:xxx: (online 5447s, rcvd 2592, sent 1442, failed 4, queued 19 msgs) xSMPP:xxx: (online 5447s, rcvd 2725, sent 1544, failed 33, queued 0 msgs) xSMPP:xxx: (online 5447s, rcvd 0, sent 0, failed 0, queued 0 msgs) --- Thanks Jinson Abraham -- |-| Envíe y Reciba Datos y mensajes de Texto (SMS) hacia y desde cualquier celular y Nextel en el Perú, México y en mas de 180 paises. Use aplicaciones 2 vias via SMS y GPRS online Visitenos en www.perusms.NET http://www.perusms.net/ www.smsglobal.com.mx y www.pravcom.com -- Windows Live: Keep your friends up to date with what you do online.http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_1:092010
Re: Kannel / sendsms.php mobile phone (CMS ERROR: Unknown error. - maybe Sim storage is full? I'll have a look at it. (500))
Wow! Glad it could help. Nikos - Original Message - From: Emmanuel CHANSON To: Nikos Balkanas Cc: users@kannel.org Sent: Monday, October 19, 2009 12:14 PM Subject: Re: Kannel / sendsms.php mobile phone (CMS ERROR: Unknown error. - maybe Sim storage is full? I'll have a look at it. (500)) Thanks Nikos for your answer. In fact I think I found the reason of this. It is because in my PHP script I did not use the PHP function urlencode($text), then when I tried to send a SMS with several word it did not work cause of the space between each word. Now it is working but thanks to tell me to add at+CMEE=1 or 2 in order to get more debug information ! BR, Emmanuel 2009/10/19 Nikos Balkanas n...@amdtelecom.net Hi, Were you able to get any SMS from this mobile? Add at+CMEE=1 or 2 to your init string to get more detailed errors. Please attach your modem/smsc configuration. BR, Nikos - Original Message - From: Emmanuel CHANSON To: users@kannel.org Sent: Monday, October 19, 2009 4:59 AM Subject: Kannel / sendsms.php mobile phone (CMS ERROR: Unknown error. - maybe Sim storage is full? I'll have a look at it. (500)) Hello, I try to send SMS from the PHP script sendsms.php through a NOKIA 6230 connected to my server but I got this on the bearerbox: 2009-10-19 12:30:31 [29472] [9] DEBUG: boxc_receiver: sms received 2009-10-19 12:30:31 [29472] [9] DEBUG: send_msg: sending msg to box: 127.0.0.1 2009-10-19 12:30:33 [29472] [6] DEBUG: AT2[nokia6230]: TP-Validity-Period: 24.0 hours 2009-10-19 12:30:33 [29472] [6] DEBUG: AT2[nokia6230]: -- AT+CMGS=13^M 2009-10-19 12:30:33 [29472] [6] DEBUG: AT2[nokia6230]: -- 2009-10-19 12:30:33 [29472] [6] DEBUG: AT2[nokia6230]: send command status: 1 2009-10-19 12:30:33 [29472] [6] DEBUG: AT2[nokia6230]: -- 001100098186870558 2009-10-19 12:30:33 [29472] [6] DEBUG: AT2[nokia6230]: -- F0A700 2009-10-19 12:30:43 [29472] [6] DEBUG: AT2[nokia6230]: -- 2009-10-19 12:30:43 [29472] [6] DEBUG: AT2[nokia6230]: -- +CMS ERROR: 500 2009-10-19 12:30:43 [29472] [6] ERROR: AT2[nokia6230]: CMS ERROR: +CMS ERROR: 500 2009-10-19 12:30:43 [29472] [6] ERROR: AT2[nokia6230]: CMS ERROR: Unknown error. - maybe Sim storage is full? I'll have a look at it. (500) 2009-10-19 12:30:43 [29472] [6] DEBUG: AT2[nokia6230]: send command status: 1 2009-10-19 12:30:43 [29472] [7] DEBUG: sms_router: handling message (0x97d9838 vs 0x97d9838) 2009-10-19 12:30:43 [29472] [7] DEBUG: re-queing SMS not-yet-to-be resent 2009-10-19 12:30:43 [29472] [7] DEBUG: sms_router: handling message (0x97d9838 vs 0x97d9838) 2009-10-19 12:30:43 [29472] [7] DEBUG: re-queing SMS not-yet-to-be resent 2009-10-19 12:30:43 [29472] [7] DEBUG: sms_router: time to sleep 30.00 secs. 2009-10-19 12:30:43 [29472] [7] DEBUG: sms_router: gwlist_len = 1 2009-10-19 12:30:43 [29472] [7] DEBUG: sms_router: handling message (0x97d9838 vs 0x97d9838) 2009-10-19 12:30:43 [29472] [7] DEBUG: re-queing SMS not-yet-to-be resent 2009-10-19 12:30:43 [29472] [7] DEBUG: sms_router: handling message (0x97d9838 vs 0x97d9838) 2009-10-19 12:30:43 [29472] [7] DEBUG: re-queing SMS not-yet-to-be resent 2009-10-19 12:30:43 [29472] [7] DEBUG: sms_router: time to sleep 30.00 secs. 2009-10-19 12:30:49 [29472] [8] DEBUG: Dumping 1 messages to store 2009-10-19 12:31:13 [29472] [7] DEBUG: sms_router: gwlist_len = 1 2009-10-19 12:31:13 [29472] [7] DEBUG: sms_router: handling message (0x97d9838 vs 0x97d9838) 2009-10-19 12:31:13 [29472] [7] DEBUG: re-queing SMS not-yet-to-be resent 2009-10-19 12:31:13 [29472] [7] DEBUG: sms_router: handling message (0x97d9838 vs 0x97d9838) 2009-10-19 12:31:13 [29472] [7] DEBUG: re-queing SMS not-yet-to-be resent 2009-10-19 12:31:13 [29472] [7] DEBUG: sms_router: time to sleep 30.00 secs. I already saw this error at the beginnng and the solution I found on internet was to set the parameter enable-mms to false in modems.conf file But I still have this issue. Do you know how to check the SIM card using gnooki with this mobile? Regards, -- Emmanuel -- Emmanuel CHANSON Emmanuel Mobile Nouvelle-Calιdonie: +687 850.850 Mobile France: +33 (0) 6.68.03.89.56 @email : emmanuelchan...@gmail.com
Re: getting delivery report: delivery failure
Hi, It seems that your SMSc is sending out the wrong DLR format. According to SMPP 3.4 specs: “id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .” Several optional fields (sub, dlvrd, err) are missing, but also a required field: Text. Without it kannel cannot understand the DLR. Contact your SMSc about it. They should comply to the SMPP spec. BR, Nikos - Original Message - From: Latitude Test To: users ; Nikos Balkanas Sent: Monday, October 19, 2009 12:26 PM Subject: Re: getting delivery report: delivery failure Apologies for not sending the complete PDU before. Kindly review the complete PDU and guide. Thanks. ... [7] DEBUG: SMPP[abc1]: Got PDU: [7] DEBUG: SMPP PDU 8174bc0 dump: [7] DEBUG: type_name: enquire_link_resp [7] DEBUG: command_id: 2147483669 = 0x8015 [7] DEBUG: command_status: 0 = 0x [7] DEBUG: sequence_number: 201551 = 0x0003134f [7] DEBUG: SMPP PDU dump ends. [11] DEBUG: SMPP[abc3]: Sending enquire link: [11] DEBUG: SMPP PDU 8174bc0 dump: [11] DEBUG: type_name: enquire_link [11] DEBUG: command_id: 21 = 0x0015 [11] DEBUG: command_status: 0 = 0x [11] DEBUG: sequence_number: 201628 = 0x0003139c [11] DEBUG: SMPP PDU dump ends. [11] DEBUG: SMPP[abc3]: Got PDU: [11] DEBUG: SMPP PDU 8174bc0 dump: [11] DEBUG: type_name: enquire_link_resp [11] DEBUG: command_id: 2147483669 = 0x8015 [11] DEBUG: command_status: 0 = 0x [11] DEBUG: sequence_number: 201628 = 0x0003139c [11] DEBUG: SMPP PDU dump ends. [11] DEBUG: SMPP[abc3]: Got PDU: [11] DEBUG: SMPP PDU 8174bc0 dump: [11] DEBUG: type_name: deliver_sm [11] DEBUG: command_id: 5 = 0x0005 [11] DEBUG: command_status: 0 = 0x [11] DEBUG: sequence_number: 2453831019 = 0x92427d6b [11] DEBUG: service_type: NULL [11] DEBUG: source_addr_ton: 1 = 0x0001 [11] DEBUG: source_addr_npi: 1 = 0x0001 [11] DEBUG: source_addr: 989352034309 [11] DEBUG: dest_addr_ton: 0 = 0x [11] DEBUG: dest_addr_npi: 1 = 0x0001 [11] DEBUG: destination_addr: 8601001 [11] DEBUG: esm_class: 4 = 0x0004 [11] DEBUG: protocol_id: 0 = 0x [11] DEBUG: priority_flag: 0 = 0x [11] DEBUG: schedule_delivery_time: NULL [11] DEBUG: validity_period: NULL [11] DEBUG: registered_delivery: 0 = 0x [11] DEBUG: replace_if_present_flag: 0 = 0x [11] DEBUG: data_coding: 0 = 0x [11] DEBUG: sm_default_msg_id: 0 = 0x [11] DEBUG: sm_length: 70 = 0x0046 [11] DEBUG: short_message: [11] DEBUG:Octet string at 8129850: [11] DEBUG: len: 70 [11] DEBUG: size: 71 [11] DEBUG: immutable: 0 [11] DEBUG: data: 69 64 3a 32 34 35 31 37 33 33 31 33 34 20 73 75 id:2451733134 su [11] DEBUG: data: 62 6d 69 74 20 64 61 74 65 3a 30 39 31 30 31 33 bmit date:091013 [11] DEBUG: data: 30 37 30 34 20 64 6f 6e 65 20 64 61 74 65 3a 30 0704 done date:0 [11] DEBUG: data: 39 31 30 31 33 30 39 35 31 20 73 74 61 74 3a 44 910130951 stat:D [11] DEBUG: data: 45 4c 49 56 52 44 ELIVRD [11] DEBUG:Octet string dump ends. [11] DEBUG: SMPP PDU dump ends. [11] DEBUG: SMPP[abc3] handle_pdu, got DLR [11] DEBUG: SMPP[abc3]: Couldnot parse DLR string sscanf way,fallback to old way. Please report! [11] DEBUG: DLR[internal]: Looking for DLR smsc=abc3, ts=2451733134, dst=491733114042, type=2 [11] DEBUG: DLR[internal]: created DLR message for URL http://192.xxx.xxx.xxx:80/DServlet?dlrStatus=%ddlrData=%A [11] DEBUG: SMPP[abc3]: Sending PDU: [11] DEBUG: SMPP PDU 81772b8 dump: [11] DEBUG: type_name: deliver_sm_resp [11] DEBUG: command_id: 2147483653 = 0x8005 [11] DEBUG: command_status: 0 = 0x [11] DEBUG: sequence_number: 2453831019 = 0x92427d6b [11] DEBUG: message_id: NULL [11] DEBUG: SMPP PDU dump ends. ... 2009/10/16 Nikos Balkanas nbalka...@gmail.com Hmm. Interesting. I misspelled DLR to DKR and I think this caused the problem. When asking for detailed DLR excerpt from bb logs, I didn't have half a PDU in mind! Are you trying to save lines on copy and paste? Please resubmit the whole PDU entry from bb logs. Nikos - Original Message - From: Latitude Test To: users Sent: Friday, October 16, 2009 11:21 AM Subject: getting delivery report: delivery failure This is what I see in the log: DEBUG: data: 69 64 3a 32 34 35 31 37 33 33 31 33 34 20 73 75 id:2451733134 su DEBUG: data: 62 6d 69 74 20 64 61 74 65 3a 30 39 31 30 31 33 bmit date:091013 DEBUG: data: 30 37 30 34 20 64 6f 6e 65 20 64 61 74 65 3a 30 0704 done date:0 DEBUG: data: 39 31 30 31 33 30 39 35 31 20 73 74 61 74 3a 44 910130951 stat:D DEBUG: data: 45 4c 49 56 52 44
Re: getting delivery report: delivery failure
Thanks Nikos. But I do get stat field which contains some useful info. Also I felt that the format is vendor specific and the missing fields are not mandatory. Quote from http://www.nowsms.com/discus/messages/1/SMPP_v3_4_Issue1_2-24857.pdf: The informational content of an SMSC Delivery Receipt may be inserted into the short_message parameter of the deliver_sm operation. The format for this Delivery Receipt message is SMSC* vendor specific* but following is a typical example of Delivery Receipt report. “id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .” Regards. 2009/10/19 Nikos Balkanas n...@amdtelecom.net Hi, It seems that your SMSc is sending out the wrong DLR format. According to SMPP 3.4 specs: “ *id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .”* Several optional fields (sub, dlvrd, err) are missing, but also a required field: Text. Without it kannel cannot understand the DLR. Contact your SMSc about it. They should comply to the SMPP spec. BR, Nikos - Original Message - *From:* Latitude Test latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *Sent:* Monday, October 19, 2009 12:26 PM *Subject:* Re: getting delivery report: delivery failure Apologies for not sending the complete PDU before. Kindly review the complete PDU and guide. Thanks. ... [7] DEBUG: SMPP[abc1]: Got PDU: [7] DEBUG: SMPP PDU 8174bc0 dump: [7] DEBUG: type_name: enquire_link_resp [7] DEBUG: command_id: 2147483669 = 0x8015 [7] DEBUG: command_status: 0 = 0x [7] DEBUG: sequence_number: 201551 = 0x0003134f [7] DEBUG: SMPP PDU dump ends. [11] DEBUG: SMPP[abc3]: Sending enquire link: [11] DEBUG: SMPP PDU 8174bc0 dump: [11] DEBUG: type_name: enquire_link [11] DEBUG: command_id: 21 = 0x0015 [11] DEBUG: command_status: 0 = 0x [11] DEBUG: sequence_number: 201628 = 0x0003139c [11] DEBUG: SMPP PDU dump ends. [11] DEBUG: SMPP[abc3]: Got PDU: [11] DEBUG: SMPP PDU 8174bc0 dump: [11] DEBUG: type_name: enquire_link_resp [11] DEBUG: command_id: 2147483669 = 0x8015 [11] DEBUG: command_status: 0 = 0x [11] DEBUG: sequence_number: 201628 = 0x0003139c [11] DEBUG: SMPP PDU dump ends. [11] DEBUG: SMPP[abc3]: Got PDU: [11] DEBUG: SMPP PDU 8174bc0 dump: [11] DEBUG: type_name: deliver_sm [11] DEBUG: command_id: 5 = 0x0005 [11] DEBUG: command_status: 0 = 0x [11] DEBUG: sequence_number: 2453831019 = 0x92427d6b [11] DEBUG: service_type: NULL [11] DEBUG: source_addr_ton: 1 = 0x0001 [11] DEBUG: source_addr_npi: 1 = 0x0001 [11] DEBUG: source_addr: 989352034309 [11] DEBUG: dest_addr_ton: 0 = 0x [11] DEBUG: dest_addr_npi: 1 = 0x0001 [11] DEBUG: destination_addr: 8601001 [11] DEBUG: esm_class: 4 = 0x0004 [11] DEBUG: protocol_id: 0 = 0x [11] DEBUG: priority_flag: 0 = 0x [11] DEBUG: schedule_delivery_time: NULL [11] DEBUG: validity_period: NULL [11] DEBUG: registered_delivery: 0 = 0x [11] DEBUG: replace_if_present_flag: 0 = 0x [11] DEBUG: data_coding: 0 = 0x [11] DEBUG: sm_default_msg_id: 0 = 0x [11] DEBUG: sm_length: 70 = 0x0046 [11] DEBUG: short_message: [11] DEBUG:Octet string at 8129850: [11] DEBUG: len: 70 [11] DEBUG: size: 71 [11] DEBUG: immutable: 0 [11] DEBUG: data: 69 64 3a 32 34 35 31 37 33 33 31 33 34 20 73 75 id:2451733134 su [11] DEBUG: data: 62 6d 69 74 20 64 61 74 65 3a 30 39 31 30 31 33 bmit date:091013 [11] DEBUG: data: 30 37 30 34 20 64 6f 6e 65 20 64 61 74 65 3a 30 0704 done date:0 [11] DEBUG: data: 39 31 30 31 33 30 39 35 31 20 73 74 61 74 3a 44 910130951 stat:D [11] DEBUG: data: 45 4c 49 56 52 44 ELIVRD [11] DEBUG:Octet string dump ends. [11] DEBUG: SMPP PDU dump ends. [11] DEBUG: SMPP[abc3] handle_pdu, got DLR [11] DEBUG: SMPP[abc3]: Couldnot parse DLR string sscanf way,fallback to old way. Please report! [11] DEBUG: DLR[internal]: Looking for DLR smsc=abc3, ts=2451733134, dst=491733114042, type=2 [11] DEBUG: DLR[internal]: created DLR message for URL http://192.xxx.xxx.xxx:80/DServlet?dlrStatus=%ddlrData=%A [11] DEBUG: SMPP[abc3]: Sending PDU: [11] DEBUG: SMPP PDU 81772b8 dump: [11] DEBUG: type_name: deliver_sm_resp [11] DEBUG: command_id: 2147483653 = 0x8005 [11] DEBUG: command_status: 0 = 0x [11] DEBUG: sequence_number: 2453831019 = 0x92427d6b [11] DEBUG: message_id: NULL [11] DEBUG: SMPP PDU dump ends. ... 2009/10/16 Nikos Balkanas nbalka...@gmail.com Hmm. Interesting. I misspelled DLR to DKR and I think this caused the problem. When asking for detailed DLR excerpt from bb logs, I didn't have half a PDU in mind! Are you trying to save lines on copy and paste? Please resubmit
Fwd: getting delivery report: delivery failure
Adding to it, I saw Kannel sending me correct DLRs with another SMSC and in the logs I saw the following: dlvrd:001 sub:001 Text:. The mendatory field Text does not contain any useful info here. How kannel knows the status of the message then? Seems it uses the optional fields which are sub and dlvrd. Please confirm. Thanks. -- Forwarded message -- From: Latitude Test latitude...@googlemail.com Date: Mon, Oct 19, 2009 at 1:31 PM Subject: Re: getting delivery report: delivery failure To: users users@kannel.org, Nikos Balkanas nbalka...@gmail.com Thanks Nikos. But I do get stat field which contains some useful info. Also I felt that the format is vendor specific and the missing fields are not mandatory. Quote from http://www.nowsms.com/discus/messages/1/SMPP_v3_4_Issue1_2-24857.pdf: The informational content of an SMSC Delivery Receipt may be inserted into the short_message parameter of the deliver_sm operation. The format for this Delivery Receipt message is SMSC* vendor specific* but following is a typical example of Delivery Receipt report. “id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .” Regards. 2009/10/19 Nikos Balkanas n...@amdtelecom.net Hi, It seems that your SMSc is sending out the wrong DLR format. According to SMPP 3.4 specs: “ *id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .”* Several optional fields (sub, dlvrd, err) are missing, but also a required field: Text. Without it kannel cannot understand the DLR. Contact your SMSc about it. They should comply to the SMPP spec. BR, Nikos - Original Message - *From:* Latitude Test latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *Sent:* Monday, October 19, 2009 12:26 PM *Subject:* Re: getting delivery report: delivery failure Apologies for not sending the complete PDU before. Kindly review the complete PDU and guide. Thanks. ... [7] DEBUG: SMPP[abc1]: Got PDU: [7] DEBUG: SMPP PDU 8174bc0 dump: [7] DEBUG: type_name: enquire_link_resp [7] DEBUG: command_id: 2147483669 = 0x8015 [7] DEBUG: command_status: 0 = 0x [7] DEBUG: sequence_number: 201551 = 0x0003134f [7] DEBUG: SMPP PDU dump ends. [11] DEBUG: SMPP[abc3]: Sending enquire link: [11] DEBUG: SMPP PDU 8174bc0 dump: [11] DEBUG: type_name: enquire_link [11] DEBUG: command_id: 21 = 0x0015 [11] DEBUG: command_status: 0 = 0x [11] DEBUG: sequence_number: 201628 = 0x0003139c [11] DEBUG: SMPP PDU dump ends. [11] DEBUG: SMPP[abc3]: Got PDU: [11] DEBUG: SMPP PDU 8174bc0 dump: [11] DEBUG: type_name: enquire_link_resp [11] DEBUG: command_id: 2147483669 = 0x8015 [11] DEBUG: command_status: 0 = 0x [11] DEBUG: sequence_number: 201628 = 0x0003139c [11] DEBUG: SMPP PDU dump ends. [11] DEBUG: SMPP[abc3]: Got PDU: [11] DEBUG: SMPP PDU 8174bc0 dump: [11] DEBUG: type_name: deliver_sm [11] DEBUG: command_id: 5 = 0x0005 [11] DEBUG: command_status: 0 = 0x [11] DEBUG: sequence_number: 2453831019 = 0x92427d6b [11] DEBUG: service_type: NULL [11] DEBUG: source_addr_ton: 1 = 0x0001 [11] DEBUG: source_addr_npi: 1 = 0x0001 [11] DEBUG: source_addr: 989352034309 [11] DEBUG: dest_addr_ton: 0 = 0x [11] DEBUG: dest_addr_npi: 1 = 0x0001 [11] DEBUG: destination_addr: 8601001 [11] DEBUG: esm_class: 4 = 0x0004 [11] DEBUG: protocol_id: 0 = 0x [11] DEBUG: priority_flag: 0 = 0x [11] DEBUG: schedule_delivery_time: NULL [11] DEBUG: validity_period: NULL [11] DEBUG: registered_delivery: 0 = 0x [11] DEBUG: replace_if_present_flag: 0 = 0x [11] DEBUG: data_coding: 0 = 0x [11] DEBUG: sm_default_msg_id: 0 = 0x [11] DEBUG: sm_length: 70 = 0x0046 [11] DEBUG: short_message: [11] DEBUG:Octet string at 8129850: [11] DEBUG: len: 70 [11] DEBUG: size: 71 [11] DEBUG: immutable: 0 [11] DEBUG: data: 69 64 3a 32 34 35 31 37 33 33 31 33 34 20 73 75 id:2451733134 su [11] DEBUG: data: 62 6d 69 74 20 64 61 74 65 3a 30 39 31 30 31 33 bmit date:091013 [11] DEBUG: data: 30 37 30 34 20 64 6f 6e 65 20 64 61 74 65 3a 30 0704 done date:0 [11] DEBUG: data: 39 31 30 31 33 30 39 35 31 20 73 74 61 74 3a 44 910130951 stat:D [11] DEBUG: data: 45 4c 49 56 52 44 ELIVRD [11] DEBUG:Octet string dump ends. [11] DEBUG: SMPP PDU dump ends. [11] DEBUG: SMPP[abc3] handle_pdu, got DLR [11] DEBUG: SMPP[abc3]: Couldnot parse DLR string sscanf way,fallback to old way. Please report! [11] DEBUG: DLR[internal]: Looking for DLR smsc=abc3, ts=2451733134, dst=491733114042, type=2 [11] DEBUG: DLR[internal]: created DLR message for URL http://192.xxx.xxx.xxx:80/DServlet?dlrStatus=%ddlrData=%A [11] DEBUG: SMPP[abc3]: Sending PDU: [11]
Re: How to stop message retries
This sometimes happen if the user is in a foreign network, like when travelling. The message get delivered, but the SMSC that you are using does not receive an ack from the phone that message is delivered. So, it retries the message. You can try asking the user to select another network on the phone for roaming in. This sometimes fix the problem, Mandag 19 oktober 2009 14:13:53 skrev Jinson : Got stuck with this problem again today. See my logs attached.Somebody received 150 Messages. This log is for a particular number which the message was retired nearly 150 times and I can not find anything on the bearerbox access log for this number. Thanks Jinson Abraham On Fri, Sep 25, 2009 at 3:57 PM, Nikos Balkanas nbalka...@gmail.com wrote: Do you know that you can change log-level on the fly from the http admin interface? Nikos On Fri, Sep 25, 2009 at 12:59 PM, Jinson jin...@mobme.in wrote: Will post it soon. Just enabled access logs and set log level to 0. Thanks Jinson On Fri, Sep 25, 2009 at 3:20 PM, Nikos Balkanas nbalka...@gmail.comwrote: Hi, Can you please post relvant bb logs (access + aplication) showing the problem? BR, Nikos On Fri, Sep 25, 2009 at 12:46 PM, Jinson jin...@mobme.in wrote: Hello Users, Seems like reties are still happening at my end. is there anything else to configure other than *sms-resend-retry = 0* Thanks Jinson On Wed, Sep 23, 2009 at 9:53 AM, Jinson jin...@mobme.in wrote: Yes. DLRs are getting failed. But this should solve my problem of retries for the time being. Thanks JJinson 2009/9/23 Nikos Balkanas nbalka...@gmail.com Yeap. That should do it. However, it will be logged as an error, and the DLR will probably be discarded. BR, Nikos - Original Message - *From:* Jinson jin...@mobme.in *To:* Nikos Balkanas nbalka...@gmail.com *Cc:* users users@kannel.org *Sent:* Tuesday, September 22, 2009 1:56 PM *Subject:* Re: How to stop message retries Hi, I got the point. The provider fail to send ACK sometimes. They are still not able to solve the issue. My current concern is to stop retries from Kannel, other than setting the wait-ack-expire. I set the sms-resend-retry = 0, that means no messages will be retried...rite? 2009/9/18 Nikos Balkanas nbalka...@gmail.com Hi, You probably want to say that kannel was not able to submit messages and queued up heavily. That is accurate, unless the SMSc sends an ACK, kannel won't remove SMS from Q. However, with 2, it won't try to resend it either. Note that this doesn't mean that the SMS was not sent. Just that kannel is pending on an ACK. So what's the deal? Your SMSc never sends ACKs? You may want to talk to them. Otherwise check also flow-control and window. But at the end, you will need to get an ACK from them, for SMPP to work. BR, Nikos - Original Message - *From:* Jinson jin...@mobme.in *To:* Nikos Balkanas nbalka...@gmail.com *Cc:* users users@kannel.org *Sent:* Friday, September 18, 2009 11:16 AM *Subject:* Re: How to stop message retries I tried wait-ack-expire = 0x02 before, but the SMSC was not able to submit messages and queued up heavily. Something to do with sms-resend-retry in core group? Thanks Jinson MobME storms into Emerging 50 Companies in India by Nasscom 2009/9/18 Nikos Balkanas nbalka...@gmail.com Hi, There are 2 options in SMPP configuration that will solve your problem: wait-ack wait-ack-expire Please read User guide on how to use them. BR, Nikos - Original Message - *From:* Jinson jin...@mobme.in *To:* users users@kannel.org *Sent:* Friday, September 18, 2009 8:53 AM *Subject:* How to stop message retries Hello , Im getting the following warning very frequently *2009-09-18 05:48:48 [18220] [10] WARNING: SMPP[SMPP1]: Not ACKED message found, will retransmit. SENT93sec. ago, SEQ94598, DST* * * Is there any way to stop the resending completely, Some people are getting messages more than twice. I have the following line in my core group. sms-resend-retry = 1 Thanks Jinson Abraham MobME Wireless Solutions Pvt. Ltd Cochin +91 4846492646 MobME storms into Emerging 50 Companies in India by Nasscom -- Arne K. Haaje | www.drx.no T: 69 51 15 52 | M: 92 88 44 66
Re: How to stop message retries
* sms-resend-retry = 0 * should stop the retries rite? Thanks Jinson Abraham On Mon, Oct 19, 2009 at 6:02 PM, Arne K. Haaje a...@drlinux.no wrote: This sometimes happen if the user is in a foreign network, like when travelling. The message get delivered, but the SMSC that you are using does not receive an ack from the phone that message is delivered. So, it retries the message. You can try asking the user to select another network on the phone for roaming in. This sometimes fix the problem, Mandag 19 oktober 2009 14:13:53 skrev Jinson : Got stuck with this problem again today. See my logs attached.Somebody received 150 Messages. This log is for a particular number which the message was retired nearly 150 times and I can not find anything on the bearerbox access log for this number. Thanks Jinson Abraham On Fri, Sep 25, 2009 at 3:57 PM, Nikos Balkanas nbalka...@gmail.com wrote: Do you know that you can change log-level on the fly from the http admin interface? Nikos On Fri, Sep 25, 2009 at 12:59 PM, Jinson jin...@mobme.in wrote: Will post it soon. Just enabled access logs and set log level to 0. Thanks Jinson On Fri, Sep 25, 2009 at 3:20 PM, Nikos Balkanas nbalka...@gmail.comwrote: Hi, Can you please post relvant bb logs (access + aplication) showing the problem? BR, Nikos On Fri, Sep 25, 2009 at 12:46 PM, Jinson jin...@mobme.in wrote: Hello Users, Seems like reties are still happening at my end. is there anything else to configure other than *sms-resend-retry = 0* Thanks Jinson On Wed, Sep 23, 2009 at 9:53 AM, Jinson jin...@mobme.in wrote: Yes. DLRs are getting failed. But this should solve my problem of retries for the time being. Thanks JJinson 2009/9/23 Nikos Balkanas nbalka...@gmail.com Yeap. That should do it. However, it will be logged as an error, and the DLR will probably be discarded. BR, Nikos - Original Message - *From:* Jinson jin...@mobme.in *To:* Nikos Balkanas nbalka...@gmail.com *Cc:* users users@kannel.org *Sent:* Tuesday, September 22, 2009 1:56 PM *Subject:* Re: How to stop message retries Hi, I got the point. The provider fail to send ACK sometimes. They are still not able to solve the issue. My current concern is to stop retries from Kannel, other than setting the wait-ack-expire. I set the sms-resend-retry = 0, that means no messages will be retried...rite? 2009/9/18 Nikos Balkanas nbalka...@gmail.com Hi, You probably want to say that kannel was not able to submit messages and queued up heavily. That is accurate, unless the SMSc sends an ACK, kannel won't remove SMS from Q. However, with 2, it won't try to resend it either. Note that this doesn't mean that the SMS was not sent. Just that kannel is pending on an ACK. So what's the deal? Your SMSc never sends ACKs? You may want to talk to them. Otherwise check also flow-control and window. But at the end, you will need to get an ACK from them, for SMPP to work. BR, Nikos - Original Message - *From:* Jinson jin...@mobme.in *To:* Nikos Balkanas nbalka...@gmail.com *Cc:* users users@kannel.org *Sent:* Friday, September 18, 2009 11:16 AM *Subject:* Re: How to stop message retries I tried wait-ack-expire = 0x02 before, but the SMSC was not able to submit messages and queued up heavily. Something to do with sms-resend-retry in core group? Thanks Jinson MobME storms into Emerging 50 Companies in India by Nasscom 2009/9/18 Nikos Balkanas nbalka...@gmail.com Hi, There are 2 options in SMPP configuration that will solve your problem: wait-ack wait-ack-expire Please read User guide on how to use them. BR, Nikos - Original Message - *From:* Jinson jin...@mobme.in *To:* users users@kannel.org *Sent:* Friday, September 18, 2009 8:53 AM *Subject:* How to stop message retries Hello , Im getting the following warning very frequently *2009-09-18 05:48:48 [18220] [10] WARNING: SMPP[SMPP1]: Not ACKED message found, will retransmit. SENT93sec. ago, SEQ94598, DST* * * Is there any way to stop the resending completely, Some people are getting messages more than twice. I have the following line in my core group. sms-resend-retry = 1 Thanks Jinson Abraham MobME Wireless Solutions Pvt. Ltd Cochin +91 4846492646 MobME storms into Emerging 50 Companies in India by Nasscom -- Arne K. Haaje | www.drx.no T: 69 51 15 52 | M: 92 88 44 66
Re: getting delivery report: delivery failure
If available, kannel uses the optional value network_error (or something like that) prior to digging into the message text. Regards, Alejandro On Mon, Oct 19, 2009 at 1:49 PM, Latitude Test latitude...@googlemail.comwrote: Adding to it, I saw Kannel sending me correct DLRs with another SMSC and in the logs I saw the following: dlvrd:001 sub:001 Text:. The mendatory field Text does not contain any useful info here. How kannel knows the status of the message then? Seems it uses the optional fields which are sub and dlvrd. Please confirm. Thanks. -- Forwarded message -- From: Latitude Test latitude...@googlemail.com Date: Mon, Oct 19, 2009 at 1:31 PM Subject: Re: getting delivery report: delivery failure To: users users@kannel.org, Nikos Balkanas nbalka...@gmail.com Thanks Nikos. But I do get stat field which contains some useful info. Also I felt that the format is vendor specific and the missing fields are not mandatory. Quote from http://www.nowsms.com/discus/messages/1/SMPP_v3_4_Issue1_2-24857.pdf: The informational content of an SMSC Delivery Receipt may be inserted into the short_message parameter of the deliver_sm operation. The format for this Delivery Receipt message is SMSC* vendor specific* but following is a typical example of Delivery Receipt report. “id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .” Regards. 2009/10/19 Nikos Balkanas n...@amdtelecom.net Hi, It seems that your SMSc is sending out the wrong DLR format. According to SMPP 3.4 specs: “ *id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .”* Several optional fields (sub, dlvrd, err) are missing, but also a required field: Text. Without it kannel cannot understand the DLR. Contact your SMSc about it. They should comply to the SMPP spec. BR, Nikos - Original Message - *From:* Latitude Test latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *Sent:* Monday, October 19, 2009 12:26 PM *Subject:* Re: getting delivery report: delivery failure Apologies for not sending the complete PDU before. Kindly review the complete PDU and guide. Thanks. ... [7] DEBUG: SMPP[abc1]: Got PDU: [7] DEBUG: SMPP PDU 8174bc0 dump: [7] DEBUG: type_name: enquire_link_resp [7] DEBUG: command_id: 2147483669 = 0x8015 [7] DEBUG: command_status: 0 = 0x [7] DEBUG: sequence_number: 201551 = 0x0003134f [7] DEBUG: SMPP PDU dump ends. [11] DEBUG: SMPP[abc3]: Sending enquire link: [11] DEBUG: SMPP PDU 8174bc0 dump: [11] DEBUG: type_name: enquire_link [11] DEBUG: command_id: 21 = 0x0015 [11] DEBUG: command_status: 0 = 0x [11] DEBUG: sequence_number: 201628 = 0x0003139c [11] DEBUG: SMPP PDU dump ends. [11] DEBUG: SMPP[abc3]: Got PDU: [11] DEBUG: SMPP PDU 8174bc0 dump: [11] DEBUG: type_name: enquire_link_resp [11] DEBUG: command_id: 2147483669 = 0x8015 [11] DEBUG: command_status: 0 = 0x [11] DEBUG: sequence_number: 201628 = 0x0003139c [11] DEBUG: SMPP PDU dump ends. [11] DEBUG: SMPP[abc3]: Got PDU: [11] DEBUG: SMPP PDU 8174bc0 dump: [11] DEBUG: type_name: deliver_sm [11] DEBUG: command_id: 5 = 0x0005 [11] DEBUG: command_status: 0 = 0x [11] DEBUG: sequence_number: 2453831019 = 0x92427d6b [11] DEBUG: service_type: NULL [11] DEBUG: source_addr_ton: 1 = 0x0001 [11] DEBUG: source_addr_npi: 1 = 0x0001 [11] DEBUG: source_addr: 989352034309 [11] DEBUG: dest_addr_ton: 0 = 0x [11] DEBUG: dest_addr_npi: 1 = 0x0001 [11] DEBUG: destination_addr: 8601001 [11] DEBUG: esm_class: 4 = 0x0004 [11] DEBUG: protocol_id: 0 = 0x [11] DEBUG: priority_flag: 0 = 0x [11] DEBUG: schedule_delivery_time: NULL [11] DEBUG: validity_period: NULL [11] DEBUG: registered_delivery: 0 = 0x [11] DEBUG: replace_if_present_flag: 0 = 0x [11] DEBUG: data_coding: 0 = 0x [11] DEBUG: sm_default_msg_id: 0 = 0x [11] DEBUG: sm_length: 70 = 0x0046 [11] DEBUG: short_message: [11] DEBUG:Octet string at 8129850: [11] DEBUG: len: 70 [11] DEBUG: size: 71 [11] DEBUG: immutable: 0 [11] DEBUG: data: 69 64 3a 32 34 35 31 37 33 33 31 33 34 20 73 75 id:2451733134 su [11] DEBUG: data: 62 6d 69 74 20 64 61 74 65 3a 30 39 31 30 31 33 bmit date:091013 [11] DEBUG: data: 30 37 30 34 20 64 6f 6e 65 20 64 61 74 65 3a 30 0704 done date:0 [11] DEBUG: data: 39 31 30 31 33 30 39 35 31 20 73 74 61 74 3a 44 910130951 stat:D [11] DEBUG: data: 45 4c 49 56 52 44 ELIVRD [11] DEBUG:Octet string dump ends. [11] DEBUG: SMPP PDU dump ends. [11] DEBUG: SMPP[abc3] handle_pdu, got DLR [11] DEBUG: SMPP[abc3]: Couldnot parse DLR string sscanf way,fallback to old way. Please report!
Re: getting delivery report: delivery failure
Still confused about mandatory fields. Can someone tell me which fields are used by Kannel to return the message status? Regards. On Mon, Oct 19, 2009 at 3:07 PM, Alejandro Guerrieri alejandro.guerri...@gmail.com wrote: If available, kannel uses the optional value network_error (or something like that) prior to digging into the message text. Regards, Alejandro On Mon, Oct 19, 2009 at 1:49 PM, Latitude Test latitude...@googlemail.com wrote: Adding to it, I saw Kannel sending me correct DLRs with another SMSC and in the logs I saw the following: dlvrd:001 sub:001 Text:. The mendatory field Text does not contain any useful info here. How kannel knows the status of the message then? Seems it uses the optional fields which are sub and dlvrd. Please confirm. Thanks. -- Forwarded message -- From: Latitude Test latitude...@googlemail.com Date: Mon, Oct 19, 2009 at 1:31 PM Subject: Re: getting delivery report: delivery failure To: users users@kannel.org, Nikos Balkanas nbalka...@gmail.com Thanks Nikos. But I do get stat field which contains some useful info. Also I felt that the format is vendor specific and the missing fields are not mandatory. Quote from http://www.nowsms.com/discus/messages/1/SMPP_v3_4_Issue1_2-24857.pdf: The informational content of an SMSC Delivery Receipt may be inserted into the short_message parameter of the deliver_sm operation. The format for this Delivery Receipt message is SMSC* vendor specific* but following is a typical example of Delivery Receipt report. “id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .” Regards. 2009/10/19 Nikos Balkanas n...@amdtelecom.net Hi, It seems that your SMSc is sending out the wrong DLR format. According to SMPP 3.4 specs: “ *id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .”* Several optional fields (sub, dlvrd, err) are missing, but also a required field: Text. Without it kannel cannot understand the DLR. Contact your SMSc about it. They should comply to the SMPP spec. BR, Nikos - Original Message - *From:* Latitude Test latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *Sent:* Monday, October 19, 2009 12:26 PM *Subject:* Re: getting delivery report: delivery failure Apologies for not sending the complete PDU before. Kindly review the complete PDU and guide. Thanks. ... [7] DEBUG: SMPP[abc1]: Got PDU: [7] DEBUG: SMPP PDU 8174bc0 dump: [7] DEBUG: type_name: enquire_link_resp [7] DEBUG: command_id: 2147483669 = 0x8015 [7] DEBUG: command_status: 0 = 0x [7] DEBUG: sequence_number: 201551 = 0x0003134f [7] DEBUG: SMPP PDU dump ends. [11] DEBUG: SMPP[abc3]: Sending enquire link: [11] DEBUG: SMPP PDU 8174bc0 dump: [11] DEBUG: type_name: enquire_link [11] DEBUG: command_id: 21 = 0x0015 [11] DEBUG: command_status: 0 = 0x [11] DEBUG: sequence_number: 201628 = 0x0003139c [11] DEBUG: SMPP PDU dump ends. [11] DEBUG: SMPP[abc3]: Got PDU: [11] DEBUG: SMPP PDU 8174bc0 dump: [11] DEBUG: type_name: enquire_link_resp [11] DEBUG: command_id: 2147483669 = 0x8015 [11] DEBUG: command_status: 0 = 0x [11] DEBUG: sequence_number: 201628 = 0x0003139c [11] DEBUG: SMPP PDU dump ends. [11] DEBUG: SMPP[abc3]: Got PDU: [11] DEBUG: SMPP PDU 8174bc0 dump: [11] DEBUG: type_name: deliver_sm [11] DEBUG: command_id: 5 = 0x0005 [11] DEBUG: command_status: 0 = 0x [11] DEBUG: sequence_number: 2453831019 = 0x92427d6b [11] DEBUG: service_type: NULL [11] DEBUG: source_addr_ton: 1 = 0x0001 [11] DEBUG: source_addr_npi: 1 = 0x0001 [11] DEBUG: source_addr: 989352034309 [11] DEBUG: dest_addr_ton: 0 = 0x [11] DEBUG: dest_addr_npi: 1 = 0x0001 [11] DEBUG: destination_addr: 8601001 [11] DEBUG: esm_class: 4 = 0x0004 [11] DEBUG: protocol_id: 0 = 0x [11] DEBUG: priority_flag: 0 = 0x [11] DEBUG: schedule_delivery_time: NULL [11] DEBUG: validity_period: NULL [11] DEBUG: registered_delivery: 0 = 0x [11] DEBUG: replace_if_present_flag: 0 = 0x [11] DEBUG: data_coding: 0 = 0x [11] DEBUG: sm_default_msg_id: 0 = 0x [11] DEBUG: sm_length: 70 = 0x0046 [11] DEBUG: short_message: [11] DEBUG:Octet string at 8129850: [11] DEBUG: len: 70 [11] DEBUG: size: 71 [11] DEBUG: immutable: 0 [11] DEBUG: data: 69 64 3a 32 34 35 31 37 33 33 31 33 34 20 73 75 id:2451733134 su [11] DEBUG: data: 62 6d 69 74 20 64 61 74 65 3a 30 39 31 30 31 33 bmit date:091013 [11] DEBUG: data: 30 37 30 34 20 64 6f 6e 65 20 64 61 74 65 3a 30 0704 done date:0 [11] DEBUG: data: 39 31 30 31 33 30 39 35 31 20 73 74 61 74 3a 44 910130951 stat:D [11] DEBUG: data: 45 4c 49 56
Re: Help me about Kannel + HTTP connection
Sorry, but I think you have not understood my previous email. The intention was never to attack anyone, but I do send me a thousand questions and reading the user guide, a document that I have read several times and still can not find the answers. If I thought that the Guide or the community will not be productive, not write to it, on the contrary, only need my software to work and therefore ask the questions because I dont find the answers in the User Guide. I hope he had not hurt anyone's feelings, but if I expect more to help new developers. - Nikos Balkanas nbalka...@gmail.com escribió: | Hi, I have rewritten the whole wap code for another (commercial) project. However, let's pretend, as you say, that I don't know how to answer. Since you know the User's Guide by heart, please enlighten me: 1) What are the required modules to run wap? 2) What variables in the core group are needed to enable wap? 3) What groups do you need to configure aforementioned modules? 4) In what page in the guide is an example wap... configuration, and in what a PPG? PS. A lot of good people have contributed extra effort to maintain this guide. I trust that this is enough, and that you respect them for what they did, by not asking them to read it to you as well. BR, Nikos | - Original Message - | From: David Gerardo | To: Nikos Balkanas | Cc: users | Sent: Thursday, October 15, 2009 10:09 PM | Subject: Re: Help me about Kannel + HTTP connection | | excuse me Kannel community but every time I ask a question send me to see the user guide, I am a programmer and software developer and well that is the user guide. If I make a question is precisely because they find the answer in the materials provided by the community, so if you do not know the answers, understand, but no more to send me the user guide that I almost know it by heart. Sorry for the message but it is certainly unpleasant to all the questions I am doing so visit rebuts materials. | | - Nikos Balkanas n...@amdtelecom.net escribiΓ³: | | Hi, There is an excellent how-to and examples in the User's Guide. You can download it from the site. If you have specific questions about what you read we will be glad to help you. BR, Nikos | | - Original Message - | | From: David Gerardo | | To: users | | Sent: Thursday, October 15, 2009 8:16 PM | | Subject: Help me about Kannel + HTTP connection | | | | Gentlemen, please help urgently. I have a WAP terminal (it is a trunki) that connects to Kannel to review a website that is hosted on another computer. The Kannel creates bridges between the terminal and host the site. I need to know the file kannel.conf, What do I have to configure? The IP address of the computer that is hosting the Kannel is 10.31.18.4 and the IP address where is the site that I want to show in the terminal is on 10.31.18.5. Can you tell me the settings I put in the kannel.conf? | | Thank you for your support. | | | | -- | | | | | | -- | | El universitario de estos tiempos estΓ΅ llamado a convertir su espacio en un espacio productivo | -- El universitario de estos tiempos está llamado a convertir su espacio en un espacio productivo
Re: getting delivery report: delivery failure
For regular messages, on SMPP the status is inferred from the submit_sm_resp PDU. If you have DLR's active, this also creates the first fake DLR (internally created by kannel without needing the SMSC to have DLR's activated). For SMSC-created DLR's (which are kind of special MO's also handled over deliver_sm PDU's), the DLR status is first attempted by using the network_error_code tag. If that's not available, then the DLR text message is parsed with sscanf to try to infer the status from there. However, kannel expects a specific (not very flexible) format for the DLR text. If the format differs, sscanf won't be able to extract the information and your DLR will fail. Hope this helps clarifying how it works. Regards, Alejandro On Mon, Oct 19, 2009 at 3:15 PM, Latitude Test latitude...@googlemail.comwrote: Still confused about mandatory fields. Can someone tell me which fields are used by Kannel to return the message status? Regards. On Mon, Oct 19, 2009 at 3:07 PM, Alejandro Guerrieri alejandro.guerri...@gmail.com wrote: If available, kannel uses the optional value network_error (or something like that) prior to digging into the message text. Regards, Alejandro On Mon, Oct 19, 2009 at 1:49 PM, Latitude Test latitude.de@ googlemail.com wrote: Adding to it, I saw Kannel sending me correct DLRs with another SMSC and in the logs I saw the following: dlvrd:001 sub:001 Text:. The mendatory field Text does not contain any useful info here. How kannel knows the status of the message then? Seems it uses the optional fields which are sub and dlvrd. Please confirm. Thanks. -- Forwarded message -- From: Latitude Test latitude...@googlemail.com Date: Mon, Oct 19, 2009 at 1:31 PM Subject: Re: getting delivery report: delivery failure To: users users@kannel.org, Nikos Balkanas nbalka...@gmail.com Thanks Nikos. But I do get stat field which contains some useful info. Also I felt that the format is vendor specific and the missing fields are not mandatory. Quote from http://www.nowsms.com/discus/messages/1/SMPP_v3_4_Issue1_2-24857.pdf: The informational content of an SMSC Delivery Receipt may be inserted into the short_message parameter of the deliver_sm operation. The format for this Delivery Receipt message is SMSC* vendor specific* but following is a typical example of Delivery Receipt report. “id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .” Regards. 2009/10/19 Nikos Balkanas n...@amdtelecom.net Hi, It seems that your SMSc is sending out the wrong DLR format. According to SMPP 3.4 specs: “ *id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .”* Several optional fields (sub, dlvrd, err) are missing, but also a required field: Text. Without it kannel cannot understand the DLR. Contact your SMSc about it. They should comply to the SMPP spec. BR, Nikos - Original Message - *From:* Latitude Test latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *Sent:* Monday, October 19, 2009 12:26 PM *Subject:* Re: getting delivery report: delivery failure Apologies for not sending the complete PDU before. Kindly review the complete PDU and guide. Thanks. ... [7] DEBUG: SMPP[abc1]: Got PDU: [7] DEBUG: SMPP PDU 8174bc0 dump: [7] DEBUG: type_name: enquire_link_resp [7] DEBUG: command_id: 2147483669 = 0x8015 [7] DEBUG: command_status: 0 = 0x [7] DEBUG: sequence_number: 201551 = 0x0003134f [7] DEBUG: SMPP PDU dump ends. [11] DEBUG: SMPP[abc3]: Sending enquire link: [11] DEBUG: SMPP PDU 8174bc0 dump: [11] DEBUG: type_name: enquire_link [11] DEBUG: command_id: 21 = 0x0015 [11] DEBUG: command_status: 0 = 0x [11] DEBUG: sequence_number: 201628 = 0x0003139c [11] DEBUG: SMPP PDU dump ends. [11] DEBUG: SMPP[abc3]: Got PDU: [11] DEBUG: SMPP PDU 8174bc0 dump: [11] DEBUG: type_name: enquire_link_resp [11] DEBUG: command_id: 2147483669 = 0x8015 [11] DEBUG: command_status: 0 = 0x [11] DEBUG: sequence_number: 201628 = 0x0003139c [11] DEBUG: SMPP PDU dump ends. [11] DEBUG: SMPP[abc3]: Got PDU: [11] DEBUG: SMPP PDU 8174bc0 dump: [11] DEBUG: type_name: deliver_sm [11] DEBUG: command_id: 5 = 0x0005 [11] DEBUG: command_status: 0 = 0x [11] DEBUG: sequence_number: 2453831019 = 0x92427d6b [11] DEBUG: service_type: NULL [11] DEBUG: source_addr_ton: 1 = 0x0001 [11] DEBUG: source_addr_npi: 1 = 0x0001 [11] DEBUG: source_addr: 989352034309 [11] DEBUG: dest_addr_ton: 0 = 0x [11] DEBUG: dest_addr_npi: 1 = 0x0001 [11] DEBUG: destination_addr: 8601001 [11] DEBUG: esm_class: 4 = 0x0004 [11] DEBUG: protocol_id: 0 = 0x [11] DEBUG: priority_flag: 0 = 0x [11] DEBUG: schedule_delivery_time: NULL
Re: getting delivery report: delivery failure
Hi, Indeed there are some optional DLR fields that are vendor specific. However, required fields need to be there. I could provide a patch for your case, but I don't want to do it by breaking up SMPP compatibility. What the hell? Try this. I can't promise that it will be accepted, but it is worth a try. Let me know how it works. I can not test it. BR, Nikos - Original Message - From: Latitude Test To: users ; Nikos Balkanas Sent: Monday, October 19, 2009 2:31 PM Subject: Re: getting delivery report: delivery failure Thanks Nikos. But I do get stat field which contains some useful info. Also I felt that the format is vendor specific and the missing fields are not mandatory. Quote from http://www.nowsms.com/discus/messages/1/SMPP_v3_4_Issue1_2-24857.pdf: The informational content of an SMSC Delivery Receipt may be inserted into the short_message parameter of the deliver_sm operation. The format for this Delivery Receipt message is SMSC vendor specific but following is a typical example of Delivery Receipt report. “id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .” Regards. 2009/10/19 Nikos Balkanas n...@amdtelecom.net Hi, It seems that your SMSc is sending out the wrong DLR format. According to SMPP 3.4 specs: “ id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .” Several optional fields (sub, dlvrd, err) are missing, but also a required field: Text. Without it kannel cannot understand the DLR. Contact your SMSc about it. They should comply to the SMPP spec. BR, Nikos - Original Message - From: Latitude Test To: users ; Nikos Balkanas Sent: Monday, October 19, 2009 12:26 PM Subject: Re: getting delivery report: delivery failure Apologies for not sending the complete PDU before. Kindly review the complete PDU and guide. Thanks. ... [7] DEBUG: SMPP[abc1]: Got PDU: [7] DEBUG: SMPP PDU 8174bc0 dump: [7] DEBUG: type_name: enquire_link_resp [7] DEBUG: command_id: 2147483669 = 0x8015 [7] DEBUG: command_status: 0 = 0x [7] DEBUG: sequence_number: 201551 = 0x0003134f [7] DEBUG: SMPP PDU dump ends. [11] DEBUG: SMPP[abc3]: Sending enquire link: [11] DEBUG: SMPP PDU 8174bc0 dump: [11] DEBUG: type_name: enquire_link [11] DEBUG: command_id: 21 = 0x0015 [11] DEBUG: command_status: 0 = 0x [11] DEBUG: sequence_number: 201628 = 0x0003139c [11] DEBUG: SMPP PDU dump ends. [11] DEBUG: SMPP[abc3]: Got PDU: [11] DEBUG: SMPP PDU 8174bc0 dump: [11] DEBUG: type_name: enquire_link_resp [11] DEBUG: command_id: 2147483669 = 0x8015 [11] DEBUG: command_status: 0 = 0x [11] DEBUG: sequence_number: 201628 = 0x0003139c [11] DEBUG: SMPP PDU dump ends. [11] DEBUG: SMPP[abc3]: Got PDU: [11] DEBUG: SMPP PDU 8174bc0 dump: [11] DEBUG: type_name: deliver_sm [11] DEBUG: command_id: 5 = 0x0005 [11] DEBUG: command_status: 0 = 0x [11] DEBUG: sequence_number: 2453831019 = 0x92427d6b [11] DEBUG: service_type: NULL [11] DEBUG: source_addr_ton: 1 = 0x0001 [11] DEBUG: source_addr_npi: 1 = 0x0001 [11] DEBUG: source_addr: 989352034309 [11] DEBUG: dest_addr_ton: 0 = 0x [11] DEBUG: dest_addr_npi: 1 = 0x0001 [11] DEBUG: destination_addr: 8601001 [11] DEBUG: esm_class: 4 = 0x0004 [11] DEBUG: protocol_id: 0 = 0x [11] DEBUG: priority_flag: 0 = 0x [11] DEBUG: schedule_delivery_time: NULL [11] DEBUG: validity_period: NULL [11] DEBUG: registered_delivery: 0 = 0x [11] DEBUG: replace_if_present_flag: 0 = 0x [11] DEBUG: data_coding: 0 = 0x [11] DEBUG: sm_default_msg_id: 0 = 0x [11] DEBUG: sm_length: 70 = 0x0046 [11] DEBUG: short_message: [11] DEBUG:Octet string at 8129850: [11] DEBUG: len: 70 [11] DEBUG: size: 71 [11] DEBUG: immutable: 0 [11] DEBUG: data: 69 64 3a 32 34 35 31 37 33 33 31 33 34 20 73 75 id:2451733134 su [11] DEBUG: data: 62 6d 69 74 20 64 61 74 65 3a 30 39 31 30 31 33 bmit date:091013 [11] DEBUG: data: 30 37 30 34 20 64 6f 6e 65 20 64 61 74 65 3a 30 0704 done date:0 [11] DEBUG: data: 39 31 30 31 33 30 39 35 31 20 73 74 61 74 3a 44 910130951 stat:D [11] DEBUG: data: 45 4c 49 56 52 44 ELIVRD [11] DEBUG:Octet string dump ends. [11] DEBUG: SMPP PDU dump ends. [11] DEBUG: SMPP[abc3] handle_pdu, got DLR [11] DEBUG: SMPP[abc3]:
Re: getting delivery report: delivery failure
Yes, but it is required to be there. I am not making the spec. Nikos - Original Message - From: Latitude Test To: users ; Nikos Balkanas Sent: Monday, October 19, 2009 2:49 PM Subject: Fwd: getting delivery report: delivery failure Adding to it, I saw Kannel sending me correct DLRs with another SMSC and in the logs I saw the following: dlvrd:001 sub:001 Text:. The mendatory field Text does not contain any useful info here. How kannel knows the status of the message then? Seems it uses the optional fields which are sub and dlvrd. Please confirm. Thanks. -- Forwarded message -- From: Latitude Test latitude...@googlemail.com Date: Mon, Oct 19, 2009 at 1:31 PM Subject: Re: getting delivery report: delivery failure To: users users@kannel.org, Nikos Balkanas nbalka...@gmail.com Thanks Nikos. But I do get stat field which contains some useful info. Also I felt that the format is vendor specific and the missing fields are not mandatory. Quote from http://www.nowsms.com/discus/messages/1/SMPP_v3_4_Issue1_2-24857.pdf: The informational content of an SMSC Delivery Receipt may be inserted into the short_message parameter of the deliver_sm operation. The format for this Delivery Receipt message is SMSC vendor specific but following is a typical example of Delivery Receipt report. “id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .” Regards. 2009/10/19 Nikos Balkanas n...@amdtelecom.net Hi, It seems that your SMSc is sending out the wrong DLR format. According to SMPP 3.4 specs: “ id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .” Several optional fields (sub, dlvrd, err) are missing, but also a required field: Text. Without it kannel cannot understand the DLR. Contact your SMSc about it. They should comply to the SMPP spec. BR, Nikos - Original Message - From: Latitude Test To: users ; Nikos Balkanas Sent: Monday, October 19, 2009 12:26 PM Subject: Re: getting delivery report: delivery failure Apologies for not sending the complete PDU before. Kindly review the complete PDU and guide. Thanks. ... [7] DEBUG: SMPP[abc1]: Got PDU: [7] DEBUG: SMPP PDU 8174bc0 dump: [7] DEBUG: type_name: enquire_link_resp [7] DEBUG: command_id: 2147483669 = 0x8015 [7] DEBUG: command_status: 0 = 0x [7] DEBUG: sequence_number: 201551 = 0x0003134f [7] DEBUG: SMPP PDU dump ends. [11] DEBUG: SMPP[abc3]: Sending enquire link: [11] DEBUG: SMPP PDU 8174bc0 dump: [11] DEBUG: type_name: enquire_link [11] DEBUG: command_id: 21 = 0x0015 [11] DEBUG: command_status: 0 = 0x [11] DEBUG: sequence_number: 201628 = 0x0003139c [11] DEBUG: SMPP PDU dump ends. [11] DEBUG: SMPP[abc3]: Got PDU: [11] DEBUG: SMPP PDU 8174bc0 dump: [11] DEBUG: type_name: enquire_link_resp [11] DEBUG: command_id: 2147483669 = 0x8015 [11] DEBUG: command_status: 0 = 0x [11] DEBUG: sequence_number: 201628 = 0x0003139c [11] DEBUG: SMPP PDU dump ends. [11] DEBUG: SMPP[abc3]: Got PDU: [11] DEBUG: SMPP PDU 8174bc0 dump: [11] DEBUG: type_name: deliver_sm [11] DEBUG: command_id: 5 = 0x0005 [11] DEBUG: command_status: 0 = 0x [11] DEBUG: sequence_number: 2453831019 = 0x92427d6b [11] DEBUG: service_type: NULL [11] DEBUG: source_addr_ton: 1 = 0x0001 [11] DEBUG: source_addr_npi: 1 = 0x0001 [11] DEBUG: source_addr: 989352034309 [11] DEBUG: dest_addr_ton: 0 = 0x [11] DEBUG: dest_addr_npi: 1 = 0x0001 [11] DEBUG: destination_addr: 8601001 [11] DEBUG: esm_class: 4 = 0x0004 [11] DEBUG: protocol_id: 0 = 0x [11] DEBUG: priority_flag: 0 = 0x [11] DEBUG: schedule_delivery_time: NULL [11] DEBUG: validity_period: NULL [11] DEBUG: registered_delivery: 0 = 0x [11] DEBUG: replace_if_present_flag: 0 = 0x [11] DEBUG: data_coding: 0 = 0x [11] DEBUG: sm_default_msg_id: 0 = 0x [11] DEBUG: sm_length: 70 = 0x0046 [11] DEBUG: short_message: [11] DEBUG:Octet string at 8129850: [11] DEBUG: len: 70 [11] DEBUG: size: 71 [11] DEBUG: immutable: 0 [11] DEBUG: data: 69 64 3a 32 34 35 31 37 33 33 31 33 34 20 73 75 id:2451733134 su [11] DEBUG: data: 62 6d 69 74 20 64 61 74 65 3a 30 39 31 30 31 33 bmit date:091013 [11] DEBUG: data: 30 37 30 34 20 64 6f 6e 65 20 64 61 74 65 3a 30 0704 done date:0 [11] DEBUG: data: 39 31 30
Re: getting delivery report: delivery failure
Are you saying dlvrd and sub are mandatory for Kannel? 2009/10/19 Nikos Balkanas n...@amdtelecom.net Yes, but it is required to be there. I am not making the spec. Nikos - Original Message - *From:* Latitude Test latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *Sent:* Monday, October 19, 2009 2:49 PM *Subject:* Fwd: getting delivery report: delivery failure Adding to it, I saw Kannel sending me correct DLRs with another SMSC and in the logs I saw the following: dlvrd:001 sub:001 Text:. The mendatory field Text does not contain any useful info here. How kannel knows the status of the message then? Seems it uses the optional fields which are sub and dlvrd. Please confirm. Thanks. -- Forwarded message -- From: Latitude Test latitude.de@ latitude...@googlemail.com googlemail.com Date: Mon, Oct 19, 2009 at 1:31 PM Subject: Re: getting delivery report: delivery failure To: users users@kannel.org, Nikos Balkanas nbalka...@gmail.com Thanks Nikos. But I do get stat field which contains some useful info. Also I felt that the format is vendor specific and the missing fields are not mandatory. Quote from http://www.nowsms.com/discus/messages/1/SMPP_v3_4_Issue1_2-24857.pdf: The informational content of an SMSC Delivery Receipt may be inserted into the short_message parameter of the deliver_sm operation. The format for this Delivery Receipt message is SMSC* vendor specific* but following is a typical example of Delivery Receipt report. “id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .” Regards. 2009/10/19 Nikos Balkanas n...@amdtelecom.net Hi, It seems that your SMSc is sending out the wrong DLR format. According to SMPP 3.4 specs: “ *id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .”* Several optional fields (sub, dlvrd, err) are missing, but also a required field: Text. Without it kannel cannot understand the DLR. Contact your SMSc about it. They should comply to the SMPP spec. BR, Nikos - Original Message - *From:* Latitude Test latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *Sent:* Monday, October 19, 2009 12:26 PM *Subject:* Re: getting delivery report: delivery failure Apologies for not sending the complete PDU before. Kindly review the complete PDU and guide. Thanks. ... [7] DEBUG: SMPP[abc1]: Got PDU: [7] DEBUG: SMPP PDU 8174bc0 dump: [7] DEBUG: type_name: enquire_link_resp [7] DEBUG: command_id: 2147483669 = 0x8015 [7] DEBUG: command_status: 0 = 0x [7] DEBUG: sequence_number: 201551 = 0x0003134f [7] DEBUG: SMPP PDU dump ends. [11] DEBUG: SMPP[abc3]: Sending enquire link: [11] DEBUG: SMPP PDU 8174bc0 dump: [11] DEBUG: type_name: enquire_link [11] DEBUG: command_id: 21 = 0x0015 [11] DEBUG: command_status: 0 = 0x [11] DEBUG: sequence_number: 201628 = 0x0003139c [11] DEBUG: SMPP PDU dump ends. [11] DEBUG: SMPP[abc3]: Got PDU: [11] DEBUG: SMPP PDU 8174bc0 dump: [11] DEBUG: type_name: enquire_link_resp [11] DEBUG: command_id: 2147483669 = 0x8015 [11] DEBUG: command_status: 0 = 0x [11] DEBUG: sequence_number: 201628 = 0x0003139c [11] DEBUG: SMPP PDU dump ends. [11] DEBUG: SMPP[abc3]: Got PDU: [11] DEBUG: SMPP PDU 8174bc0 dump: [11] DEBUG: type_name: deliver_sm [11] DEBUG: command_id: 5 = 0x0005 [11] DEBUG: command_status: 0 = 0x [11] DEBUG: sequence_number: 2453831019 = 0x92427d6b [11] DEBUG: service_type: NULL [11] DEBUG: source_addr_ton: 1 = 0x0001 [11] DEBUG: source_addr_npi: 1 = 0x0001 [11] DEBUG: source_addr: 989352034309 [11] DEBUG: dest_addr_ton: 0 = 0x [11] DEBUG: dest_addr_npi: 1 = 0x0001 [11] DEBUG: destination_addr: 8601001 [11] DEBUG: esm_class: 4 = 0x0004 [11] DEBUG: protocol_id: 0 = 0x [11] DEBUG: priority_flag: 0 = 0x [11] DEBUG: schedule_delivery_time: NULL [11] DEBUG: validity_period: NULL [11] DEBUG: registered_delivery: 0 = 0x [11] DEBUG: replace_if_present_flag: 0 = 0x [11] DEBUG: data_coding: 0 = 0x [11] DEBUG: sm_default_msg_id: 0 = 0x [11] DEBUG: sm_length: 70 = 0x0046 [11] DEBUG: short_message: [11] DEBUG:Octet string at 8129850: [11] DEBUG: len: 70 [11] DEBUG: size: 71 [11] DEBUG: immutable: 0 [11] DEBUG: data: 69 64 3a 32 34 35 31 37 33 33 31 33 34 20 73 75 id:2451733134 su [11] DEBUG: data: 62 6d 69 74 20 64 61 74 65 3a 30 39 31 30 31 33 bmit date:091013 [11] DEBUG: data: 30 37 30 34 20 64 6f 6e 65 20 64 61 74 65 3a 30 0704 done date:0 [11] DEBUG: data: 39 31 30 31 33 30 39 35 31 20 73 74 61 74 3a 44 910130951 stat:D [11] DEBUG: data: 45 4c 49 56 52 44
Re: How to stop message retries
Hi, Are these logs with sms-resend-retry = 0? Nikos - Original Message - From: Jinson To: Arne K. Haaje Cc: users@kannel.org ; Nikos Balkanas Sent: Monday, October 19, 2009 3:52 PM Subject: Re: How to stop message retries sms-resend-retry = 0 should stop the retries rite? Thanks Jinson Abraham On Mon, Oct 19, 2009 at 6:02 PM, Arne K. Haaje a...@drlinux.no wrote: This sometimes happen if the user is in a foreign network, like when travelling. The message get delivered, but the SMSC that you are using does not receive an ack from the phone that message is delivered. So, it retries the message. You can try asking the user to select another network on the phone for roaming in. This sometimes fix the problem, Mandag 19 oktober 2009 14:13:53 skrev Jinson : Got stuck with this problem again today. See my logs attached.Somebody received 150 Messages. This log is for a particular number which the message was retired nearly 150 times and I can not find anything on the bearerbox access log for this number. Thanks Jinson Abraham On Fri, Sep 25, 2009 at 3:57 PM, Nikos Balkanas nbalka...@gmail.com wrote: Do you know that you can change log-level on the fly from the http admin interface? Nikos On Fri, Sep 25, 2009 at 12:59 PM, Jinson jin...@mobme.in wrote: Will post it soon. Just enabled access logs and set log level to 0. Thanks Jinson On Fri, Sep 25, 2009 at 3:20 PM, Nikos Balkanas nbalka...@gmail.comwrote: Hi, Can you please post relvant bb logs (access + aplication) showing the problem? BR, Nikos On Fri, Sep 25, 2009 at 12:46 PM, Jinson jin...@mobme.in wrote: Hello Users, Seems like reties are still happening at my end. is there anything else to configure other than *sms-resend-retry = 0* Thanks Jinson On Wed, Sep 23, 2009 at 9:53 AM, Jinson jin...@mobme.in wrote: Yes. DLRs are getting failed. But this should solve my problem of retries for the time being. Thanks JJinson 2009/9/23 Nikos Balkanas nbalka...@gmail.com Yeap. That should do it. However, it will be logged as an error, and the DLR will probably be discarded. BR, Nikos - Original Message - *From:* Jinson jin...@mobme.in *To:* Nikos Balkanas nbalka...@gmail.com *Cc:* users users@kannel.org *Sent:* Tuesday, September 22, 2009 1:56 PM *Subject:* Re: How to stop message retries Hi, I got the point. The provider fail to send ACK sometimes. They are still not able to solve the issue. My current concern is to stop retries from Kannel, other than setting the wait-ack-expire. I set the sms-resend-retry = 0, that means no messages will be retried...rite? 2009/9/18 Nikos Balkanas nbalka...@gmail.com Hi, You probably want to say that kannel was not able to submit messages and queued up heavily. That is accurate, unless the SMSc sends an ACK, kannel won't remove SMS from Q. However, with 2, it won't try to resend it either. Note that this doesn't mean that the SMS was not sent. Just that kannel is pending on an ACK. So what's the deal? Your SMSc never sends ACKs? You may want to talk to them. Otherwise check also flow-control and window. But at the end, you will need to get an ACK from them, for SMPP to work. BR, Nikos - Original Message - *From:* Jinson jin...@mobme.in *To:* Nikos Balkanas nbalka...@gmail.com *Cc:* users users@kannel.org *Sent:* Friday, September 18, 2009 11:16 AM *Subject:* Re: How to stop message retries I tried wait-ack-expire = 0x02 before, but the SMSC was not able to submit messages and queued up heavily. Something to do with sms-resend-retry in core group? Thanks Jinson MobME storms into Emerging 50 Companies in India by Nasscom 2009/9/18 Nikos Balkanas nbalka...@gmail.com Hi, There are 2 options in SMPP configuration that will solve your problem: wait-ack wait-ack-expire Please read User guide on how to use them. BR, Nikos - Original Message - *From:* Jinson jin...@mobme.in *To:* users users@kannel.org *Sent:* Friday, September 18, 2009 8:53 AM *Subject:* How to stop message retries Hello , Im getting the following warning very frequently
Fwd: getting delivery report: delivery failure
I will contact my SMSC but I need to know exactly which fields are really being used by Kannel to return the DLR status?. Seems to me that Kannel is using *optional fields* like sub and dlvrd. If thats true, then isn't is a bug? Quoting Nokos Hi, It seems that your SMSc is sending out the wrong DLR format. According to SMPP 3.4 specs: “ *id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .”* Several optional fields (sub, dlvrd, err) are missing, but also a required field: Text. Without it kannel cannot understand the DLR. Contact your SMSc about it. They should comply to the SMPP spec. BR, Nikos -- Forwarded message -- From: Latitude Test latitude...@googlemail.com Date: Mon, Oct 19, 2009 at 3:29 PM Subject: Re: getting delivery report: delivery failure To: Nikos Balkanas n...@amdtelecom.net Cc: users users@kannel.org Are you saying dlvrd and sub are mandatory for Kannel? 2009/10/19 Nikos Balkanas n...@amdtelecom.net Yes, but it is required to be there. I am not making the spec. Nikos - Original Message - *From:* Latitude Test latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *Sent:* Monday, October 19, 2009 2:49 PM *Subject:* Fwd: getting delivery report: delivery failure Adding to it, I saw Kannel sending me correct DLRs with another SMSC and in the logs I saw the following: dlvrd:001 sub:001 Text:. The mendatory field Text does not contain any useful info here. How kannel knows the status of the message then? Seems it uses the optional fields which are sub and dlvrd. Please confirm. Thanks. -- Forwarded message -- From: Latitude Test latitude.de@ latitude...@googlemail.com googlemail.com Date: Mon, Oct 19, 2009 at 1:31 PM Subject: Re: getting delivery report: delivery failure To: users users@kannel.org, Nikos Balkanas nbalka...@gmail.com Thanks Nikos. But I do get stat field which contains some useful info. Also I felt that the format is vendor specific and the missing fields are not mandatory. Quote from http://www.nowsms.com/discus/messages/1/SMPP_v3_4_Issue1_2-24857.pdf: The informational content of an SMSC Delivery Receipt may be inserted into the short_message parameter of the deliver_sm operation. The format for this Delivery Receipt message is SMSC* vendor specific* but following is a typical example of Delivery Receipt report. “id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .” Regards. 2009/10/19 Nikos Balkanas n...@amdtelecom.net Hi, It seems that your SMSc is sending out the wrong DLR format. According to SMPP 3.4 specs: “ *id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .”* Several optional fields (sub, dlvrd, err) are missing, but also a required field: Text. Without it kannel cannot understand the DLR. Contact your SMSc about it. They should comply to the SMPP spec. BR, Nikos - Original Message - *From:* Latitude Test latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *Sent:* Monday, October 19, 2009 12:26 PM *Subject:* Re: getting delivery report: delivery failure Apologies for not sending the complete PDU before. Kindly review the complete PDU and guide. Thanks. ... [7] DEBUG: SMPP[abc1]: Got PDU: [7] DEBUG: SMPP PDU 8174bc0 dump: [7] DEBUG: type_name: enquire_link_resp [7] DEBUG: command_id: 2147483669 = 0x8015 [7] DEBUG: command_status: 0 = 0x [7] DEBUG: sequence_number: 201551 = 0x0003134f [7] DEBUG: SMPP PDU dump ends. [11] DEBUG: SMPP[abc3]: Sending enquire link: [11] DEBUG: SMPP PDU 8174bc0 dump: [11] DEBUG: type_name: enquire_link [11] DEBUG: command_id: 21 = 0x0015 [11] DEBUG: command_status: 0 = 0x [11] DEBUG: sequence_number: 201628 = 0x0003139c [11] DEBUG: SMPP PDU dump ends. [11] DEBUG: SMPP[abc3]: Got PDU: [11] DEBUG: SMPP PDU 8174bc0 dump: [11] DEBUG: type_name: enquire_link_resp [11] DEBUG: command_id: 2147483669 = 0x8015 [11] DEBUG: command_status: 0 = 0x [11] DEBUG: sequence_number: 201628 = 0x0003139c [11] DEBUG: SMPP PDU dump ends. [11] DEBUG: SMPP[abc3]: Got PDU: [11] DEBUG: SMPP PDU 8174bc0 dump: [11] DEBUG: type_name: deliver_sm [11] DEBUG: command_id: 5 = 0x0005 [11] DEBUG: command_status: 0 = 0x [11] DEBUG: sequence_number: 2453831019 = 0x92427d6b [11] DEBUG: service_type: NULL [11] DEBUG: source_addr_ton: 1 = 0x0001 [11] DEBUG: source_addr_npi: 1 = 0x0001 [11] DEBUG: source_addr: 989352034309 [11] DEBUG: dest_addr_ton: 0 = 0x [11] DEBUG: dest_addr_npi: 1 = 0x0001 [11] DEBUG: destination_addr: 8601001 [11] DEBUG: esm_class: 4 = 0x0004 [11] DEBUG:
Re: Help me about Kannel + HTTP connection
Hi, I am not hurt. but the issue is still the same. Ask specific questions, you will get an answer. Ask general questions, like I need to know the file kannel.conf, What do I have to configure?, go read the guide. We don't have the time nor the inclination to explain it to you over emails. BR, Nikos - Original Message - From: David Gerardo To: Nikos Balkanas Cc: users Sent: Monday, October 19, 2009 4:19 PM Subject: Re: Help me about Kannel + HTTP connection Sorry, but I think you have not understood my previous email. The intention was never to attack anyone, but I do send me a thousand questions and reading the user guide, a document that I have read several times and still can not find the answers. If I thought that the Guide or the community will not be productive, not write to it, on the contrary, only need my software to work and therefore ask the questions because I dont find the answers in the User Guide. I hope he had not hurt anyone's feelings, but if I expect more to help new developers. - Nikos Balkanas nbalka...@gmail.com escribió: | Hi, I have rewritten the whole wap code for another (commercial) project. However, let's pretend, as you say, that I don't know how to answer. Since you know the User's Guide by heart, please enlighten me: 1) What are the required modules to run wap? 2) What variables in the core group are needed to enable wap? 3) What groups do you need to configure aforementioned modules? 4) In what page in the guide is an example wap... configuration, and in what a PPG? PS. A lot of good people have contributed extra effort to maintain this guide. I trust that this is enough, and that you respect them for what they did, by not asking them to read it to you as well. BR, Nikos | - Original Message - | From: David Gerardo | To: Nikos Balkanas | Cc: users | Sent: Thursday, October 15, 2009 10:09 PM | Subject: Re: Help me about Kannel + HTTP connection | | excuse me Kannel community but every time I ask a question send me to see the user guide, I am a programmer and software developer and well that is the user guide. If I make a question is precisely because they find the answer in the materials provided by the community, so if you do not know the answers, understand, but no more to send me the user guide that I almost know it by heart. Sorry for the message but it is certainly unpleasant to all the questions I am doing so visit rebuts materials. | | - Nikos Balkanas n...@amdtelecom.net escribiΓ³: | | Hi, There is an excellent how-to and examples in the User's Guide. You can download it from the site. If you have specific questions about what you read we will be glad to help you. BR, Nikos | | - Original Message - | | From: David Gerardo | | To: users | | Sent: Thursday, October 15, 2009 8:16 PM | | Subject: Help me about Kannel + HTTP connection | | | | Gentlemen, please help urgently. I have a WAP terminal (it is a trunki) that connects to Kannel to review a website that is hosted on another computer. The Kannel creates bridges between the terminal and host the site. I need to know the file kannel.conf, What do I have to configure? The IP address of the computer that is hosting the Kannel is 10.31.18.4 and the IP address where is the site that I want to show in the terminal is on 10.31.18.5. Can you tell me the settings I put in the kannel.conf? | | Thank you for your support. | | | | -- | | | | | | -- | | El universitario de estos tiempos estΓ΅ llamado a convertir su espacio en un espacio productivo | -- El universitario de estos tiempos está llamado a convertir su espacio en un espacio productivo
Re: getting delivery report: delivery failure
Hi, You seem to have the spec. Just read which fields are mandatory from there. Kannel requires mandatory fields. Kannel will use optional fields, if they exist, but it doesn't reuire them. Optional fields are: sub, dlvrd err. Read the spec. Nikos - Original Message - From: Latitude Test To: users ; Nikos Balkanas Sent: Monday, October 19, 2009 4:59 PM Subject: Fwd: getting delivery report: delivery failure I will contact my SMSC but I need to know exactly which fields are really being used by Kannel to return the DLR status?. Seems to me that Kannel is using optional fields like sub and dlvrd. If thats true, then isn't is a bug? Quoting Nokos Hi, It seems that your SMSc is sending out the wrong DLR format. According to SMPP 3.4 specs: “ id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .” Several optional fields (sub, dlvrd, err) are missing, but also a required field: Text. Without it kannel cannot understand the DLR. Contact your SMSc about it. They should comply to the SMPP spec. BR, Nikos -- Forwarded message -- From: Latitude Test latitude...@googlemail.com Date: Mon, Oct 19, 2009 at 3:29 PM Subject: Re: getting delivery report: delivery failure To: Nikos Balkanas n...@amdtelecom.net Cc: users users@kannel.org Are you saying dlvrd and sub are mandatory for Kannel? 2009/10/19 Nikos Balkanas n...@amdtelecom.net Yes, but it is required to be there. I am not making the spec. Nikos - Original Message - From: Latitude Test To: users ; Nikos Balkanas Sent: Monday, October 19, 2009 2:49 PM Subject: Fwd: getting delivery report: delivery failure Adding to it, I saw Kannel sending me correct DLRs with another SMSC and in the logs I saw the following: dlvrd:001 sub:001 Text:. The mendatory field Text does not contain any useful info here. How kannel knows the status of the message then? Seems it uses the optional fields which are sub and dlvrd. Please confirm. Thanks. -- Forwarded message -- From: Latitude Test latitude...@googlemail.com Date: Mon, Oct 19, 2009 at 1:31 PM Subject: Re: getting delivery report: delivery failure To: users users@kannel.org, Nikos Balkanas nbalka...@gmail.com Thanks Nikos. But I do get stat field which contains some useful info. Also I felt that the format is vendor specific and the missing fields are not mandatory. Quote from http://www.nowsms.com/discus/messages/1/SMPP_v3_4_Issue1_2-24857.pdf: The informational content of an SMSC Delivery Receipt may be inserted into the short_message parameter of the deliver_sm operation. The format for this Delivery Receipt message is SMSC vendor specific but following is a typical example of Delivery Receipt report. “id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .” Regards. 2009/10/19 Nikos Balkanas n...@amdtelecom.net Hi, It seems that your SMSc is sending out the wrong DLR format. According to SMPP 3.4 specs: “ id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .” Several optional fields (sub, dlvrd, err) are missing, but also a required field: Text. Without it kannel cannot understand the DLR. Contact your SMSc about it. They should comply to the SMPP spec. BR, Nikos - Original Message - From: Latitude Test To: users ; Nikos Balkanas Sent: Monday, October 19, 2009 12:26 PM Subject: Re: getting delivery report: delivery failure Apologies for not sending the complete PDU before. Kindly review the complete PDU and guide. Thanks. ... [7] DEBUG: SMPP[abc1]: Got PDU: [7] DEBUG: SMPP PDU 8174bc0 dump: [7] DEBUG: type_name: enquire_link_resp [7] DEBUG: command_id: 2147483669 = 0x8015 [7] DEBUG: command_status: 0 = 0x [7] DEBUG: sequence_number: 201551 = 0x0003134f [7] DEBUG: SMPP PDU dump ends. [11] DEBUG: SMPP[abc3]: Sending enquire link: [11] DEBUG: SMPP PDU 8174bc0 dump: [11] DEBUG: type_name: enquire_link [11] DEBUG: command_id: 21 = 0x0015 [11] DEBUG: command_status: 0 = 0x [11] DEBUG: sequence_number: 201628 = 0x0003139c [11] DEBUG: SMPP PDU dump ends. [11] DEBUG: SMPP[abc3]: Got PDU: [11] DEBUG: SMPP PDU 8174bc0 dump: [11] DEBUG: type_name: enquire_link_resp [11] DEBUG: command_id:
question about kannel's service
I have a question ... Kannel the only thing you do is set the configuration variables for communication between mobile devices and services for these devices? At the end you have to configure mobile devices to communicate through the Kannel gateway.?
Re: getting delivery report: delivery failure
As you can confirm by reading the 3.4 spec (Appendix B), the format is far from an established standard: *Delivery Receipt Format* SMPP provides for return of an SMSC delivery receipt via the *deliver_sm* or *data_sm* PDU, which indicates the delivery status of the message. The informational content of an SMSC Delivery Receipt may be inserted into the *short_message* parameter of the *deliver_sm *operation. *The format for this Delivery Receipt** **message is SMSC vendor specific but following is a typical example of Delivery Receipt report.** * “*id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .”* Kannel expects that format, a missing field will definitely confuse sscanf. Regards, Alejandro 2009/10/19 Nikos Balkanas n...@amdtelecom.net Hi, You seem to have the spec. Just read which fields are mandatory from there. Kannel requires mandatory fields. Kannel will use optional fields, if they exist, but it doesn't reuire them. Optional fields are: sub, dlvrd err. Read the spec. Nikos - Original Message - *From:* Latitude Test latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *Sent:* Monday, October 19, 2009 4:59 PM *Subject:* Fwd: getting delivery report: delivery failure I will contact my SMSC but I need to know exactly which fields are really being used by Kannel to return the DLR status?. Seems to me that Kannel is using *optional fields* like sub and dlvrd. If thats true, then isn't is a bug? Quoting Nokos Hi, It seems that your SMSc is sending out the wrong DLR format. According to SMPP 3.4 specs: “ *id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .”* Several optional fields (sub, dlvrd, err) are missing, but also a required field: Text. Without it kannel cannot understand the DLR. Contact your SMSc about it. They should comply to the SMPP spec. BR, Nikos -- Forwarded message -- From: Latitude Test latitude...@googlemail.com Date: Mon, Oct 19, 2009 at 3:29 PM Subject: Re: getting delivery report: delivery failure To: Nikos Balkanas n...@amdtelecom.net Cc: users users@kannel.org Are you saying dlvrd and sub are mandatory for Kannel? 2009/10/19 Nikos Balkanas n...@amdtelecom.net Yes, but it is required to be there. I am not making the spec. Nikos - Original Message - *From:* Latitude Test latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *Sent:* Monday, October 19, 2009 2:49 PM *Subject:* Fwd: getting delivery report: delivery failure Adding to it, I saw Kannel sending me correct DLRs with another SMSC and in the logs I saw the following: dlvrd:001 sub:001 Text:. The mendatory field Text does not contain any useful info here. How kannel knows the status of the message then? Seems it uses the optional fields which are sub and dlvrd. Please confirm. Thanks. -- Forwarded message -- From: Latitude Test latitude.de@ latitude...@googlemail.com googlemail.com Date: Mon, Oct 19, 2009 at 1:31 PM Subject: Re: getting delivery report: delivery failure To: users users@kannel.org, Nikos Balkanas nbalka...@gmail.com Thanks Nikos. But I do get stat field which contains some useful info. Also I felt that the format is vendor specific and the missing fields are not mandatory. Quote from http://www.nowsms.com/discus/messages/1/SMPP_v3_4_Issue1_2-24857.pdf: The informational content of an SMSC Delivery Receipt may be inserted into the short_message parameter of the deliver_sm operation. The format for this Delivery Receipt message is SMSC* vendor specific* but following is a typical example of Delivery Receipt report. “id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .” Regards. 2009/10/19 Nikos Balkanas n...@amdtelecom.net Hi, It seems that your SMSc is sending out the wrong DLR format. According to SMPP 3.4 specs: “ *id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .”* Several optional fields (sub, dlvrd, err) are missing, but also a required field: Text. Without it kannel cannot understand the DLR. Contact your SMSc about it. They should comply to the SMPP spec. BR, Nikos - Original Message - *From:* Latitude Test latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *Sent:* Monday, October 19, 2009 12:26 PM *Subject:* Re: getting delivery report: delivery failure Apologies for not sending the complete PDU before. Kindly review the complete PDU and guide. Thanks. ... [7] DEBUG: SMPP[abc1]: Got PDU: [7] DEBUG: SMPP PDU 8174bc0 dump: [7] DEBUG: type_name: enquire_link_resp [7] DEBUG: command_id:
Re: getting delivery report: delivery failure
I have SMPP 3.4 specs but it doesn't give any info on mandatory/optional fields when it comes to DLR format. 2009/10/19 Nikos Balkanas n...@amdtelecom.net Hi, You seem to have the spec. Just read which fields are mandatory from there. Kannel requires mandatory fields. Kannel will use optional fields, if they exist, but it doesn't reuire them. Optional fields are: sub, dlvrd err. Read the spec. Nikos - Original Message - *From:* Latitude Test latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *Sent:* Monday, October 19, 2009 4:59 PM *Subject:* Fwd: getting delivery report: delivery failure I will contact my SMSC but I need to know exactly which fields are really being used by Kannel to return the DLR status?. Seems to me that Kannel is using *optional fields* like sub and dlvrd. If thats true, then isn't is a bug? Quoting Nokos Hi, It seems that your SMSc is sending out the wrong DLR format. According to SMPP 3.4 specs: “ *id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .”* Several optional fields (sub, dlvrd, err) are missing, but also a required field: Text. Without it kannel cannot understand the DLR. Contact your SMSc about it. They should comply to the SMPP spec. BR, Nikos -- Forwarded message -- From: Latitude Test latitude...@googlemail.com Date: Mon, Oct 19, 2009 at 3:29 PM Subject: Re: getting delivery report: delivery failure To: Nikos Balkanas n...@amdtelecom.net Cc: users users@kannel.org Are you saying dlvrd and sub are mandatory for Kannel? 2009/10/19 Nikos Balkanas n...@amdtelecom.net Yes, but it is required to be there. I am not making the spec. Nikos - Original Message - *From:* Latitude Test latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *Sent:* Monday, October 19, 2009 2:49 PM *Subject:* Fwd: getting delivery report: delivery failure Adding to it, I saw Kannel sending me correct DLRs with another SMSC and in the logs I saw the following: dlvrd:001 sub:001 Text:. The mendatory field Text does not contain any useful info here. How kannel knows the status of the message then? Seems it uses the optional fields which are sub and dlvrd. Please confirm. Thanks. -- Forwarded message -- From: Latitude Test latitude.de@ latitude...@googlemail.com googlemail.com Date: Mon, Oct 19, 2009 at 1:31 PM Subject: Re: getting delivery report: delivery failure To: users users@kannel.org, Nikos Balkanas nbalka...@gmail.com Thanks Nikos. But I do get stat field which contains some useful info. Also I felt that the format is vendor specific and the missing fields are not mandatory. Quote from http://www.nowsms.com/discus/messages/1/SMPP_v3_4_Issue1_2-24857.pdf: The informational content of an SMSC Delivery Receipt may be inserted into the short_message parameter of the deliver_sm operation. The format for this Delivery Receipt message is SMSC* vendor specific* but following is a typical example of Delivery Receipt report. “id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .” Regards. 2009/10/19 Nikos Balkanas n...@amdtelecom.net Hi, It seems that your SMSc is sending out the wrong DLR format. According to SMPP 3.4 specs: “ *id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .”* Several optional fields (sub, dlvrd, err) are missing, but also a required field: Text. Without it kannel cannot understand the DLR. Contact your SMSc about it. They should comply to the SMPP spec. BR, Nikos - Original Message - *From:* Latitude Test latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *Sent:* Monday, October 19, 2009 12:26 PM *Subject:* Re: getting delivery report: delivery failure Apologies for not sending the complete PDU before. Kindly review the complete PDU and guide. Thanks. ... [7] DEBUG: SMPP[abc1]: Got PDU: [7] DEBUG: SMPP PDU 8174bc0 dump: [7] DEBUG: type_name: enquire_link_resp [7] DEBUG: command_id: 2147483669 = 0x8015 [7] DEBUG: command_status: 0 = 0x [7] DEBUG: sequence_number: 201551 = 0x0003134f [7] DEBUG: SMPP PDU dump ends. [11] DEBUG: SMPP[abc3]: Sending enquire link: [11] DEBUG: SMPP PDU 8174bc0 dump: [11] DEBUG: type_name: enquire_link [11] DEBUG: command_id: 21 = 0x0015 [11] DEBUG: command_status: 0 = 0x [11] DEBUG: sequence_number: 201628 = 0x0003139c [11] DEBUG: SMPP PDU dump ends. [11] DEBUG: SMPP[abc3]: Got PDU: [11] DEBUG: SMPP PDU 8174bc0 dump: [11] DEBUG: type_name: enquire_link_resp [11] DEBUG: command_id: 2147483669 = 0x8015 [11] DEBUG: command_status: 0 = 0x [11] DEBUG:
Re: getting delivery report: delivery failure
Hi, A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? On Mon, 2009-10-19 at 16:29, Alejandro Guerrieri wrote: As you can confirm by reading the 3.4 spec (Appendix B), the format is far from an established standard: *Delivery Receipt Format* SMPP provides for return of an SMSC delivery receipt via the *deliver_sm* or *data_sm* PDU, which indicates the delivery status of the message. The informational content of an SMSC Delivery Receipt may be inserted into the *short_message* parameter of the *deliver_sm *operation. *The format for this Delivery Receipt** **message is SMSC vendor specific but following is a typical example of Delivery Receipt report.** * “*id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .”* Kannel expects that format, a missing field will definitely confuse sscanf. If the kannel relies on not standardized format then that _is_ the bug in kannel. Regards, Alejandro 2009/10/19 Nikos Balkanas n...@amdtelecom.net Hi, You seem to have the spec. Just read which fields are mandatory from there. Kannel requires mandatory fields. Kannel will use optional fields, if they exist, but it doesn't reuire them. Optional fields are: sub, dlvrd err. Read the spec. Nikos - Original Message - *From:* Latitude Test latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *Sent:* Monday, October 19, 2009 4:59 PM *Subject:* Fwd: getting delivery report: delivery failure I will contact my SMSC but I need to know exactly which fields are really being used by Kannel to return the DLR status?. Seems to me that Kannel is using *optional fields* like sub and dlvrd. If thats true, then isn't is a bug? Quoting Nokos Hi, It seems that your SMSc is sending out the wrong DLR format. According to SMPP 3.4 specs: “ *id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .”* Several optional fields (sub, dlvrd, err) are missing, but also a required field: Text. Without it kannel cannot understand the DLR. Contact your SMSc about it. They should comply to the SMPP spec. BR, Nikos -- Forwarded message -- From: Latitude Test latitude...@googlemail.com Date: Mon, Oct 19, 2009 at 3:29 PM Subject: Re: getting delivery report: delivery failure To: Nikos Balkanas n...@amdtelecom.net Cc: users users@kannel.org Are you saying dlvrd and sub are mandatory for Kannel? 2009/10/19 Nikos Balkanas n...@amdtelecom.net Yes, but it is required to be there. I am not making the spec. Nikos - Original Message - *From:* Latitude Test latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *Sent:* Monday, October 19, 2009 2:49 PM *Subject:* Fwd: getting delivery report: delivery failure Adding to it, I saw Kannel sending me correct DLRs with another SMSC and in the logs I saw the following: dlvrd:001 sub:001 Text:. The mendatory field Text does not contain any useful info here. How kannel knows the status of the message then? Seems it uses the optional fields which are sub and dlvrd. Please confirm. Thanks. -- Forwarded message -- From: Latitude Test latitude.de@ latitude...@googlemail.com googlemail.com Date: Mon, Oct 19, 2009 at 1:31 PM Subject: Re: getting delivery report: delivery failure To: users users@kannel.org, Nikos Balkanas nbalka...@gmail.com Thanks Nikos. But I do get stat field which contains some useful info. Also I felt that the format is vendor specific and the missing fields are not mandatory. Quote from http://www.nowsms.com/discus/messages/1/SMPP_v3_4_Issue1_2-24857.pdf: The informational content of an SMSC Delivery Receipt may be inserted into the short_message parameter of the deliver_sm operation. The format for this Delivery Receipt message is SMSC* vendor specific* but following is a typical example of Delivery Receipt report. “id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .” Regards. 2009/10/19 Nikos Balkanas n...@amdtelecom.net Hi, It seems that your SMSc is sending out the wrong DLR format. According to SMPP 3.4 specs: “ *id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .”* Several optional fields (sub, dlvrd, err) are missing, but also a required field: Text. Without it kannel cannot understand the DLR. Contact your SMSc about it. They should comply to the SMPP spec. BR, Nikos - Original Message
Re: getting delivery report: delivery failure
Sorry, what optional fields are you talking about? sub: and dlvrd: are _not_ optional parameters but part of the de facto standard for DLR format. The only optional parameter honored by kannel on DLR's is network_error_code but it's not mandatory: if present, Kannel will use it to determine if a DLR was successful, otherwise it'll rely solely on the DLR text field. Regards, Alejandro On Mon, Oct 19, 2009 at 4:42 PM, Latitude Test latitude...@googlemail.comwrote: I have SMPP 3.4 specs but it doesn't give any info on mandatory/optional fields when it comes to DLR format. 2009/10/19 Nikos Balkanas n...@amdtelecom.net Hi, You seem to have the spec. Just read which fields are mandatory from there. Kannel requires mandatory fields. Kannel will use optional fields, if they exist, but it doesn't reuire them. Optional fields are: sub, dlvrd err. Read the spec. Nikos - Original Message - *From:* Latitude Test latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *Sent:* Monday, October 19, 2009 4:59 PM *Subject:* Fwd: getting delivery report: delivery failure I will contact my SMSC but I need to know exactly which fields are really being used by Kannel to return the DLR status?. Seems to me that Kannel is using *optional fields* like sub and dlvrd. If thats true, then isn't is a bug? Quoting Nokos Hi, It seems that your SMSc is sending out the wrong DLR format. According to SMPP 3.4 specs: “ *id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .”* Several optional fields (sub, dlvrd, err) are missing, but also a required field: Text. Without it kannel cannot understand the DLR. Contact your SMSc about it. They should comply to the SMPP spec. BR, Nikos -- Forwarded message -- From: Latitude Test latitude...@googlemail.com Date: Mon, Oct 19, 2009 at 3:29 PM Subject: Re: getting delivery report: delivery failure To: Nikos Balkanas n...@amdtelecom.net Cc: users users@kannel.org Are you saying dlvrd and sub are mandatory for Kannel? 2009/10/19 Nikos Balkanas n...@amdtelecom.net Yes, but it is required to be there. I am not making the spec. Nikos - Original Message - *From:* Latitude Test latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *Sent:* Monday, October 19, 2009 2:49 PM *Subject:* Fwd: getting delivery report: delivery failure Adding to it, I saw Kannel sending me correct DLRs with another SMSC and in the logs I saw the following: dlvrd:001 sub:001 Text:. The mendatory field Text does not contain any useful info here. How kannel knows the status of the message then? Seems it uses the optional fields which are sub and dlvrd. Please confirm. Thanks. -- Forwarded message -- From: Latitude Test latitude.de@ latitude...@googlemail.com googlemail.com Date: Mon, Oct 19, 2009 at 1:31 PM Subject: Re: getting delivery report: delivery failure To: users users@kannel.org, Nikos Balkanas nbalka...@gmail.com Thanks Nikos. But I do get stat field which contains some useful info. Also I felt that the format is vendor specific and the missing fields are not mandatory. Quote from http://www.nowsms.com/discus/messages/1/SMPP_v3_4_Issue1_2-24857.pdf: The informational content of an SMSC Delivery Receipt may be inserted into the short_message parameter of the deliver_sm operation. The format for this Delivery Receipt message is SMSC* vendor specific* but following is a typical example of Delivery Receipt report. “id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .” Regards. 2009/10/19 Nikos Balkanas n...@amdtelecom.net Hi, It seems that your SMSc is sending out the wrong DLR format. According to SMPP 3.4 specs: “ *id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .”* Several optional fields (sub, dlvrd, err) are missing, but also a required field: Text. Without it kannel cannot understand the DLR. Contact your SMSc about it. They should comply to the SMPP spec. BR, Nikos - Original Message - *From:* Latitude Test latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *Sent:* Monday, October 19, 2009 12:26 PM *Subject:* Re: getting delivery report: delivery failure Apologies for not sending the complete PDU before. Kindly review the complete PDU and guide. Thanks. ... [7] DEBUG: SMPP[abc1]: Got PDU: [7] DEBUG: SMPP PDU 8174bc0 dump: [7] DEBUG: type_name: enquire_link_resp [7] DEBUG: command_id: 2147483669 = 0x8015 [7] DEBUG: command_status: 0 = 0x [7] DEBUG: sequence_number: 201551 = 0x0003134f [7] DEBUG: SMPP PDU dump ends. [11] DEBUG: SMPP[abc3]: Sending enquire link:
Re: GENERIC: ERROR when openning device
Kannel detected your modem config but is unable to open the modem. There is no info about kannel been able to open /dev/ttyACM0 Check permissions for kannel to read/write on your /dev/ttyACM0 Regards Alvaro |-| Envíe y Reciba Datos y mensajes de Texto (SMS) hacia y desde cualquier celular y Nextel en el Perú, México y en mas de 180 paises. Use aplicaciones 2 vias via SMS y GPRS online Visitenos en www.perusms.NET www.smsglobal.com.mx y www.pravcom.com On Mon, Oct 19, 2009 at 2:25 AM, st2forget st2for...@gmail.com wrote: Hi all, i'm having trouble with Kannel and Nokia N70 Music Edition. I wonder if Kannel can read that phone or not? :(. Here is my situation: 2009-10-17 01:13:21 [7238] [6] INFO: AT2[N70]: opening device 2009-10-17 01:13:21 [7238] [0] INFO: Adding interface * 2009-10-17 01:13:21 [7238] [0] INFO: 2009-10-17 01:13:21 [7238] [0] INFO: Kannel bearerbox II version 1.4.3 starting 2009-10-17 01:13:21 [7238] [0] INFO: MAIN: Start-up done, entering mainloop 2009-10-17 01:13:22 [7238] [6] INFO: AT2[N70]: speed set to 115200 2009-10-17 01:13:24 [7238] [6] INFO: AT2[N70]: Closing device 2009-10-17 01:13:24 [7238] [6] INFO: AT2[N70]: detect speed is 115200 2009-10-17 01:13:24 [7238] [6] INFO: AT2[N70]: opening device 2009-10-17 01:13:25 [7238] [6] INFO: AT2[N70]: speed set to 115200 2009-10-17 01:13:27 [7238] [6] INFO: AT2[N70]: Closing device 2009-10-17 01:13:27 [7238] [6] INFO: AT2[N70]: opening device 2009-10-17 01:13:28 [7238] [6] INFO: AT2[N70]: Logging in 2009-10-17 01:13:29 [7238] [6] INFO: AT2[N70]: init device 2009-10-17 01:13:29 [7238] [6] INFO: AT2[N70]: speed set to 115200 2009-10-17 01:13:30 [7238] [6] ERROR: AT2[N70]: Generic error: ERROR 2009-10-17 01:13:30 [7238] [6] ERROR: AT2[N70]: Initialization of device failed. 2009-10-17 01:13:30 [7238] [6] INFO: AT2[N70]: Closing device 2009-10-17 01:13:30 [7238] [6] ERROR: AT2[N70]: Couldn't connect (retrying in 10 seconds). It seems that Kannel entered mainloop and could listen to mobile phone, but when it set speed for mobile, there is and error occured. Is there any way to configure or install package for my phone to detect kannel? Or any way to update kannel to detect my phone co'z it's Nokia N70 Music Edition, not N70. Here is my Kannel.conf file: group = core admin-port = 13000 admin-password = hoanggia admin-deny-ip = *.*.*.* admin-allow-ip = 127.0.0.1 smsbox-port = 13001 wapbox-port = 13002 wdp-interface-name = * log-file = /var/log/kannel/bearerbox.log box-deny-ip = *.*.*.* box-allow-ip = 127.0.0.1 group = wapbox bearerbox-host = localhost log-file = /var/log/kannel/wapbox.log #group = smsc #smsc = at #modemtype = auto #device=/dev/ttyACM0 #my-number = 123123123123 #The my-number field contains the number of #your GSM modem’s SIM chip ##log-level = 0 group = smsc smsc = at smsc-id = N70 device = /dev/ttyACM0 my-number = 0983040785 modemtype = nokiaphone # phone type speed = 0 connect-allow-ip = 127.0.0.1 #sms-center = +84980200030 group = modems id = nokiaphone name = Nokia N70 detect-string = Nokia init-string = ATQ0 V1 E1 S0=0 C1 D2 +FCLASS=0 #use sudo wvdialconf /etc/wvdial.conf keepalive-cmd = AT+CBC;+CSQ #detect-string2 = N70 speed = 0 need-sleep = true #pin = group = modems id = wavecome name = Wavecom detect-string = WAVECOM group = smsbox bearerbox-host = 127.0.0.1 sendsms-port = 13013 sendsms-chars = 0123456789+ log-file = /etc/kannel/smsbox.log #global-sender = 123123123123 log-level = 0 group = sendsms-user username = baochau password = hoanggia concatenation= true max-messages = 10 group = sms-service keyword = keyword-regex = .* catch-all = yes max-messages = 0 get-url = http://localhost/php.php?phone=%ptext=%a; -- View this message in context: http://www.nabble.com/GENERIC%3A-ERROR-when-openning-device-tp25930608p25930608.html Sent from the Kannel - User mailing list archive at Nabble.com.
Re: getting delivery report: delivery failure
There's not a standarized format... how could this be a bug? Kannel relies on what's considered a typical example and in fact it's being used by the vast majority of SMSC's out there (Believe me, I've connected with over 50 different SMSC's all over the world and never experienced an issue). If you need to deal with a different format and the SMSC can't/don't want to change their format, you'll need to patch kannel to use a different sscanf string (it's a simple patch if you know where to touch). Regards, Alejandro PS: Please keep your views about the top/bottom posting for yourself. Posting off-topic and breaking the former email reading order is far more annoying than top-posting (which it seems to be the norm for a lot of people nowadays, either you like it or not). On Mon, Oct 19, 2009 at 4:48 PM, Milan P. Stanic m...@arvanta.net wrote: Hi, A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? On Mon, 2009-10-19 at 16:29, Alejandro Guerrieri wrote: As you can confirm by reading the 3.4 spec (Appendix B), the format is far from an established standard: *Delivery Receipt Format* SMPP provides for return of an SMSC delivery receipt via the *deliver_sm* or *data_sm* PDU, which indicates the delivery status of the message. The informational content of an SMSC Delivery Receipt may be inserted into the *short_message* parameter of the *deliver_sm *operation. *The format for this Delivery Receipt** **message is SMSC vendor specific but following is a typical example of Delivery Receipt report.** * “*id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .”* Kannel expects that format, a missing field will definitely confuse sscanf. If the kannel relies on not standardized format then that _is_ the bug in kannel. Regards, Alejandro 2009/10/19 Nikos Balkanas n...@amdtelecom.net Hi, You seem to have the spec. Just read which fields are mandatory from there. Kannel requires mandatory fields. Kannel will use optional fields, if they exist, but it doesn't reuire them. Optional fields are: sub, dlvrd err. Read the spec. Nikos - Original Message - *From:* Latitude Test latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *Sent:* Monday, October 19, 2009 4:59 PM *Subject:* Fwd: getting delivery report: delivery failure I will contact my SMSC but I need to know exactly which fields are really being used by Kannel to return the DLR status?. Seems to me that Kannel is using *optional fields* like sub and dlvrd. If thats true, then isn't is a bug? Quoting Nokos Hi, It seems that your SMSc is sending out the wrong DLR format. According to SMPP 3.4 specs: “ *id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .”* Several optional fields (sub, dlvrd, err) are missing, but also a required field: Text. Without it kannel cannot understand the DLR. Contact your SMSc about it. They should comply to the SMPP spec. BR, Nikos -- Forwarded message -- From: Latitude Test latitude...@googlemail.com Date: Mon, Oct 19, 2009 at 3:29 PM Subject: Re: getting delivery report: delivery failure To: Nikos Balkanas n...@amdtelecom.net Cc: users users@kannel.org Are you saying dlvrd and sub are mandatory for Kannel? 2009/10/19 Nikos Balkanas n...@amdtelecom.net Yes, but it is required to be there. I am not making the spec. Nikos - Original Message - *From:* Latitude Test latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *Sent:* Monday, October 19, 2009 2:49 PM *Subject:* Fwd: getting delivery report: delivery failure Adding to it, I saw Kannel sending me correct DLRs with another SMSC and in the logs I saw the following: dlvrd:001 sub:001 Text:. The mendatory field Text does not contain any useful info here. How kannel knows the status of the message then? Seems it uses the optional fields which are sub and dlvrd. Please confirm. Thanks. -- Forwarded message -- From: Latitude Test latitude.de@ latitude...@googlemail.com googlemail.com Date: Mon, Oct 19, 2009 at 1:31 PM Subject: Re: getting delivery report: delivery failure To: users users@kannel.org, Nikos Balkanas nbalka...@gmail.com Thanks Nikos. But I do get stat field which contains some useful info. Also I felt that the format is vendor specific and the missing fields are not mandatory. Quote from
Re: getting delivery report: delivery failure
Sorry, Alej, You are in the wrong here. In the spec some of these fields are declared as optional, and others as not: msgid: The message ID allocated to the message by the SMSC when originally submitted. sub: Number of short messages originally submitted. This is only relevant when the original message was submitted to a distribution list.The value is padded with leading zeros if necessary. dlvr: Number of short messages delivered. This is only relevant where the original message was submitted to a distribution list.The value ispadded with leading zeros if necessary. err: Where appropriate this may hold a Network specific error code or an SMSC error code for the attempted delivery of the message. These errors are Network or SMSC specific and are not included here. These can be omitted according to the spec. Furthermore, kannel doesn't rely exclusively in sscanf , but also falls back in the old way, as stated in the warning, where it manually scans for the variables it needs. In the old way it is much more flexible. @Test: I have provided you with a patch, please test and let's take it from there. Let's stop the spam, until it's needed. BR, Nikos - Original Message - From: Alejandro Guerrieri To: Latitude Test Cc: Nikos Balkanas ; users Sent: Monday, October 19, 2009 5:50 PM Subject: Re: getting delivery report: delivery failure Sorry, what optional fields are you talking about? sub: and dlvrd: are _not_ optional parameters but part of the de facto standard for DLR format. The only optional parameter honored by kannel on DLR's is network_error_code but it's not mandatory: if present, Kannel will use it to determine if a DLR was successful, otherwise it'll rely solely on the DLR text field. Regards, Alejandro On Mon, Oct 19, 2009 at 4:42 PM, Latitude Test latitude...@googlemail.com wrote: I have SMPP 3.4 specs but it doesn't give any info on mandatory/optional fields when it comes to DLR format. 2009/10/19 Nikos Balkanas n...@amdtelecom.net Hi, You seem to have the spec. Just read which fields are mandatory from there. Kannel requires mandatory fields. Kannel will use optional fields, if they exist, but it doesn't reuire them. Optional fields are: sub, dlvrd err. Read the spec. Nikos - Original Message - From: Latitude Test To: users ; Nikos Balkanas Sent: Monday, October 19, 2009 4:59 PM Subject: Fwd: getting delivery report: delivery failure I will contact my SMSC but I need to know exactly which fields are really being used by Kannel to return the DLR status?. Seems to me that Kannel is using optional fields like sub and dlvrd. If thats true, then isn't is a bug? Quoting Nokos Hi, It seems that your SMSc is sending out the wrong DLR format. According to SMPP 3.4 specs: “ id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .” Several optional fields (sub, dlvrd, err) are missing, but also a required field: Text. Without it kannel cannot understand the DLR. Contact your SMSc about it. They should comply to the SMPP spec. BR, Nikos -- Forwarded message -- From: Latitude Test latitude...@googlemail.com Date: Mon, Oct 19, 2009 at 3:29 PM Subject: Re: getting delivery report: delivery failure To: Nikos Balkanas n...@amdtelecom.net Cc: users users@kannel.org Are you saying dlvrd and sub are mandatory for Kannel? 2009/10/19 Nikos Balkanas n...@amdtelecom.net Yes, but it is required to be there. I am not making the spec. Nikos - Original Message - From: Latitude Test To: users ; Nikos Balkanas Sent: Monday, October 19, 2009 2:49 PM Subject: Fwd: getting delivery report: delivery failure Adding to it, I saw Kannel sending me correct DLRs with another SMSC and in the logs I saw the following: dlvrd:001 sub:001 Text:. The mendatory field Text does not contain any useful info here. How kannel knows the status of the message then? Seems it uses the optional fields which are sub and dlvrd. Please confirm. Thanks. -- Forwarded message -- From: Latitude Test latitude...@googlemail.com Date: Mon, Oct 19, 2009 at 1:31 PM Subject: Re: getting delivery report: delivery failure To: users users@kannel.org, Nikos Balkanas nbalka...@gmail.com Thanks Nikos. But I do get stat field which contains some useful info. Also I felt that the format is vendor specific and the missing fields are not mandatory.
Re: getting delivery report: delivery failure
not relevant !== optional. Where did you read optional or can be removed? Again, this is NOT a standard, and it's documented by example, which it's imho a flaw on the spec's strictness, but it is what it is. The fact that most smsc's uses that format makes a strong point for kannel to use it as well. For the small fraction of smscs that don't use it the only alternative right now is to patch the source code, I'm afraid. Regards, Alejandro 2009/10/19 Nikos Balkanas n...@amdtelecom.net Sorry, Alej, You are in the wrong here. In the spec some of these fields are declared as optional, and others as not: msgid: The message ID allocated to the message by the SMSC when originally submitted. sub: Number of short messages originally submitted. This is only *relevant *when the original message was submitted to a distribution list.The value is padded with leading zeros if necessary. dlvr: Number of short messages delivered. This is only *relevant* where the original message was submitted to a distribution list.The value ispadded with leading zeros if necessary. err: Where *appropriate* this may hold a Network specific error code or an SMSC error code for the attempted delivery of the message. These errors are Network or SMSC specific and are not included here. These can be omitted according to the spec. Furthermore, kannel doesn't rely exclusively in sscanf , but also falls back in the old way, as stated in the warning, where it manually scans for the variables it needs. In the old way it is much more flexible. @Test: I have provided you with a patch, please test and let's take it from there. Let's stop the spam, until it's needed. BR, Nikos - Original Message - *From:* Alejandro Guerrieri alejandro.guerri...@gmail.com *To:* Latitude Test latitude...@googlemail.com *Cc:* Nikos Balkanas n...@amdtelecom.net ; users users@kannel.org *Sent:* Monday, October 19, 2009 5:50 PM *Subject:* Re: getting delivery report: delivery failure Sorry, what optional fields are you talking about? sub: and dlvrd: are _not_ optional parameters but part of the de facto standard for DLR format. The only optional parameter honored by kannel on DLR's is network_error_code but it's not mandatory: if present, Kannel will use it to determine if a DLR was successful, otherwise it'll rely solely on the DLR text field. Regards, Alejandro On Mon, Oct 19, 2009 at 4:42 PM, Latitude Test latitude.de@latitude...@googlemail.com googlemail.com wrote: I have SMPP 3.4 specs but it doesn't give any info on mandatory/optional fields when it comes to DLR format. 2009/10/19 Nikos Balkanas n...@amdtelecom.net Hi, You seem to have the spec. Just read which fields are mandatory from there. Kannel requires mandatory fields. Kannel will use optional fields, if they exist, but it doesn't reuire them. Optional fields are: sub, dlvrd err. Read the spec. Nikos - Original Message - *From:* Latitude Test latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *Sent:* Monday, October 19, 2009 4:59 PM *Subject:* Fwd: getting delivery report: delivery failure I will contact my SMSC but I need to know exactly which fields are really being used by Kannel to return the DLR status?. Seems to me that Kannel is using *optional fields* like sub and dlvrd. If thats true, then isn't is a bug? Quoting Nokos Hi, It seems that your SMSc is sending out the wrong DLR format. According to SMPP 3.4 specs: “ *id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .”* Several optional fields (sub, dlvrd, err) are missing, but also a required field: Text. Without it kannel cannot understand the DLR. Contact your SMSc about it. They should comply to the SMPP spec. BR, Nikos -- Forwarded message -- From: Latitude Test latitude...@googlemail.com Date: Mon, Oct 19, 2009 at 3:29 PM Subject: Re: getting delivery report: delivery failure To: Nikos Balkanas n...@amdtelecom.net Cc: users users@kannel.org Are you saying dlvrd and sub are mandatory for Kannel? 2009/10/19 Nikos Balkanas n...@amdtelecom.net Yes, but it is required to be there. I am not making the spec. Nikos - Original Message - *From:* Latitude Test latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *Sent:* Monday, October 19, 2009 2:49 PM *Subject:* Fwd: getting delivery report: delivery failure Adding to it, I saw Kannel sending me correct DLRs with another SMSC and in the logs I saw the following: dlvrd:001 sub:001 Text:. The mendatory field Text does not contain any useful info here. How kannel knows the status of the message then? Seems it uses the optional fields which are sub and dlvrd. Please confirm. Thanks. -- Forwarded message -- From: Latitude Test latitude.de@
Re: getting delivery report: delivery failure
On Mon, 2009-10-19 at 17:04, Alejandro Guerrieri wrote: There's not a standarized format... how could this be a bug? Obviously, it _is_ bug if the format is not standardized and kannel fails. If kannel parses non-standard text it should not fail in case the text is not in the format it expects. Kannel relies on what's considered a typical example and in fact it's being used by the vast majority of SMSC's out there (Believe me, I've connected with over 50 different SMSC's all over the world and never experienced an issue). I didn't yet seen a different format than a typical example (except one null terminated), too. If you need to deal with a different format and the SMSC can't/don't want to change their format, you'll need to patch kannel to use a different sscanf string (it's a simple patch if you know where to touch). I can patch (and adapt source for my needs) but there are a lot of people who can't do that. They will see that as bug. Regards, Alejandro flame on PS: Please keep your views about the top/bottom posting for yourself. Posting off-topic and breaking the former email reading order is far more annoying than top-posting (which it seems to be the norm for a lot of people nowadays, either you like it or not). You are wrong here. Top-posting in mailing list is always wrong. flame off On Mon, Oct 19, 2009 at 4:48 PM, Milan P. Stanic m...@arvanta.net wrote: Hi, A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? On Mon, 2009-10-19 at 16:29, Alejandro Guerrieri wrote: As you can confirm by reading the 3.4 spec (Appendix B), the format is far from an established standard: *Delivery Receipt Format* SMPP provides for return of an SMSC delivery receipt via the *deliver_sm* or *data_sm* PDU, which indicates the delivery status of the message. The informational content of an SMSC Delivery Receipt may be inserted into the *short_message* parameter of the *deliver_sm *operation. *The format for this Delivery Receipt** **message is SMSC vendor specific but following is a typical example of Delivery Receipt report.** * “*id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .”* Kannel expects that format, a missing field will definitely confuse sscanf. If the kannel relies on not standardized format then that _is_ the bug in kannel. Regards, Alejandro 2009/10/19 Nikos Balkanas n...@amdtelecom.net Hi, You seem to have the spec. Just read which fields are mandatory from there. Kannel requires mandatory fields. Kannel will use optional fields, if they exist, but it doesn't reuire them. Optional fields are: sub, dlvrd err. Read the spec. Nikos - Original Message - *From:* Latitude Test latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *Sent:* Monday, October 19, 2009 4:59 PM *Subject:* Fwd: getting delivery report: delivery failure I will contact my SMSC but I need to know exactly which fields are really being used by Kannel to return the DLR status?. Seems to me that Kannel is using *optional fields* like sub and dlvrd. If thats true, then isn't is a bug? Quoting Nokos Hi, It seems that your SMSc is sending out the wrong DLR format. According to SMPP 3.4 specs: “ *id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .”* Several optional fields (sub, dlvrd, err) are missing, but also a required field: Text. Without it kannel cannot understand the DLR. Contact your SMSc about it. They should comply to the SMPP spec. BR, Nikos -- Forwarded message -- From: Latitude Test latitude...@googlemail.com Date: Mon, Oct 19, 2009 at 3:29 PM Subject: Re: getting delivery report: delivery failure To: Nikos Balkanas n...@amdtelecom.net Cc: users users@kannel.org Are you saying dlvrd and sub are mandatory for Kannel? 2009/10/19 Nikos Balkanas n...@amdtelecom.net Yes, but it is required to be there. I am not making the spec. Nikos - Original Message - *From:* Latitude Test latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *Sent:* Monday, October 19, 2009 2:49 PM *Subject:* Fwd: getting delivery report: delivery failure Adding to it, I saw Kannel sending me correct DLRs with another SMSC and in the logs I saw the following: dlvrd:001 sub:001 Text:. The mendatory field Text does not contain any useful
nokia 3500c?
i would like to know if Nokia 3500c works to get sms queue on kannel , i tried init-string = ATF and it works only to send sms. Exists any AT+CNMI= to get the messages that nokia 3500c recives? i need send and recive Thanks for help Adolfo
Re: getting delivery report: delivery failure
I had similar issues three times. In two of the cases the telco people was not able or not willing to change the response. So I just did a work arround. At the last case the telco ppl were just convinced they have to implement the changes at their side because of the fact the other telco operators in the country use the same response structure /readable by kannel/. So, kannel is not ultimate ESME client. As there is no ultimate SMSC server. Bug definition is for the developers list I think ?:) And if someone has the patch dealing with all the DLR related issues ... well it will be nice to share. Kind regards Alejandro Guerrieri wrote: not relevant !== optional. Where did you read optional or can be removed? Again, this is NOT a standard, and it's documented by example, which it's imho a flaw on the spec's strictness, but it is what it is. The fact that most smsc's uses that format makes a strong point for kannel to use it as well. For the small fraction of smscs that don't use it the only alternative right now is to patch the source code, I'm afraid. Regards, Alejandro 2009/10/19 Nikos Balkanas n...@amdtelecom.net mailto:n...@amdtelecom.net Sorry, Alej, You are in the wrong here. In the spec some of these fields are declared as optional, and others as not: msgid: The message ID allocated to the message by the SMSC when originally submitted. sub: Number of short messages originally submitted. This is only *relevant *when the original message was submitted to a distribution list.The value is padded with leading zeros if necessary. dlvr: Number of short messages delivered. This is only *relevant* where the original message was submitted to a distribution list.The value ispadded with leading zeros if necessary. err: Where *appropriate* this may hold a Network specific error code or an SMSC error code for the attempted delivery of the message. These errors are Network or SMSC specific and are not included here. These can be omitted according to the spec. Furthermore, kannel doesn't rely exclusively in sscanf , but also falls back in the old way, as stated in the warning, where it manually scans for the variables it needs. In the old way it is much more flexible. @Test: I have provided you with a patch, please test and let's take it from there. Let's stop the spam, until it's needed. BR, Nikos - Original Message - *From:* Alejandro Guerrieri mailto:alejandro.guerri...@gmail.com *To:* Latitude Test mailto:latitude...@googlemail.com *Cc:* Nikos Balkanas mailto:n...@amdtelecom.net ; users mailto:users@kannel.org *Sent:* Monday, October 19, 2009 5:50 PM *Subject:* Re: getting delivery report: delivery failure Sorry, what optional fields are you talking about? sub: and dlvrd: are _not_ optional parameters but part of the de facto standard for DLR format. The only optional parameter honored by kannel on DLR's is network_error_code but it's not mandatory: if present, Kannel will use it to determine if a DLR was successful, otherwise it'll rely solely on the DLR text field. Regards, Alejandro On Mon, Oct 19, 2009 at 4:42 PM, Latitude Test latitude.de@ mailto:latitude...@googlemail.comgooglemail.com http://googlemail.com wrote: I have SMPP 3.4 specs but it doesn't give any info on mandatory/optional fields when it comes to DLR format. 2009/10/19 Nikos Balkanas n...@amdtelecom.net mailto:n...@amdtelecom.net Hi, You seem to have the spec. Just read which fields are mandatory from there. Kannel requires mandatory fields. Kannel will use optional fields, if they exist, but it doesn't reuire them. Optional fields are: sub, dlvrd err. Read the spec. Nikos - Original Message - *From:* Latitude Test mailto:latitude...@googlemail.com *To:* users mailto:users@kannel.org ; Nikos Balkanas mailto:nbalka...@gmail.com *Sent:* Monday, October 19, 2009 4:59 PM *Subject:* Fwd: getting delivery report: delivery failure I will contact my SMSC but I need to know exactly which fields are really being used by Kannel to return the DLR status?. Seems to me that Kannel is using *optional fields* like sub and dlvrd. If thats true, then isn't is a bug?
Re: getting delivery report: delivery failure
What would be the proper behavior in your opinion? Imho it's not a bug, perhaps a limitation. Could it be changed to make it configurable? Sure, your patch is more than welcome :) Regards, Alejandro On Mon, Oct 19, 2009 at 5:21 PM, Milan P. Stanic m...@arvanta.net wrote: On Mon, 2009-10-19 at 17:04, Alejandro Guerrieri wrote: There's not a standarized format... how could this be a bug? Obviously, it _is_ bug if the format is not standardized and kannel fails. If kannel parses non-standard text it should not fail in case the text is not in the format it expects. Kannel relies on what's considered a typical example and in fact it's being used by the vast majority of SMSC's out there (Believe me, I've connected with over 50 different SMSC's all over the world and never experienced an issue). I didn't yet seen a different format than a typical example (except one null terminated), too. If you need to deal with a different format and the SMSC can't/don't want to change their format, you'll need to patch kannel to use a different sscanf string (it's a simple patch if you know where to touch). I can patch (and adapt source for my needs) but there are a lot of people who can't do that. They will see that as bug. Regards, Alejandro flame on PS: Please keep your views about the top/bottom posting for yourself. Posting off-topic and breaking the former email reading order is far more annoying than top-posting (which it seems to be the norm for a lot of people nowadays, either you like it or not). You are wrong here. Top-posting in mailing list is always wrong. flame off On Mon, Oct 19, 2009 at 4:48 PM, Milan P. Stanic m...@arvanta.net wrote: Hi, A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? On Mon, 2009-10-19 at 16:29, Alejandro Guerrieri wrote: As you can confirm by reading the 3.4 spec (Appendix B), the format is far from an established standard: *Delivery Receipt Format* SMPP provides for return of an SMSC delivery receipt via the *deliver_sm* or *data_sm* PDU, which indicates the delivery status of the message. The informational content of an SMSC Delivery Receipt may be inserted into the *short_message* parameter of the *deliver_sm *operation. *The format for this Delivery Receipt** **message is SMSC vendor specific but following is a typical example of Delivery Receipt report.** * “*id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .”* Kannel expects that format, a missing field will definitely confuse sscanf. If the kannel relies on not standardized format then that _is_ the bug in kannel. Regards, Alejandro 2009/10/19 Nikos Balkanas n...@amdtelecom.net Hi, You seem to have the spec. Just read which fields are mandatory from there. Kannel requires mandatory fields. Kannel will use optional fields, if they exist, but it doesn't reuire them. Optional fields are: sub, dlvrd err. Read the spec. Nikos - Original Message - *From:* Latitude Test latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *Sent:* Monday, October 19, 2009 4:59 PM *Subject:* Fwd: getting delivery report: delivery failure I will contact my SMSC but I need to know exactly which fields are really being used by Kannel to return the DLR status?. Seems to me that Kannel is using *optional fields* like sub and dlvrd. If thats true, then isn't is a bug? Quoting Nokos Hi, It seems that your SMSc is sending out the wrong DLR format. According to SMPP 3.4 specs: “ *id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .”* Several optional fields (sub, dlvrd, err) are missing, but also a required field: Text. Without it kannel cannot understand the DLR. Contact your SMSc about it. They should comply to the SMPP spec. BR, Nikos -- Forwarded message -- From: Latitude Test latitude...@googlemail.com Date: Mon, Oct 19, 2009 at 3:29 PM Subject: Re: getting delivery report: delivery failure To: Nikos Balkanas n...@amdtelecom.net Cc: users users@kannel.org Are you saying dlvrd and sub are mandatory for Kannel? 2009/10/19 Nikos Balkanas n...@amdtelecom.net Yes, but it is required to be there. I am not making the spec. Nikos - Original Message - *From:* Latitude
Re: getting delivery report: delivery failure
On Mon, 2009-10-19 at 17:36, Alejandro Guerrieri wrote: What would be the proper behavior in your opinion? Imho it's not a bug, perhaps a limitation. It is not bug if we all expect that behavior, but because at least one user have a problem with it, it _is_ bug for him. It didn't bite me so I don't care, actually ;) Could it be changed to make it configurable? Sure, your patch is more than welcome :) Heh... standard excuse here: not enough time. :( Regards, Alejandro On Mon, Oct 19, 2009 at 5:21 PM, Milan P. Stanic m...@arvanta.net wrote: On Mon, 2009-10-19 at 17:04, Alejandro Guerrieri wrote: There's not a standarized format... how could this be a bug? Obviously, it _is_ bug if the format is not standardized and kannel fails. If kannel parses non-standard text it should not fail in case the text is not in the format it expects. Kannel relies on what's considered a typical example and in fact it's being used by the vast majority of SMSC's out there (Believe me, I've connected with over 50 different SMSC's all over the world and never experienced an issue). I didn't yet seen a different format than a typical example (except one null terminated), too. If you need to deal with a different format and the SMSC can't/don't want to change their format, you'll need to patch kannel to use a different sscanf string (it's a simple patch if you know where to touch). I can patch (and adapt source for my needs) but there are a lot of people who can't do that. They will see that as bug. Regards, Alejandro flame on PS: Please keep your views about the top/bottom posting for yourself. Posting off-topic and breaking the former email reading order is far more annoying than top-posting (which it seems to be the norm for a lot of people nowadays, either you like it or not). You are wrong here. Top-posting in mailing list is always wrong. flame off On Mon, Oct 19, 2009 at 4:48 PM, Milan P. Stanic m...@arvanta.net wrote: Hi, A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? On Mon, 2009-10-19 at 16:29, Alejandro Guerrieri wrote: As you can confirm by reading the 3.4 spec (Appendix B), the format is far from an established standard: *Delivery Receipt Format* SMPP provides for return of an SMSC delivery receipt via the *deliver_sm* or *data_sm* PDU, which indicates the delivery status of the message. The informational content of an SMSC Delivery Receipt may be inserted into the *short_message* parameter of the *deliver_sm *operation. *The format for this Delivery Receipt** **message is SMSC vendor specific but following is a typical example of Delivery Receipt report.** * “*id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .”* Kannel expects that format, a missing field will definitely confuse sscanf. If the kannel relies on not standardized format then that _is_ the bug in kannel. Regards, Alejandro 2009/10/19 Nikos Balkanas n...@amdtelecom.net Hi, You seem to have the spec. Just read which fields are mandatory from there. Kannel requires mandatory fields. Kannel will use optional fields, if they exist, but it doesn't reuire them. Optional fields are: sub, dlvrd err. Read the spec. Nikos - Original Message - *From:* Latitude Test latitude...@googlemail.com *To:* users users@kannel.org ; Nikos Balkanas nbalka...@gmail.com *Sent:* Monday, October 19, 2009 4:59 PM *Subject:* Fwd: getting delivery report: delivery failure I will contact my SMSC but I need to know exactly which fields are really being used by Kannel to return the DLR status?. Seems to me that Kannel is using *optional fields* like sub and dlvrd. If thats true, then isn't is a bug? Quoting Nokos Hi, It seems that your SMSc is sending out the wrong DLR format. According to SMPP 3.4 specs: “ *id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done* *date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .”* Several optional fields (sub, dlvrd, err) are missing, but also a required field: Text. Without it kannel cannot understand the DLR. Contact your SMSc about it. They should comply to the SMPP spec. BR, Nikos -- Forwarded message -- From: Latitude Test latitude...@googlemail.com Date: Mon, Oct
Re: getting delivery report: delivery failure
You are right. Not relevant == irrelevant. Which means simply don't use it. Stronger word than optional, I would think. Anyway, I think that the consensus is for patching. Let's focus on that. Nikos - Original Message - From: Alejandro Guerrieri To: Nikos Balkanas Cc: Latitude Test ; users Sent: Monday, October 19, 2009 6:16 PM Subject: Re: getting delivery report: delivery failure not relevant !== optional. Where did you read optional or can be removed? Again, this is NOT a standard, and it's documented by example, which it's imho a flaw on the spec's strictness, but it is what it is. The fact that most smsc's uses that format makes a strong point for kannel to use it as well. For the small fraction of smscs that don't use it the only alternative right now is to patch the source code, I'm afraid. Regards, Alejandro 2009/10/19 Nikos Balkanas n...@amdtelecom.net Sorry, Alej, You are in the wrong here. In the spec some of these fields are declared as optional, and others as not: msgid: The message ID allocated to the message by the SMSC when originally submitted. sub: Number of short messages originally submitted. This is only relevant when the original message was submitted to a distribution list.The value is padded with leading zeros if necessary. dlvr: Number of short messages delivered. This is only relevant where the original message was submitted to a distribution list.The value ispadded with leading zeros if necessary. err: Where appropriate this may hold a Network specific error code or an SMSC error code for the attempted delivery of the message. These errors are Network or SMSC specific and are not included here. These can be omitted according to the spec. Furthermore, kannel doesn't rely exclusively in sscanf , but also falls back in the old way, as stated in the warning, where it manually scans for the variables it needs. In the old way it is much more flexible. @Test: I have provided you with a patch, please test and let's take it from there. Let's stop the spam, until it's needed. BR, Nikos - Original Message - From: Alejandro Guerrieri To: Latitude Test Cc: Nikos Balkanas ; users Sent: Monday, October 19, 2009 5:50 PM Subject: Re: getting delivery report: delivery failure Sorry, what optional fields are you talking about? sub: and dlvrd: are _not_ optional parameters but part of the de facto standard for DLR format. The only optional parameter honored by kannel on DLR's is network_error_code but it's not mandatory: if present, Kannel will use it to determine if a DLR was successful, otherwise it'll rely solely on the DLR text field. Regards, Alejandro On Mon, Oct 19, 2009 at 4:42 PM, Latitude Test latitude...@googlemail.com wrote: I have SMPP 3.4 specs but it doesn't give any info on mandatory/optional fields when it comes to DLR format. 2009/10/19 Nikos Balkanas n...@amdtelecom.net Hi, You seem to have the spec. Just read which fields are mandatory from there. Kannel requires mandatory fields. Kannel will use optional fields, if they exist, but it doesn't reuire them. Optional fields are: sub, dlvrd err. Read the spec. Nikos - Original Message - From: Latitude Test To: users ; Nikos Balkanas Sent: Monday, October 19, 2009 4:59 PM Subject: Fwd: getting delivery report: delivery failure I will contact my SMSC but I need to know exactly which fields are really being used by Kannel to return the DLR status?. Seems to me that Kannel is using optional fields like sub and dlvrd. If thats true, then isn't is a bug? Quoting Nokos Hi, It seems that your SMSc is sending out the wrong DLR format. According to SMPP 3.4 specs: “ id:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDD err:E Text: . . . . . . . . .” Several optional fields (sub, dlvrd, err) are missing, but also a required field: Text. Without it kannel cannot understand the DLR. Contact your SMSc about it. They should comply to the SMPP spec. BR, Nikos -- Forwarded message -- From: Latitude Test latitude...@googlemail.com Date: Mon, Oct 19, 2009 at 3:29 PM Subject: Re: getting delivery report: delivery failure To: Nikos Balkanas n...@amdtelecom.net Cc: users users@kannel.org Are you saying dlvrd and sub are mandatory for Kannel? 2009/10/19 Nikos Balkanas n...@amdtelecom.net Yes, but it is required to be there. I am not making the spec.
Fw: only receiving DLR type=8
Hi List,
Below is the kannel.log and configuration file.
I am only receiving DLR type=8 i.e SMSC submit.
How can I recieve Other DLR type=1 2 or 5 ?
Plese any one help me
I am using kannel-1.4.3, DLR mask 31
2009-10-18 12:28:22 [15936] [6] DEBUG: SMPP[Id72]: Sending
PDU:
2009-10-18 12:28:22 [15936] [6] DEBUG: SMPP PDU 0x9c4e3e8
dump:
2009-10-18 12:28:22 [15936] [6]
DEBUG: type_name: submit_sm
2009-10-18 12:28:22 [15936] [6]
DEBUG: command_id: 4 = 0x0004
2009-10-18 12:28:22 [15936] [6]
DEBUG: command_status: 0 = 0x
2009-10-18 12:28:22 [15936] [6]
DEBUG: sequence_number: 575 = 0x023f
2009-10-18 12:28:22 [15936] [6]
DEBUG: service_type: NULL
2009-10-18 12:28:22 [15936] [6]
DEBUG: source_addr_ton: 5 = 0x0005
2009-10-18 12:28:22 [15936] [6]
DEBUG: source_addr_npi: 0 = 0x
2009-10-18 12:28:22 [15936] [6]
DEBUG: source_addr: Lalit
2009-10-18 12:28:22 [15936] [6]
DEBUG: dest_addr_ton: 2 = 0x0002
2009-10-18 12:28:22 [15936] [6]
DEBUG: dest_addr_npi: 1 = 0x0001
2009-10-18 12:28:22 [15936] [6]
DEBUG: destination_addr: 919868311699
2009-10-18 12:28:22 [15936] [6]
DEBUG: esm_class: 3 = 0x0003
2009-10-18 12:28:22 [15936] [6]
DEBUG: protocol_id: 0 = 0x
2009-10-18 12:28:22 [15936] [6]
DEBUG: priority_flag: 0 = 0x
2009-10-18 12:28:22 [15936] [6]
DEBUG: schedule_delivery_time: NULL
2009-10-18 12:28:22 [15936] [6]
DEBUG: validity_period: NULL
2009-10-18 12:28:22 [15936] [6]
DEBUG: registered_delivery: 1 = 0x0001
2009-10-18 12:28:22 [15936] [6]
DEBUG: replace_if_present_flag: 0 =
0x
2009-10-18 12:28:22 [15936] [6]
DEBUG: data_coding: 242 = 0x00f2
2009-10-18 12:28:22 [15936] [6]
DEBUG: sm_default_msg_id: 0 = 0x
2009-10-18 12:28:22 [15936] [6]
DEBUG: sm_length: 14 = 0x000e
2009-10-18 12:28:22 [15936] [6]
DEBUG: short_message: Jai Ram-sunil
2009-10-18 12:28:22 [15936] [6] DEBUG: SMPP PDU dump ends.
2009-10-18 12:28:22 [15936] [6] DEBUG: SMPP[Id72]: Got
PDU:
2009-10-18 12:28:22 [15936] [6] DEBUG: SMPP PDU 0x9c4e3e8
dump:
2009-10-18 12:28:22 [15936] [6]
DEBUG: type_name: submit_sm_resp
2009-10-18 12:28:22 [15936] [6]
DEBUG: command_id: 2147483652 = 0x8004
2009-10-18 12:28:22 [15936] [6]
DEBUG: command_status: 0 = 0x
2009-10-18 12:28:22 [15936] [6]
DEBUG: sequence_number: 575 = 0x023f
2009-10-18 12:28:22 [15936] [6]
DEBUG: message_id: 4ADA0A0E
2009-10-18 12:28:22 [15936] [6] DEBUG: SMPP PDU dump ends.
2009-10-18 12:28:22 [15936] [6] DEBUG: DLR[mysql]: Adding
DLR smsc=Id72, ts=4ADA0A0E, src=Lalit, dst=919868311699,
mask=31, boxc=dlrbox
2009-10-18 12:28:22 [15936] [6] DEBUG: sql: INSERT INTO dlr
(smsc, ts, source, destination, service, url, mask, boxc,
status) VALUES ('Id72', '4ADA0A0E', 'Lalit', '919868311699',
'playsms',
'http://localhost/smsadmin/plugin/gateway/kannel/dlr.php?type=%dslid=749uid=7',
'31', 'dlrbox', '0');
2009-10-18 12:28:22 [15936] [6] DEBUG: SMSC[Id72]: creating
DLR message
2009-10-18 12:28:22 [15936] [6] DEBUG: SMSC[Id72]: DLR =
http://localhost/smsadmin/plugin/gateway/kannel/dlr.php?type=%dslid=749uid=7
2009-10-18 12:28:22 [15936] [9] DEBUG: send_msg: sending
msg to boxc: dlrbox
2009-10-18 12:28:22 [15936] [9] DEBUG: boxc_sender: sent
message to 127.0.0.1
2009-10-18 12:28:22 [15936] [8] DEBUG: boxc_receiver: got
ack
###Kannel CONF FILE##
group = core
admin-port = 13000
admin-password = **
status-password = **
log-file = /var/log/kannel/kannel.log
log-level = 0
access-log = /var/log/kannel/access.log
smsbox-port = 13001
#store-file = /var/log/kannel/kannel.store
#store-location = /var/log/kannel/kannel.store
sms-resend-retry = 5
dlr-storage = mysql
# SMSC SMPP
group = smsc
smsc = smpp
smsc-id = Id72
host = *
port = 8899
smsc-username = *
smsc-password = *
system-type = VMA
msg-id-type=0x01
# SMSBOX SETUP
group = smsbox
smsbox-id = dlrbox
bearerbox-host = localhost
sendsms-port = 13131
sendsms-chars = 0123456789+
log-file = /var/log/kannel/smsbox.log
log-level = 0
access-log = /var/log/kannel/access.log
# SEND-SMS USERS
group = sendsms-user
username = *
password = *
# SMS SERVICE 'Default'
# there should be default always
group = sms-service
keyword = default
#exec = /usr/local/bin/kannel_incoming %t %q %a
get-url =
http://localhost/smsadmin/plugin/gateway/kannel/geturl.php?t=%tq=%qa=%ad=%d;
# Example defining a MySQL database connection resource
and
# the required table and field values.
#
group = mysql-connection
id = mydlr
host = localhost
username = *
password =
database = mysms
# max count of connections that will be opened for dbpool
# default is 1
max-connections = 3
group = dlr-db
id = mydlr
table = dlr
field-smsc = smsc
field-timestamp = ts
field-destination = destination
field-source = source
field-service = service
Re: only receiving DLR type=8
Hi,
Please post your send-url. Have you tested it with your mobile? Is the SMS
received?
BR,
Nikos
- Original Message -
From: Sunil Soni sunil.s...@yahoo.co.in
To: users@kannel.org
Sent: Monday, October 19, 2009 9:04 PM
Subject: Fw: only receiving DLR type=8
Hi List,
Below is the kannel.log and configuration file.
I am only receiving DLR type=8 i.e SMSC submit.
How can I recieve Other DLR type=1 2 or 5 ?
Plese any one help me
I am using kannel-1.4.3, DLR mask 31
2009-10-18 12:28:22 [15936] [6] DEBUG: SMPP[Id72]: Sending
PDU:
2009-10-18 12:28:22 [15936] [6] DEBUG: SMPP PDU 0x9c4e3e8
dump:
2009-10-18 12:28:22 [15936] [6]
DEBUG: type_name: submit_sm
2009-10-18 12:28:22 [15936] [6]
DEBUG: command_id: 4 = 0x0004
2009-10-18 12:28:22 [15936] [6]
DEBUG: command_status: 0 = 0x
2009-10-18 12:28:22 [15936] [6]
DEBUG: sequence_number: 575 = 0x023f
2009-10-18 12:28:22 [15936] [6]
DEBUG: service_type: NULL
2009-10-18 12:28:22 [15936] [6]
DEBUG: source_addr_ton: 5 = 0x0005
2009-10-18 12:28:22 [15936] [6]
DEBUG: source_addr_npi: 0 = 0x
2009-10-18 12:28:22 [15936] [6]
DEBUG: source_addr: Lalit
2009-10-18 12:28:22 [15936] [6]
DEBUG: dest_addr_ton: 2 = 0x0002
2009-10-18 12:28:22 [15936] [6]
DEBUG: dest_addr_npi: 1 = 0x0001
2009-10-18 12:28:22 [15936] [6]
DEBUG: destination_addr: 919868311699
2009-10-18 12:28:22 [15936] [6]
DEBUG: esm_class: 3 = 0x0003
2009-10-18 12:28:22 [15936] [6]
DEBUG: protocol_id: 0 = 0x
2009-10-18 12:28:22 [15936] [6]
DEBUG: priority_flag: 0 = 0x
2009-10-18 12:28:22 [15936] [6]
DEBUG: schedule_delivery_time: NULL
2009-10-18 12:28:22 [15936] [6]
DEBUG: validity_period: NULL
2009-10-18 12:28:22 [15936] [6]
DEBUG: registered_delivery: 1 = 0x0001
2009-10-18 12:28:22 [15936] [6]
DEBUG: replace_if_present_flag: 0 =
0x
2009-10-18 12:28:22 [15936] [6]
DEBUG: data_coding: 242 = 0x00f2
2009-10-18 12:28:22 [15936] [6]
DEBUG: sm_default_msg_id: 0 = 0x
2009-10-18 12:28:22 [15936] [6]
DEBUG: sm_length: 14 = 0x000e
2009-10-18 12:28:22 [15936] [6]
DEBUG: short_message: Jai Ram-sunil
2009-10-18 12:28:22 [15936] [6] DEBUG: SMPP PDU dump ends.
2009-10-18 12:28:22 [15936] [6] DEBUG: SMPP[Id72]: Got
PDU:
2009-10-18 12:28:22 [15936] [6] DEBUG: SMPP PDU 0x9c4e3e8
dump:
2009-10-18 12:28:22 [15936] [6]
DEBUG: type_name: submit_sm_resp
2009-10-18 12:28:22 [15936] [6]
DEBUG: command_id: 2147483652 = 0x8004
2009-10-18 12:28:22 [15936] [6]
DEBUG: command_status: 0 = 0x
2009-10-18 12:28:22 [15936] [6]
DEBUG: sequence_number: 575 = 0x023f
2009-10-18 12:28:22 [15936] [6]
DEBUG: message_id: 4ADA0A0E
2009-10-18 12:28:22 [15936] [6] DEBUG: SMPP PDU dump ends.
2009-10-18 12:28:22 [15936] [6] DEBUG: DLR[mysql]: Adding
DLR smsc=Id72, ts=4ADA0A0E, src=Lalit, dst=919868311699,
mask=31, boxc=dlrbox
2009-10-18 12:28:22 [15936] [6] DEBUG: sql: INSERT INTO dlr
(smsc, ts, source, destination, service, url, mask, boxc,
status) VALUES ('Id72', '4ADA0A0E', 'Lalit', '919868311699',
'playsms',
'http://localhost/smsadmin/plugin/gateway/kannel/dlr.php?type=%dslid=749uid=7',
'31', 'dlrbox', '0');
2009-10-18 12:28:22 [15936] [6] DEBUG: SMSC[Id72]: creating
DLR message
2009-10-18 12:28:22 [15936] [6] DEBUG: SMSC[Id72]: DLR =
http://localhost/smsadmin/plugin/gateway/kannel/dlr.php?type=%dslid=749uid=7
2009-10-18 12:28:22 [15936] [9] DEBUG: send_msg: sending
msg to boxc: dlrbox
2009-10-18 12:28:22 [15936] [9] DEBUG: boxc_sender: sent
message to 127.0.0.1
2009-10-18 12:28:22 [15936] [8] DEBUG: boxc_receiver: got
ack
###Kannel CONF FILE##
group = core
admin-port = 13000
admin-password = **
status-password = **
log-file = /var/log/kannel/kannel.log
log-level = 0
access-log = /var/log/kannel/access.log
smsbox-port = 13001
#store-file = /var/log/kannel/kannel.store
#store-location = /var/log/kannel/kannel.store
sms-resend-retry = 5
dlr-storage = mysql
# SMSC SMPP
group = smsc
smsc = smpp
smsc-id = Id72
host = *
port = 8899
smsc-username = *
smsc-password = *
system-type = VMA
msg-id-type=0x01
# SMSBOX SETUP
group = smsbox
smsbox-id = dlrbox
bearerbox-host = localhost
sendsms-port = 13131
sendsms-chars = 0123456789+
log-file = /var/log/kannel/smsbox.log
log-level = 0
access-log = /var/log/kannel/access.log
# SEND-SMS USERS
group = sendsms-user
username = *
password = *
# SMS SERVICE 'Default'
# there should be default always
group = sms-service
keyword = default
#exec = /usr/local/bin/kannel_incoming %t %q %a
get-url =
http://localhost/smsadmin/plugin/gateway/kannel/geturl.php?t=%tq=%qa=%ad=%d;
# Example defining a MySQL database connection resource
and
# the required table and field values.
#
group = mysql-connection
id = mydlr
host = localhost
username = *
password =
database = mysms
# max count of connections that will be opened for dbpool
# default is 1
max-connections = 3
group = dlr-db
id = mydlr
table = dlr
field-smsc =
Re: Fw: only receiving DLR type=8
bind as transceiver
not as transmitter:
group = smsc
...
transceiver-mode = true
Sunil Soni wrote:
Hi List,
Below is the kannel.log and configuration file.
I am only receiving DLR type=8 i.e SMSC submit.
How can I recieve Other DLR type=1 2 or 5 ?
Plese any one help me
I am using kannel-1.4.3, DLR mask 31
2009-10-18 12:28:22 [15936] [6] DEBUG: SMPP[Id72]: Sending
PDU:
2009-10-18 12:28:22 [15936] [6] DEBUG: SMPP PDU 0x9c4e3e8
dump:
2009-10-18 12:28:22 [15936] [6]
DEBUG: type_name: submit_sm
2009-10-18 12:28:22 [15936] [6]
DEBUG: command_id: 4 = 0x0004
2009-10-18 12:28:22 [15936] [6]
DEBUG: command_status: 0 = 0x
2009-10-18 12:28:22 [15936] [6]
DEBUG: sequence_number: 575 = 0x023f
2009-10-18 12:28:22 [15936] [6]
DEBUG: service_type: NULL
2009-10-18 12:28:22 [15936] [6]
DEBUG: source_addr_ton: 5 = 0x0005
2009-10-18 12:28:22 [15936] [6]
DEBUG: source_addr_npi: 0 = 0x
2009-10-18 12:28:22 [15936] [6]
DEBUG: source_addr: Lalit
2009-10-18 12:28:22 [15936] [6]
DEBUG: dest_addr_ton: 2 = 0x0002
2009-10-18 12:28:22 [15936] [6]
DEBUG: dest_addr_npi: 1 = 0x0001
2009-10-18 12:28:22 [15936] [6]
DEBUG: destination_addr: 919868311699
2009-10-18 12:28:22 [15936] [6]
DEBUG: esm_class: 3 = 0x0003
2009-10-18 12:28:22 [15936] [6]
DEBUG: protocol_id: 0 = 0x
2009-10-18 12:28:22 [15936] [6]
DEBUG: priority_flag: 0 = 0x
2009-10-18 12:28:22 [15936] [6]
DEBUG: schedule_delivery_time: NULL
2009-10-18 12:28:22 [15936] [6]
DEBUG: validity_period: NULL
2009-10-18 12:28:22 [15936] [6]
DEBUG: registered_delivery: 1 = 0x0001
2009-10-18 12:28:22 [15936] [6]
DEBUG: replace_if_present_flag: 0 =
0x
2009-10-18 12:28:22 [15936] [6]
DEBUG: data_coding: 242 = 0x00f2
2009-10-18 12:28:22 [15936] [6]
DEBUG: sm_default_msg_id: 0 = 0x
2009-10-18 12:28:22 [15936] [6]
DEBUG: sm_length: 14 = 0x000e
2009-10-18 12:28:22 [15936] [6]
DEBUG: short_message: Jai Ram-sunil
2009-10-18 12:28:22 [15936] [6] DEBUG: SMPP PDU dump ends.
2009-10-18 12:28:22 [15936] [6] DEBUG: SMPP[Id72]: Got
PDU:
2009-10-18 12:28:22 [15936] [6] DEBUG: SMPP PDU 0x9c4e3e8
dump:
2009-10-18 12:28:22 [15936] [6]
DEBUG: type_name: submit_sm_resp
2009-10-18 12:28:22 [15936] [6]
DEBUG: command_id: 2147483652 = 0x8004
2009-10-18 12:28:22 [15936] [6]
DEBUG: command_status: 0 = 0x
2009-10-18 12:28:22 [15936] [6]
DEBUG: sequence_number: 575 = 0x023f
2009-10-18 12:28:22 [15936] [6]
DEBUG: message_id: 4ADA0A0E
2009-10-18 12:28:22 [15936] [6] DEBUG: SMPP PDU dump ends.
2009-10-18 12:28:22 [15936] [6] DEBUG: DLR[mysql]: Adding
DLR smsc=Id72, ts=4ADA0A0E, src=Lalit, dst=919868311699,
mask=31, boxc=dlrbox
2009-10-18 12:28:22 [15936] [6] DEBUG: sql: INSERT INTO dlr
(smsc, ts, source, destination, service, url, mask, boxc,
status) VALUES ('Id72', '4ADA0A0E', 'Lalit', '919868311699',
'playsms',
'http://localhost/smsadmin/plugin/gateway/kannel/dlr.php?type=%dslid=749uid=7',
'31', 'dlrbox', '0');
2009-10-18 12:28:22 [15936] [6] DEBUG: SMSC[Id72]: creating
DLR message
2009-10-18 12:28:22 [15936] [6] DEBUG: SMSC[Id72]: DLR =
http://localhost/smsadmin/plugin/gateway/kannel/dlr.php?type=%dslid=749uid=7
2009-10-18 12:28:22 [15936] [9] DEBUG: send_msg: sending
msg to boxc: dlrbox
2009-10-18 12:28:22 [15936] [9] DEBUG: boxc_sender: sent
message to 127.0.0.1
2009-10-18 12:28:22 [15936] [8] DEBUG: boxc_receiver: got
ack
###Kannel CONF FILE##
group = core
admin-port = 13000
admin-password = **
status-password = **
log-file = /var/log/kannel/kannel.log
log-level = 0
access-log = /var/log/kannel/access.log
smsbox-port = 13001
#store-file = /var/log/kannel/kannel.store
#store-location = /var/log/kannel/kannel.store
sms-resend-retry = 5
dlr-storage = mysql
# SMSC SMPP
group = smsc
smsc = smpp
smsc-id = Id72
host = *
port = 8899
smsc-username = *
smsc-password = *
system-type = VMA
msg-id-type=0x01
# SMSBOX SETUP
group = smsbox
smsbox-id = dlrbox
bearerbox-host = localhost
sendsms-port = 13131
sendsms-chars = 0123456789+
log-file = /var/log/kannel/smsbox.log
log-level = 0
access-log = /var/log/kannel/access.log
# SEND-SMS USERS
group = sendsms-user
username = *
password = *
# SMS SERVICE 'Default'
# there should be default always
group = sms-service
keyword = default
#exec = /usr/local/bin/kannel_incoming %t %q %a
get-url =
http://localhost/smsadmin/plugin/gateway/kannel/geturl.php?t=%tq=%qa=%ad=%d;
# Example defining a MySQL database connection resource
and
# the required table and field values.
#
group = mysql-connection
id = mydlr
host = localhost
username = *
password =
database = mysms
# max
Re: nokia 3500c?
You should check the AT manual of your Nokia. We have detected taht some nokia phones does not support CNMI comand... you might need to look for another phone. Regards Alvaro |-| Envíe y Reciba Datos y mensajes de Texto (SMS) hacia y desde cualquier celular y Nextel en el Perú, México y en mas de 180 paises. Use aplicaciones 2 vias via SMS y GPRS online Visitenos en www.perusms.NET www.smsglobal.com.mx y www.pravcom.com On Mon, Oct 19, 2009 at 10:26 AM, adolfo feria adolfofe...@gmail.com wrote: i would like to know if Nokia 3500c works to get sms queue on kannel , i tried init-string = ATF and it works only to send sms. Exists any AT+CNMI= to get the messages that nokia 3500c recives? i need send and recive Thanks for help Adolfo
Kannel / fakesmsc errors Could not open pid-file `10000'
Hello guys, Does anyone know why I am getting these errors when trying to use fakesmsc ? *[r...@elodine ~]# /home/manu/softs/gateway-1.4.3/test/fakesmsc -p 1 -H localhost -i 1 -m 1 111222 99 text MAREE 2009-10-20 08:08:45 [31937] [0] PANIC: Could not open pid-file `1' 2009-10-20 08:08:45 [31937] [0] PANIC: System error 17: File exists 2009-10-20 08:08:45 [31937] [0] PANIC: /home/manu/softs/gateway-1.4.3/test/fakesmsc(gw_panic+0xbc) [0x805e4cc] 2009-10-20 08:08:45 [31937] [0] PANIC: /home/manu/softs/gateway-1.4.3/test/fakesmsc(get_and_set_debugs+0xb3e) [0x806a72e] 2009-10-20 08:08:45 [31937] [0] PANIC: /home/manu/softs/gateway-1.4.3/test/fakesmsc(main+0xbd) [0x804e39d] 2009-10-20 08:08:45 [31937] [0] PANIC: /lib/libc.so.6(__libc_start_main+0xe6) [0x9fd5d6] 2009-10-20 08:08:45 [31937] [0] PANIC: /home/manu/softs/gateway-1.4.3/test/fakesmsc [0x804e1d1] [r...@elodine ~]#* Regards, -- Emmanuel
Re: question about kannel's service
I will try to answer without having clearly understood your question I you want to use mobile devices and Kannel you first have to choose relevants mobiles phones that work with Kannel gateway. All the configuration will be done using configuration files but check the user guide page 56 of the kannel documentation, it explains this precisely. Emmanuel 2009/10/20 David Gerardo dgnava...@estudiantes.uci.cu I have a question ... Kannel the only thing you do is set the configuration variables for communication between mobile devices and services for these devices? At the end you have to configure mobile devices to communicate through the Kannel gateway.? -- Emmanuel CHANSON Emmanuel Mobile Nouvelle-Calédonie: +687 850.850 Mobile France: +33 (0) 6.68.03.89.56 @email : emmanuelchan...@gmail.com
Re: Kannel / fakesmsc errors Could not open pid-file `10000'
Hi, You probably want to use: test/fakesmsc -r 1 ... When in doubt try: test/fakesmsc --help BR, Nikos - Original Message - From: Emmanuel CHANSON To: users@kannel.org Sent: Tuesday, October 20, 2009 12:21 AM Subject: Kannel / fakesmsc errors Could not open pid-file `1' Hello guys, Does anyone know why I am getting these errors when trying to use fakesmsc ? [r...@elodine ~]# /home/manu/softs/gateway-1.4.3/test/fakesmsc -p 1 -H localhost -i 1 -m 1 111222 99 text MAREE 2009-10-20 08:08:45 [31937] [0] PANIC: Could not open pid-file `1' 2009-10-20 08:08:45 [31937] [0] PANIC: System error 17: File exists 2009-10-20 08:08:45 [31937] [0] PANIC: /home/manu/softs/gateway-1.4.3/test/fakesmsc(gw_panic+0xbc) [0x805e4cc] 2009-10-20 08:08:45 [31937] [0] PANIC: /home/manu/softs/gateway-1.4.3/test/fakesmsc(get_and_set_debugs+0xb3e) [0x806a72e] 2009-10-20 08:08:45 [31937] [0] PANIC: /home/manu/softs/gateway-1.4.3/test/fakesmsc(main+0xbd) [0x804e39d] 2009-10-20 08:08:45 [31937] [0] PANIC: /lib/libc.so.6(__libc_start_main+0xe6) [0x9fd5d6] 2009-10-20 08:08:45 [31937] [0] PANIC: /home/manu/softs/gateway-1.4.3/test/fakesmsc [0x804e1d1] [r...@elodine ~]# Regards, -- Emmanuel
Re: Kannel / fakesmsc errors Could not open pid-file `10000'
For your info, when I try -p it will give me something completely different. Still it is a bug, since it is supposed to panic with illegal arguments... Nikos - Original Message - From: Emmanuel CHANSON To: Nikos Balkanas Cc: users@kannel.org Sent: Tuesday, October 20, 2009 4:29 AM Subject: Re: Kannel / fakesmsc errors Could not open pid-file `1' Thanks Nikos, you probably right it works using -r But it worked before using -p so I don't know for what is used -p parameter Regards, Emmanuel 2009/10/20 Nikos Balkanas nbalka...@gmail.com Hi, You probably want to use: test/fakesmsc -r 1 ... When in doubt try: test/fakesmsc --help BR, Nikos - Original Message - From: Emmanuel CHANSON To: users@kannel.org Sent: Tuesday, October 20, 2009 12:21 AM Subject: Kannel / fakesmsc errors Could not open pid-file `1' Hello guys, Does anyone know why I am getting these errors when trying to use fakesmsc ? [r...@elodine ~]# /home/manu/softs/gateway-1.4.3/test/fakesmsc -p 1 -H localhost -i 1 -m 1 111222 99 text MAREE 2009-10-20 08:08:45 [31937] [0] PANIC: Could not open pid-file `1' 2009-10-20 08:08:45 [31937] [0] PANIC: System error 17: File exists 2009-10-20 08:08:45 [31937] [0] PANIC: /home/manu/softs/gateway-1.4.3/test/fakesmsc(gw_panic+0xbc) [0x805e4cc] 2009-10-20 08:08:45 [31937] [0] PANIC: /home/manu/softs/gateway-1.4.3/test/fakesmsc(get_and_set_debugs+0xb3e) [0x806a72e] 2009-10-20 08:08:45 [31937] [0] PANIC: /home/manu/softs/gateway-1.4.3/test/fakesmsc(main+0xbd) [0x804e39d] 2009-10-20 08:08:45 [31937] [0] PANIC: /lib/libc.so.6(__libc_start_main+0xe6) [0x9fd5d6] 2009-10-20 08:08:45 [31937] [0] PANIC: /home/manu/softs/gateway-1.4.3/test/fakesmsc [0x804e1d1] [r...@elodine ~]# Regards, -- Emmanuel -- Emmanuel CHANSON Emmanuel Mobile Nouvelle-Calιdonie: +687 850.850 Mobile France: +33 (0) 6.68.03.89.56 @email : emmanuelchan...@gmail.com
Re: Fw: only receiving DLR type=8
Thanks a lot seikath Now I am able to receving DLR type =1 after binding as
transceiver.
-Thanks
-Sunil
--- On Mon, 19/10/09, seikath seik...@gmail.com wrote:
From: seikath seik...@gmail.com
Subject: Re: Fw: only receiving DLR type=8
To:
Cc: users@kannel.org
Date: Monday, 19 October, 2009, 11:53 PM
bind as transceiver
not as transmitter:
group = smsc
...
transceiver-mode = true
Sunil Soni wrote:
Hi List,
Below is the kannel.log and configuration file.
I am only receiving DLR type=8 i.e SMSC
submit.
How can I recieve Other DLR type=1 2 or 5
?
Plese any one help me
I am using kannel-1.4.3, DLR mask 31
2009-10-18 12:28:22 [15936] [6] DEBUG:
SMPP[Id72]: Sending
PDU:
2009-10-18 12:28:22 [15936] [6] DEBUG: SMPP PDU
0x9c4e3e8
dump:
2009-10-18 12:28:22 [15936] [6]
DEBUG: type_name: submit_sm
2009-10-18 12:28:22 [15936] [6]
DEBUG: command_id: 4 =
0x0004
2009-10-18 12:28:22 [15936] [6]
DEBUG: command_status: 0 =
0x
2009-10-18 12:28:22 [15936] [6]
DEBUG: sequence_number: 575 =
0x023f
2009-10-18 12:28:22 [15936] [6]
DEBUG: service_type: NULL
2009-10-18 12:28:22 [15936] [6]
DEBUG: source_addr_ton: 5 =
0x0005
2009-10-18 12:28:22 [15936] [6]
DEBUG: source_addr_npi: 0 =
0x
2009-10-18 12:28:22 [15936] [6]
DEBUG: source_addr: Lalit
2009-10-18 12:28:22 [15936] [6]
DEBUG: dest_addr_ton: 2 =
0x0002
2009-10-18 12:28:22 [15936] [6]
DEBUG: dest_addr_npi: 1 =
0x0001
2009-10-18 12:28:22 [15936] [6]
DEBUG: destination_addr:
919868311699
2009-10-18 12:28:22 [15936] [6]
DEBUG: esm_class: 3 =
0x0003
2009-10-18 12:28:22 [15936] [6]
DEBUG: protocol_id: 0 =
0x
2009-10-18 12:28:22 [15936] [6]
DEBUG: priority_flag: 0 =
0x
2009-10-18 12:28:22 [15936] [6]
DEBUG: schedule_delivery_time:
NULL
2009-10-18 12:28:22 [15936] [6]
DEBUG: validity_period: NULL
2009-10-18 12:28:22 [15936] [6]
DEBUG: registered_delivery: 1 =
0x0001
2009-10-18 12:28:22 [15936] [6]
DEBUG: replace_if_present_flag:
0 =
0x
2009-10-18 12:28:22 [15936] [6]
DEBUG: data_coding: 242 =
0x00f2
2009-10-18 12:28:22 [15936] [6]
DEBUG: sm_default_msg_id: 0 =
0x
2009-10-18 12:28:22 [15936] [6]
DEBUG: sm_length: 14 =
0x000e
2009-10-18 12:28:22 [15936] [6]
DEBUG: short_message: Jai
Ram-sunil
2009-10-18 12:28:22 [15936] [6] DEBUG: SMPP PDU
dump ends.
2009-10-18 12:28:22 [15936] [6] DEBUG:
SMPP[Id72]: Got
PDU:
2009-10-18 12:28:22 [15936] [6] DEBUG: SMPP PDU
0x9c4e3e8
dump:
2009-10-18 12:28:22 [15936] [6]
DEBUG: type_name:
submit_sm_resp
2009-10-18 12:28:22 [15936] [6]
DEBUG: command_id: 2147483652 =
0x8004
2009-10-18 12:28:22 [15936] [6]
DEBUG: command_status: 0 =
0x
2009-10-18 12:28:22 [15936] [6]
DEBUG: sequence_number: 575 =
0x023f
2009-10-18 12:28:22 [15936] [6]
DEBUG: message_id: 4ADA0A0E
2009-10-18 12:28:22 [15936] [6] DEBUG: SMPP PDU
dump ends.
2009-10-18 12:28:22 [15936] [6] DEBUG:
DLR[mysql]: Adding
DLR smsc=Id72, ts=4ADA0A0E, src=Lalit,
dst=919868311699,
mask=31, boxc=dlrbox
2009-10-18 12:28:22 [15936] [6] DEBUG: sql:
INSERT INTO dlr
(smsc, ts, source, destination, service, url,
mask, boxc,
status) VALUES ('Id72', '4ADA0A0E', 'Lalit',
'919868311699',
'playsms',
'http://localhost/smsadmin/plugin/gateway/kannel/dlr.php?type=%dslid=749uid=7',
'31', 'dlrbox', '0');
2009-10-18 12:28:22 [15936] [6] DEBUG:
SMSC[Id72]: creating
DLR message
2009-10-18 12:28:22 [15936] [6] DEBUG:
SMSC[Id72]: DLR =
http://localhost/smsadmin/plugin/gateway/kannel/dlr.php?type=%dslid=749uid=7
2009-10-18 12:28:22 [15936] [9] DEBUG: send_msg:
sending
msg to boxc: dlrbox
2009-10-18 12:28:22 [15936] [9] DEBUG:
boxc_sender: sent
message to 127.0.0.1
2009-10-18 12:28:22 [15936] [8] DEBUG:
boxc_receiver: got
ack
###Kannel CONF FILE##
group = core
admin-port = 13000
admin-password = **
status-password = **
log-file = /var/log/kannel/kannel.log
log-level = 0
access-log = /var/log/kannel/access.log
smsbox-port = 13001
#store-file = /var/log/kannel/kannel.store
#store-location =
/var/log/kannel/kannel.store
sms-resend-retry = 5
dlr-storage = mysql
# SMSC SMPP
group = smsc
smsc = smpp
smsc-id = Id72
host = *
port = 8899
smsc-username = *
smsc-password = *
system-type = VMA
msg-id-type=0x01
# SMSBOX SETUP
group = smsbox
smsbox-id = dlrbox
bearerbox-host = localhost
sendsms-port = 13131
sendsms-chars = 0123456789+
log-file = /var/log/kannel/smsbox.log
log-level = 0
access-log = /var/log/kannel/access.log
# SEND-SMS USERS
group = sendsms-user
username = *
Re: only receiving DLR type=8
Thanks Nikos!
Yes I am receiving almost every SMS in my moblie.
my post url is
/cgi-bin/sendsms?username=***password=senderid=Lalitfrom=Lalitto=919868311699text=testdlr-mask=31dlr-url=http%3A%2F%2F209.61.238.10%2Fsmsadmin%2Fplugin%2Fgateway%2Fkannel%2Fdlr.php%3Ftype%3D%25d%26slid%3D750%26uid%3D7mclass=2
dlr-mask is 31
and DLR URL is
http://209.*.*.*/smsadmin/plugin/gateway/kannel/dlr.php?type=%dslid=750uid=7mclass=2
-Thanks
-Sunil
--- On Mon, 19/10/09, Nikos Balkanas n...@amdtelecom.net wrote:
From: Nikos Balkanas n...@amdtelecom.net
Subject: Re: only receiving DLR type=8
To: Sunil Soni sunil.s...@yahoo.co.in, users@kannel.org
Date: Monday, 19 October, 2009, 11:50 PM
Hi,
Please post your send-url. Have you tested it with your
mobile? Is the SMS received?
BR,
Nikos
- Original Message - From: Sunil Soni sunil.s...@yahoo.co.in
To: users@kannel.org
Sent: Monday, October 19, 2009 9:04 PM
Subject: Fw: only receiving DLR type=8
Hi List,
Below is the kannel.log and configuration file.
I am only receiving DLR type=8 i.e SMSC submit.
How can I recieve Other DLR type=1 2 or 5 ?
Plese any one help me
I am using kannel-1.4.3, DLR mask 31
2009-10-18 12:28:22 [15936] [6] DEBUG: SMPP[Id72]: Sending
PDU:
2009-10-18 12:28:22 [15936] [6] DEBUG: SMPP PDU 0x9c4e3e8
dump:
2009-10-18 12:28:22 [15936] [6]
DEBUG: type_name: submit_sm
2009-10-18 12:28:22 [15936] [6]
DEBUG: command_id: 4 = 0x0004
2009-10-18 12:28:22 [15936] [6]
DEBUG: command_status: 0 = 0x
2009-10-18 12:28:22 [15936] [6]
DEBUG: sequence_number: 575 = 0x023f
2009-10-18 12:28:22 [15936] [6]
DEBUG: service_type: NULL
2009-10-18 12:28:22 [15936] [6]
DEBUG: source_addr_ton: 5 = 0x0005
2009-10-18 12:28:22 [15936] [6]
DEBUG: source_addr_npi: 0 = 0x
2009-10-18 12:28:22 [15936] [6]
DEBUG: source_addr: Lalit
2009-10-18 12:28:22 [15936] [6]
DEBUG: dest_addr_ton: 2 = 0x0002
2009-10-18 12:28:22 [15936] [6]
DEBUG: dest_addr_npi: 1 = 0x0001
2009-10-18 12:28:22 [15936] [6]
DEBUG: destination_addr: 919868311699
2009-10-18 12:28:22 [15936] [6]
DEBUG: esm_class: 3 = 0x0003
2009-10-18 12:28:22 [15936] [6]
DEBUG: protocol_id: 0 = 0x
2009-10-18 12:28:22 [15936] [6]
DEBUG: priority_flag: 0 = 0x
2009-10-18 12:28:22 [15936] [6]
DEBUG: schedule_delivery_time: NULL
2009-10-18 12:28:22 [15936] [6]
DEBUG: validity_period: NULL
2009-10-18 12:28:22 [15936] [6]
DEBUG: registered_delivery: 1 =
0x0001
2009-10-18 12:28:22 [15936] [6]
DEBUG: replace_if_present_flag: 0 =
0x
2009-10-18 12:28:22 [15936] [6]
DEBUG: data_coding: 242 = 0x00f2
2009-10-18 12:28:22 [15936] [6]
DEBUG: sm_default_msg_id: 0 = 0x
2009-10-18 12:28:22 [15936] [6]
DEBUG: sm_length: 14 = 0x000e
2009-10-18 12:28:22 [15936] [6]
DEBUG: short_message: Jai Ram-sunil
2009-10-18 12:28:22 [15936] [6] DEBUG: SMPP PDU dump ends.
2009-10-18 12:28:22 [15936] [6] DEBUG: SMPP[Id72]: Got
PDU:
2009-10-18 12:28:22 [15936] [6] DEBUG: SMPP PDU 0x9c4e3e8
dump:
2009-10-18 12:28:22 [15936] [6]
DEBUG: type_name: submit_sm_resp
2009-10-18 12:28:22 [15936] [6]
DEBUG: command_id: 2147483652 =
0x8004
2009-10-18 12:28:22 [15936] [6]
DEBUG: command_status: 0 = 0x
2009-10-18 12:28:22 [15936] [6]
DEBUG: sequence_number: 575 = 0x023f
2009-10-18 12:28:22 [15936] [6]
DEBUG: message_id: 4ADA0A0E
2009-10-18 12:28:22 [15936] [6] DEBUG: SMPP PDU dump ends.
2009-10-18 12:28:22 [15936] [6] DEBUG: DLR[mysql]: Adding
DLR smsc=Id72, ts=4ADA0A0E, src=Lalit, dst=919868311699,
mask=31, boxc=dlrbox
2009-10-18 12:28:22 [15936] [6] DEBUG: sql: INSERT INTO
dlr
(smsc, ts, source, destination, service, url, mask, boxc,
status) VALUES ('Id72', '4ADA0A0E', 'Lalit',
'919868311699',
'playsms',
'http://localhost/smsadmin/plugin/gateway/kannel/dlr.php?type=%dslid=749uid=7',
'31', 'dlrbox', '0');
2009-10-18 12:28:22 [15936] [6] DEBUG: SMSC[Id72]:
creating
DLR message
2009-10-18 12:28:22 [15936] [6] DEBUG: SMSC[Id72]: DLR =
http://localhost/smsadmin/plugin/gateway/kannel/dlr.php?type=%dslid=749uid=7
2009-10-18 12:28:22 [15936] [9] DEBUG: send_msg: sending
msg to boxc: dlrbox
2009-10-18 12:28:22 [15936] [9] DEBUG: boxc_sender: sent
message to 127.0.0.1
2009-10-18 12:28:22 [15936] [8] DEBUG: boxc_receiver: got
ack
###Kannel CONF FILE##
group = core
admin-port = 13000
admin-password = **
status-password = **
log-file = /var/log/kannel/kannel.log
log-level = 0
access-log = /var/log/kannel/access.log
smsbox-port = 13001
#store-file = /var/log/kannel/kannel.store
#store-location = /var/log/kannel/kannel.store
sms-resend-retry = 5
dlr-storage = mysql
# SMSC SMPP
group = smsc
smsc = smpp
smsc-id = Id72
host = *
port = 8899
smsc-username = *
smsc-password = *
system-type = VMA
msg-id-type=0x01
# SMSBOX SETUP
group = smsbox
smsbox-id = dlrbox
