Hi Edwin.
Kannel can handle any variation on decimal / hex message_id's using the
variable msg-id-type
Check out the usergiude..
My problem is the extra information that my provider has 'helpfully' added
and won't remove...
Regards,
David.
----- Original Message -----
From: "Edwin Pratomo" <[EMAIL PROTECTED]>
To: "David Tully" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, June 27, 2003 6:48 AM
Subject: [-] Re: non standard message_id breaks DLR
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.
rgds,
Edwin.
