> 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
>> > 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
> 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
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
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
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
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
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
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
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
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
11 matches
Mail list logo