Kannel timeouts / connectivity issues
Anybody know what Kannel's expected behavior when HTTP connections timeout or fail? We have a situation with 120+ "sms-service" services defined, but have noticed a few of them behave in a peculiar manner where, very occasionally, HTTP requests don't occur until 16 minutes after being received by Kannel. This will happen "out of the blue" without any errors logged in smsbox.log or kannel.log. This occurs in a transient fashion - there doesn't appear to be any rhyme or reason to when this occurs. This only appears to happen with a particular subset of SMS services which happen to be hosted outside of our immediate hosting environment, suggesting there's some sort of network disruption causing this problem. Potentially this is some of retry based on a 1-minute timeout, followed by a retry 15 minutes later; however this would be "out of character" since in my experience with Kannel most timeouts / 404s / 500s usually generate everyone's favourite "Couldn't fetch content, sorry"-type messages. I also can't find any reference to timeouts of these values in the user's guide or the configuration files. Until recently the get-urls for these services had the SMSC included in the URLs (i.e. "&smsc=%i") but, as these were the only services using this, I've removed this in case there's some sort of problem caused by this. Has anybody else had a similar situation where these sorts of delays have happened? David
RE: Forcing SMSC doesn't work
Hello all I seem to have cracked this problem by making sure all the other SMSCs are listed under denied-smsc-id. For example, under SMSC-T1.A should be the following configuration parameters: group = smsc smsc = smpp smsc-id = SMSC-T1.A allowed-prefix = "027;6427;+6427;021;6421;+6421;" preferred-prefix = "027;6427;+6427" denied-smsc-id = SMSC-T1.B;SMSC-T1.C;SMSC-T2.A <-- had to include the SMSC(s) for the other telco here preferred-smsc-id = SMSC-T1.A Messages have been pushed out on the requested SMSC 100% of the time now. David -Original Message----- From: David Ritchie [mailto:[EMAIL PROTECTED] Sent: Tuesday, 3 April 2007 1:48 p.m. To: users@kannel.org Subject: Forcing SMSC doesn't work Hi -- when doing an MT push, I want to force the SMSC I want messages to go out on, regardless of what the handset's prefix happens to be. However, it doesn't seem to work -- messages just go out on a random SMSC, even when I include a "smsc=" value in the MT push URL. We're recently suffering the overhead of the telcos rolling out number portability, and want to achieve the following: -- force a message to be pushed to a specific SMSC, provided the SMSC is specified in the push URL -- set a default SMSC (or group of SMSCs) for a prefix, in case the SMSC *isn't* specified -- and have confidence it'll all work. I am currently connected to 4 SMSCs, 3 providing connectivity to telco T1 (call these SMSC-T1.A through SMSC-T1.C), and one connected to telco T2 (SMSC-T2.A). Previously if I pushed out to a handset prefixed with "6427", it went out (randomly) through one of the 3 SMSCs connected to telco T1. The three smsc groups looked like this: group = smsc smsc = smpp smsc-id = SMSC-T1.A [ this changed between SMSCs ] allowed-prefix = "027;6427;+6427" denied-smsc-id = SMS-T1.B;SMS-T1.C [ obviously this was different between SMSCs ] preferred-smsc-id = smsc-t1a And the fourth SMSC (to the other telco) was along these lines: group = smsc smsc = smpp smsc-id = SMSC-T2.A allowed-prefix = "021;6421;+6421" (Judging from these prefixes, you can probably guess what country I am in.) With number portability, messages sent to handsets beginning with "6427" could potentially be forced to be sent out through telco T2; likewise handsets prefixed with "6421" might have to have messages pushed out through one of the SMSCs associated with telco T1. So I tried a test -- knowing a handset number which happened to have been ported from T1 to T2, but still keeping the "6427" prefix, I made some changes to the Kannel configuration, namely changing the allowed prefixes for all the SMSCs to allow all prefixes: allowed-prefix = "027;6427;+6427;021;6421;+6421;" I also added a "preferred-prefix" value in case we tried to push out messages without specifying the SMSC preferred-prefix = "021;6421;+6421" The URL I requested included a value for "smsc" set to "SMSC-T2.A" (url-encoded), and assumed this would forced the message to go out through SMSC-T2.A; instead the message goes to *any* of the four SMSCs (since they've all got "6427" as a valid prefix). It appears to be a random choice between the four. Your advice is appreciated. David
Forcing SMSC doesn't work
Hi -- when doing an MT push, I want to force the SMSC I want messages to go out on, regardless of what the handset's prefix happens to be. However, it doesn't seem to work -- messages just go out on a random SMSC, even when I include a "smsc=" value in the MT push URL. We're recently suffering the overhead of the telcos rolling out number portability, and want to achieve the following: -- force a message to be pushed to a specific SMSC, provided the SMSC is specified in the push URL -- set a default SMSC (or group of SMSCs) for a prefix, in case the SMSC *isn't* specified -- and have confidence it'll all work. I am currently connected to 4 SMSCs, 3 providing connectivity to telco T1 (call these SMSC-T1.A through SMSC-T1.C), and one connected to telco T2 (SMSC-T2.A). Previously if I pushed out to a handset prefixed with "6427", it went out (randomly) through one of the 3 SMSCs connected to telco T1. The three smsc groups looked like this: group = smsc smsc = smpp smsc-id = SMSC-T1.A [ this changed between SMSCs ] allowed-prefix = "027;6427;+6427" denied-smsc-id = SMS-T1.B;SMS-T1.C [ obviously this was different between SMSCs ] preferred-smsc-id = smsc-t1a And the fourth SMSC (to the other telco) was along these lines: group = smsc smsc = smpp smsc-id = SMSC-T2.A allowed-prefix = "021;6421;+6421" (Judging from these prefixes, you can probably guess what country I am in.) With number portability, messages sent to handsets beginning with "6427" could potentially be forced to be sent out through telco T2; likewise handsets prefixed with "6421" might have to have messages pushed out through one of the SMSCs associated with telco T1. So I tried a test -- knowing a handset number which happened to have been ported from T1 to T2, but still keeping the "6427" prefix, I made some changes to the Kannel configuration, namely changing the allowed prefixes for all the SMSCs to allow all prefixes: allowed-prefix = "027;6427;+6427;021;6421;+6421;" I also added a "preferred-prefix" value in case we tried to push out messages without specifying the SMSC preferred-prefix = "021;6421;+6421" The URL I requested included a value for "smsc" set to "SMSC-T2.A" (url-encoded), and assumed this would forced the message to go out through SMSC-T2.A; instead the message goes to *any* of the four SMSCs (since they've all got "6427" as a valid prefix). It appears to be a random choice between the four. Your advice is appreciated. David
RE: Masking originating addresses
Yes, that's right -- setting the sender number. -Original Message- From: Iain Dooley [mailto:[EMAIL PROTECTED] Sent: Tuesday, 30 January 2007 10:32 a.m. To: David Ritchie Cc: users@kannel.org Subject: Re: Masking originating addresses hi david, On Tue, 30 Jan 2007, David Ritchie wrote: > Hello all -- has anybody had any success with using TPOA (or similar) to > mask the originating address for MT SMS messages? do you just mean setting the sender number? cheers iain
Masking originating addresses
Hello all -- has anybody had any success with using TPOA (or similar) to mask the originating address for MT SMS messages? Regards David
DLR storage in MySQL
We're storing DLRs in MySQL successfully but the DLRs aren't being deleted which seems at odds with other people's experience (i.e. http://www.kannel.org/pipermail/users/2006-August/000294.html) but makes sense, since often we include a dlr-mask value (e.g. 12) which result in multiple DLRs being returned. Can anybody outline any successful DLR archiving or deletion strategies they've implemented, or perhaps outline how we can delete DLRs after a certain expiry date? Is there a danger (other than disk space issues) in letting the DLR table grow? Thanks! David R
Multiple smsboxes (was RE: Prioritising MO/MT messages)
Thanks Stipe -- having multiple smsboxes sounds like it could be worth
following up on. Can anyone provide me with an example of how to configure
Kannel to use multiple smsboxes? I've tried doing this and, although Kannel
starts up successfully, I'm not entirely sure I've configured it correctly:
--8<-
# SMSBOX SETUP
#
group = smsbox
smsbox-id = smsbox01
bearerbox-host = localhost
sendsms-port = 13013
log-file = "/etc/kannel/logs/smsbox.log"
log-level = 0
group = smsbox
smsbox-id = smsbox02
bearerbox-host = localhost
sendsms-port = 13013
log-file = "/etc/kannel/logs/smsbox.log"
log-level = 0
--8<-
Note that if I change the log file names (e.g. "smsbox01.log" and
"smsbox02.log"), only smsbox02.log gets written to. This makes me think only
the second config is being read in and obeyed. Likewise, if the sendsms-port
values are different, only the second one is actually listened to. If I leave
off the second "group" configuration, then it doesn't start up at all.
Thanks
David R
-Original Message-
From: Stipe Tolj [mailto:[EMAIL PROTECTED]
Sent: Sunday, 16 July 2006 11:52 p.m.
To: David Ritchie
Cc: users@kannel.org
Subject: Re: Prioritising MO/MT messages
David Ritchie wrote:
> Hello all. A scenario I'm experiencing at the moment involves a large
> (several thousand) number of MT messages being pushed through Kannel,
> during which it looks like MO messages (and the routing of them to the
> appropriate URLs) gets relegated to a "back seat"; that is, a delay of
> several minutes can take place between Kannel receiving the MO message,
> and it getting around to pushing it to the correct URL:
>
> smsbox.log:2006-07-15 12:52:13 [8487] [4] INFO: Starting to service
> from to
> smsbox.log:2006-07-15 12:53:08 [8487] [4] INFO: Starting to service
> from to
> smsbox.log:2006-07-15 12:55:10 [8487] [9] DEBUG: Parsing URL
> `http://URL/?source=HANDSET&destination=SHORTCODE&message=Test':
> smsbox.log:2006-07-15 12:55:10 [8487] [9] DEBUG: Query:
> source=HANDSET&destination=SHORTCODE&message=Test
> smsbox.log:2006-07-15 13:01:22 [8487] [9] DEBUG: Parsing URL
> `http://URL/?source=HANDSET&destination=SHORTCODE&message=Test':
> smsbox.log:2006-07-15 13:01:22 [8487] [9] DEBUG: Query:
> source=HANDSET&destination=SHORTCODE&message=Test
>
> As the log above displays, I sent in two messages (both saying "Test")
> to the shortcode, 1 minute apart. I was some minutes (between 3 and 8)
> minutes before either of those messages were routed to the URL for that
> shortcode. During this time we were successfully sending 100s of MT
> messages (pushed using the HTTP interface) to handsets to the same SMSC
> as I would have sent the above message from (i.e there's only one for
> that carrier), but on a different shortcode and from a different server
> (i.e. an entirely different service!).
ok, this seems to be the issue when you load the MT side heavily, and the HTTP
calling thread inside smsbox is set to "pending", since resources (cpu time)
have to be shared.
I agree that a heavy loading of one side (MT) should not "block" fully the
other
side (MO).
We currently don't handle this extreme situation.
One solution is to use several smsbox'es connected to the same bearerbox. This
can balance out the load on the single smsbox.
> It appears that restarting Kannel wipes the queue of messages, as any
> sent between restarts are happily accepted but never routed. I have
> started using the store file to see whether that makes a difference.
correct, smsbox's internal HTTP calling queue is _NOT_ persistant. Which means
if you restart the box while in heavy load, the waiting messages to be called
will get lost.
We need to addapt store file mechanism to smsbo too. Some guys have such
versions in private branches (namely Alex and me). But this needs to get merged
into the official tree.
> It's also worth noting that the service with the MT messages also
> requests DLRs (down to deliver to handset), so for every MT message
> there are 1 - 2 MO messages with DLR information. These also apparently
> get queued, in favour of the outgoing MT messages.
yep, MO and/or DLR HTTP calls are the "same" for smsbox.
> Is there a way of prioritising MT messages to be a lower priority to MO
> messages? Or even prioritising services one over another? Or perhaps
> this is a file descriptor problem -- would increasing the number of FDs
> allow more messages to be sent during a given time? Have you any other
> ideas / experience?
no, there is no current way in setting priority policy. You'll need to use more
smsboxs connected to the bearerbox and let the system balance over them.
Stipe
---
Kölner Landstrasse 419
40589 Düsseldorf, NRW, Germany
tolj.org system architecture Kannel Software Foundation (KSF)
http://www.tolj.org/ http://www.kannel.org/
mailto:st_{at}_tolj.org mailto:stolj_{at}_kannel.org
---
Prioritising MO/MT messages
Hello all. A scenario I'm experiencing at the moment involves a large (several thousand) number of MT messages being pushed through Kannel, during which it looks like MO messages (and the routing of them to the appropriate URLs) gets relegated to a "back seat"; that is, a delay of several minutes can take place between Kannel receiving the MO message, and it getting around to pushing it to the correct URL: smsbox.log:2006-07-15 12:52:13 [8487] [4] INFO: Starting to service from to smsbox.log:2006-07-15 12:53:08 [8487] [4] INFO: Starting to service from to smsbox.log:2006-07-15 12:55:10 [8487] [9] DEBUG: Parsing URL `http://URL/?source=HANDSET&destination=SHORTCODE&message=Test': smsbox.log:2006-07-15 12:55:10 [8487] [9] DEBUG: Query: source=HANDSET&destination=SHORTCODE&message=Test smsbox.log:2006-07-15 13:01:22 [8487] [9] DEBUG: Parsing URL `http://URL/?source=HANDSET&destination=SHORTCODE&message=Test': smsbox.log:2006-07-15 13:01:22 [8487] [9] DEBUG: Query: source=HANDSET&destination=SHORTCODE&message=Test As the log above displays, I sent in two messages (both saying "Test") to the shortcode, 1 minute apart. I was some minutes (between 3 and 8) minutes before either of those messages were routed to the URL for that shortcode. During this time we were successfully sending 100s of MT messages (pushed using the HTTP interface) to handsets to the same SMSC as I would have sent the above message from (i.e there's only one for that carrier), but on a different shortcode and from a different server (i.e. an entirely different service!). It appears that restarting Kannel wipes the queue of messages, as any sent between restarts are happily accepted but never routed. I have started using the store file to see whether that makes a difference. It's also worth noting that the service with the MT messages also requests DLRs (down to deliver to handset), so for every MT message there are 1 - 2 MO messages with DLR information. These also apparently get queued, in favour of the outgoing MT messages. Is there a way of prioritising MT messages to be a lower priority to MO messages? Or even prioritising services one over another? Or perhaps this is a file descriptor problem -- would increasing the number of FDs allow more messages to be sent during a given time? Have you any other ideas / experience? Regards David Ritchie
Abnormal termination every 5 minutes
Hello all -- I have inherited a peculiar situation where Kannel has suddenly decided to terminate every 300 seconds (occasionally making it to 600, but usually 300). Everything goes along well until it stops and needs to be restarted. No changes to configuration files have been made, but we have been experiencing a considerable increase in traffic recently (which makes the downtime even more concerning). The fact that it terminates on either 300 or 600 seconds is a little eyebrow-raising. Typically the process terminates with the following information in the smsbox.log: 2005-06-13 22:04:24 [0] INFO: Connection closed by the bearerbox 2005-06-13 22:04:24 [0] INFO: Received (and handled?) 64 requests in 300 seconds (0.21 per second) 2005-06-13 22:04:24 [0] INFO: Kannel smsbox terminating. 2005-06-13 22:04:24 [1] WARNING: Destroying fdset with 1 active entries. 2005-06-13 22:04:24 [8] WARNING: Destroying fdset with 3 active entries. Some other pertinent information: Kannel version 1.2.1, running on SunOS 5.8, with libxml version 20604 I have attached our kannel.conf file (apologies for the messiness). If anybody has any light to shine on the situation I'd like to hear it! Many thanks David Ritchie Run The Red nopassword-kannel.conf Description: nopassword-kannel.conf
