Nisan Bloch wrote:
>
> Hi
>
> We have a queue load balancer in front of Kannel, that through a
> "statusbox" monitors Kannel, and knows extended information about each
> gateway that kannel is connected to. This way we can control the throughput
> of any of the Kannel connections, as well as load
Hi
We have a queue load balancer in front of Kannel, that through a
"statusbox" monitors Kannel, and knows extended information about each
gateway that kannel is connected to. This way we can control the throughput
of any of the Kannel connections, as well as load balance them
If messages are
Alexander Malysh <[EMAIL PROTECTED]> wrote:
> Hi Bruno,
>
> Am Donnerstag, 19. Juni 2003 16:03 schrieb Bruno Rodrigues:
>> Stipe Tolj <[EMAIL PROTECTED]> wrote:
>> > Bruno Rodrigues wrote:
>> >> You need to "sleep" right after sending the message for it to work.
>> >> We can have configuration cod
Andreas Fink wrote:
>
> AT2 module sleeps anyway and waits for ACK from modem before proceeding.
> So adding sleeps there is not making any sense unless you wana limit it to have only
> 1 message every minute or such.
ok, I wasn't aware of it right now. That's fine with me then.
Stipe
[EMAIL P
Alexander Malysh wrote:
>
> hmm, sleep is very bad (imho). In this sleep time you can maybe handle 100
> delivery receipts instead just sleeping. It would be great to add abstracted
> bandwidth calculation code to kannel and then send only if bandwidth allow
> this.
so sleeping makes only sense i
On Jeudi, juin 19, 2003, at 03:49 Uhr, Stipe Tolj wrote:
Bruno Rodrigues wrote:
You need to "sleep" right after sending the message for it to work.
We can have configuration code in smsccon abstraction and only that
"usleep" inside smsc_* modules.
why not having the whole throttling mechanism i
Hi Bruno,
Am Donnerstag, 19. Juni 2003 16:03 schrieb Bruno Rodrigues:
> Stipe Tolj <[EMAIL PROTECTED]> wrote:
> > Bruno Rodrigues wrote:
> >> You need to "sleep" right after sending the message for it to work.
> >> We can have configuration code in smsccon abstraction and only that
> >> "usleep" i
Stipe Tolj <[EMAIL PROTECTED]> wrote:
> Bruno Rodrigues wrote:
>>
>> You need to "sleep" right after sending the message for it to work.
>> We can have configuration code in smsccon abstraction and only that
>> "usleep" inside smsc_* modules.
>
> why not having the whole throttling mechanism insi
Rory Campbell-Lange wrote:
>
> 10:28:37 [8] DEBUG: SMPP[duckalorange]: Manually forced source addr ton = 1, source
> add npi = 1
> 10:28:37 [8] DEBUG: SMPP[duckalorange]: Manually forced dest addr ton = 1, dest add
> npi = 1
> 10:28:37 [8] DEBUG: SMPP[duckalorange]: Sending PDU:
> 10:28:37 [8] D
Bruno Rodrigues wrote:
>
> You need to "sleep" right after sending the message for it to work.
> We can have configuration code in smsccon abstraction and only that
> "usleep" inside smsc_* modules.
why not having the whole throttling mechanism inside the abstracted
layer?
This would also help i
Stipe Tolj <[EMAIL PROTECTED]> wrote:
> Rory Campbell-Lange schrieb:
>>
>> Thanks very much for your message, Stipe.
>>
>> Upon enquirey it appears that the target SMPP host only allows 6
>> messages a second to pass through on our service. I was trying to send
>> 150 messages in less than a seco
Rory Campbell-Lange wrote:
>
> The only error codes I'm getting are:
> 2003-06-06 20:42:53 [8] ERROR: SMPP[orangelong]: SMSC returned error
> code 0x0045 in response to submit_sm.
according to SMPP specs this is considered to be a *general* error for
a submit_sm PDU. (seee SMPP v3.4, p. 113).
Rory Campbell-Lange schrieb:
>
> Thanks very much for your message, Stipe.
>
> Upon enquirey it appears that the target SMPP host only allows 6
> messages a second to pass through on our service. I was trying to send
> 150 messages in less than a second!
yeah, Kannel performs very well ;))
> I'
|There's no way to make it more elegant!||The SMPP specs dont allow for anything else. Nice would be
to stop sending if we |got "throttle" and resume when we get some kind of
"resume" message but there is |no such message. Kannel does the only valid thing
which is wait a bit and try |again.
A
Thanks for the help, Alex and Andreas.
I've had a look at the specs. Thanks for the pointer, Andreas.
You are right, Alex. I'm not suffering from throttling problems. I have
no 0x0058 errors in my logs, despite sometimes sending Kannel over
100 messages in a second on some occasions -- Orange
On Dienstag, Juni 10, 2003, at 04:20 Uhr, David Tully wrote:
4. We should have more elegant throttling code in the SMPP driver
There's no way to make it more elegant!
The SMPP specs dont allow for anything else. Nice would be to stop sending
if we got "throttle" and resume when we get some kin
>> 4. We should have more elegant throttling code in the SMPP driver
> There's no way to make it more elegant!
>
> The SMPP specs dont allow for anything else. Nice would be to stop sending
if we got "throttle" and resume when we get some kind of "resume" message
but there is no such message. Kann
On Dienstag, Juni 10, 2003, at 02:52 Uhr, Alex Judd wrote:
That doesn't sound right :)
With our connection to Orange we have higher capacity, however still got
0x0058 I/F Throttled Error when we exceed our per second limit.
e.g. "2003-06-10 11:48:07 [5] ERROR: SMPP[Orange]: SMSC returned e
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, June 10, 2003 1:42 PM
Subject: Re: Strange smsbox/bearerbox problem : SMS messages not being sent
> Thanks for the info, Andreas.
>
> How can I find SMPP error codes?
> Nothing in the Kannel user guide -- in the mail archives I see:
>
On Dienstag, Juni 10, 2003, at 02:42 Uhr, Rory Campbell-Lange wrote:
Thanks for the info, Andreas.
How can I find SMPP error codes?
Nothing in the Kannel user guide -- in the mail archives I see:
the SMPP specs tell you the error codes. (File: SMPP_v3_4_Issue1_2.pdf)
SMPP error code 14 is a
Thanks for the info, Andreas.
How can I find SMPP error codes?
Nothing in the Kannel user guide -- in the mail archives I see:
> SMPP error code 14 is a queue full error and 58 is a throttling error,
> so it looks like your not throttling your traffic and flooding your
> SMSC's queues.
The only
On Montag, Juni 9, 2003, at 05:07 Uhr, Rory Campbell-Lange wrote:
Thanks very much for your message, Stipe.
Upon enquirey it appears that the target SMPP host only allows 6
messages a second to pass through on our service. I was trying to send
150 messages in less than a second!
I've slowed do
Thanks very much for your message, Stipe.
Upon enquirey it appears that the target SMPP host only allows 6
messages a second to pass through on our service. I was trying to send
150 messages in less than a second!
I've slowed down the sending system. However, is there a way of
throttling the numb
Rory Campbell-Lange wrote:
>
> Hi Andreas
>
> Is this a response?
>
> 2003-06-06 07:30:08 [6] DEBUG: SMPP PDU 0x81358a0 dump:
> 2003-06-06 07:30:08 [6] DEBUG: type_name: submit_sm_resp
> 2003-06-06 07:30:08 [6] DEBUG: command_id: 2147483652 = 0x8004
> 2003-06-06 07:30:08 [6] DEBUG: com
Rory Campbell-Lange wrote:
>
> My smsbox/bearerbox setup has been working flawlessly for about a month.
> However recently I have had to restart the system after a number of
> messages are shown as queued but not sent. On restarting bearerbox the
> messages flood through.
>
> The problems start w
Hi Andreas
Is this a response?
2003-06-06 07:30:08 [6] DEBUG: SMPP PDU 0x81358a0 dump:
2003-06-06 07:30:08 [6] DEBUG: type_name: submit_sm_resp
2003-06-06 07:30:08 [6] DEBUG: command_id: 2147483652 = 0x8004
2003-06-06 07:30:08 [6] DEBUG: command_status: 0 = 0x
2003-06-06 07:30:0
My smsbox/bearerbox setup has been working flawlessly for about a month.
However recently I have had to restart the system after a number of
messages are shown as queued but not sent. On restarting bearerbox the
messages flood through.
The problems start with a message I sent myself at 7.30am in t
27 matches
Mail list logo
