Re: ERROR: SMPP[xxxx]: got DLR but could not find message or was not interested in it
Thank you all. It worked with the DLR Storage in same database. - Mahesh On Sat, Aug 4, 2018 at 12:56 PM, Денис Давыдов wrote: > Manesh, > > See msg-id-type in the User Guide. Also I suggest you to enable debug mode > to smsc group (log_level=0) to see how your provider work with a message ID > numbers. > > -- > Regards, > Denis > > пт, 3 авг. 2018 г. в 9:38, mahesh Lavanam : > >> Hi, >> >> Please help me in resolving the DLR issue >> >> I have a SMS Port with 2 TX & 2 RX sessions enabled. >> >> I have configured these sessions in two kannel configurations with same >> smsc id >> >> *kannel1.conf - 1TX & 1RX(SMSbox1 & Bearerbox1) * >> >> #1st tx connection >> group = smsc >> smsc = smpp >> smsc-id = tran >> host = xxx.xxx.xxx.xx >> port = xxx >> smsc-username = x >> smsc-password = xx >> system-type = smpp >> connect-allow-ip = 127.0.0.1 >> source-addr-ton = 0 >> source-addr-npi = 1 >> dest-addr-ton = 1 >> dest-addr-npi = 1 >> >> >> #1st Rx Connection >> group = smsc >> smsc = smpp >> smsc-id = tran >> host = xxx.xxx.xxx.xx >> port = xxx >> smsc-username = x >> smsc-password = xx >> system-type = smpp >> connect-allow-ip = 127.0.0.1 >> source-addr-ton = 0 >> source-addr-npi = 1 >> dest-addr-ton = 1 >> dest-addr-npi = 1 >> >> kannel2.conf * - 1TX & 1RX(SMSbox2 & Bearerbox2) * >> >> #1st tx connection >> group = smsc >> smsc = smpp >> smsc-id = tran >> host = xxx.xxx.xxx.xx >> port = xxx >> smsc-username = x >> smsc-password = xx >> system-type = smpp >> connect-allow-ip = 127.0.0.1 >> source-addr-ton = 0 >> source-addr-npi = 1 >> dest-addr-ton = 1 >> dest-addr-npi = 1 >> >> >> #1st Rx Connection >> group = smsc >> smsc = smpp >> smsc-id = tran >> host = xxx.xxx.xxx.xx >> port = xxx >> smsc-username = x >> smsc-password = xx >> system-type = smpp >> connect-allow-ip = 127.0.0.1 >> source-addr-ton = 0 >> source-addr-npi = 1 >> dest-addr-ton = 1 >> dest-addr-npi = 1 >> >> >> In kannel2.log file, I see that kannel1's sms DLRs are receiving and >> seeing the error as below: >> >> DEBUG: DLR[internal]: Looking for DLR smsc=tran, ts=0160683811, >> dst=919134556661, type=1 >> WARNING: DLR[internal]: DLR from SMSC for DST<919134556661> not >> found. >> ERROR: SMPP[bsnl_tran]: got DLR but could not find message or was not >> interested in it id<0160683811> dst<919134556661>, type<1> >> >> Same error at kannel1.log file, when received the SMS DLRs of kannel2's >> messages >> >> Please help me to resolve the issue, to route the DLRs into its >> respective kannel's i.e., Kannel1's sent sms dlr into kannel1 & kannel2's >> sent sms dlr into kannel2. >> >> Thanks, >> Mahesh >> >>
Re: ERROR: SMPP[xxxx]: got DLR but could not find message or was not interested in it
Manesh, See msg-id-type in the User Guide. Also I suggest you to enable debug mode to smsc group (log_level=0) to see how your provider work with a message ID numbers. -- Regards, Denis пт, 3 авг. 2018 г. в 9:38, mahesh Lavanam : > Hi, > > Please help me in resolving the DLR issue > > I have a SMS Port with 2 TX & 2 RX sessions enabled. > > I have configured these sessions in two kannel configurations with same > smsc id > > *kannel1.conf - 1TX & 1RX(SMSbox1 & Bearerbox1) * > > #1st tx connection > group = smsc > smsc = smpp > smsc-id = tran > host = xxx.xxx.xxx.xx > port = xxx > smsc-username = x > smsc-password = xx > system-type = smpp > connect-allow-ip = 127.0.0.1 > source-addr-ton = 0 > source-addr-npi = 1 > dest-addr-ton = 1 > dest-addr-npi = 1 > > > #1st Rx Connection > group = smsc > smsc = smpp > smsc-id = tran > host = xxx.xxx.xxx.xx > port = xxx > smsc-username = x > smsc-password = xx > system-type = smpp > connect-allow-ip = 127.0.0.1 > source-addr-ton = 0 > source-addr-npi = 1 > dest-addr-ton = 1 > dest-addr-npi = 1 > > kannel2.conf * - 1TX & 1RX(SMSbox2 & Bearerbox2) * > > #1st tx connection > group = smsc > smsc = smpp > smsc-id = tran > host = xxx.xxx.xxx.xx > port = xxx > smsc-username = x > smsc-password = xx > system-type = smpp > connect-allow-ip = 127.0.0.1 > source-addr-ton = 0 > source-addr-npi = 1 > dest-addr-ton = 1 > dest-addr-npi = 1 > > > #1st Rx Connection > group = smsc > smsc = smpp > smsc-id = tran > host = xxx.xxx.xxx.xx > port = xxx > smsc-username = x > smsc-password = xx > system-type = smpp > connect-allow-ip = 127.0.0.1 > source-addr-ton = 0 > source-addr-npi = 1 > dest-addr-ton = 1 > dest-addr-npi = 1 > > > In kannel2.log file, I see that kannel1's sms DLRs are receiving and > seeing the error as below: > > DEBUG: DLR[internal]: Looking for DLR smsc=tran, ts=0160683811, > dst=919134556661, type=1 > WARNING: DLR[internal]: DLR from SMSC for DST<919134556661> not > found. > ERROR: SMPP[bsnl_tran]: got DLR but could not find message or was not > interested in it id<0160683811> dst<919134556661>, type<1> > > Same error at kannel1.log file, when received the SMS DLRs of kannel2's > messages > > Please help me to resolve the issue, to route the DLRs into its respective > kannel's i.e., Kannel1's sent sms dlr into kannel1 & kannel2's sent sms dlr > into kannel2. > > Thanks, > Mahesh > >
Re: ERROR: SMPP[xxxx]: got DLR but could not find message or was not interested in it
use database with same DLR table, each kannel database has its own timestamp table store, so it is normal respond when DLR received in another kannel box... On Friday, 3 August 2018, 5:13:55 PM GMT+7, mahesh Lavanam wrote: But, this error I'm seeing at kannel.log file. I think as it is not identifying it, it does not store into database. Thanks,Mahesh On Fri, Aug 3, 2018 at 2:12 PM, wrote: Hi, do both Kannel share the same database and table ? they have to share DLR database. Alex Am 03.08.2018 um 08:37 schrieb mahesh Lavanam : Hi, Please help me in resolving the DLR issue I have a SMS Port with 2 TX & 2 RX sessions enabled. I have configured these sessions in two kannel configurations with same smsc id kannel1.conf - 1TX & 1RX(SMSbox1 & Bearerbox1) #1st tx connectiongroup = smscsmsc = smppsmsc-id = tranhost = xxx.xxx.xxx.xxport = xxxsmsc-username = xsmsc-password = xxsystem-type = smppconnect-allow-ip = 127.0.0.1source-addr-ton = 0source-addr-npi = 1dest-addr-ton = 1dest-addr-npi = 1 #1st Rx Connectiongroup = smscsmsc = smppsmsc-id = tranhost = xxx.xxx.xxx.xxport = xxxsmsc-username = xsmsc-password = xxsystem-type = smppconnect-allow-ip = 127.0.0.1source-addr-ton = 0source-addr-npi = 1dest-addr-ton = 1dest-addr-npi = 1 kannel2.conf - 1TX & 1RX(SMSbox2 & Bearerbox2) #1st tx connectiongroup = smscsmsc = smppsmsc-id = tranhost = xxx.xxx.xxx.xxport = xxxsmsc-username = xsmsc-password = xxsystem-type = smppconnect-allow-ip = 127.0.0.1source-addr-ton = 0source-addr-npi = 1dest-addr-ton = 1dest-addr-npi = 1 #1st Rx Connectiongroup = smscsmsc = smppsmsc-id = tranhost = xxx.xxx.xxx.xxport = xxxsmsc-username = xsmsc-password = xxsystem-type = smppconnect-allow-ip = 127.0.0.1source-addr-ton = 0source-addr-npi = 1dest-addr-ton = 1dest-addr-npi = 1 In kannel2.log file, I see that kannel1's sms DLRs are receiving and seeing the error as below: DEBUG: DLR[internal]: Looking for DLR smsc=tran, ts=0160683811, dst=919134556661, type=1WARNING: DLR[internal]: DLR from SMSC for DST<919134556661> not found.ERROR: SMPP[bsnl_tran]: got DLR but could not find message or was not interested in it id<0160683811> dst<919134556661>, type<1> Same error at kannel1.log file, when received the SMS DLRs of kannel2's messages Please help me to resolve the issue, to route the DLRs into its respective kannel's i.e., Kannel1's sent sms dlr into kannel1 & kannel2's sent sms dlr into kannel2. Thanks,Mahesh
Re: ERROR: SMPP[xxxx]: got DLR but could not find message or was not interested in it
But, this error I'm seeing at kannel.log file. I think as it is not identifying it, it does not store into database. Thanks, Mahesh On Fri, Aug 3, 2018 at 2:12 PM, wrote: > Hi, > > do both Kannel share the same database and table ? they have to share DLR > database. > > Alex > > > Am 03.08.2018 um 08:37 schrieb mahesh Lavanam >: > > Hi, > > Please help me in resolving the DLR issue > > I have a SMS Port with 2 TX & 2 RX sessions enabled. > > I have configured these sessions in two kannel configurations with same > smsc id > > *kannel1.conf - 1TX & 1RX(SMSbox1 & Bearerbox1) * > > #1st tx connection > group = smsc > smsc = smpp > smsc-id = tran > host = xxx.xxx.xxx.xx > port = xxx > smsc-username = x > smsc-password = xx > system-type = smpp > connect-allow-ip = 127.0.0.1 > source-addr-ton = 0 > source-addr-npi = 1 > dest-addr-ton = 1 > dest-addr-npi = 1 > > > #1st Rx Connection > group = smsc > smsc = smpp > smsc-id = tran > host = xxx.xxx.xxx.xx > port = xxx > smsc-username = x > smsc-password = xx > system-type = smpp > connect-allow-ip = 127.0.0.1 > source-addr-ton = 0 > source-addr-npi = 1 > dest-addr-ton = 1 > dest-addr-npi = 1 > > kannel2.conf * - 1TX & 1RX(SMSbox2 & Bearerbox2) * > > #1st tx connection > group = smsc > smsc = smpp > smsc-id = tran > host = xxx.xxx.xxx.xx > port = xxx > smsc-username = x > smsc-password = xx > system-type = smpp > connect-allow-ip = 127.0.0.1 > source-addr-ton = 0 > source-addr-npi = 1 > dest-addr-ton = 1 > dest-addr-npi = 1 > > > #1st Rx Connection > group = smsc > smsc = smpp > smsc-id = tran > host = xxx.xxx.xxx.xx > port = xxx > smsc-username = x > smsc-password = xx > system-type = smpp > connect-allow-ip = 127.0.0.1 > source-addr-ton = 0 > source-addr-npi = 1 > dest-addr-ton = 1 > dest-addr-npi = 1 > > > In kannel2.log file, I see that kannel1's sms DLRs are receiving and > seeing the error as below: > > DEBUG: DLR[internal]: Looking for DLR smsc=tran, ts=0160683811, > dst=919134556661, type=1 > WARNING: DLR[internal]: DLR from SMSC for DST<919134556661> not > found. > ERROR: SMPP[bsnl_tran]: got DLR but could not find message or was not > interested in it id<0160683811> dst<919134556661>, type<1> > > Same error at kannel1.log file, when received the SMS DLRs of kannel2's > messages > > Please help me to resolve the issue, to route the DLRs into its respective > kannel's i.e., Kannel1's sent sms dlr into kannel1 & kannel2's sent sms dlr > into kannel2. > > Thanks, > Mahesh > > >
Re: ERROR: SMPP[xxxx]: got DLR but could not find message or was not interested in it
Hi, do both Kannel share the same database and table ? they have to share DLR database. Alex > Am 03.08.2018 um 08:37 schrieb mahesh Lavanam : > > Hi, > > Please help me in resolving the DLR issue > > I have a SMS Port with 2 TX & 2 RX sessions enabled. > > I have configured these sessions in two kannel configurations with same smsc > id > > kannel1.conf - 1TX & 1RX(SMSbox1 & Bearerbox1) > > #1st tx connection > group = smsc > smsc = smpp > smsc-id = tran > host = xxx.xxx.xxx.xx > port = xxx > smsc-username = x > smsc-password = xx > system-type = smpp > connect-allow-ip = 127.0.0.1 > source-addr-ton = 0 > source-addr-npi = 1 > dest-addr-ton = 1 > dest-addr-npi = 1 > > > #1st Rx Connection > group = smsc > smsc = smpp > smsc-id = tran > host = xxx.xxx.xxx.xx > port = xxx > smsc-username = x > smsc-password = xx > system-type = smpp > connect-allow-ip = 127.0.0.1 > source-addr-ton = 0 > source-addr-npi = 1 > dest-addr-ton = 1 > dest-addr-npi = 1 > > kannel2.conf - 1TX & 1RX(SMSbox2 & Bearerbox2) > > #1st tx connection > group = smsc > smsc = smpp > smsc-id = tran > host = xxx.xxx.xxx.xx > port = xxx > smsc-username = x > smsc-password = xx > system-type = smpp > connect-allow-ip = 127.0.0.1 > source-addr-ton = 0 > source-addr-npi = 1 > dest-addr-ton = 1 > dest-addr-npi = 1 > > > #1st Rx Connection > group = smsc > smsc = smpp > smsc-id = tran > host = xxx.xxx.xxx.xx > port = xxx > smsc-username = x > smsc-password = xx > system-type = smpp > connect-allow-ip = 127.0.0.1 > source-addr-ton = 0 > source-addr-npi = 1 > dest-addr-ton = 1 > dest-addr-npi = 1 > > > In kannel2.log file, I see that kannel1's sms DLRs are receiving and seeing > the error as below: > > DEBUG: DLR[internal]: Looking for DLR smsc=tran, ts=0160683811, > dst=919134556661, type=1 > WARNING: DLR[internal]: DLR from SMSC for DST<919134556661> not found. > ERROR: SMPP[bsnl_tran]: got DLR but could not find message or was not > interested in it id<0160683811> dst<919134556661>, type<1> > > Same error at kannel1.log file, when received the SMS DLRs of kannel2's > messages > > Please help me to resolve the issue, to route the DLRs into its respective > kannel's i.e., Kannel1's sent sms dlr into kannel1 & kannel2's sent sms dlr > into kannel2. > > Thanks, > Mahesh >
ERROR: SMPP[xxxx]: got DLR but could not find message or was not interested in it
Hi, Please help me in resolving the DLR issue I have a SMS Port with 2 TX & 2 RX sessions enabled. I have configured these sessions in two kannel configurations with same smsc id *kannel1.conf - 1TX & 1RX(SMSbox1 & Bearerbox1) * #1st tx connection group = smsc smsc = smpp smsc-id = tran host = xxx.xxx.xxx.xx port = xxx smsc-username = x smsc-password = xx system-type = smpp connect-allow-ip = 127.0.0.1 source-addr-ton = 0 source-addr-npi = 1 dest-addr-ton = 1 dest-addr-npi = 1 #1st Rx Connection group = smsc smsc = smpp smsc-id = tran host = xxx.xxx.xxx.xx port = xxx smsc-username = x smsc-password = xx system-type = smpp connect-allow-ip = 127.0.0.1 source-addr-ton = 0 source-addr-npi = 1 dest-addr-ton = 1 dest-addr-npi = 1 kannel2.conf * - 1TX & 1RX(SMSbox2 & Bearerbox2) * #1st tx connection group = smsc smsc = smpp smsc-id = tran host = xxx.xxx.xxx.xx port = xxx smsc-username = x smsc-password = xx system-type = smpp connect-allow-ip = 127.0.0.1 source-addr-ton = 0 source-addr-npi = 1 dest-addr-ton = 1 dest-addr-npi = 1 #1st Rx Connection group = smsc smsc = smpp smsc-id = tran host = xxx.xxx.xxx.xx port = xxx smsc-username = x smsc-password = xx system-type = smpp connect-allow-ip = 127.0.0.1 source-addr-ton = 0 source-addr-npi = 1 dest-addr-ton = 1 dest-addr-npi = 1 In kannel2.log file, I see that kannel1's sms DLRs are receiving and seeing the error as below: DEBUG: DLR[internal]: Looking for DLR smsc=tran, ts=0160683811, dst=919134556661, type=1 WARNING: DLR[internal]: DLR from SMSC for DST<919134556661> not found. ERROR: SMPP[bsnl_tran]: got DLR but could not find message or was not interested in it id<0160683811> dst<919134556661>, type<1> Same error at kannel1.log file, when received the SMS DLRs of kannel2's messages Please help me to resolve the issue, to route the DLRs into its respective kannel's i.e., Kannel1's sent sms dlr into kannel1 & kannel2's sent sms dlr into kannel2. Thanks, Mahesh
Re: got DLR but could not find message or was not interested in it
Am 31.07.2015 12:03, schrieb Achyut Raj: Hi Kannel Users, I am having issue with the DLR receiving. I have attached the log and config file below. the SMSC provides the msg ID as HEX notation in the submit_sm.message_id, AND then does provide it as DECIMAL notation in the DLR payload of the deliver_sm PDU. So you need to set: group = smsc ... msg-id-type = 0x01 Please see the corresponding documentation part at: http://www.kannel.org/download/kannel-userguide-snapshot/userguide.html#AEN1936 -- Best Regards, Stipe Tolj --- Düsseldorf, NRW, Germany Kannel Foundation tolj.org system architecture http://www.kannel.org/http://www.tolj.org/ stolj at kannel.org st at tolj.org ---
got DLR but could not find message or was not interested in it
Hi Kannel Users, I am having issue with the DLR receiving. I have attached the log and config file below. Thanx.. 2015-07-31 09:28:15 [21765] [19] DEBUG: SMPP[smarttz2]: Sending PDU: 2015-07-31 09:28:15 [21765] [19] DEBUG: SMPP PDU 0x1de84c00 dump: 2015-07-31 09:28:15 [21765] [19] DEBUG: type_name: submit_sm 2015-07-31 09:28:15 [21765] [19] DEBUG: command_id: 4 = 0x0004 2015-07-31 09:28:15 [21765] [19] DEBUG: command_status: 0 = 0x 2015-07-31 09:28:15 [21765] [19] DEBUG: sequence_number: 226901 = 0x00037655 2015-07-31 09:28:15 [21765] [19] DEBUG: service_type: NULL 2015-07-31 09:28:15 [21765] [19] DEBUG: source_addr_ton: 5 = 0x0005 2015-07-31 09:28:15 [21765] [19] DEBUG: source_addr_npi: 0 = 0x 2015-07-31 09:28:15 [21765] [19] DEBUG: source_addr: STANBIC 2015-07-31 09:28:15 [21765] [19] DEBUG: dest_addr_ton: 1 = 0x0001 2015-07-31 09:28:15 [21765] [19] DEBUG: dest_addr_npi: 1 = 0x0001 2015-07-31 09:28:15 [21765] [19] DEBUG: destination_addr: 255763960715 2015-07-31 09:28:15 [21765] [19] DEBUG: esm_class: 3 = 0x0003 2015-07-31 09:28:15 [21765] [19] DEBUG: protocol_id: 0 = 0x 2015-07-31 09:28:15 [21765] [19] DEBUG: priority_flag: 0 = 0x 2015-07-31 09:28:15 [21765] [19] DEBUG: schedule_delivery_time: NULL 2015-07-31 09:28:15 [21765] [19] DEBUG: validity_period: 150802092815000+ 2015-07-31 09:28:15 [21765] [19] DEBUG: registered_delivery: 1 = 0x0001 2015-07-31 09:28:15 [21765] [19] DEBUG: replace_if_present_flag: 0 = 0x 2015-07-31 09:28:15 [21765] [19] DEBUG: data_coding: 0 = 0x 2015-07-31 09:28:15 [21765] [19] DEBUG: sm_default_msg_id: 0 = 0x 2015-07-31 09:28:15 [21765] [19] DEBUG: sm_length: 15 = 0x000f 2015-07-31 09:28:15 [21765] [19] DEBUG: short_message: Test characters 2015-07-31 09:28:15 [21765] [19] DEBUG: SMPP PDU dump ends. 2015-07-31 09:28:15 [21765] [19] DEBUG: SMPP[smarttz2]: throughput (1.00,20.00) 2015-07-31 09:28:15 [21765] [19] DEBUG: SMPP[smarttz2]: throughput (1.00,20.00) 2015-07-31 09:28:15 [21765] [19] DEBUG: SMPP[smarttz2]: Got PDU: 2015-07-31 09:28:15 [21765] [19] DEBUG: SMPP PDU 0x1cb90720 dump: 2015-07-31 09:28:15 [21765] [19] DEBUG: type_name: enquire_link_resp 2015-07-31 09:28:15 [21765] [19] DEBUG: command_id: 2147483669 = 0x8015 2015-07-31 09:28:15 [21765] [19] DEBUG: command_status: 0 = 0x 2015-07-31 09:28:15 [21765] [19] DEBUG: sequence_number: 226900 = 0x00037654 2015-07-31 09:28:15 [21765] [19] DEBUG: SMPP PDU dump ends. 2015-07-31 09:28:15 [21765] [19] DEBUG: SMPP[smarttz2]: throughput (1.00,20.00) 2015-07-31 09:28:15 [21765] [19] DEBUG: SMPP[smarttz2]: throughput (1.00,20.00) 2015-07-31 09:28:15 [21765] [19] DEBUG: SMPP[smarttz2]: Got PDU: 2015-07-31 09:28:15 [21765] [19] DEBUG: SMPP PDU 0x1cb90720 dump: 2015-07-31 09:28:15 [21765] [19] DEBUG: type_name: submit_sm_resp 2015-07-31 09:28:15 [21765] [19] DEBUG: command_id: 2147483652 = 0x8004 2015-07-31 09:28:15 [21765] [19] DEBUG: command_status: 0 = 0x 2015-07-31 09:28:15 [21765] [19] DEBUG: sequence_number: 226901 = 0x00037655 2015-07-31 09:28:15 [21765] [19] DEBUG: message_id: 899C4941 2015-07-31 09:28:15 [21765] [19] DEBUG: SMPP PDU dump ends. 2015-07-31 09:28:15 [21765] [19] DEBUG: new group created `smpp' 2015-07-31 09:28:15 [21765] [19] DEBUG: DLR[internal]: Adding DLR smsc=smarttz2, ts=899C4941, src=STANBIC, dst=255763960715, mask=19, boxc=testuser8 2015-07-31 09:28:15 [21765] [19] DEBUG: SMPP[smarttz2]: throughput (1.00,20.00) 2015-07-31 09:28:19 [21765] [19] DEBUG: SMPP[smarttz2]: throughput (0.00,20.00) 2015-07-31 09:28:19 [21765] [19] DEBUG: SMPP[smarttz2]: Got PDU: 2015-07-31 09:28:19 [21765] [19] DEBUG: SMPP PDU 0x1de84c00 dump: 2015-07-31 09:28:19 [21765] [19] DEBUG: type_name: deliver_sm 2015-07-31 09:28:19 [21765] [19] DEBUG: command_id: 5 = 0x0005 2015-07-31 09:28:19 [21765] [19] DEBUG: command_status: 0 = 0x 2015-07-31 09:28:19 [21765] [19] DEBUG: sequence_number: 340499 = 0x00053213 2015-07-31 09:28:19 [21765] [19] DEBUG: service_type: NULL 2015-07-31 09:28:19 [21765] [19] DEBUG: source_addr_ton: 1 = 0x0001 2015-07-31 09:28:19 [21765] [19] DEBUG: source_addr_npi: 1 = 0x0001 2015-07-31 09:28:19 [21765] [19] DEBUG: source_addr: 255763960715 2015-07-31 09:28:19 [21765] [19] DEBUG: dest_addr_ton: 5 = 0x0005 2015-07-31 09:28:19 [21765] [19] DEBUG: dest_addr_npi: 0 = 0x 2015-07-31 09:28:19 [21765] [19] DEBUG: destination_addr: STANBIC 2015-07-31 09:28:19 [21765] [19] DEBUG: esm_class: 4 = 0x0004 2015-07-31 09:28:19 [21765] [19] DEBUG: protocol_id: 0 = 0x 2015-07-31 09:28:19 [21765] [19] DEBUG: priority_flag: 0 = 0x 2015-07-31 09:28:19 [21765] [19] DEBUG: schedule_delivery_time: NULL 2015-07-31 09:28:19 [21765] [19] DEBUG: validity_period: NULL 2015-07-31 09:28:19 [21765] [19] DEBUG: registered_delivery: 0 = 0x 2015-07-31 09:28:19 [21765] [19]
Re: got DLR but could not find message or was not interested in it id
Does all smsc connect with same telco and account? If yes you just need to set the smsc_id with the same name. On 4 Nov 2013 10:11, Qqblog Qqblog qqb...@ymail.com wrote: I have 3 smsc two smsc are load balancing and one is backup e.g smsc = mysmsc smsc-admin-id = mysmsc1 smsc = mysmsc smsc-admin-id = mysmsc2 smsc = mysmsc_backup smsc-admin-id = mysmsc3 I find some messages sent out via mysmsc2, but DLR Returned via mysmsc3 and produce error like this got DLR but could not find message or was not interested in it id
got DLR but could not find message or was not interested in it id
I have 3 smsc two smsc are load balancing and one is backup e.g smsc = mysmsc smsc-admin-id = mysmsc1 smsc = mysmsc smsc-admin-id = mysmsc2 smsc = mysmsc_backup smsc-admin-id = mysmsc3 I find some messages sent out via mysmsc2, but DLR Returned via mysmsc3 and produce error like this got DLR but could not find message or was not interested in it id
Re: got DLR but could not find message or was not interested in for some messages
I don't see any dlr-storage defined in your configuration :) Willy Mularto sangpr...@gmail.com On Jun 23, 2013, at 12:36 PM, Majid Azimi azimi.ma...@yahoo.com wrote: Hi guys, can someone help with this question: http://serverfault.com/questions/517765/got-dlr-but-could-not-find-message-or-was-not-interested-in-for-some-messages thank you very much
Re: got DLR but could not find message or was not interested in for some messages
user guide says dlr-storage = internal is the default option. should I mention it again? I don't see any dlr-storage defined in your configuration :) Hi guys, can someone help with this question: http://serverfault.com/questions/517765/got-dlr-but-could-not-find-message-or-was-not-interested-in-for-some-messages thank you very much
Re: got DLR but could not find message or was not interested in for some messages
Yes you are correct, but keep in mind that this internal type stores your DLRs temporary in memory, which means you will lost them when you restart Bearerbox. It is recommended to use spool or db-based DLR type. Will be helpful if you set the log-level to 0 so we can analyse what is going on. Willy Mularto sangpr...@gmail.com On Jun 23, 2013, at 1:31 PM, Majid Azimi azimi.ma...@yahoo.com wrote: user guide says dlr-storage = internal is the default option. should I mention it again? I don't see any dlr-storage defined in your configuration :) Hi guys, can someone help with this question: http://serverfault.com/questions/517765/got-dlr-but-could-not-find-message-or-was-not-interested-in-for-some-messages thank you very much
got DLR but could not find message or was not interested in for some messages
Hi guys, can someone help with this question: http://serverfault.com/questions/517765/got-dlr-but-could-not-find-message-or-was-not-interested-in-for-some-messages thank you very much
Re: got DLR but could not find message or was not interested in it
anyone here can check and verify, all you need is to post your logs :)) Best Regards, Mohammed M I Sleem http://www.abusleem.net - Personal blog http://www.freakle.com On Sat, Jul 9, 2011 at 12:26 AM, Ashvin Savani ash...@avinashi.com wrote: Saleem, Thanks for your reply. Here are my answers: 1) I am only having single SMSC defined, with id called internal. 2) Do I need to set it explicitly? I did not set any value for dlr_mask. Should I set it to 1? 3) Thats good point as well but my test message was even less than 50 chars, so no chance of having more than one part. 4) I am not too used to kannel to verify that, but how to verify it? Regards, Ashvin Savani CEO - Avinashi Group of Companies On Fri, Jul 8, 2011 at 4:52 AM, Mohammed Saleem mohammedsl...@gmail.comwrote: I am not a Kannel Guru, but I've seen it many times, could happen due to at least 4 reasons: (1) You sent a message through a different connection with different SMSC ID, the callback DLR won't get a match e.g. The transmit connection uses a different SMSC ID than the receiver connection, because kannel matches the SMSC ID, too !! (2) You sent a message without asking for DLR e.g. dlr_mask = 0, kannel then won't store a reference for the sent message. But the carrier sent you a DLR !! this case may happen because some carriers send you a DLR even if you don't ask for it. (3) When you send a concatenated MT, kannel keeps a reference for the first part only and ignores the other parts, but some operators send you the DLRs for all the parts, the other parts won't find a match. (4) This case is the most critical, some carriers send you the DLR before sending the ACK ! the DLR won't get a match because kannel didn't save the message reference yet ! it waits for the submit_sm_resp (ACK,NACK,...) before storing the reference in the store, Alex had a fix for this but it has performance penalties http://www.blogalex.com/archives/132. Hope u find your answers, or post your full log of this SMSC connection Best Regards, Mohammed M I Sleem http://www.abusleem.net - Personal blog On Fri, Jul 8, 2011 at 12:44 AM, Alan McNatty a...@catalyst.net.nzwrote: Hi Ashvin, Can you please include the original submit_sm with register_delivery enabled so we can see the dlr being stored? Cheers, Alan On Thu, 2011-07-07 at 03:35 +0530, Ashvin Savani wrote: @Alvaro, I am using mysql-dlr. Here is bit full log of PDU 2011-07-07 03:36:08 [10828] [6] DEBUG: SMPP[internal]: Got PDU: 2011-07-07 03:36:08 [10828] [6] DEBUG: SMPP PDU 0x1f286ad0 dump: 2011-07-07 03:36:08 [10828] [6] DEBUG: type_name: deliver_sm 2011-07-07 03:36:08 [10828] [6] DEBUG: command_id: 5 = 0x0005 2011-07-07 03:36:08 [10828] [6] DEBUG: command_status: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: sequence_number: 1310398007 = 0x4e1b1637 2011-07-07 03:36:08 [10828] [6] DEBUG: service_type: NULL 2011-07-07 03:36:08 [10828] [6] DEBUG: source_addr_ton: 2 = 0x0002 2011-07-07 03:36:08 [10828] [6] DEBUG: source_addr_npi: 1 = 0x0001 2011-07-07 03:36:08 [10828] [6] DEBUG: source_addr: 91903930 2011-07-07 03:36:08 [10828] [6] DEBUG: dest_addr_ton: 2 = 0x0002 2011-07-07 03:36:08 [10828] [6] DEBUG: dest_addr_npi: 1 = 0x0001 2011-07-07 03:36:08 [10828] [6] DEBUG: destination_addr: 11 2011-07-07 03:36:08 [10828] [6] DEBUG: esm_class: 4 = 0x0004 2011-07-07 03:36:08 [10828] [6] DEBUG: protocol_id: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: priority_flag: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: schedule_delivery_time: NULL 2011-07-07 03:36:08 [10828] [6] DEBUG: validity_period: NULL 2011-07-07 03:36:08 [10828] [6] DEBUG: registered_delivery: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: replace_if_present_flag: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: data_coding: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: sm_default_msg_id: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: sm_length: 132 = 0x0084 2011-07-07 03:36:08 [10828] [6] DEBUG: short_message: 2011-07-07 03:36:08 [10828] [6] DEBUG:Octet string at 0x1f27c670: 2011-07-07 03:36:08 [10828] [6] DEBUG: len: 132 2011-07-07 03:36:08 [10828] [6] DEBUG: size: 133 2011-07-07 03:36:08 [10828] [6] DEBUG: immutable: 0 2011-07-07 03:36:08 [10828] [6] DEBUG: data: 69 64 3a 30 33 31 33 39 38 30 31 2d 61 37 34 37 id:03139801-a747 2011-07-07 03:36:08 [10828] [6] DEBUG: data: 2d 34 64 63 33 2d 39 32 31 34 2d 32 34 30 32 30 -4dc3-9214-24020 2011-07-07 03:36:08 [10828] [6] DEBUG: data: 31 37 66 62 33 66 34 20 73 75 62 3a 30 30 30 20 17fb3f4 sub:000 2011-07-07 03:36:08 [10828] [6] DEBUG: data: 64 6c 76 72 64 3a 30 30 31 20 73 75 62 6d 69 74 dlvrd:001 submit 2011-07-07 03:36:08 [10828] [6] DEBUG: data: 20
Re: got DLR but could not find message or was not interested in it
Hi, Just adding to what Mohammed said, logs should be max detail bb logs (with smsc traffic) showing at least the submit_sm, submit_sm_resp and deliver_sm PDUs of the same SMS, along with their application bb responses. Also please post your core and smsc configurations. BR, Nikos - Original Message - From: Mohammed Saleem To: Ashvin Savani Cc: users@kannel.org Sent: Saturday, July 09, 2011 11:19 AM Subject: Re: got DLR but could not find message or was not interested in it anyone here can check and verify, all you need is to post your logs :)) Best Regards, Mohammed M I Sleem http://www.abusleem.netΒ - Personal blog On Sat, Jul 9, 2011 at 12:26 AM, Ashvin Savani ash...@avinashi.com wrote: Saleem, Thanks for your reply. Here are my answers: 1) I am only having single SMSC defined, with id called internal. 2) Do I need to set itΒ explicitly? I did not set any value for dlr_mask. Should I set it to 1? 3) Thats good point as well but my test message was even less than 50 chars, so no chance of having more than one part. 4) I am not too used to kannel to verify that, but how to verify it? Regards, Ashvin Savani CEO - Avinashi Group of Companies On Fri, Jul 8, 2011 at 4:52 AM, Mohammed Saleem mohammedsl...@gmail.com wrote: I am not a Kannel Guru, but I've seen it many times, could happen due to at least 4 reasons: (1) You sent a message through a different connection with different SMSC ID, the callback DLR won't get a match e.g. The transmit connection uses a different SMSC ID than the receiver connection, because kannel matches the SMSC ID, too !! (2) You sent a message without asking for DLR e.g. dlr_mask = 0, kannel then won't store a reference for the sent message. But the carrier sent you a DLR !! this case may happen because some carriers send you a DLR even if you don't ask for it. (3) When you send a concatenated MT, kannel keeps a reference for the first part only and ignores the other parts, but some operators send you the DLRs for all the parts, the other parts won't find a match. (4) This case is the most critical, some carriers send you the DLR before sending the ACK ! the DLR won't get a match because kannel didn't save the message reference yet ! it waits for the submit_sm_resp (ACK,NACK,...) before storing the reference in the store, Alex had a fix for this but it has performance penalties. Hope u find your answers, or post your full log of this SMSC connection Best Regards, Mohammed M I Sleem http://www.abusleem.netΒ - Personal blog On Fri, Jul 8, 2011 at 12:44 AM, Alan McNatty a...@catalyst.net.nz wrote: Hi Ashvin, Can you please include the original submit_sm with register_delivery enabled so we can see the dlr being stored? Cheers, Alan On Thu, 2011-07-07 at 03:35 +0530, Ashvin Savani wrote: @Alvaro, I am using mysql-dlr. Here is bit full log of PDU 2011-07-07 03:36:08 [10828] [6] DEBUG: SMPP[internal]: Got PDU: 2011-07-07 03:36:08 [10828] [6] DEBUG: SMPP PDU 0x1f286ad0 dump: 2011-07-07 03:36:08 [10828] [6] DEBUG: Β type_name: deliver_sm 2011-07-07 03:36:08 [10828] [6] DEBUG: Β command_id: 5 = 0x0005 2011-07-07 03:36:08 [10828] [6] DEBUG: Β command_status: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: Β sequence_number: 1310398007 = 0x4e1b1637 2011-07-07 03:36:08 [10828] [6] DEBUG: Β service_type: NULL 2011-07-07 03:36:08 [10828] [6] DEBUG: Β source_addr_ton: 2 = 0x0002 2011-07-07 03:36:08 [10828] [6] DEBUG: Β source_addr_npi: 1 = 0x0001 2011-07-07 03:36:08 [10828] [6] DEBUG: Β source_addr: 91903930 2011-07-07 03:36:08 [10828] [6] DEBUG: Β dest_addr_ton: 2 = 0x0002 2011-07-07 03:36:08 [10828] [6] DEBUG: Β dest_addr_npi: 1 = 0x0001 2011-07-07 03:36:08 [10828] [6] DEBUG: Β destination_addr: 11 2011-07-07 03:36:08 [10828] [6] DEBUG: Β esm_class: 4 = 0x0004 2011-07-07 03:36:08 [10828] [6] DEBUG: Β protocol_id: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: Β priority_flag: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: Β schedule_delivery_time: NULL 2011-07-07 03:36:08 [10828] [6] DEBUG: Β validity_period: NULL 2011-07-07 03:36:08 [10828] [6] DEBUG: Β registered_delivery: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: Β replace_if_present_flag: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: Β data_coding: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: Β sm_default_msg_id: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: Β sm_length: 132 = 0x0084 2011-07-07 03:36:08 [10828] [6] DEBUG: Β short_message: 2011-07-07 03:36:08 [10828] [6] DEBUG: Β Β Octet string at 0x1f27c670: 2011-07-07 03:36:08 [10828] [6] DEBUG: Β Β Β len: Β 132 2011-07-07 03:36:08 [10828] [6] DEBUG: Β Β Β size: 133 2011-07-07 03:36:08 [10828] [6] DEBUG: Β Β Β immutable: 0 2011-07-07 03:36:08 [10828] [6] DEBUG: Β Β Β data: 69 64 3a 30 33 31 33 39 38 30 31 2d 61 37 34 37 Β id:03139801-a747 2011-07-07 03:36:08 [10828] [6]
Re: got DLR but could not find message or was not interested in it
Sorry, didn't see that. Please disregard my previuous mail. Just set your dlr_mask to 31 and you are set (more or less). BR, Nikos - Original Message - From: Ashvin Savani To: Mohammed Saleem Cc: users@kannel.org Sent: Saturday, July 09, 2011 12:26 AM Subject: Re: got DLR but could not find message or was not interested in it Saleem, Thanks for your reply. Here are my answers: 1) I am only having single SMSC defined, with id called internal. 2) Do I need to set itΒ explicitly? I did not set any value for dlr_mask. Should I set it to 1? 3) Thats good point as well but my test message was even less than 50 chars, so no chance of having more than one part. 4) I am not too used to kannel to verify that, but how to verify it? Regards, Ashvin Savani CEO - Avinashi Group of Companies On Fri, Jul 8, 2011 at 4:52 AM, Mohammed Saleem mohammedsl...@gmail.com wrote: I am not a Kannel Guru, but I've seen it many times, could happen due to at least 4 reasons: (1) You sent a message through a different connection with different SMSC ID, the callback DLR won't get a match e.g. The transmit connection uses a different SMSC ID than the receiver connection, because kannel matches the SMSC ID, too !! (2) You sent a message without asking for DLR e.g. dlr_mask = 0, kannel then won't store a reference for the sent message. But the carrier sent you a DLR !! this case may happen because some carriers send you a DLR even if you don't ask for it. (3) When you send a concatenated MT, kannel keeps a reference for the first part only and ignores the other parts, but some operators send you the DLRs for all the parts, the other parts won't find a match. (4) This case is the most critical, some carriers send you the DLR before sending the ACK ! the DLR won't get a match because kannel didn't save the message reference yet ! it waits for the submit_sm_resp (ACK,NACK,...) before storing the reference in the store, Alex had a fix for this but it has performance penalties. Hope u find your answers, or post your full log of this SMSC connection Best Regards, Mohammed M I Sleem http://www.abusleem.netΒ - Personal blog On Fri, Jul 8, 2011 at 12:44 AM, Alan McNatty a...@catalyst.net.nz wrote: Hi Ashvin, Can you please include the original submit_sm with register_delivery enabled so we can see the dlr being stored? Cheers, Alan On Thu, 2011-07-07 at 03:35 +0530, Ashvin Savani wrote: @Alvaro, I am using mysql-dlr. Here is bit full log of PDU 2011-07-07 03:36:08 [10828] [6] DEBUG: SMPP[internal]: Got PDU: 2011-07-07 03:36:08 [10828] [6] DEBUG: SMPP PDU 0x1f286ad0 dump: 2011-07-07 03:36:08 [10828] [6] DEBUG: Β type_name: deliver_sm 2011-07-07 03:36:08 [10828] [6] DEBUG: Β command_id: 5 = 0x0005 2011-07-07 03:36:08 [10828] [6] DEBUG: Β command_status: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: Β sequence_number: 1310398007 = 0x4e1b1637 2011-07-07 03:36:08 [10828] [6] DEBUG: Β service_type: NULL 2011-07-07 03:36:08 [10828] [6] DEBUG: Β source_addr_ton: 2 = 0x0002 2011-07-07 03:36:08 [10828] [6] DEBUG: Β source_addr_npi: 1 = 0x0001 2011-07-07 03:36:08 [10828] [6] DEBUG: Β source_addr: 91903930 2011-07-07 03:36:08 [10828] [6] DEBUG: Β dest_addr_ton: 2 = 0x0002 2011-07-07 03:36:08 [10828] [6] DEBUG: Β dest_addr_npi: 1 = 0x0001 2011-07-07 03:36:08 [10828] [6] DEBUG: Β destination_addr: 11 2011-07-07 03:36:08 [10828] [6] DEBUG: Β esm_class: 4 = 0x0004 2011-07-07 03:36:08 [10828] [6] DEBUG: Β protocol_id: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: Β priority_flag: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: Β schedule_delivery_time: NULL 2011-07-07 03:36:08 [10828] [6] DEBUG: Β validity_period: NULL 2011-07-07 03:36:08 [10828] [6] DEBUG: Β registered_delivery: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: Β replace_if_present_flag: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: Β data_coding: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: Β sm_default_msg_id: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: Β sm_length: 132 = 0x0084 2011-07-07 03:36:08 [10828] [6] DEBUG: Β short_message: 2011-07-07 03:36:08 [10828] [6] DEBUG: Β Β Octet string at 0x1f27c670: 2011-07-07 03:36:08 [10828] [6] DEBUG: Β Β Β len: Β 132 2011-07-07 03:36:08 [10828] [6] DEBUG: Β Β Β size: 133 2011-07-07 03:36:08 [10828] [6] DEBUG: Β Β Β immutable: 0 2011-07-07 03:36:08 [10828] [6] DEBUG: Β Β Β data: 69 64 3a 30 33 31 33 39 38 30 31 2d 61 37 34 37 Β id:03139801-a747 2011-07-07 03:36:08 [10828] [6] DEBUG: Β Β Β data: 2d 34 64 63 33 2d 39 32 31 34 2d 32 34 30 32 30 Β -4dc3-9214-24020 2011-07-07 03:36:08 [10828] [6] DEBUG: Β Β Β data: 31 37 66 62 33 66 34 20 73 75 62 3a 30 30 30 20 Β 17fb3f4 sub:000 2011-07-07 03:36:08 [10828] [6] DEBUG: Β Β Β data: 64 6c 76 72 64 3a 30 30 31 20 73 75 62 6d 69 74 Β dlvrd:001 submit 2011-07-07 03:36:08 [10828] [6] DEBUG: Β Β Β data: 20
Re: got DLR but could not find message or was not interested in it
Alan, I am new to Kannel, so please tell me from where should I get those or how to enable it. Regards, Ashvin Savani CEO - Avinashi Group of Companies On Fri, Jul 8, 2011 at 3:14 AM, Alan McNatty a...@catalyst.net.nz wrote: Hi Ashvin, Can you please include the original submit_sm with register_delivery enabled so we can see the dlr being stored? Cheers, Alan On Thu, 2011-07-07 at 03:35 +0530, Ashvin Savani wrote: @Alvaro, I am using mysql-dlr. Here is bit full log of PDU 2011-07-07 03:36:08 [10828] [6] DEBUG: SMPP[internal]: Got PDU: 2011-07-07 03:36:08 [10828] [6] DEBUG: SMPP PDU 0x1f286ad0 dump: 2011-07-07 03:36:08 [10828] [6] DEBUG: type_name: deliver_sm 2011-07-07 03:36:08 [10828] [6] DEBUG: command_id: 5 = 0x0005 2011-07-07 03:36:08 [10828] [6] DEBUG: command_status: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: sequence_number: 1310398007 = 0x4e1b1637 2011-07-07 03:36:08 [10828] [6] DEBUG: service_type: NULL 2011-07-07 03:36:08 [10828] [6] DEBUG: source_addr_ton: 2 = 0x0002 2011-07-07 03:36:08 [10828] [6] DEBUG: source_addr_npi: 1 = 0x0001 2011-07-07 03:36:08 [10828] [6] DEBUG: source_addr: 91903930 2011-07-07 03:36:08 [10828] [6] DEBUG: dest_addr_ton: 2 = 0x0002 2011-07-07 03:36:08 [10828] [6] DEBUG: dest_addr_npi: 1 = 0x0001 2011-07-07 03:36:08 [10828] [6] DEBUG: destination_addr: 11 2011-07-07 03:36:08 [10828] [6] DEBUG: esm_class: 4 = 0x0004 2011-07-07 03:36:08 [10828] [6] DEBUG: protocol_id: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: priority_flag: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: schedule_delivery_time: NULL 2011-07-07 03:36:08 [10828] [6] DEBUG: validity_period: NULL 2011-07-07 03:36:08 [10828] [6] DEBUG: registered_delivery: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: replace_if_present_flag: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: data_coding: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: sm_default_msg_id: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: sm_length: 132 = 0x0084 2011-07-07 03:36:08 [10828] [6] DEBUG: short_message: 2011-07-07 03:36:08 [10828] [6] DEBUG:Octet string at 0x1f27c670: 2011-07-07 03:36:08 [10828] [6] DEBUG: len: 132 2011-07-07 03:36:08 [10828] [6] DEBUG: size: 133 2011-07-07 03:36:08 [10828] [6] DEBUG: immutable: 0 2011-07-07 03:36:08 [10828] [6] DEBUG: data: 69 64 3a 30 33 31 33 39 38 30 31 2d 61 37 34 37 id:03139801-a747 2011-07-07 03:36:08 [10828] [6] DEBUG: data: 2d 34 64 63 33 2d 39 32 31 34 2d 32 34 30 32 30 -4dc3-9214-24020 2011-07-07 03:36:08 [10828] [6] DEBUG: data: 31 37 66 62 33 66 34 20 73 75 62 3a 30 30 30 20 17fb3f4 sub:000 2011-07-07 03:36:08 [10828] [6] DEBUG: data: 64 6c 76 72 64 3a 30 30 31 20 73 75 62 6d 69 74 dlvrd:001 submit 2011-07-07 03:36:08 [10828] [6] DEBUG: data: 20 64 61 74 65 3a 31 31 30 37 30 37 30 33 33 34date:1107070334 2011-07-07 03:36:08 [10828] [6] DEBUG: data: 32 33 20 64 6f 6e 65 20 64 61 74 65 3a 31 31 30 23 done date:110 2011-07-07 03:36:08 [10828] [6] DEBUG: data: 37 30 37 30 33 33 34 32 39 20 73 74 61 74 3a 44 707033429 stat:D 2011-07-07 03:36:08 [10828] [6] DEBUG: data: 45 4c 49 56 52 44 20 65 72 72 3a 30 30 30 20 74 ELIVRD err:000 t 2011-07-07 03:36:08 [10828] [6] DEBUG: data: 65 78 74 3a ext: 2011-07-07 03:36:08 [10828] [6] DEBUG:Octet string dump ends. 2011-07-07 03:36:08 [10828] [6] DEBUG: source_subaddress: 2011-07-07 03:36:08 [10828] [6] DEBUG:Octet string at 0x1f27d540: 2011-07-07 03:36:08 [10828] [6] DEBUG: len: 7 2011-07-07 03:36:08 [10828] [6] DEBUG: size: 8 2011-07-07 03:36:08 [10828] [6] DEBUG: immutable: 0 2011-07-07 03:36:08 [10828] [6] DEBUG: data: a0 74 74 73 6c 74 64 .ttsltd 2011-07-07 03:36:08 [10828] [6] DEBUG:Octet string dump ends. 2011-07-07 03:36:08 [10828] [6] DEBUG: SMPP PDU dump ends. 2011-07-07 03:36:08 [10828] [6] DEBUG: SMPP[internal] handle_pdu, got DLR 2011-07-07 03:36:08 [10828] [6] DEBUG: DLR[internal]: Looking for DLR smsc=internal, ts=51615745, dst=91903930, type=1 2011-07-07 03:36:08 [10828] [6] WARNING: DLR[internal]: DLR from SMSCinternal for DST91903930 not found. 2011-07-07 03:36:08 [10828] [6] ERROR: SMPP[internal]: got DLR but could not find message or was not interested in it id51615745 dst91903930, type1 2011-07-07 03:36:08 [10828] [6] DEBUG: SMPP[internal]: Sending PDU: 2011-07-07 03:36:08 [10828] [6] DEBUG: SMPP PDU 0x1f27ce80 dump: 2011-07-07 03:36:08 [10828] [6] DEBUG: type_name: deliver_sm_resp 2011-07-07 03:36:08 [10828] [6] DEBUG: command_id: 2147483653 = 0x8005 2011-07-07 03:36:08 [10828] [6] DEBUG: command_status: 0 = 0x 2011-07-07 03:36:08
Re: got DLR but could not find message or was not interested in it
Saleem, Thanks for your reply. Here are my answers: 1) I am only having single SMSC defined, with id called internal. 2) Do I need to set it explicitly? I did not set any value for dlr_mask. Should I set it to 1? 3) Thats good point as well but my test message was even less than 50 chars, so no chance of having more than one part. 4) I am not too used to kannel to verify that, but how to verify it? Regards, Ashvin Savani CEO - Avinashi Group of Companies On Fri, Jul 8, 2011 at 4:52 AM, Mohammed Saleem mohammedsl...@gmail.comwrote: I am not a Kannel Guru, but I've seen it many times, could happen due to at least 4 reasons: (1) You sent a message through a different connection with different SMSC ID, the callback DLR won't get a match e.g. The transmit connection uses a different SMSC ID than the receiver connection, because kannel matches the SMSC ID, too !! (2) You sent a message without asking for DLR e.g. dlr_mask = 0, kannel then won't store a reference for the sent message. But the carrier sent you a DLR !! this case may happen because some carriers send you a DLR even if you don't ask for it. (3) When you send a concatenated MT, kannel keeps a reference for the first part only and ignores the other parts, but some operators send you the DLRs for all the parts, the other parts won't find a match. (4) This case is the most critical, some carriers send you the DLR before sending the ACK ! the DLR won't get a match because kannel didn't save the message reference yet ! it waits for the submit_sm_resp (ACK,NACK,...) before storing the reference in the store, Alex had a fix for this but it has performance penalties http://www.blogalex.com/archives/132. Hope u find your answers, or post your full log of this SMSC connection Best Regards, Mohammed M I Sleem http://www.abusleem.net - Personal blog On Fri, Jul 8, 2011 at 12:44 AM, Alan McNatty a...@catalyst.net.nzwrote: Hi Ashvin, Can you please include the original submit_sm with register_delivery enabled so we can see the dlr being stored? Cheers, Alan On Thu, 2011-07-07 at 03:35 +0530, Ashvin Savani wrote: @Alvaro, I am using mysql-dlr. Here is bit full log of PDU 2011-07-07 03:36:08 [10828] [6] DEBUG: SMPP[internal]: Got PDU: 2011-07-07 03:36:08 [10828] [6] DEBUG: SMPP PDU 0x1f286ad0 dump: 2011-07-07 03:36:08 [10828] [6] DEBUG: type_name: deliver_sm 2011-07-07 03:36:08 [10828] [6] DEBUG: command_id: 5 = 0x0005 2011-07-07 03:36:08 [10828] [6] DEBUG: command_status: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: sequence_number: 1310398007 = 0x4e1b1637 2011-07-07 03:36:08 [10828] [6] DEBUG: service_type: NULL 2011-07-07 03:36:08 [10828] [6] DEBUG: source_addr_ton: 2 = 0x0002 2011-07-07 03:36:08 [10828] [6] DEBUG: source_addr_npi: 1 = 0x0001 2011-07-07 03:36:08 [10828] [6] DEBUG: source_addr: 91903930 2011-07-07 03:36:08 [10828] [6] DEBUG: dest_addr_ton: 2 = 0x0002 2011-07-07 03:36:08 [10828] [6] DEBUG: dest_addr_npi: 1 = 0x0001 2011-07-07 03:36:08 [10828] [6] DEBUG: destination_addr: 11 2011-07-07 03:36:08 [10828] [6] DEBUG: esm_class: 4 = 0x0004 2011-07-07 03:36:08 [10828] [6] DEBUG: protocol_id: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: priority_flag: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: schedule_delivery_time: NULL 2011-07-07 03:36:08 [10828] [6] DEBUG: validity_period: NULL 2011-07-07 03:36:08 [10828] [6] DEBUG: registered_delivery: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: replace_if_present_flag: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: data_coding: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: sm_default_msg_id: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: sm_length: 132 = 0x0084 2011-07-07 03:36:08 [10828] [6] DEBUG: short_message: 2011-07-07 03:36:08 [10828] [6] DEBUG:Octet string at 0x1f27c670: 2011-07-07 03:36:08 [10828] [6] DEBUG: len: 132 2011-07-07 03:36:08 [10828] [6] DEBUG: size: 133 2011-07-07 03:36:08 [10828] [6] DEBUG: immutable: 0 2011-07-07 03:36:08 [10828] [6] DEBUG: data: 69 64 3a 30 33 31 33 39 38 30 31 2d 61 37 34 37 id:03139801-a747 2011-07-07 03:36:08 [10828] [6] DEBUG: data: 2d 34 64 63 33 2d 39 32 31 34 2d 32 34 30 32 30 -4dc3-9214-24020 2011-07-07 03:36:08 [10828] [6] DEBUG: data: 31 37 66 62 33 66 34 20 73 75 62 3a 30 30 30 20 17fb3f4 sub:000 2011-07-07 03:36:08 [10828] [6] DEBUG: data: 64 6c 76 72 64 3a 30 30 31 20 73 75 62 6d 69 74 dlvrd:001 submit 2011-07-07 03:36:08 [10828] [6] DEBUG: data: 20 64 61 74 65 3a 31 31 30 37 30 37 30 33 33 34date:1107070334 2011-07-07 03:36:08 [10828] [6] DEBUG: data: 32 33 20 64 6f 6e 65 20 64 61 74 65 3a 31 31 30 23 done date:110 2011-07-07 03:36:08 [10828] [6] DEBUG: data: 37 30 37 30 33 33 34 32
Re: got DLR but could not find message or was not interested in it
Hi Ashvin, Can you please include the original submit_sm with register_delivery enabled so we can see the dlr being stored? Cheers, Alan On Thu, 2011-07-07 at 03:35 +0530, Ashvin Savani wrote: @Alvaro, I am using mysql-dlr. Here is bit full log of PDU 2011-07-07 03:36:08 [10828] [6] DEBUG: SMPP[internal]: Got PDU: 2011-07-07 03:36:08 [10828] [6] DEBUG: SMPP PDU 0x1f286ad0 dump: 2011-07-07 03:36:08 [10828] [6] DEBUG: type_name: deliver_sm 2011-07-07 03:36:08 [10828] [6] DEBUG: command_id: 5 = 0x0005 2011-07-07 03:36:08 [10828] [6] DEBUG: command_status: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: sequence_number: 1310398007 = 0x4e1b1637 2011-07-07 03:36:08 [10828] [6] DEBUG: service_type: NULL 2011-07-07 03:36:08 [10828] [6] DEBUG: source_addr_ton: 2 = 0x0002 2011-07-07 03:36:08 [10828] [6] DEBUG: source_addr_npi: 1 = 0x0001 2011-07-07 03:36:08 [10828] [6] DEBUG: source_addr: 91903930 2011-07-07 03:36:08 [10828] [6] DEBUG: dest_addr_ton: 2 = 0x0002 2011-07-07 03:36:08 [10828] [6] DEBUG: dest_addr_npi: 1 = 0x0001 2011-07-07 03:36:08 [10828] [6] DEBUG: destination_addr: 11 2011-07-07 03:36:08 [10828] [6] DEBUG: esm_class: 4 = 0x0004 2011-07-07 03:36:08 [10828] [6] DEBUG: protocol_id: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: priority_flag: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: schedule_delivery_time: NULL 2011-07-07 03:36:08 [10828] [6] DEBUG: validity_period: NULL 2011-07-07 03:36:08 [10828] [6] DEBUG: registered_delivery: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: replace_if_present_flag: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: data_coding: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: sm_default_msg_id: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: sm_length: 132 = 0x0084 2011-07-07 03:36:08 [10828] [6] DEBUG: short_message: 2011-07-07 03:36:08 [10828] [6] DEBUG:Octet string at 0x1f27c670: 2011-07-07 03:36:08 [10828] [6] DEBUG: len: 132 2011-07-07 03:36:08 [10828] [6] DEBUG: size: 133 2011-07-07 03:36:08 [10828] [6] DEBUG: immutable: 0 2011-07-07 03:36:08 [10828] [6] DEBUG: data: 69 64 3a 30 33 31 33 39 38 30 31 2d 61 37 34 37 id:03139801-a747 2011-07-07 03:36:08 [10828] [6] DEBUG: data: 2d 34 64 63 33 2d 39 32 31 34 2d 32 34 30 32 30 -4dc3-9214-24020 2011-07-07 03:36:08 [10828] [6] DEBUG: data: 31 37 66 62 33 66 34 20 73 75 62 3a 30 30 30 20 17fb3f4 sub:000 2011-07-07 03:36:08 [10828] [6] DEBUG: data: 64 6c 76 72 64 3a 30 30 31 20 73 75 62 6d 69 74 dlvrd:001 submit 2011-07-07 03:36:08 [10828] [6] DEBUG: data: 20 64 61 74 65 3a 31 31 30 37 30 37 30 33 33 34date:1107070334 2011-07-07 03:36:08 [10828] [6] DEBUG: data: 32 33 20 64 6f 6e 65 20 64 61 74 65 3a 31 31 30 23 done date:110 2011-07-07 03:36:08 [10828] [6] DEBUG: data: 37 30 37 30 33 33 34 32 39 20 73 74 61 74 3a 44 707033429 stat:D 2011-07-07 03:36:08 [10828] [6] DEBUG: data: 45 4c 49 56 52 44 20 65 72 72 3a 30 30 30 20 74 ELIVRD err:000 t 2011-07-07 03:36:08 [10828] [6] DEBUG: data: 65 78 74 3a ext: 2011-07-07 03:36:08 [10828] [6] DEBUG:Octet string dump ends. 2011-07-07 03:36:08 [10828] [6] DEBUG: source_subaddress: 2011-07-07 03:36:08 [10828] [6] DEBUG:Octet string at 0x1f27d540: 2011-07-07 03:36:08 [10828] [6] DEBUG: len: 7 2011-07-07 03:36:08 [10828] [6] DEBUG: size: 8 2011-07-07 03:36:08 [10828] [6] DEBUG: immutable: 0 2011-07-07 03:36:08 [10828] [6] DEBUG: data: a0 74 74 73 6c 74 64 .ttsltd 2011-07-07 03:36:08 [10828] [6] DEBUG:Octet string dump ends. 2011-07-07 03:36:08 [10828] [6] DEBUG: SMPP PDU dump ends. 2011-07-07 03:36:08 [10828] [6] DEBUG: SMPP[internal] handle_pdu, got DLR 2011-07-07 03:36:08 [10828] [6] DEBUG: DLR[internal]: Looking for DLR smsc=internal, ts=51615745, dst=91903930, type=1 2011-07-07 03:36:08 [10828] [6] WARNING: DLR[internal]: DLR from SMSCinternal for DST91903930 not found. 2011-07-07 03:36:08 [10828] [6] ERROR: SMPP[internal]: got DLR but could not find message or was not interested in it id51615745 dst91903930, type1 2011-07-07 03:36:08 [10828] [6] DEBUG: SMPP[internal]: Sending PDU: 2011-07-07 03:36:08 [10828] [6] DEBUG: SMPP PDU 0x1f27ce80 dump: 2011-07-07 03:36:08 [10828] [6] DEBUG: type_name: deliver_sm_resp 2011-07-07 03:36:08 [10828] [6] DEBUG: command_id: 2147483653 = 0x8005 2011-07-07 03:36:08 [10828] [6] DEBUG: command_status: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: sequence_number: 1310398007 = 0x4e1b1637 2011-07-07 03:36:08 [10828] [6] DEBUG: message_id: NULL 2011-07-07 03:36:08 [10828] [6] DEBUG: SMPP PDU dump ends. Regards, Ashvin Savani CEO - Avinashi Group of Companies On Thu, Jul 7, 2011 at 3:31 AM, Alvaro Cornejo
Re: got DLR but could not find message or was not interested in it
I am not a Kannel Guru, but I've seen it many times, could happen due to at least 4 reasons: (1) You sent a message through a different connection with different SMSC ID, the callback DLR won't get a match e.g. The transmit connection uses a different SMSC ID than the receiver connection, because kannel matches the SMSC ID, too !! (2) You sent a message without asking for DLR e.g. dlr_mask = 0, kannel then won't store a reference for the sent message. But the carrier sent you a DLR !! this case may happen because some carriers send you a DLR even if you don't ask for it. (3) When you send a concatenated MT, kannel keeps a reference for the first part only and ignores the other parts, but some operators send you the DLRs for all the parts, the other parts won't find a match. (4) This case is the most critical, some carriers send you the DLR before sending the ACK ! the DLR won't get a match because kannel didn't save the message reference yet ! it waits for the submit_sm_resp (ACK,NACK,...) before storing the reference in the store, Alex had a fix for this but it has performance penalties http://www.blogalex.com/archives/132. Hope u find your answers, or post your full log of this SMSC connection Best Regards, Mohammed M I Sleem http://www.abusleem.net - Personal blog On Fri, Jul 8, 2011 at 12:44 AM, Alan McNatty a...@catalyst.net.nz wrote: Hi Ashvin, Can you please include the original submit_sm with register_delivery enabled so we can see the dlr being stored? Cheers, Alan On Thu, 2011-07-07 at 03:35 +0530, Ashvin Savani wrote: @Alvaro, I am using mysql-dlr. Here is bit full log of PDU 2011-07-07 03:36:08 [10828] [6] DEBUG: SMPP[internal]: Got PDU: 2011-07-07 03:36:08 [10828] [6] DEBUG: SMPP PDU 0x1f286ad0 dump: 2011-07-07 03:36:08 [10828] [6] DEBUG: type_name: deliver_sm 2011-07-07 03:36:08 [10828] [6] DEBUG: command_id: 5 = 0x0005 2011-07-07 03:36:08 [10828] [6] DEBUG: command_status: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: sequence_number: 1310398007 = 0x4e1b1637 2011-07-07 03:36:08 [10828] [6] DEBUG: service_type: NULL 2011-07-07 03:36:08 [10828] [6] DEBUG: source_addr_ton: 2 = 0x0002 2011-07-07 03:36:08 [10828] [6] DEBUG: source_addr_npi: 1 = 0x0001 2011-07-07 03:36:08 [10828] [6] DEBUG: source_addr: 91903930 2011-07-07 03:36:08 [10828] [6] DEBUG: dest_addr_ton: 2 = 0x0002 2011-07-07 03:36:08 [10828] [6] DEBUG: dest_addr_npi: 1 = 0x0001 2011-07-07 03:36:08 [10828] [6] DEBUG: destination_addr: 11 2011-07-07 03:36:08 [10828] [6] DEBUG: esm_class: 4 = 0x0004 2011-07-07 03:36:08 [10828] [6] DEBUG: protocol_id: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: priority_flag: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: schedule_delivery_time: NULL 2011-07-07 03:36:08 [10828] [6] DEBUG: validity_period: NULL 2011-07-07 03:36:08 [10828] [6] DEBUG: registered_delivery: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: replace_if_present_flag: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: data_coding: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: sm_default_msg_id: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: sm_length: 132 = 0x0084 2011-07-07 03:36:08 [10828] [6] DEBUG: short_message: 2011-07-07 03:36:08 [10828] [6] DEBUG:Octet string at 0x1f27c670: 2011-07-07 03:36:08 [10828] [6] DEBUG: len: 132 2011-07-07 03:36:08 [10828] [6] DEBUG: size: 133 2011-07-07 03:36:08 [10828] [6] DEBUG: immutable: 0 2011-07-07 03:36:08 [10828] [6] DEBUG: data: 69 64 3a 30 33 31 33 39 38 30 31 2d 61 37 34 37 id:03139801-a747 2011-07-07 03:36:08 [10828] [6] DEBUG: data: 2d 34 64 63 33 2d 39 32 31 34 2d 32 34 30 32 30 -4dc3-9214-24020 2011-07-07 03:36:08 [10828] [6] DEBUG: data: 31 37 66 62 33 66 34 20 73 75 62 3a 30 30 30 20 17fb3f4 sub:000 2011-07-07 03:36:08 [10828] [6] DEBUG: data: 64 6c 76 72 64 3a 30 30 31 20 73 75 62 6d 69 74 dlvrd:001 submit 2011-07-07 03:36:08 [10828] [6] DEBUG: data: 20 64 61 74 65 3a 31 31 30 37 30 37 30 33 33 34date:1107070334 2011-07-07 03:36:08 [10828] [6] DEBUG: data: 32 33 20 64 6f 6e 65 20 64 61 74 65 3a 31 31 30 23 done date:110 2011-07-07 03:36:08 [10828] [6] DEBUG: data: 37 30 37 30 33 33 34 32 39 20 73 74 61 74 3a 44 707033429 stat:D 2011-07-07 03:36:08 [10828] [6] DEBUG: data: 45 4c 49 56 52 44 20 65 72 72 3a 30 30 30 20 74 ELIVRD err:000 t 2011-07-07 03:36:08 [10828] [6] DEBUG: data: 65 78 74 3a ext: 2011-07-07 03:36:08 [10828] [6] DEBUG:Octet string dump ends. 2011-07-07 03:36:08 [10828] [6] DEBUG: source_subaddress: 2011-07-07 03:36:08 [10828] [6] DEBUG:Octet string at 0x1f27d540: 2011-07-07 03:36:08 [10828] [6] DEBUG: len: 7 2011-07-07 03:36:08 [10828] [6] DEBUG: size: 8 2011-07-07 03:36:08
got DLR but could not find message or was not interested in it
Hi, I know that this question asked many times ago but I almost tried everything but it simply is not working. Here are useful information ( I also tried all msg id types and even commented it): Log of Problem: DEBUG: SMPP[internal] handle_pdu, got DLR 2011-07-07 02:27:04 [9255] [6] DEBUG: DLR[internal]: Looking for DLR smsc=internal, ts=ece60bb7-725b-433a-9337-39a61cec86c9, dst=91903930, type=1 2011-07-07 02:27:04 [9255] [6] WARNING: DLR[internal]: DLR from SMSCinternal for DST91903930 not found. 2011-07-07 02:27:04 [9255] [6] ERROR: SMPP[internal]: got DLR but could not find message or was not interested in it idece60bb7-725b-433a-9337-39a61cec86c9 dst91903930, type1 Configuration: group=smsc smsc=smpp smsc-id=internal interface-version=34 host=xxx port=xzxx smsc-username=x smsc-password= system-type=default transceiver-mode=1 group = mysql-connection id = mydlr host = x.com username = x password = x database = kannel_dlr # max count of connections that will be opened for dbpool # default is 1 max-connections = 1 group = dlr-db id = mydlr table = dlr field-smsc = smsc field-timestamp = ts field-destination = destination field-source = source field-service = service field-url = url field-mask = mask field-status = status field-boxc-id = boxc Please help me :) Regards, Ashvin Savani CEO - Avinashi Group of Companies
Re: got DLR but could not find message or was not interested in it
Hi Ashvin, Can you also include full bearerbox logs of both the raw MT and DLR (submit_sm and deliver_sm PDUs). On Thu, 2011-07-07 at 02:57 +0530, Ashvin Savani wrote: Hi, I know that this question asked many times ago but I almost tried everything but it simply is not working. Here are useful information ( I also tried all msg id types and even commented it): Log of Problem: DEBUG: SMPP[internal] handle_pdu, got DLR 2011-07-07 02:27:04 [9255] [6] DEBUG: DLR[internal]: Looking for DLR smsc=internal, ts=ece60bb7-725b-433a-9337-39a61cec86c9, dst=91903930, type=1 2011-07-07 02:27:04 [9255] [6] WARNING: DLR[internal]: DLR from SMSCinternal for DST91903930 not found. 2011-07-07 02:27:04 [9255] [6] ERROR: SMPP[internal]: got DLR but could not find message or was not interested in it idece60bb7-725b-433a-9337-39a61cec86c9 dst91903930, type1 Configuration: group=smsc smsc=smpp smsc-id=internal interface-version=34 host=xxx port=xzxx smsc-username=x smsc-password= system-type=default transceiver-mode=1 group = mysql-connection id = mydlr host = x.com username = x password = x database = kannel_dlr # max count of connections that will be opened for dbpool # default is 1 max-connections = 1 group = dlr-db id = mydlr table = dlr field-smsc = smsc field-timestamp = ts field-destination = destination field-source = source field-service = service field-url = url field-mask = mask field-status = status field-boxc-id = boxc Please help me :) Regards, Ashvin Savani CEO - Avinashi Group of Companies
Re: got DLR but could not find message or was not interested in it
sorry for the silly question but what is default location to get BB logs? Regards, Ashvin Savani CEO - Avinashi Group of Companies On Thu, Jul 7, 2011 at 3:20 AM, Alan McNatty a...@catalyst.net.nz wrote: Hi Ashvin, Can you also include full bearerbox logs of both the raw MT and DLR (submit_sm and deliver_sm PDUs). On Thu, 2011-07-07 at 02:57 +0530, Ashvin Savani wrote: Hi, I know that this question asked many times ago but I almost tried everything but it simply is not working. Here are useful information ( I also tried all msg id types and even commented it): Log of Problem: DEBUG: SMPP[internal] handle_pdu, got DLR 2011-07-07 02:27:04 [9255] [6] DEBUG: DLR[internal]: Looking for DLR smsc=internal, ts=ece60bb7-725b-433a-9337-39a61cec86c9, dst=91903930, type=1 2011-07-07 02:27:04 [9255] [6] WARNING: DLR[internal]: DLR from SMSCinternal for DST91903930 not found. 2011-07-07 02:27:04 [9255] [6] ERROR: SMPP[internal]: got DLR but could not find message or was not interested in it idece60bb7-725b-433a-9337-39a61cec86c9 dst91903930, type1 Configuration: group=smsc smsc=smpp smsc-id=internal interface-version=34 host=xxx port=xzxx smsc-username=x smsc-password= system-type=default transceiver-mode=1 group = mysql-connection id = mydlr host = x.com username = x password = x database = kannel_dlr # max count of connections that will be opened for dbpool # default is 1 max-connections = 1 group = dlr-db id = mydlr table = dlr field-smsc = smsc field-timestamp = ts field-destination = destination field-source = source field-service = service field-url = url field-mask = mask field-status = status field-boxc-id = boxc Please help me :) Regards, Ashvin Savani CEO - Avinashi Group of Companies
Re: got DLR but could not find message or was not interested in it
This usually means kannel is receiving a dlr from your provider but kannel can't match between it and its dlr database. which store are you using? check the pdu to see how your message id is been sent and if it matches the one sent by your provider. I think kannel always sent in decimal format -and store it like that- but some smsc convert it to hex. So you need to adjust id-type accordingly (check userguide) 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 Wed, Jul 6, 2011 at 4:27 PM, Ashvin Savani ash...@avinashi.com wrote: Hi, I know that this question asked many times ago but I almost tried everything but it simply is not working. Here are useful information ( I also tried all msg id types and even commented it): Log of Problem: DEBUG: SMPP[internal] handle_pdu, got DLR 2011-07-07 02:27:04 [9255] [6] DEBUG: DLR[internal]: Looking for DLR smsc=internal, ts=ece60bb7-725b-433a-9337-39a61cec86c9, dst=91903930, type=1 2011-07-07 02:27:04 [9255] [6] WARNING: DLR[internal]: DLR from SMSCinternal for DST91903930 not found. 2011-07-07 02:27:04 [9255] [6] ERROR: SMPP[internal]: got DLR but could not find message or was not interested in it idece60bb7-725b-433a-9337-39a61cec86c9 dst91903930, type1 Configuration: group=smsc smsc=smpp smsc-id=internal interface-version=34 host=xxx port=xzxx smsc-username=x smsc-password= system-type=default transceiver-mode=1 group = mysql-connection id = mydlr host = x.com username = x password = x database = kannel_dlr # max count of connections that will be opened for dbpool # default is 1 max-connections = 1 group = dlr-db id = mydlr table = dlr field-smsc = smsc field-timestamp = ts field-destination = destination field-source = source field-service = service field-url = url field-mask = mask field-status = status field-boxc-id = boxc Please help me :) Regards, Ashvin Savani CEO - Avinashi Group of Companies
Re: got DLR but could not find message or was not interested in it
@Alvaro, I am using mysql-dlr. Here is bit full log of PDU 2011-07-07 03:36:08 [10828] [6] DEBUG: SMPP[internal]: Got PDU: 2011-07-07 03:36:08 [10828] [6] DEBUG: SMPP PDU 0x1f286ad0 dump: 2011-07-07 03:36:08 [10828] [6] DEBUG: type_name: deliver_sm 2011-07-07 03:36:08 [10828] [6] DEBUG: command_id: 5 = 0x0005 2011-07-07 03:36:08 [10828] [6] DEBUG: command_status: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: sequence_number: 1310398007 = 0x4e1b1637 2011-07-07 03:36:08 [10828] [6] DEBUG: service_type: NULL 2011-07-07 03:36:08 [10828] [6] DEBUG: source_addr_ton: 2 = 0x0002 2011-07-07 03:36:08 [10828] [6] DEBUG: source_addr_npi: 1 = 0x0001 2011-07-07 03:36:08 [10828] [6] DEBUG: source_addr: 91903930 2011-07-07 03:36:08 [10828] [6] DEBUG: dest_addr_ton: 2 = 0x0002 2011-07-07 03:36:08 [10828] [6] DEBUG: dest_addr_npi: 1 = 0x0001 2011-07-07 03:36:08 [10828] [6] DEBUG: destination_addr: 11 2011-07-07 03:36:08 [10828] [6] DEBUG: esm_class: 4 = 0x0004 2011-07-07 03:36:08 [10828] [6] DEBUG: protocol_id: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: priority_flag: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: schedule_delivery_time: NULL 2011-07-07 03:36:08 [10828] [6] DEBUG: validity_period: NULL 2011-07-07 03:36:08 [10828] [6] DEBUG: registered_delivery: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: replace_if_present_flag: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: data_coding: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: sm_default_msg_id: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: sm_length: 132 = 0x0084 2011-07-07 03:36:08 [10828] [6] DEBUG: short_message: 2011-07-07 03:36:08 [10828] [6] DEBUG:Octet string at 0x1f27c670: 2011-07-07 03:36:08 [10828] [6] DEBUG: len: 132 2011-07-07 03:36:08 [10828] [6] DEBUG: size: 133 2011-07-07 03:36:08 [10828] [6] DEBUG: immutable: 0 2011-07-07 03:36:08 [10828] [6] DEBUG: data: 69 64 3a 30 33 31 33 39 38 30 31 2d 61 37 34 37 id:03139801-a747 2011-07-07 03:36:08 [10828] [6] DEBUG: data: 2d 34 64 63 33 2d 39 32 31 34 2d 32 34 30 32 30 -4dc3-9214-24020 2011-07-07 03:36:08 [10828] [6] DEBUG: data: 31 37 66 62 33 66 34 20 73 75 62 3a 30 30 30 20 17fb3f4 sub:000 2011-07-07 03:36:08 [10828] [6] DEBUG: data: 64 6c 76 72 64 3a 30 30 31 20 73 75 62 6d 69 74 dlvrd:001 submit 2011-07-07 03:36:08 [10828] [6] DEBUG: data: 20 64 61 74 65 3a 31 31 30 37 30 37 30 33 33 34date:1107070334 2011-07-07 03:36:08 [10828] [6] DEBUG: data: 32 33 20 64 6f 6e 65 20 64 61 74 65 3a 31 31 30 23 done date:110 2011-07-07 03:36:08 [10828] [6] DEBUG: data: 37 30 37 30 33 33 34 32 39 20 73 74 61 74 3a 44 707033429 stat:D 2011-07-07 03:36:08 [10828] [6] DEBUG: data: 45 4c 49 56 52 44 20 65 72 72 3a 30 30 30 20 74 ELIVRD err:000 t 2011-07-07 03:36:08 [10828] [6] DEBUG: data: 65 78 74 3a ext: 2011-07-07 03:36:08 [10828] [6] DEBUG:Octet string dump ends. 2011-07-07 03:36:08 [10828] [6] DEBUG: source_subaddress: 2011-07-07 03:36:08 [10828] [6] DEBUG:Octet string at 0x1f27d540: 2011-07-07 03:36:08 [10828] [6] DEBUG: len: 7 2011-07-07 03:36:08 [10828] [6] DEBUG: size: 8 2011-07-07 03:36:08 [10828] [6] DEBUG: immutable: 0 2011-07-07 03:36:08 [10828] [6] DEBUG: data: a0 74 74 73 6c 74 64 .ttsltd 2011-07-07 03:36:08 [10828] [6] DEBUG:Octet string dump ends. 2011-07-07 03:36:08 [10828] [6] DEBUG: SMPP PDU dump ends. 2011-07-07 03:36:08 [10828] [6] DEBUG: SMPP[internal] handle_pdu, got DLR 2011-07-07 03:36:08 [10828] [6] DEBUG: DLR[internal]: Looking for DLR smsc=internal, ts=51615745, dst=91903930, type=1 2011-07-07 03:36:08 [10828] [6] WARNING: DLR[internal]: DLR from SMSCinternal for DST91903930 not found. 2011-07-07 03:36:08 [10828] [6] ERROR: SMPP[internal]: got DLR but could not find message or was not interested in it id51615745 dst91903930, type1 2011-07-07 03:36:08 [10828] [6] DEBUG: SMPP[internal]: Sending PDU: 2011-07-07 03:36:08 [10828] [6] DEBUG: SMPP PDU 0x1f27ce80 dump: 2011-07-07 03:36:08 [10828] [6] DEBUG: type_name: deliver_sm_resp 2011-07-07 03:36:08 [10828] [6] DEBUG: command_id: 2147483653 = 0x8005 2011-07-07 03:36:08 [10828] [6] DEBUG: command_status: 0 = 0x 2011-07-07 03:36:08 [10828] [6] DEBUG: sequence_number: 1310398007 = 0x4e1b1637 2011-07-07 03:36:08 [10828] [6] DEBUG: message_id: NULL 2011-07-07 03:36:08 [10828] [6] DEBUG: SMPP PDU dump ends. Regards, Ashvin Savani CEO - Avinashi Group of Companies On Thu, Jul 7, 2011 at 3:31 AM, Alvaro Cornejo cornejo.alv...@gmail.comwrote: This usually means kannel is receiving a dlr from your provider but kannel can't match between it and its dlr database. which store are you using? check the pdu to see how your message id is been sent and if it matches the one sent by your provider. I think kannel always
DLR Concurrency Problem (got DLR but could not find message or was not interested in it)
Dear Kannel Developers, I found a concurrency BUG in DLR Code. 2011-02-09 11:30:26 [29361] [27] DEBUG: DLR[mysql]: Looking for DLR smsc=mtn1, ts=1613732592, dst=989372474050, type=2 2011-02-09 11:30:26 [29361] [27] DEBUG: sql: SELECT mask, service, url, source, destination, boxc FROM dlr WHERE smsc='SMSC' AND ts='1613732592'; 2011-02-09 11:30:26 [29361] [27] ERROR: SMPP[SMSC]: got DLR but could not find message or was not interested in it id1613732592 dstDST, type2 2011-02-09 11:30:26 [29361] [26] DEBUG: DLR[mysql]: Adding DLR smsc=SMSC, ts=1613732592, src=SRC, dst=DST, mask=31, boxc=13013 2011-02-09 11:30:26 [29361] [26] DEBUG: sql: INSERT INTO dlr (smsc, ts, source, destination, service, url, mask, boxc, status) VALUES (...); *dlr_find* method got calls before *dlr_add!* -- Sincerely, Sayed Hadi Rastgou Haghi
Re: DLR Concurrency Problem (got DLR but could not find message or was not interested in it)
It's not a concurrency bug, your aggregator is probably sending the DLR's deliver_sm before sending the submit_sm_resp. I've seen it happening on some aggregators (maybe because of their load-balancers processing the messages on different nodes? Can't tell for sure). I have a simple patch that retries the dlr-find a given number of times, but it poses a performance penalty and it's not intended to be used under heavy traffic. Regards, Alex On Wed, Feb 9, 2011 at 9:35 AM, Sayed Hadi Rastgou Haghi hadi.rast...@gmail.com wrote: Dear Kannel Developers, I found a concurrency BUG in DLR Code. 2011-02-09 11:30:26 [29361] [27] DEBUG: DLR[mysql]: Looking for DLR smsc=mtn1, ts=1613732592, dst=989372474050, type=2 2011-02-09 11:30:26 [29361] [27] DEBUG: sql: SELECT mask, service, url, source, destination, boxc FROM dlr WHERE smsc='SMSC' AND ts='1613732592'; 2011-02-09 11:30:26 [29361] [27] ERROR: SMPP[SMSC]: got DLR but could not find message or was not interested in it id1613732592 dstDST, type2 2011-02-09 11:30:26 [29361] [26] DEBUG: DLR[mysql]: Adding DLR smsc=SMSC, ts=1613732592, src=SRC, dst=DST, mask=31, boxc=13013 2011-02-09 11:30:26 [29361] [26] DEBUG: sql: INSERT INTO dlr (smsc, ts, source, destination, service, url, mask, boxc, status) VALUES (...); *dlr_find* method got calls before *dlr_add!* -- Sincerely, Sayed Hadi Rastgou Haghi
Re: Help for Error ERROR: SMPP[XL_1]: got DLR but could not find message or was not interested in it id2451373786 dst62817xxxxx, type2
You have to use: msg-id-type = 0x01 in smsc group Good Luck benaiad almontaha.com.ly
Help for Error ERROR: SMPP[XL_1]: got DLR but could not find message or was not interested in it id2451373786 dst62817xxxxx, type2
Dear All, I have a problem with delivery report, in Log seem like that : 2007-07-08 13:19:29 [19789] [7] ERROR: SMPP[XL_1]: got DLR but could not find message or was not interested in it id2451373786 dst62817xxx, type2 2007-07-11 05:18:39 [19789] [6] ERROR: SMPP[XL_1]: got DLR but could not find message or was not interested in it id3248991539 dst62817, type2 2007-07-11 13:18:23 [19789] [6] ERROR: SMPP[XL_1]: got DLR but could not find message or was not interested in it id3966075365 dst62817x, type2 2007-07-22 13:19:22 [5910] [6] ERROR: SMPP[XL_1]: got DLR but could not find message or was not interested in it id289476950 dst628171x, type1 My Kannel.conf like : group = core admin-port = 1 smsbox-port = 10001 admin-password = kannel #admin-allow-ip = log-file = /var/log/kannel/xl_kannel_core.log box-deny-ip = *.*.*.* box-allow-ip = 127.0.0.1 access-log = /var/log/kannel/xl_kannel_access.log store-file = /tmp/store_xl.dat dlr-storage = mysql log-level = 0 group = mysql-connection id = xldlr host = Interface username = root password = root2007 database = kannel_db group = dlr-db id = xldlr table = dlr_xl field-smsc = smsc_id field-timestamp = timestamp field-source = source field-destination = destination field-service = service field-boxc-id = smsbox_id field-url = url field-mask = mask field-status = status # SMSBOX SETUP group = smsbox bearerbox-host = 127.0.0.1 sendsms-port = 19788 global-sender = 9788 #sendsms-chars = 0123456789 +- log-file = /var/log/kannel/xl_kannel_smsbox.log log-level = 0 access-log = /var/log/kannel/xl_kannel_smsbox-access.log # SERVICES group = sendsms-user username = root password = root2007 #user-allow-ip = 192.168.1.* # there should be default always group = sms-service keyword = default text = No service specified catch-all = true get-url = http://192.168.1.7/smpp/index.php?seq=%Ifrom=%pto=%Ptext=%a; max-messages = 0 group = smsc smsc-id = XL_1 smsc = smpp throughput = 3 host = 192.168.1.17 receive-port = 10104 port = 10104 reconnect-delay = 3 transceiver-mode = true smsc-username = root smsc-password = root9788 system-type = TCP enquire-link-interval = 60 interface-version = 34 source-addr-ton = 0 source-addr-npi= 1 dest-addr-ton = 1 dest-addr-npi = 1 msg-id-type = 0x00 group = smsc smsc-id = XL_1 smsc = smpp throughput = 3 host = 192.168.1.17 port = 10104 receive-port = 0 reconnect-delay = 3 transceiver-mode = false smsc-username = root smsc-password = root9788 system-type = TCP enquire-link-interval = 60 interface-version = 34 source-addr-ton = 0 source-addr-npi= 1 dest-addr-ton = 1 dest-addr-npi = 1 msg-id-type = 0x01 Anyone can help ? Thanks Best Regards, Hendra *** Confidentiality Notice This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. **
Re: got DLR but could not find message or was not interested in it
Hi Mikko, thanks for the fast help, now it works :-D I have added msg-id-type = 1 smsc-id = text and I get delivery report :-) without any encoding changes ??? , However: I have defined service which depending on the keyword sends back some data. But when I send SMS from my mobile phone to the SMSC I get the service working but do not get delivery report for my reply althought the message is sent. does dlr-url works for the whole kannel instance? (what is the diference between SMS sent from browser and SMS sent per request i.e. as a result of some kannel processing? I even added dlr-url in the service url and still nothing. group = sms-service keyword = php get-url = http://10.1.10.146/test/receive.php?k=%kdlr-mask=3dlr-url=http://10.1.10.146/test/record-dlr.php?oa=%pda=%Psmsc=%idlr=%dtime=%t; What I am making wrong? looking forward to hearing from you alex Mikko Kiesilä wrote: aleksandar ivanovski wrote: Hi, I am asking the same Q 2nd time, I will rephrase it this time with hope that somebody can help. (I now there are million post on this issue on the forum but I cannot make it work :( ) KANNEL USER GUIDE: Note: If you want to use delivery reports, you must define a smsc-id for each smsc group. i've added a line smsc-id=ENC in # SMSC CONNECTIONS and nothing changes :( (Should I add this somewhere else)? Uhm... Not sure where the # SMSC CONNECTIONS -comment is, but the smsc-id should be defined in the smsc group like this: # Connection to SMSC group = smsc smsc = smpp smsc-id = some_oper host = x.x.x.x port = smsc-username = myname smsc-password = secret ...and so on. Other than that, if you are using SMPP (as in the example above) you might need to set the msg-id-type -parameter, if the SMSC you're connecting to doesn't use same number base when you get the message id when sending and when receiving DLRs. For example, (IIRC) Vodafone in UK does this. You get the id for the submitted message as hexadecimal and the delivery report has the message id as decimal. I am trying to put dlr-url and dlr-mask in the sendsms url: http://10.1.10.146:13013/cgi-bin/sendsms?username=zpassword=zfrom=zto=38970327924dlr-mask=7dlr-url=http://10.1.10.146/test/record-dlr.php?dlrtype=%d The url parameters should be URLEncoded, your dlr-url parameter is not... (Ie. there are characters like ? visible there.)
got DLR but could not find message or was not interested in it
Hi, I am asking the same Q 2nd time, I will rephrase it this time with hope that somebody can help. (I now there are million post on this issue on the forum but I cannot make it work :( ) KANNEL USER GUIDE: Note: If you want to use delivery reports, you must define a smsc-id for each smsc group. i've added a line smsc-id=ENC in # SMSC CONNECTIONS and nothing changes :( (Should I add this somewhere else)? I have made a php page that works when requested with values from browser and add dlr-url=http://10.1.10.146/test/record-dlr.php?oa=%pda=%Psmsc=%idlr=%d; at SEND_SMS USER part no luck I am trying to put dlr-url and dlr-mask in the sendsms url: http://10.1.10.146:13013/cgi-bin/sendsms?username=zpassword=zfrom=zto=38970327924dlr-mask=7dlr-url=http://10.1.10.146/test/record-dlr.php?dlrtype=%d and all I get from my log in all cases above is: 2005-05-24 04:53:03 [1857] [7] WARNING: DLR[internal]: DLR for DST38970327924 not found. 2005-05-24 04:53:03 [1857] [7] ERROR: SMPP[ENC]: got DLR but could not find message or was not interested in it id0474628512 dsteuronetcom, type1 2005-05-24 04:55:35 [1857] [7] WARNING: DLR[internal]: DLR for DST38970327924 not found. 2005-05-24 04:55:35 [1857] [7] ERROR: SMPP[ENC]: got DLR but could not find message or was not interested in it id0474630125 dsteuronetcom, type1 May this be a compile time conf? Or smskannel.conf error ? Suse Linux 9.0 and Kannel 1.4.0 Please help couse I think I have killed this forum + google and I guess it is really simple but I cannot figure it out :-( 10x
got DLR but could not find message or was not interested in it
Hi list, I've been dealing with the DLR reports for a couple of days and I'm not able to make this works. I'm using mysql storage, and every time I send a message a new DLR record is inserted in the DLR table with the DLR status=12, this happens in the submit_sm phase, and after that in the deliver_sm kannel gets the DLR from the SMSC but always get the message got DLR but could not find message or was not interested in it I reviewed the mail list and did tests with all combinations of msg-id-type parameter and also y set the alt-charset parameter to LATIN1 but in all cases the same result. Here is my log 2004-04-16 09:58:42 [14] DEBUG: boxc_receiver: sms received 2004-04-16 09:58:42 [5] DEBUG: SMPP[viva]: Sending PDU: 2004-04-16 09:58:42 [5] DEBUG: SMPP PDU 0x80fc548 dump: 2004-04-16 09:58:42 [5] DEBUG: type_name: submit_sm 2004-04-16 09:58:42 [5] DEBUG: command_id: 4 = 0x0004 2004-04-16 09:58:42 [5] DEBUG: command_status: 0 = 0x 2004-04-16 09:58:42 [5] DEBUG: sequence_number: 3 = 0x0003 2004-04-16 09:58:42 [5] DEBUG: service_type: NULL 2004-04-16 09:58:42 [5] DEBUG: source_addr_ton: 2 = 0x0002 2004-04-16 09:58:42 [5] DEBUG: source_addr_npi: 1 = 0x0001 2004-04-16 09:58:42 [5] DEBUG: source_addr: 123 2004-04-16 09:58:42 [5] DEBUG: dest_addr_ton: 2 = 0x0002 2004-04-16 09:58:42 [5] DEBUG: dest_addr_npi: 1 = 0x0001 2004-04-16 09:58:42 [5] DEBUG: destination_addr: 59170610160 2004-04-16 09:58:42 [5] DEBUG: esm_class: 3 = 0x0003 2004-04-16 09:58:42 [5] DEBUG: protocol_id: 0 = 0x 2004-04-16 09:58:42 [5] DEBUG: priority_flag: 0 = 0x 2004-04-16 09:58:42 [5] DEBUG: schedule_delivery_time: NULL 2004-04-16 09:58:42 [5] DEBUG: validity_period: NULL 2004-04-16 09:58:42 [5] DEBUG: registered_delivery: 1 = 0x0001 2004-04-16 09:58:42 [5] DEBUG: replace_if_present_flag: 0 = 0x 2004-04-16 09:58:42 [5] DEBUG: data_coding: 0 = 0x 2004-04-16 09:58:42 [5] DEBUG: sm_default_msg_id: 0 = 0x 2004-04-16 09:58:42 [5] DEBUG: sm_length: 33 = 0x0021 2004-04-16 09:58:42 [5] DEBUG: short_message: 2004-04-16 09:58:42 [5] DEBUG:Octet string at 0x80fc5e8: 2004-04-16 09:58:42 [5] DEBUG: len: 33 2004-04-16 09:58:42 [5] DEBUG: size: 34 2004-04-16 09:58:42 [5] DEBUG: immutable: 0 2004-04-16 09:58:42 [5] DEBUG: data: 68 6f 6c 61 20 65 73 74 hola est 2004-04-16 09:58:42 [5] DEBUG: data: 65 20 65 73 20 75 6e 20 e es un 2004-04-16 09:58:42 [5] DEBUG: data: 6d 65 6e 73 61 6a 65 20 mensaje 2004-04-16 09:58:42 [5] DEBUG: data: 64 65 20 70 72 75 65 62 de prueb 2004-04-16 09:58:42 [5] DEBUG: data: 61a 2004-04-16 09:58:42 [5] DEBUG:Octet string dump ends. 2004-04-16 09:58:42 [5] DEBUG: SMPP PDU dump ends. 2004-04-16 09:58:42 [5] DEBUG: SMPP[viva]: Got PDU: 2004-04-16 09:58:42 [5] DEBUG: SMPP PDU 0x80fc548 dump: 2004-04-16 09:58:42 [5] DEBUG: type_name: submit_sm_resp 2004-04-16 09:58:42 [5] DEBUG: command_id: 2147483652 = 0x8004 2004-04-16 09:58:42 [5] DEBUG: command_status: 0 = 0x 2004-04-16 09:58:42 [5] DEBUG: sequence_number: 3 = 0x0003 2004-04-16 09:58:42 [5] DEBUG: message_id: 2004-04-16 09:58:42 [5] DEBUG:Octet string at 0x80fbfd8: 2004-04-16 09:58:42 [5] DEBUG: len: 23 2004-04-16 09:58:42 [5] DEBUG: size: 24 2004-04-16 09:58:42 [5] DEBUG: immutable: 0 2004-04-16 09:58:42 [5] DEBUG: data: 30 34 30 34 31 36 30 39 04041609 2004-04-16 09:58:42 [5] DEBUG: data: 35 34 33 32 35 39 31 37 54325917 2004-04-16 09:58:42 [5] DEBUG: data: 30 36 31 30 31 36 30 0610160 2004-04-16 09:58:42 [5] DEBUG:Octet string dump ends. 2004-04-16 09:58:42 [5] DEBUG: SMPP PDU dump ends. 2004-04-16 09:58:42 [5] DEBUG: Found entry, row[0]=31, row[1]=viva, row[2]=http://10.29.3.23/kannel/dlr.php?id=3dlr=%d, row[3]=123, row[4]=viva 2004-04-16 09:58:42 [5] DEBUG: created DLR message for URL http://10.29.3.23/kannel/dlr.php?id=3dlr=%d 2004-04-16 09:58:42 [5] DEBUG: DLR not deleted because we wait on more reports 2004-04-16 09:58:42 [15] DEBUG: send_msg: sending msg to boxc: viva 2004-04-16 09:58:42 [15] DEBUG: boxc_sender: sent message to 127.0.0.1 2004-04-16 09:58:42 [14] DEBUG: boxc_receiver: got ack 2004-04-16 09:58:47 [5] DEBUG: SMPP[viva]: Got PDU: 2004-04-16 09:58:47 [5] DEBUG: SMPP PDU 0x80fc5e8 dump: 2004-04-16 09:58:47 [5] DEBUG: type_name: deliver_sm 2004-04-16 09:58:47 [5] DEBUG: command_id: 5 = 0x0005 2004-04-16 09:58:47 [5] DEBUG: command_status: 0 = 0x 2004-04-16 09:58:47 [5] DEBUG: sequence_number: 2 = 0x0002 2004-04-16 09:58:47 [5] DEBUG: service_type: NULL 2004-04-16 09:58:47 [5] DEBUG: source_addr_ton: 1 = 0x0001 2004-04-16 09:58:47 [5] DEBUG: source_addr_npi: 1 = 0x0001 2004-04-16 09:58:47 [5] DEBUG: source_addr: 59170610160 2004-04-16 09:58:47 [5] DEBUG: dest_addr_ton: 1 = 0x0001 2004-04-16 09:58:47 [5] DEBUG: dest_addr_npi: 1 = 0x0001
Re: got DLR but could not find message or was not interested in it
Hi Ivars, Check Appendix B - Delivery Receipt Format of the SMPP 3.4 specs for details on expected DLR format. The format you quote seems to differ from this significantly (I looks like your provider has modified to include billing notifications, ie: status: charged?). So, the msg-id-type config parameter won't work for you. If you need to make your DLR's work then I suggest you have a look in the handle_pdu function in gw/smsc/smsc_smpp.c (Kannel source code). Happy hacking. Cheers, Alan On Wed, 2004-02-04 at 05:39, Ivars Jukams wrote: I think, I receive this DLR in alphanumeric format: Syntax: id: status: . - message id returned by SUBMIT_SM_RESP - delivery status. example (from my old SMS gateway): 'id:12206904 status:charged' then how must I configure msg-id-type? I can also send full documentation for this SMSC, if it can help somebody to help me. - Original Message - From: Alan McNatty [EMAIL PROTECTED] To: Ivars Jukams [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, February 02, 2004 10:12 PM Subject: Re: got DLR but could not find message or was not interested in it Hi Ivars, The message means (as you suggest) that a DLR was received by Kannel but it couldn't match it to the original message. So effectively Kannel has no way of knowing what message the receipts is for. The format of the DLR receipts does vary across SMSC so your experience is not all that uncommon. Better yet it has been built into Kannel - there is a smsc group config variable called msg-id-type which is described in docs (see exert below). These docs are pretty good especially when review with a copy of the SMPP specs in front of you. Experiment with this setting and let us know how you get on. If you have no luck I would suggest you supply some logs - level 0. Cheers, Alan http://www.kannel.org/download/kannel-userguide-snapshot/userguide.html#AEN1525 msg-id-type - number Optional, specifies which number base the SMSC is using for the message ID numbers in the corresponding submit_sm_resp and deliver_sm PDUs. This is required to make delivery reports (DLR) work on SMSC that behave differently. The number is a combined set of bit 1 and bit 2 that indicate as follows: bit 1: type for submit_sm_resp, bit 2: type for deliver_sm. If the bit is set then the value is in hex otherwise in decimal number base. Which means the following combinations are possible and valid: 0x00 deliver_sm decimal, submit_sm_resp decimal; 0x01 deliver_sm decimal, submit_sm_resp hex; 0x02 deliver_sm hex, submit_sm_resp decimal; 0x03 deliver_sm hex, submit_sm_resp hex. In accordance to the SMPP v3.4 specs the default will be a C string literal if no of the above values is explicitly indicated using the config directive. On Tue, 2004-02-03 at 07:44, Ivars Jukams wrote: Can anybody explain what does it mean: ERROR: SMPP[lmt3]: got DLR but could not find message or was not interested in it Why I receive this text in bearerbox log, when I send a sms via .../cgi-bin/sendsms? I receive my message, so I think maybe it is some kind of delivery status report from operator, wich kannel does not handles.
got DLR but could not find message or was not interested in it
Can anybody explain what does it mean: ERROR: SMPP[lmt3]: got DLR but could not find message or was not interested in it Why I receive this text in bearerbox log, when I send a sms via .../cgi-bin/sendsms? I receive my message, so I think maybe it is some kind of delivery status report from operator, wich kannel does not handles.
