Filed issue #397 under "SMSBox" (shall I use HTTP instead?)
Please let me know if you need me to conduct more tests or try some
code on my dev machine.
Regards,
Alejandro.
On 4/3/07, Stipe Tolj <[EMAIL PROTECTED]> wrote:
Stipe Tolj wrote:
> now, this behaviour is now *confirmed* for a vanila
Stipe Tolj wrote:
now, this behaviour is now *confirmed* for a vanila CVS checkout and
fakesmsc usage via gw/smskannel.conf sample config on the following
hosts too:
amd64, 2.6.20-1.2307.fc5 x86_64
x86, 2.6.11-1.1369_FC4 i686
so this is considered as generic bug! (that's why I cross-post to
now, this behaviour is now *confirmed* for a vanila CVS checkout and fakesmsc
usage via gw/smskannel.conf sample config on the following hosts too:
amd64, 2.6.20-1.2307.fc5 x86_64
x86, 2.6.11-1.1369_FC4 i686
so this is considered as generic bug! (that's why I cross-post to devel@ too).
Please
Alexander Malysh wrote:
Hi Ben,
sorry you are right. That was 0x10 and is in my local copy :)
Stipe made commit that changed it:
1.21 (stolj07-Jan-07): #define DLR_SMSC_FAIL 0x16
Ok, I will correct it in cvs and commit.
yep, my fault, appologies... I mis-interpreted it
No worries,
You had me thinking I was going mad :-)
Glad I'm not
Ben
On 3 Apr 2007, at 15:27, Alexander Malysh wrote:
Hi Ben,
sorry you are right. That was 0x10 and is in my local copy :)
Stipe made commit that changed it:
1.21 (stolj07-Jan-07): #define DLR_SMSC_FAIL
Hi Ben,
sorry you are right. That was 0x10 and is in my local copy :)
Stipe made commit that changed it:
1.21 (stolj07-Jan-07): #define DLR_SMSC_FAIL 0x16
Ok, I will correct it in cvs and commit.
Thanks for pointing it!
Ben Suffolk wrote:
> I had assumed it was a binary
I had assumed it was a binary bit mask :-
1 Success
00010 Fail
00100 Buffered
01000 SMSC Success
1 SMSC Failed
Which would tie up with the value of decimal 31(1) for
submission of all DLRs.
However if the last value is in fact 0x16 (10110) then it would cause
problems with mat
Hi,
it's pretty simple. If in documentation mentioned 16 then it's hex value and
all values except 0x16 match with dec because below 0x10 dec and hex
equal :)
Ben Suffolk wrote:
> Ok,
>
> Slightly confused then, the SMSC rejected my message at submission,
> and so I should have got back a dlr_m
Ok,
Slightly confused then, the SMSC rejected my message at submission,
and so I should have got back a dlr_mask value of 16 (dec) in the DLR
according to the documentation, but I got back 22 (dec). Maybe I
jumped to the wrong conclusion seeing the DLR_SMSC_FAIL set to 0x16
(22 dec) in th
Hi Ben,
your patch is not correct. You will receive SMSC_FAIL or DLR_FAIL depending
on the dlr_mask you used. If you set dlr_mask to request SMSC_FAIL then you
will receive it if only DLR_FAIL requested then DLR_FAIL will be set.
Ben Suffolk wrote:
> Just noticed that when the SMSC rejects a mes
woops wrong ML ;)
- Original Message -
From: "Vincent CHAVANIS" <[EMAIL PROTECTED]>
To:
Sent: Tuesday, April 03, 2007 11:27 AM
Subject: Re: [PATCH] Group_id for MMC
If we keep id in config file, we should aplpy this
diff -rbau /mbuni-cvs/mmsbox/mmsbox_cfg.c /mbuni/mmsbox/mmsbox_cf
If we keep id in config file, we should aplpy this
diff -rbau /mbuni-cvs/mmsbox/mmsbox_cfg.c /mbuni/mmsbox/mmsbox_cfg.c
--- /mbuni-cvs/mmsbox/mmsbox_cfg.c 2007-04-02 21:36:58.0 +0200
+++ /mbuni/mmsbox/mmsbox_cfg.c 2007-04-03 11:21:55.0 +0200
@@ -146,7 +146,7 @@
Andreas Fink writes:
> This is usually received as the text of the delivery report itself as
> far as I remember
Yes - at least that's what we use for the aforementioned purpose.
The parameter to add to the delivery report URL is %A.
%A the delivery report SMSC reply, if any
--
Guillaume
13 matches
Mail list logo
