Ops, I should have RTFM then...

I've read the guide many times but never noticed that (maybe because I've
never thought that was possible to do that).

I already did the function that cleans the "7_" and translates from binary
to hex on gw/dlr.c

At the beggining of dlr.c (line 64) I added:

static char * clean_ts ( char* ts ) {
   char * pos;
   char buf[10];
   int n;

   pos = strchr( ts, '_' );
   if ( pos != NULL ) {
     ts = strchr( ts, '_' );
    ts++;
     n = sprintf( buf, "%010d", strtol( ts, NULL, 16 ) );
     ts = buf;
   }
   return ts;
}

Then about line 490 also on gw/dlr.c, just after the dlr_add header:

void dlr_add(char *smsc, char *ts, char *src, char *dst,
             char *keyword, char *id, int mask)
{
//I ADDED THE FOLLOWING LINE
  ts = clean_ts ( ts );

That should fix it I think... I hope.

PS: I'm not precisely a C Language gur� :)

----- Original Message ----- 
From: "Stipe Tolj" <[EMAIL PROTECTED]>
To: "Alejandro Guerrieri" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, August 12, 2004 7:26 PM
Subject: Re: DLRs


> Alejandro Guerrieri wrote:
>
> > 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).
>
> thats not a problem to Kannel. Refer to the user's guide to see how
> you configure the DLR ID mapping.
>
> 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-----
>
>


Reply via email to