Edwin Pratomo wrote: > > On Thursday 26 June 2003 18:05, David Tully wrote: > > Hi! > > > > > > The middle bit of the submit_sm_resp is the message_id - 'b9637bb4' out of > > '02/00/b9637bb4/11353872920997' > > The rest is junk - the last number is the destination number. > > Interesting, I've just noticed that I get a similar problem with an operator > here. > > SMPP PDU 0x8168850 dump: > type_name: submit_sm_resp > command_id: 2147483652 = 0x80000004 > command_status: 0 = 0x00000000 > sequence_number: 5 = 0x00000005 > message_id: "51f25d96" > > and in deliver_sm's short_message I got: > data: 69 64 3a 31 33 37 34 38 id:13748 > data: 33 38 31 36 36 20 73 75 38166 su > data: 62 3a 30 30 31 20 64 6c b:001 dl > > so dlr->timestamp comparison in dlr_mem_entry_match() in gw/dlr_mem.c always > fails. The fix for my problem is easy, just a hex num conversion will do it.
beware that this "problem" is solved using the 'msg-id-type' directive for the smsc group, espacially SMPP related of source. See user's guide. Stipe [EMAIL PROTECTED] ------------------------------------------------------------------- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de ------------------------------------------------------------------- wapme.net - wherever you are
