Re: DLR sql select problem with message id containing space

[Alex Kinch]

Hi Rene   In the SMPP v3.4 issue 1.2 (12th October 1999) docs that I have, it's been up'd from 9 to 33, and then to 65 octets. I guess this is to accomodate for the increasing use of GUID-style message ids?   It seems that Kannel handles the SUBMIT_SM_RESP ok with these long ids, but doesn't do it in the DELIVER_SM for the DLR.   Alex ----- Original Message ----- From: Rene Kluwen To: Alex Kinch ; [EMAIL PROTECTED] Sent: Tuesday, December 23, 2003 9:24 PM Subject: RE: DLR sql select problem with message id containing space Fix would be not too hard to implement... BUT... In the SMPP specs that I have (note: I am talking about v3.3) it says: Message ID, var max. 9. So taking off the terminating NUL this means that message ids can be 8 characters at most. I noticed this 'quirk' (message ids of more than 8 chars) also with a certain upstream provider that I have.   Question: Has this changed in successive SMPP versions? Or is it just plainly against specifications?   Regards,   Rene Kluwen Chimit -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Alex Kinch Sent: dinsdag 23 december 2003 18:47 To: [EMAIL PROTECTED] Subject: DLR sql select problem with message id containing space Hi,   Just hooked up another SMPP connection, and they use rather large message ids. For example:   00047274 20031223170148.364   Kannel is inserting this whole value (including characters after the space) into the ts field on the dlr table. However, when it comes to receiving the delivery report, it's truncating the message id after the first space, so it does:    DLR[mysql]: Looking for DLR smsc=XXXX, ts=00047274, dst=44xxxxxxxxxx, type=1   Which of course it won't find, as it's lost the rest of the message id.   My C coding skills aren't up to much, but I would imagine it requires something that tests the first character after the space to see if it's numeric.   Alex