You're right the message id is in short_message but it should be in receipted_message_id. It's a bug of the operator, but they told me that they can't do any change.
That's why I asked to use the timestamp :) Here is my config (it tried msg-id-type = 2 but didn't work): #Rx SMSC1 group = smsc smsc = smpp smsc-id = SMSC1 host = X.X.X.X port = 0 receive-port = 10000 smsc-username = esystem smsc-password = psystem system-type = interface-version = 34 throughput=20 msg-id-type = 1 allowed-smsc-id = SMSC1 #Tx SMSC1 group = smsc smsc = smpp smsc-id = SMSC1 host = X.X.X.X port = 10000 receive-port = 0 smsc-username = esystem smsc-password = psystem system-type = interface-version = 34 throughput=20 msg-id-type = 1 log-level = 0 allowed-smsc-id = SMSC1 Thanks! 2014-07-18 16:35 GMT-05:00 spameden <[email protected]>: > Actually, I've just looked at your logs again: > > 2014-07-17 12:45:12 [32271] [36] DEBUG: SMPP[SMSC1]: Got PDU: > 2014-07-17 12:45:12 [32271] [36] DEBUG: SMPP PDU 0x11f4cb80 dump: > 2014-07-17 12:45:12 [32271] [36] DEBUG: type_name: submit_sm_resp > 2014-07-17 12:45:12 [32271] [36] DEBUG: command_id: 2147483652 = > 0x80000004 > 2014-07-17 12:45:12 [32271] [36] DEBUG: command_status: 0 = 0x00000000 > 2014-07-17 12:45:12 [32271] [36] DEBUG: sequence_number: 5579 = > 0x000015cb > 2014-07-17 12:45:12 [32271] [36] DEBUG: message_id: "1e13a15" > 2014-07-17 12:45:12 [32271] [36] DEBUG: SMPP PDU dump ends. > 2014-07-17 12:45:12 [32271] [36] DEBUG: DLR[internal]: Adding DLR > smsc=SMSC1, ts=31537685, src=30100, dst=XXXXXXXXXXX, mask=31, boxc= > 2014-07-17 12:45:12 [32271] [36] DEBUG: SMSC[SMSC1]: creating DLR message > > Message ID is 31537685 in submit_sm. > > In deliver_sm it's: > 2014-07-17 12:45:16 [32271] [35] DEBUG: short_message: > 2014-07-17 12:45:16 [32271] [35] DEBUG: Octet string at 0x11f4cf80: > 2014-07-17 12:45:16 [32271] [35] DEBUG: len: 119 > 2014-07-17 12:45:16 [32271] [35] DEBUG: size: 120 > 2014-07-17 12:45:16 [32271] [35] DEBUG: immutable: 0 > 2014-07-17 12:45:16 [32271] [35] DEBUG: data: 69 64 3a 30 30 33 31 35 > 33 37 36 38 35 20 73 75 id:0031537685 su > 2014-07-17 12:45:16 [32271] [35] DEBUG: data: 62 3a 30 30 31 20 64 6c > 76 72 64 3a 30 30 31 20 b:001 dlvrd:001 > 2014-07-17 12:45:16 [32271] [35] DEBUG: data: 73 75 62 6d 69 74 20 64 > 61 74 65 3a 31 34 30 37 submit date:1407 > 2014-07-17 12:45:16 [32271] [35] DEBUG: data: 31 37 31 32 34 35 20 64 > 6f 6e 65 20 64 61 74 65 171245 done date > 2014-07-17 12:45:16 [32271] [35] DEBUG: data: 3a 31 34 30 37 31 37 31 > 32 34 35 20 73 74 61 74 :1407171245 stat > 2014-07-17 12:45:16 [32271] [35] DEBUG: data: 3a 44 45 4c 49 56 52 44 > 20 65 72 72 3a 30 30 30 :DELIVRD err:000 > 2014-07-17 12:45:16 [32271] [35] DEBUG: data: 20 74 65 78 74 3a 6d 65 > 6e 73 61 6a 65 20 64 65 text:test messa > 2014-07-17 12:45:16 [32271] [35] DEBUG: data: 20 70 72 75 65 62 61 > ge 000 > 2014-07-17 12:45:16 [32271] [35] DEBUG: Octet string dump ends. > 2014-07-17 12:45:16 [32271] [35] DEBUG: message_state: 2 = 0x00000002 > 2014-07-17 12:45:16 [32271] [35] DEBUG: receipted_message_id: "2496a396" > > In msg-log it says: id:0031537685 so it must be either kannel converting > it to hex for some reason or maybe some SMSC bug. > I can't seem to be able to get hex number from source id so it must be > something either at your operator side or something. > > What is the kannel version you're using? And show your configuration. > > > 2014-07-19 1:16 GMT+04:00 Mario Noboa <[email protected]>: > > Thanks your answer Spameden. I thought the same thing, but the message ids >> are complete different: >> >> if you see the log: >> >> submit_sm_resp: message_id: 31537685 (decimal) >> deliver_sm: ts=613852054 (decimal) >> >> regards, >> >> >> >> 2014-07-18 16:04 GMT-05:00 spameden <[email protected]>: >> >> err, I meant hex in submit_sm and decimal in deliver_sm packets. >>> >>> >>> 2014-07-19 1:04 GMT+04:00 spameden <[email protected]>: >>> >>> It looks like your SMSC operator gives hex number in submit_sm packet >>>> and hex number in deliver_sm, so you need to add this in smsc group >>>> configuration: >>>> >>>> msg-id-type = 0x02 >>>> >>>> >>>> >>>> 2014-07-19 0:40 GMT+04:00 Mario Noboa <[email protected]>: >>>> >>>> Of course Niel, thanks!!! >>>>> >>>>> >>>>> >>>>> >>>>> 2014-07-18 15:30 GMT-05:00 Niel Smith <[email protected]>: >>>>> >>>>> Hi Mario, >>>>>> >>>>>> Would it be possible to supply the full submit_sm, submit_sm_resp, >>>>>> and deliver_sm PDU dumps? >>>>>> >>>>>> >>>>>> On 18 July 2014 22:12, Mario Noboa <[email protected]> wrote: >>>>>> >>>>>>> >>>>>>> Hi list, >>>>>>> >>>>>>> I got a DLR problem with an operator. >>>>>>> >>>>>>> When sent a "submit_sm", kannel receipt a message id: >>>>>>> >>>>>>> *message_id: "1e13a15"* >>>>>>> *DLR[internal]: Adding DLR smsc=SMSC1, ts=31537685, src=30100, >>>>>>> dst=XXXXXXXXXXX, mask=31, boxc=* >>>>>>> >>>>>>> >>>>>>> But its DLR arrives with another id: >>>>>>> >>>>>>> *2014-07-17 12:45:16 [32271] [35] DEBUG: DLR[internal]: Looking for >>>>>>> DLR smsc=SMSC1, ts=613852054, dst=975647918, type=1* >>>>>>> *2014-07-17 12:45:16 [32271] [35] WARNING: DLR[internal]: DLR from >>>>>>> SMSC<SMSC1> for DST<975647918> not found.* >>>>>>> *2014-07-17 12:45:16 [32271] [35] ERROR: SMPP[SMSC1]: got DLR but >>>>>>> could not find message or was not interested in it id<613852054> >>>>>>> dst<XXXXXXXXX>, type<1>* >>>>>>> >>>>>>> >>>>>>> if you notice both are in decimal and they are different. *31537685 >>>>>>> and **613852054* >>>>>>> >>>>>>> I tried to configure version 33 to use Timestamp, but they don't let >>>>>>> me connect in that way. There is any way to use timestamp instead of >>>>>>> message id? >>>>>>> >>>>>>> Thanks for your answers! >>>>>>> >>>>>>> Mario >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >
