Re: [-] Re: non standard message_id breaks DLR

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.