Stipe, You bet is unusual! Is madness!! :)))
I've tried changing the select statement (I started with the "lazy way" since it�s a lot simpler to change a single sql statement thant to write real C code). But I soon found out that not only it added the "7_" stuff, but also changed the encoding base, so the submit_sm got encoded as HEX (ie: 7_000000FF) and the deliver_sm got encoded in DECIMAL (ie: 255). Si now I'm writing a "cleaning function" to call before the insert, so if the DLR have an "_", it cuts the string before that and converts is to decimal. That way, I (hope) will solve the problem. I�ll post the code if I'm successful. Thanks for your help. Regards, ----- Original Message ----- From: "Stipe Tolj" <[EMAIL PROTECTED]> To: "Alejandro Guerrieri" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, August 12, 2004 6:16 PM Subject: Re: DLRs > Alejandro Guerrieri wrote: > > > Hi All, > > > > I am having problems with the DLRs. One of my providers adds a "7_" before > > the real message_id, so when the DLR finally arrives the number doesn�t > > match, so Kannel ignores it. > > > > ie: I submit a message with submit_sm and receives a submit_sm_response > > with: > > > > message_id: "7_0004EEC4" > > > > Then, when the DLR arrives, it says: > > > > id:0000323268 > > > > 323268 decimal is 4EEC4. > > > > I've checked my MySQL DLRs and it stores the 7_0004EEC4, so when it comes > > back looking for the DLR it doesn�t match anything. > > > > I suppose I'll have to patch the DLR code to make it work (To ignore the > > "7_" part) In fact, I was told that I should ignore anything before the "_" > > because that "7" might change in the near future for "107" or any other > > number. > > > > Any hints? My C skills are not top of the line, but I can manage a few lines > > of code anyway. > > now, as this is definetly "unusual" behavior from your SMSC provider, > I'd say, yes, you'll have to patch Kannel here specifically for this > scrappy SMPP dialect. > > Another option would be to change the SELECT statement in the > dlr_mysql code to "parse" out the after _ part and let that be the > comparison part. > > I guess it's up to you. Either patch the C code or the MySQL SQL > statements ;) > > Stipe > > mailto:stolj_{at}_wapme.de > ------------------------------------------------------------------- > Wapme Systems AG > > Vogelsanger Weg 80 > 40470 D�sseldorf, NRW, Germany > > phone: +49.211.74845.0 > fax: +49.211.74845.299 > > mailto:info_{at}_wapme-systems.de > http://www.wapme-systems.de/ > ------------------------------------------------------------------- > > -----BEGIN PGP PUBLIC KEY BLOCK----- > Version: GnuPG v1.2.2 (Cygwin) > > mIsEP6mcYwEEAMDnUiUwrbb+xwTFWN6TxF2+XZu7/alwJMeCwMBRvXtPZqfjpPhS > OkBpU0F4TrVuugz1HINTSaJTYq10AzDQXp5NkyWgckqW79nPAWuOX0dicbJk+cN2 > nM2TI4KaxUDe6u8hghNEnH/i2lXsUu9apnP/iixzV81VC2je3uc9hZpnAAYptEVT > dGlwZSBUb2xqIChUZWNobm9sb2d5IENlbnRlciAmIFJlc2VhcmNoIExhYikgPHRv > bGpAd2FwbWUtc3lzdGVtcy5kZT6ItAQTAQIAHgUCP6mcYwIbAwYLCQgHAwIDFQID > AxYCAQIeAQIXgAAKCRABV0w1BqPYRuSqA/wPzsQxao2YePENCtgRTrO86U6zg3sl > OcS6CJFI4FZP5h/xD3GRsNH1+MPSvZlomDdpFnr547DGz/Kq9MXuQwVvlVig5yWZ > K5dtKp1r5YLhxJQBhfirZbRFFnYmf19f18J8OoS28tuFVftDl1AIwJS3HLyBTv6H > g2HyLAEKQIp30Q== > =aYCI > -----END PGP PUBLIC KEY BLOCK----- >
