Enver ALTIN wrote:
Hey,
I've been stuggling to find out why some catenated messages submitted by
Kannel were getting rejected by our EMI SMSC. Apparently the problem was
the supersmart SMSC expecting catenated messages to arrive in proper
order. It was getting rejected if we send the second p
Wilfried Goesgens wrote:
On Wed, Nov 09, 2005 at 03:20:12PM +0100, Stipe Tolj wrote:
Rene Kluwen wrote:
Do you want to implement kind of a patch-o-matic, like netfilter has?
Just an idea...
hmm, don't know about that one... would have to review. What's its benefit?
Stipe
maybe darcs is
On Thursday 10 November 2005 10:20, Stipe Tolj wrote:
> Enver ALTIN wrote:
> > Hey,
> >
> > I've been stuggling to find out why some catenated messages submitted by
> > Kannel were getting rejected by our EMI SMSC. Apparently the problem was
> > the supersmart SMSC expecting catenated messages to a
Wilfried Goesgens wrote:
On Wed, Nov 09, 2005 at 03:20:12PM +0100, Stipe Tolj wrote:
Rene Kluwen wrote:
Do you want to implement kind of a patch-o-matic, like netfilter has?
Just an idea...
hmm, don't know about that one... would have to review. What's its benefit?
Stipe
maybe darcs is
Hi,
sorry but it seems we make workarounds for buggy SMSC. I'm -1 for this
patch. They must fix SMSC instead of adding some workarounds where those
don't belong to. Priority has _nothing_ todo with receiver and udh.
Instead SMSC devels should read spec properly (EMI 4.0, GSM 03.38, GSM
03.40
On Thursday 10 November 2005 12:22, Alexander Malysh wrote:
> sorry but it seems we make workarounds for buggy SMSC. I'm -1 for this
> patch. They must fix SMSC instead of adding some workarounds where those
> don't belong to. Priority has _nothing_ todo with receiver and udh.
> Instead SMSC deve
Alexander Malysh wrote:
Hi,
sorry but it seems we make workarounds for buggy SMSC. I'm -1 for this
patch. They must fix SMSC instead of adding some workarounds where those
don't belong to. Priority has _nothing_ todo with receiver and udh.
Instead SMSC devels should read spec properly (EMI
Stipe, et al,
>> sorry but it seems we make workarounds for buggy SMSC. I'm -1 for this
>> patch. They must fix SMSC instead of adding some workarounds where
>> those don't belong to. Priority has _nothing_ todo with receiver and
>> udh. Instead SMSC devels should read spec properly (E
Hi Dziugas,
Sorry I got a mistake when I did the send;-)
The problem is I have a machine running kannel 1.2.1 that I send normal GSM
messages using coding=1. In a new machine I put kannel 1.3.2 and when I send
the message with coding=1 it goes binary.
In the manual coding = 0 is equals codi
Hi Stipe,
Stipe Tolj wrote:
Alexander Malysh wrote:
Hi,
sorry but it seems we make workarounds for buggy SMSC. I'm -1 for this
patch. They must fix SMSC instead of adding some workarounds where
those don't belong to. Priority has _nothing_ todo with receiver and
udh. Instead SMSC devels s
Jon Houser wrote:
If it's a spec breaker, make it something you have to turn on.
Then you can support the broken SMSCs should you need to, but the
end-user has to enable it. Heck, even call it "hack-send-in-order" or
something so you know every time you see it that it's just a hack.
Grante
Douglas Jurcovichi wrote:
Hi Dziugas,
Sorry I got a mistake when I did the send;-)
The problem is I have a machine running kannel 1.2.1 that I send normal GSM messages using coding=1. In a new machine I put kannel 1.3.2 and when I send the message with coding=1 it goes binary.
you should
Vincent CHAVANIS wrote:
- Original Message -
From: "Cesar Gutierrez Corea" <[EMAIL PROTECTED]>
To:
Sent: Saturday, November 05, 2005 8:59 AM
Subject: sqlbox_configure_pgsql auto_increment?
1. Is it safe to use cvs sources instead of 1.4.0 in a production
server?
yes it is.
Alexander Malysh wrote:
Index: gwlib/cfg.def
===
RCS file: /home/cvs/gateway/gwlib/cfg.def,v
retrieving revision 1.112
diff -a -u -p -r1.112 cfg.def
--- gwlib/cfg.def21 Sep 2005 02:01:22 -1.112
+++ gwlib/cfg.def26 Oc
I think you can close this report. It's not really a bug as the reply path
parameter is in the CIMD2 spec.
The reason it is set to default 0 if not otherwise set, is because some phones
will insist on trying to reply to an SMS when the RPI is absent.
If you search the devel archive you should f
Stipe Tolj wrote:
+1 on the logic, I assume you did regression test this Alex, did you?
I'm -1 on the new config directive naming, and I'd like to change it to:
sms-resend-freq
sms-resend-retry
Reasons:
'sms-resend-freq' follows naming convention as introduced to prior
config directives
Unable to duplicate
--
Yours sincerely,
Eurobate ASA
Arne K. Haaje
Senior Network Engineer
Eurobate ASA - Postboks 4589 Nydalen - 0404 Oslo - Norway
Phone: +47 23 22 73 73 - Fax: +47 23 22 73 74 - Mob: +47 92 88 44 66
Douglas Jurcovichi wrote:
2005-11-08 15:10:18 Sent SMS [SMSC:BRT] [SVC:brt] [ACT:] [BINF:]
[from:90007] [to:554284017946] [flags:-1:1:-1:-1:19]
[msg:7:54657374652038] [udh:0:]
As well, how can I take out the binary mode sending the message?
I tried to change the coding value in thr URL that I'
18 matches
Mail list logo
