Fw: DLR sql select problem with message id containing space

Resending as my mail's been playing up :-)

----- Original Message ----- 
From: Alex Kinch 
To: [email protected] 
Sent: Friday, January 09, 2004 10:14 PM
Subject: Re: DLR sql select problem with message id containing space


Happy New Year to all :-)

Don't suppose the problem with spaces in message id's and DLR's got fixed in CVS?

Alex
  ----- Original Message ----- 
  From: Alex Kinch 
  To: Rene Kluwen ; [email protected] 
  Sent: Wednesday, December 24, 2003 12:59 AM
  Subject: Re: DLR sql select problem with message id containing space


  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