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 <[email protected]>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 <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 <[email protected]>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 = 0x00000005 >> > 2011-07-07 03:36:08 [10828] [6] DEBUG: command_status: 0 = >> > 0x00000000 >> > 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 = >> > 0x00000002 >> > 2011-07-07 03:36:08 [10828] [6] DEBUG: source_addr_npi: 1 = >> > 0x00000001 >> > 2011-07-07 03:36:08 [10828] [6] DEBUG: source_addr: "919033333930" >> > 2011-07-07 03:36:08 [10828] [6] DEBUG: dest_addr_ton: 2 = 0x00000002 >> > 2011-07-07 03:36:08 [10828] [6] DEBUG: dest_addr_npi: 1 = 0x00000001 >> > 2011-07-07 03:36:08 [10828] [6] DEBUG: destination_addr: >> > "1111111111" >> > 2011-07-07 03:36:08 [10828] [6] DEBUG: esm_class: 4 = 0x00000004 >> > 2011-07-07 03:36:08 [10828] [6] DEBUG: protocol_id: 0 = 0x00000000 >> > 2011-07-07 03:36:08 [10828] [6] DEBUG: priority_flag: 0 = 0x00000000 >> > 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 = >> > 0x00000000 >> > 2011-07-07 03:36:08 [10828] [6] DEBUG: replace_if_present_flag: 0 = >> > 0x00000000 >> > 2011-07-07 03:36:08 [10828] [6] DEBUG: data_coding: 0 = 0x00000000 >> > 2011-07-07 03:36:08 [10828] [6] DEBUG: sm_default_msg_id: 0 = >> > 0x00000000 >> > 2011-07-07 03:36:08 [10828] [6] DEBUG: sm_length: 132 = 0x00000084 >> > 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 34 date: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=919033333930, type=1 >> > 2011-07-07 03:36:08 [10828] [6] WARNING: DLR[internal]: DLR from >> > SMSC<internal> for DST<919033333930> 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 id<51615745> >> > dst<919033333930>, type<1> >> > 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 = >> > 0x80000005 >> > 2011-07-07 03:36:08 [10828] [6] DEBUG: command_status: 0 = >> > 0x00000000 >> > 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 >> > <[email protected]> wrote: >> > 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 >> > <[email protected]> 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=919033333930, >> > > type=1 >> > > 2011-07-07 02:27:04 [9255] [6] WARNING: DLR[internal]: DLR >> > from >> > > SMSC<internal> for DST<919033333930> 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 >> > > id<ece60bb7-725b-433a-9337-39a61cec86c9> dst<919033333930>, >> > type<1> >> > > Configuration: >> > > group=smsc >> > > smsc=smpp >> > > smsc-id=internal >> > > interface-version=34 >> > > host=xxxxxxxxxxx >> > > port=xzxx >> > > smsc-username=xxxxx >> > > smsc-password=xxxx >> > > system-type=default >> > > transceiver-mode=1 >> > > group = mysql-connection >> > > id = mydlr >> > > host = xxxxx.com >> > > username = xxxxx >> > > password = xxxxx >> > > 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 >> > > >> > >> > >> > >> >> >> >> >
