Re: [PATCH] dlr_mem.c & dlr_sdb.c check for dst

2004-04-02 Thread Robert Galach
> no, You have't got a point... We need original destination, because it will be > copied into dlr message that going to the user back... So the user should > always get "right" destination number back (means destination that was > supplied by him). > How want you normalize number if you have loss

Re: [PATCH] dlr_mem.c & dlr_sdb.c check for dst

2004-04-02 Thread Robert Galach
>> > 1) how want you guess a unified prefix in dlr_find when user has not >> >> supplied >> >> > unified prefix in the config file? (and that means user intervention). >> >> There is a way: normalize number to internal format in dlr_add also, before >> insert to database. >> (it could be even strip

Re: [PATCH] dlr_mem.c & dlr_sdb.c check for dst

2004-04-02 Thread Robert Galach
> 1) how want you guess a unified prefix in dlr_find when user has not supplied > unified prefix in the config file? (and that means user intervention). There is a way: normalize number to internal format in dlr_add also, before insert to database. (it could be even stripping prefix like in Alex

Re: [PATCH] dlr_mem.c & dlr_sdb.c check for dst

2004-04-01 Thread Robert Galach
Hi, Should I understand that, SMSC sends not normalized numbers in dlr body sometimes? Destination is taken from incoming dlr body or set in bb_smscconn_cb functions (where always is normalized) In our case providers send destination numbers in dlr body in exacly same format as we send sms dest. n

Re: [PATCH] xmlrpc missing features implementation

2004-03-19 Thread Robert Galach
Hi, Could you guys look at the patch and vote? Stipe? Alex? What do you think about it? I've just received a patch that corrects parsing fault response, thank you Fred: > +++ gwlib/xmlrpc.c 2004-03-18 17:04:43.0 -0500 > @@ -2567,9 +2567,9 @@ > */ > if (xmlrpc_value

Re: [PATCH] Binding sql variables in dbpool

2004-03-11 Thread Robert Galach
hi Alex, > why in hell are you trying to append NULL pointers to the list? No reason of course, this is a garbage I forgot. It is ugly, but does not imply any problems. Sorry, I made a mistake and diff'ed dbpool_oracle. c which was working but not clean version of file, there is no need to keep

[PATCH] xmlrpc missing features implementation

2004-03-11 Thread Robert Galach
hi all, here is implementation of missing features in gwlib/xmlrpc.[ch] the patch implements handling of structs, arrays, double type, method response and faults. there are some changes in interface also, so it affects smsbox.c and test_xmlrpc.c in octstr.[ch] function octstr_parse_double is adde

[PATCH] Binding sql variables in dbpool

2004-03-10 Thread Robert Galach
hi again, here is a patch to dbpool[.c, .h, _p.h, _oracle.h] and dlr_oracle.c this patch enables binding variable in sql statements and contains implementation for oracle. in other types of dbpool database select and update operations are not handled, so patch doesn't affect them. variables are

Re: shared.c - splitted parts of long sms with same id

2004-03-10 Thread Robert Galach
lieve that: uuid_clear(part->sms.id); is not needed? On Wednesday 10 March 2004 12:23, Robert Galach wrote: > hi again, > > I think there is one more bug, I found in current kannel cvs version. > > If long sms message is splitted (gw/shared.c:sms_split) every part created > ha

shared.c - splitted parts of long sms with same id

2004-03-10 Thread Robert Galach
hi again, I think there is one more bug, I found in current kannel cvs version. If long sms message is splitted (gw/shared.c:sms_split) every part created has the same id field, which is used to ACK/NACK comunication. It implies that acking first part by smsc, removes any other parts with that id

bb_alog.c - bug after last changes

2004-03-10 Thread Robert Galach
hello all, after long time I've updated my kannel version to current cvs :) I found a bug after last commit in gw/bb_alog.c There is a garbage in acces-log file if sms text contains e.g. "%d" text and custom-access-log-format option is enabled with %b inside. I guess this may cause seg fault in s