Thanks Alex. It's strange because we get that number no matter which of several SMS providers' connections we look at the debug for. I thought the TS was sometimes internally generated by Kannel,
How is the TS returned? Is it part of the submit_sm_response e.g. the message_id ? : 2011-11-20 14:15:24 [22886] [11] DEBUG: type_name: submit_sm_resp 2011-11-20 14:15:24 [22886] [11] DEBUG: command_id: 2147483652 = 0x80000004 2011-11-20 14:15:24 [22886] [11] DEBUG: command_status: 0 = 0x00000000 2011-11-20 14:15:24 [22886] [11] DEBUG: sequence_number: 28124 = 0x00006ddc 2011-11-20 14:15:24 [22886] [11] DEBUG: message_id: "101112015152580306" 2011-11-20 14:15:24 [22886] [11] DEBUG: SMPP PDU dump ends. On Mon, Nov 21, 2011 at 10:12 AM, Alexander Malysh <[email protected]>wrote: > Hi, > > TS in Kannel is String and not a integer so that should be external issue > because Kannel doesn't generate TS, > it's received from remote SMSC. > > Alex > > Am 18.11.2011 um 17:59 schrieb Garrett Ahern: > > > Hello, > > > > I've noticed in our Kannel logs that the ts is set to 4294967295 (the > highest 32 bit number possible) for every SMS. We use internal (memory) > storage for DLR's, so I think the TS above is internally generated, not > taken from MySQL or anything else. The consequence is that I have caught > Kannel mismatching the DLR's e.g. POST'ing a DLR for yesterday's SMS to a > particular number, instead of today's SMS to the same number, because > TS+DEST is no longer unique. > > > > So my question is has anyone else had this issue and how do you get > Kannel to start at number 1 again for the TS ? > > > > > > Thanks, > > Garrett > >
