How does the data_coding field work

2011-06-23 Thread brett skinner
Hi

I have read through the SMPP v3.4 spec, the Kannel user guide and some other
PDFs from the SMS Forum but I am still a little in the dark about this
field.

Please correct me where I am wrong:

It seems that the data_coding field is made up of 2 distinct sections.
Firstly, coding scheme, bits 3 to 0 are used to indicate to the SMSC what
encoding has been used to encode the short_message field.
The second part, data coding parameter, seems to influence how the handset
will handle the sms by manipulating the MWI (message waiting indicator).

We are trying to send messages to an SMSC and certain symbols are coming out
incorrectly on our handsets. For example the '@' is coming out as a normal
'a'. We know that we needed to change to use ASCII. So we changed our
configuration and added

alt-charset = ASCII

I can see from the traces that the short_message data field is now encoded
differently but the data_coding field remains a 0. How do these fields and
settings then relate to the charset, coding, alt-dcs parameters that you can
set in the sendsms URL?

I have also come across in the SMPP v3.4 GSM / UMTS v1.0 guide that the
following are the default encodings offered by most smscs

• SMSC default alphabet (7 or 8-bits)
• LATIN 1 (8-bits)
• US ASCII (7-bits)
• UCS2 (16-bits)

But when I have a look at the data_coding parameter in the SMPP v3.4 spec
GSM 03.38 (which I assume is the standard is not listed). Which leads me to
believe that IF the SMSC will use GSM to decode the message it will be part
of the SMSC Default Alphabet and there is no way of asking it to use GSM
specifically because it fall under the default umbrella. The SMSC uses
ASCII so we must just encode our messages using ASCII. We could also specify
0x01 in the data_coding field and it should have NO effect because we are
telling the SMSC to use ASCII to decode the message and they use that by
default anyway.

All of this is as clear as mud to me. Any help would be thoroughly
appreciated.

Regards,


Re: Why does Kannel not use sar_total_segments and sar_segment_seqnum when sending concatenated sms?

2011-01-18 Thread brett skinner
Hi guys.

Does anyone have an ideas to my question below?

Thanks,

On Thu, Jan 13, 2011 at 11:35 AM, brett skinner
tatty.dishcl...@gmail.comwrote:

 Hi

 I was looking through the logs and saw that Kannel sends concatenated SMSs
 using UDH in the Short Message fields. From reading the SMPP spec I was
 under the impression that the same thing could be achieved by using
 sar_total_segments and sar_segment_seqnum. Did I misinterpret the spec or
 does Kannel not use these fields for another reason such as
 unreliable implementation on the receiving SMSC.

 Regards,



Why does Kannel not use sar_total_segments and sar_segment_seqnum when sending concatenated sms?

2011-01-13 Thread brett skinner
Hi

I was looking through the logs and saw that Kannel sends concatenated SMSs
using UDH in the Short Message fields. From reading the SMPP spec I was
under the impression that the same thing could be achieved by using
sar_total_segments and sar_segment_seqnum. Did I misinterpret the spec or
does Kannel not use these fields for another reason such as
unreliable implementation on the receiving SMSC.

Regards,


Rerouting SMSs

2010-10-11 Thread brett skinner
Hi

We have had a couple of scenarios where a smsc that we are sending to
suddenly goes offline. We don't want to flood our bearerbox with SMS so we
only give it up to 400. When the smsc goes down we continue to try send to
that bind until the bearerbox queue is at about 400 then it stops and we no
longer send smss. At this point we get a notification that something is
stuck. We then go online and usually see that one of the binds have gone
down and its status is reconnecting. If the SMSC manages to sort out their
problems the bind is restored and we continue processing. The problem occurs
when the SMSC can't sort out their problem quickly. We stop sending SMSs
down that bind but there are still 400 odd waiting to go to that SMSC.

Is there a way to re-route all the queued sms that are waiting for the
disconnected bind to another bind that is functioning? We don't want to
loose the 400 and we don't want to wait until the connection is restored.
Some of the SMS are time sensitive. Not critically time sensitive just
within working hours etc. I read the UG but everything there seems to be
about setting up a reroute that is meant to a more permanent thing. We just
want to take what is in the queue and give it to another bind. We don't want
to make a permanent configuration change.

Regards,


Re: Rerouting SMSs

2010-10-11 Thread brett skinner
Hi Nikos

Yes, you are correct. Terribly sorry for leaving out that vital piece of
information.

Would this also work if we had the following situation:

Bind to SMSC A goes down.
Queue builds up to SMSC A.
We stop processing.
Reroute all SMSC A traffic to SMSC B only.

We are quite specific about which SMSCs we want to use due to the fact of
volume limitations and pricing.

Lastly, is the Queue to the bearerbox file backed? So restarting the
bearerbox will not lose all the SMS in the queue?

Regards,

2010/10/11 Nikos Balkanas nbalka...@gmail.com

 Hi,

 I imagine you specify the SMSc in your sendsms URL and force routing by
 allowed-smsc-id and denied-smsc-id. You can change these configuration
 variables to preferred-smsc-id instead of allowed (skip denied altogether),
 restart bb to reload configuration and bb will load-balance queue to
 remaining SMScs.

 BR,
 Nikos
 - Original Message - From: brett skinner
 To: Users
 Sent: Monday, October 11, 2010 10:45 AM
 Subject: Rerouting SMSs



 Hi


 We have had a couple of scenarios where a smsc that we are sending to
 suddenly goes offline. We don't want to flood our bearerbox with SMS so we
 only give it up to 400. When the smsc goes down we continue to try send to
 that bind until the bearerbox queue is at about 400 then it stops and we no
 longer send smss. At this point we get a notification that something is
 stuck. We then go online and usually see that one of the binds have gone
 down and its status is reconnecting. If the SMSC manages to sort out their
 problems the bind is restored and we continue processing. The problem occurs
 when the SMSC can't sort out their problem quickly. We stop sending SMSs
 down that bind but there are still 400 odd waiting to go to that SMSC.


 Is there a way to re-route all the queued sms that are waiting for the
 disconnected bind to another bind that is functioning? We don't want to
 loose the 400 and we don't want to wait until the connection is restored.
 Some of the SMS are time sensitive. Not critically time sensitive just
 within working hours etc. I read the UG but everything there seems to be
 about setting up a reroute that is meant to a more permanent thing. We just
 want to take what is in the queue and give it to another bind. We don't want
 to make a permanent configuration change.


 Regards,



Re: Rerouting SMSs

2010-10-11 Thread brett skinner
Thanks for the info Nikos.

2010/10/11 Nikos Balkanas nbalka...@gmail.com

 BB doesn't loose any SMS in queue (except maybe the 1 processing when you
 shutdown - shutdown when low traffic). You can reroute to any smsc you
 desire. But you will have to restart bb to reload config.


 BR,
 Nikos
 - Original Message - From: brett skinner
 To: Users
 Sent: Monday, October 11, 2010 11:13 AM
 Subject: Re: Rerouting SMSs



 Hi Nikos


 Yes, you are correct. Terribly sorry for leaving out that vital piece of
 information.


 Would this also work if we had the following situation:


 Bind to SMSC A goes down.
 Queue builds up to SMSC A.
 We stop processing.
 Reroute all SMSC A traffic to SMSC B only.


 We are quite specific about which SMSCs we want to use due to the fact of
 volume limitations and pricing.


 Lastly, is the Queue to the bearerbox file backed? So restarting the
 bearerbox will not lose all the SMS in the queue?


 Regards,


 2010/10/11 Nikos Balkanas nbalka...@gmail.com

 Hi,

 I imagine you specify the SMSc in your sendsms URL and force routing by
 allowed-smsc-id and denied-smsc-id. You can change these configuration
 variables to preferred-smsc-id instead of allowed (skip denied altogether),
 restart bb to reload configuration and bb will load-balance queue to
 remaining SMScs.

 BR,
 Nikos
 - Original Message - From: brett skinner
 To: Users
 Sent: Monday, October 11, 2010 10:45 AM
 Subject: Rerouting SMSs



 Hi


 We have had a couple of scenarios where a smsc that we are sending to
 suddenly goes offline. We don't want to flood our bearerbox with SMS so we
 only give it up to 400. When the smsc goes down we continue to try send to
 that bind until the bearerbox queue is at about 400 then it stops and we no
 longer send smss. At this point we get a notification that something is
 stuck. We then go online and usually see that one of the binds have gone
 down and its status is reconnecting. If the SMSC manages to sort out their
 problems the bind is restored and we continue processing. The problem occurs
 when the SMSC can't sort out their problem quickly. We stop sending SMSs
 down that bind but there are still 400 odd waiting to go to that SMSC.


 Is there a way to re-route all the queued sms that are waiting for the
 disconnected bind to another bind that is functioning? We don't want to
 loose the 400 and we don't want to wait until the connection is restored.
 Some of the SMS are time sensitive. Not critically time sensitive just
 within working hours etc. I read the UG but everything there seems to be
 about setting up a reroute that is meant to a more permanent thing. We just
 want to take what is in the queue and give it to another bind. We don't want
 to make a permanent configuration change.


 Regards,



Fwd: Weird binding issue that causes queues to build up.

2010-09-23 Thread brett skinner
Hi guys

We have just hit this issue AGAIN this morning. Can ANYONE please give some
guidance here. I have had zero response on this critical issue for over two
weeks now. Can someone please help. This issue is becoming increasingly
urgent.

Regards,
Brett

-- Forwarded message --
From: brett skinner tatty.dishcl...@gmail.com
Date: Fri, Sep 17, 2010 at 2:16 PM
Subject: Re: Weird binding issue that causes queues to build up.
To: Users users@kannel.org


Hi

We have experienced this problem again. A couple of our binds to one
particular smsc (the rest were okay) had connectivity issues last night at
12 AM. The binds were re-established and reported as being online from the
status pages. However a queue for one of the binds built up on the
bearerbox. Only when I had run a stop-smsc and start-smsc for that bind did
the queue for that bind start processing again.

In the logs at 12AM we have a bunch of Errors:

2010-09-16 23:59:35 [32641] [44] ERROR: Error reading from fd 57:
2010-09-16 23:59:35 [32641] [44] ERROR: System error 104: Connection reset
by peer
2010-09-16 23:59:35 [32641] [44] ERROR: SMPP[XXX]: Couldn't connect to SMS
center (retrying in 10 seconds).
2010-09-16 23:59:38 [32641] [38] ERROR: Error reading from fd 52:
2010-09-16 23:59:38 [32641] [38] ERROR: System error 104: Connection reset
by peer
2010-09-16 23:59:38 [32641] [38] ERROR: SMPP[YYY]: Couldn't connect to SMS
center (retrying in 10 seconds).
2010-09-16 23:59:39 [32641] [46] ERROR: Error reading from fd 50:
2010-09-16 23:59:39 [32641] [46] ERROR: System error 104: Connection reset
by peer
2010-09-16 23:59:39 [32641] [46] ERROR: SMPP[AAA]: Couldn't connect to SMS
center (retrying in 10 seconds).
2010-09-16 23:59:47 [32641] [39] ERROR: Error reading from fd 49:
2010-09-16 23:59:47 [32641] [39] ERROR: System error 104: Connection reset
by peer
2010-09-16 23:59:47 [32641] [39] ERROR: SMPP[YYY]: Couldn't connect to SMS
center (retrying in 10 seconds).
2010-09-16 23:59:51 [32641] [48] ERROR: Error reading from fd 61:
2010-09-16 23:59:51 [32641] [48] ERROR: System error 104: Connection reset
by peer
2010-09-16 23:59:51 [32641] [48] ERROR: SMPP[BBB]: Couldn't connect to SMS
center (retrying in 10 seconds).
2010-09-17 00:00:00 [32641] [47] ERROR: Error reading from fd 40:
2010-09-17 00:00:00 [32641] [47] ERROR: System error 104: Connection reset
by peer
2010-09-17 00:00:00 [32641] [47] ERROR: SMPP[XXX]: Couldn't connect to SMS
center (retrying in 10 seconds).


I am not sure how Kannel works internally, but it is almost as if when the
bind is re-established, the old one is disposed and a new one is created but
the queue and the pointers are still sticking around for the old one and
have not been updated. This results in messages sitting in the queue and not
being routed to the bind which reports as being online.

I see that there might have been similar issues in the past:
http://www.kannel.org/pipermail/users/2009-May/007166.html. It might be
related maybe not.

http://www.kannel.org/pipermail/users/2009-May/007166.htmlWe have already
set our binds up in a transmitter and receiver. We are not running
transceiver.

Regards,


On Thu, Sep 9, 2010 at 3:42 PM, brett skinner tatty.dishcl...@gmail.comwrote:

 Thanks Alvaro for your response.

 I am running a build from SVN from about a 2 weeks ago. I am bit weary of
 turning the loggers to debug mode because we are doing a lot of traffic and
 debug mode is very verbose we will eat through our disk in no time. It would
 be different if it was reproducible or if we could anticipate the problem
 because we could just turn on the loggers at the right time. This happens so
 sporadically we would have to leave the loggers in debug mode. The last time
 this happened was last week.

 I will go check out that tool you mentioned.

 I am not that interested in the extra TLVs. They were just making a bit of
 noise in our logs :)

 Thanks again for your help.



 On Thu, Sep 9, 2010 at 3:35 PM, Alvaro Cornejo 
 cornejo.alv...@gmail.comwrote:

 Have you checked what does the system logs in debug mode?

 Regarding the queue, there is a tool created by Alejandro Guerreri
 that allows you to view the queue content and delete messages... well
 kannel does have several queues, so I don't know if it does wirk for
 the one you mention. I don't remember the details but you can check
 his blog. http://www.blogalex.com/archives/72

 About the TLV's you are receiving, you should ask yoru provider to see
 what does they mean and what info are they sending. If its of your
 interest, you can configure meta-data so you can capture that info;
 otherwise you can safely ignore. As the PDU type is deliver_sm, I
 suspect that it might be the dlr status... and that is why you have
 that queue.

 Also if you upgrade to a recent version, the status page was improved
 and it shows now separate counters for MT and dlrs. in older versions
 MT/dlr counters were mixed


 Hope helps

 Alvaro

Weird binding issue that causes queues to build up.

2010-09-23 Thread brett skinner
Hi

We are using transmitter and receiver because apparently there are
performance issues when using transceiver due to both the
transmitting/receiving being handled on a single thread. We were advised to
use Tx and Rx.

We have contacted the provider and while they acknowledge that they had an
outage for a couple of seconds everyone else was able to reconnect without
an issue. It was just us. But this is not limited to them, it seems any bind
that dies and comes back there is a chance that bearerbox will start
queuing.

Do you have any extra information on the work-around?

Regards,


On Thu, Sep 23, 2010 at 2:24 PM, Benaiad bena...@gmail.com wrote:

 Hi Brett,

 Which type of connection are you using? if it's not as transceiver, I
 suggest you to use it if your provider has a support for this.
 There is a known bug regarding the separated connections for Tx  Rx.
 I beleave that there is another workaround for this by defining two smsc
 groups one for Tx and the other for Rx.

 Regards

 --
 Benaiad



 On Thu, Sep 23, 2010 at 11:21 AM, brett skinner tatty.dishcl...@gmail.com
  wrote:

 Hi guys

 We have just hit this issue AGAIN this morning. Can ANYONE please give
 some guidance here. I have had zero response on this critical issue for over
 two weeks now. Can someone please help. This issue is becoming increasingly
 urgent.

 Regards,
 Brett

 -- Forwarded message --
 From: brett skinner tatty.dishcl...@gmail.com
  Date: Fri, Sep 17, 2010 at 2:16 PM
 Subject: Re: Weird binding issue that causes queues to build up.
 To: Users users@kannel.org


 Hi

 We have experienced this problem again. A couple of our binds to one
 particular smsc (the rest were okay) had connectivity issues last night at
 12 AM. The binds were re-established and reported as being online from the
 status pages. However a queue for one of the binds built up on the
 bearerbox. Only when I had run a stop-smsc and start-smsc for that bind did
 the queue for that bind start processing again.

 In the logs at 12AM we have a bunch of Errors:

 2010-09-16 23:59:35 [32641] [44] ERROR: Error reading from fd 57:
 2010-09-16 23:59:35 [32641] [44] ERROR: System error 104: Connection reset
 by peer
 2010-09-16 23:59:35 [32641] [44] ERROR: SMPP[XXX]: Couldn't connect to SMS
 center (retrying in 10 seconds).
 2010-09-16 23:59:38 [32641] [38] ERROR: Error reading from fd 52:
 2010-09-16 23:59:38 [32641] [38] ERROR: System error 104: Connection reset
 by peer
 2010-09-16 23:59:38 [32641] [38] ERROR: SMPP[YYY]: Couldn't connect to SMS
 center (retrying in 10 seconds).
 2010-09-16 23:59:39 [32641] [46] ERROR: Error reading from fd 50:
 2010-09-16 23:59:39 [32641] [46] ERROR: System error 104: Connection reset
 by peer
 2010-09-16 23:59:39 [32641] [46] ERROR: SMPP[AAA]: Couldn't connect to SMS
 center (retrying in 10 seconds).
 2010-09-16 23:59:47 [32641] [39] ERROR: Error reading from fd 49:
 2010-09-16 23:59:47 [32641] [39] ERROR: System error 104: Connection reset
 by peer
 2010-09-16 23:59:47 [32641] [39] ERROR: SMPP[YYY]: Couldn't connect to SMS
 center (retrying in 10 seconds).
 2010-09-16 23:59:51 [32641] [48] ERROR: Error reading from fd 61:
 2010-09-16 23:59:51 [32641] [48] ERROR: System error 104: Connection reset
 by peer
 2010-09-16 23:59:51 [32641] [48] ERROR: SMPP[BBB]: Couldn't connect to SMS
 center (retrying in 10 seconds).
 2010-09-17 00:00:00 [32641] [47] ERROR: Error reading from fd 40:
 2010-09-17 00:00:00 [32641] [47] ERROR: System error 104: Connection reset
 by peer
 2010-09-17 00:00:00 [32641] [47] ERROR: SMPP[XXX]: Couldn't connect to SMS
 center (retrying in 10 seconds).


 I am not sure how Kannel works internally, but it is almost as if when the
 bind is re-established, the old one is disposed and a new one is created but
 the queue and the pointers are still sticking around for the old one and
 have not been updated. This results in messages sitting in the queue and not
 being routed to the bind which reports as being online.

 I see that there might have been similar issues in the past:
 http://www.kannel.org/pipermail/users/2009-May/007166.html. It might be
 related maybe not.

 http://www.kannel.org/pipermail/users/2009-May/007166.htmlWe have
 already set our binds up in a transmitter and receiver. We are not running
 transceiver.

 Regards,


 On Thu, Sep 9, 2010 at 3:42 PM, brett skinner 
 tatty.dishcl...@gmail.comwrote:

 Thanks Alvaro for your response.

 I am running a build from SVN from about a 2 weeks ago. I am bit weary of
 turning the loggers to debug mode because we are doing a lot of traffic and
 debug mode is very verbose we will eat through our disk in no time. It would
 be different if it was reproducible or if we could anticipate the problem
 because we could just turn on the loggers at the right time. This happens so
 sporadically we would have to leave the loggers in debug mode. The last time
 this happened was last week.

 I will go check out that tool you mentioned.

 I am

Re: Weird binding issue that causes queues to build up.

2010-09-23 Thread brett skinner
Thank you VERY MUCH for your help. We will give that a try.

On Thu, Sep 23, 2010 at 3:13 PM, Benaiad bena...@gmail.com wrote:

 Hi Brett,

 I've found that workaround, which was offered by Mr. Donald Jackson.
 you may find it at
 http://www.mail-archive.com/users@kannel.org/msg15958.html

 Regards
 --
 Abdulmnem Benaiad
 Almontaha CTO
 www.almontaha.ly
 Tripoli-Libya



 On Thu, Sep 23, 2010 at 2:58 PM, brett skinner 
 tatty.dishcl...@gmail.comwrote:

 Hi

 We are using transmitter and receiver because apparently there are
 performance issues when using transceiver due to both the
 transmitting/receiving being handled on a single thread. We were advised to
 use Tx and Rx.

 We have contacted the provider and while they acknowledge that they had an
 outage for a couple of seconds everyone else was able to reconnect without
 an issue. It was just us. But this is not limited to them, it seems any bind
 that dies and comes back there is a chance that bearerbox will start
 queuing.

 Do you have any extra information on the work-around?

 Regards,


 On Thu, Sep 23, 2010 at 2:24 PM, Benaiad bena...@gmail.com wrote:

 Hi Brett,

 Which type of connection are you using? if it's not as transceiver, I
 suggest you to use it if your provider has a support for this.
 There is a known bug regarding the separated connections for Tx  Rx.
 I beleave that there is another workaround for this by defining two smsc
 groups one for Tx and the other for Rx.

 Regards

 --
 Benaiad



 On Thu, Sep 23, 2010 at 11:21 AM, brett skinner 
 tatty.dishcl...@gmail.com wrote:

 Hi guys

 We have just hit this issue AGAIN this morning. Can ANYONE please give
 some guidance here. I have had zero response on this critical issue for 
 over
 two weeks now. Can someone please help. This issue is becoming increasingly
 urgent.

 Regards,
 Brett

 -- Forwarded message --
 From: brett skinner tatty.dishcl...@gmail.com
  Date: Fri, Sep 17, 2010 at 2:16 PM
 Subject: Re: Weird binding issue that causes queues to build up.
 To: Users users@kannel.org


 Hi

 We have experienced this problem again. A couple of our binds to one
 particular smsc (the rest were okay) had connectivity issues last night at
 12 AM. The binds were re-established and reported as being online from the
 status pages. However a queue for one of the binds built up on the
 bearerbox. Only when I had run a stop-smsc and start-smsc for that bind did
 the queue for that bind start processing again.

 In the logs at 12AM we have a bunch of Errors:

 2010-09-16 23:59:35 [32641] [44] ERROR: Error reading from fd 57:
 2010-09-16 23:59:35 [32641] [44] ERROR: System error 104: Connection
 reset by peer
 2010-09-16 23:59:35 [32641] [44] ERROR: SMPP[XXX]: Couldn't connect to
 SMS center (retrying in 10 seconds).
 2010-09-16 23:59:38 [32641] [38] ERROR: Error reading from fd 52:
 2010-09-16 23:59:38 [32641] [38] ERROR: System error 104: Connection
 reset by peer
 2010-09-16 23:59:38 [32641] [38] ERROR: SMPP[YYY]: Couldn't connect to
 SMS center (retrying in 10 seconds).
 2010-09-16 23:59:39 [32641] [46] ERROR: Error reading from fd 50:
 2010-09-16 23:59:39 [32641] [46] ERROR: System error 104: Connection
 reset by peer
 2010-09-16 23:59:39 [32641] [46] ERROR: SMPP[AAA]: Couldn't connect to
 SMS center (retrying in 10 seconds).
 2010-09-16 23:59:47 [32641] [39] ERROR: Error reading from fd 49:
 2010-09-16 23:59:47 [32641] [39] ERROR: System error 104: Connection
 reset by peer
 2010-09-16 23:59:47 [32641] [39] ERROR: SMPP[YYY]: Couldn't connect to
 SMS center (retrying in 10 seconds).
 2010-09-16 23:59:51 [32641] [48] ERROR: Error reading from fd 61:
 2010-09-16 23:59:51 [32641] [48] ERROR: System error 104: Connection
 reset by peer
 2010-09-16 23:59:51 [32641] [48] ERROR: SMPP[BBB]: Couldn't connect to
 SMS center (retrying in 10 seconds).
 2010-09-17 00:00:00 [32641] [47] ERROR: Error reading from fd 40:
 2010-09-17 00:00:00 [32641] [47] ERROR: System error 104: Connection
 reset by peer
 2010-09-17 00:00:00 [32641] [47] ERROR: SMPP[XXX]: Couldn't connect to
 SMS center (retrying in 10 seconds).


 I am not sure how Kannel works internally, but it is almost as if when
 the bind is re-established, the old one is disposed and a new one is 
 created
 but the queue and the pointers are still sticking around for the old one 
 and
 have not been updated. This results in messages sitting in the queue and 
 not
 being routed to the bind which reports as being online.

 I see that there might have been similar issues in the past:
 http://www.kannel.org/pipermail/users/2009-May/007166.html. It might be
 related maybe not.

 http://www.kannel.org/pipermail/users/2009-May/007166.htmlWe have
 already set our binds up in a transmitter and receiver. We are not running
 transceiver.

 Regards,


 On Thu, Sep 9, 2010 at 3:42 PM, brett skinner 
 tatty.dishcl...@gmail.com wrote:

 Thanks Alvaro for your response.

 I am running a build from SVN from about a 2 weeks ago. I am bit weary

Re: Weird binding issue that causes queues to build up.

2010-09-17 Thread brett skinner
Hi

We have experienced this problem again. A couple of our binds to one
particular smsc (the rest were okay) had connectivity issues last night at
12 AM. The binds were re-established and reported as being online from the
status pages. However a queue for one of the binds built up on the
bearerbox. Only when I had run a stop-smsc and start-smsc for that bind did
the queue for that bind start processing again.

In the logs at 12AM we have a bunch of Errors:

2010-09-16 23:59:35 [32641] [44] ERROR: Error reading from fd 57:
2010-09-16 23:59:35 [32641] [44] ERROR: System error 104: Connection reset
by peer
2010-09-16 23:59:35 [32641] [44] ERROR: SMPP[XXX]: Couldn't connect to SMS
center (retrying in 10 seconds).
2010-09-16 23:59:38 [32641] [38] ERROR: Error reading from fd 52:
2010-09-16 23:59:38 [32641] [38] ERROR: System error 104: Connection reset
by peer
2010-09-16 23:59:38 [32641] [38] ERROR: SMPP[YYY]: Couldn't connect to SMS
center (retrying in 10 seconds).
2010-09-16 23:59:39 [32641] [46] ERROR: Error reading from fd 50:
2010-09-16 23:59:39 [32641] [46] ERROR: System error 104: Connection reset
by peer
2010-09-16 23:59:39 [32641] [46] ERROR: SMPP[AAA]: Couldn't connect to SMS
center (retrying in 10 seconds).
2010-09-16 23:59:47 [32641] [39] ERROR: Error reading from fd 49:
2010-09-16 23:59:47 [32641] [39] ERROR: System error 104: Connection reset
by peer
2010-09-16 23:59:47 [32641] [39] ERROR: SMPP[YYY]: Couldn't connect to SMS
center (retrying in 10 seconds).
2010-09-16 23:59:51 [32641] [48] ERROR: Error reading from fd 61:
2010-09-16 23:59:51 [32641] [48] ERROR: System error 104: Connection reset
by peer
2010-09-16 23:59:51 [32641] [48] ERROR: SMPP[BBB]: Couldn't connect to SMS
center (retrying in 10 seconds).
2010-09-17 00:00:00 [32641] [47] ERROR: Error reading from fd 40:
2010-09-17 00:00:00 [32641] [47] ERROR: System error 104: Connection reset
by peer
2010-09-17 00:00:00 [32641] [47] ERROR: SMPP[XXX]: Couldn't connect to SMS
center (retrying in 10 seconds).


I am not sure how Kannel works internally, but it is almost as if when the
bind is re-established, the old one is disposed and a new one is created but
the queue and the pointers are still sticking around for the old one and
have not been updated. This results in messages sitting in the queue and not
being routed to the bind which reports as being online.

I see that there might have been similar issues in the past:
http://www.kannel.org/pipermail/users/2009-May/007166.html. It might be
related maybe not.

http://www.kannel.org/pipermail/users/2009-May/007166.htmlWe have already
set our binds up in a transmitter and receiver. We are not running
transceiver.

Regards,

On Thu, Sep 9, 2010 at 3:42 PM, brett skinner tatty.dishcl...@gmail.comwrote:

 Thanks Alvaro for your response.

 I am running a build from SVN from about a 2 weeks ago. I am bit weary of
 turning the loggers to debug mode because we are doing a lot of traffic and
 debug mode is very verbose we will eat through our disk in no time. It would
 be different if it was reproducible or if we could anticipate the problem
 because we could just turn on the loggers at the right time. This happens so
 sporadically we would have to leave the loggers in debug mode. The last time
 this happened was last week.

 I will go check out that tool you mentioned.

 I am not that interested in the extra TLVs. They were just making a bit of
 noise in our logs :)

 Thanks again for your help.



 On Thu, Sep 9, 2010 at 3:35 PM, Alvaro Cornejo 
 cornejo.alv...@gmail.comwrote:

 Have you checked what does the system logs in debug mode?

 Regarding the queue, there is a tool created by Alejandro Guerreri
 that allows you to view the queue content and delete messages... well
 kannel does have several queues, so I don't know if it does wirk for
 the one you mention. I don't remember the details but you can check
 his blog. http://www.blogalex.com/archives/72

 About the TLV's you are receiving, you should ask yoru provider to see
 what does they mean and what info are they sending. If its of your
 interest, you can configure meta-data so you can capture that info;
 otherwise you can safely ignore. As the PDU type is deliver_sm, I
 suspect that it might be the dlr status... and that is why you have
 that queue.

 Also if you upgrade to a recent version, the status page was improved
 and it shows now separate counters for MT and dlrs. in older versions
 MT/dlr counters were mixed


 Hope helps

 Alvaro

 |-|
 Envíe y Reciba Datos y mensajes de Texto (SMS) hacia y desde cualquier
 celular y Nextel
 en el Perú, México y en mas de 180 paises. Use aplicaciones 2 vias via
 SMS y GPRS online
   Visitenos en www.perusms.NET www.smsglobal.com.mx y
 www.pravcom.com



 On Thu, Sep 9, 2010 at 2:42 AM, brett skinner tatty.dishcl...@gmail.com
 wrote:
  Hi everyone
  Just wondering if anyone

Fwd: Weird binding issue that causes queues to build up.

2010-09-09 Thread brett skinner
Hi everyone

Just wondering if anyone has had a chance to look at this yet?

Thanks and appreciate any help.

-- Forwarded message --
From: brett skinner tatty.dishcl...@gmail.com
Date: Tue, Sep 7, 2010 at 10:47 AM
Subject: Weird binding issue that causes queues to build up.
To: Users users@kannel.org


Hi

We are experiencing a rather weird occasional issue with Kannel. We have two
different boxes each with a Kannel installation. Every now and then one of
the boxes stops processing SMS queues and the queues just build up. This
happens to both boxes (just not at the same time) When we have a look at the
status page we can see the queue and there are sms queued to the bearerbox.
I assume that it is the bearerbox queue. It looks as followed (from the
status page)

SMS: received 123 (0 queued), sent 123 (456 queued), store size -1

It is the 456 queued part that we are concerned about. All the binds report
as being online with 0 in the queues but that 456 queue does not disappear.
If I sit trying to restart bind after bind one of them usually does the
trick and queue disappears. The problem is we usually have no idea which
bind it is and they are all reporting as being online. I have noticed
looking through our logs from upstream applications that it appears that
there was a network outage at round about the same time. I have not yet
confirmed this with the hosting company. Also this is what appears in the
syslog.

Sep  6 23:02:46 123-123-123-123 avahi-daemon[17943]: Received response from
host 64.150.181.120 with invalid source port 53756 on interface 'eth0.0'
Sep  6 23:17:01 123-123-123-123 CRON[16934]: (root) CMD (   cd / 
run-parts --report /etc/cron.hourly)
Sep  6 23:32:46 123-123-123-123 avahi-daemon[17943]: Received response from
host 64.150.181.120 with invalid source port 33895 on interface 'eth0.0'
Sep  7 00:02:45 123-123-123-123 avahi-daemon[17943]: Received response from
host 64.150.181.120 with invalid source port 55945 on interface 'eth0.0'
Sep  7 00:17:01 123-123-123-123 CRON[17231]: (root) CMD (   cd / 
run-parts --report /etc/cron.hourly)
Sep  7 00:32:45 123-123-123-123 avahi-daemon[17943]: Received response from
host 64.150.181.120 with invalid source port 45291 on interface 'eth0.0'
Sep  7 01:02:45 123-123-123-123 avahi-daemon[17943]: Received response from
host 64.150.181.120 with invalid source port 39067 on interface 'eth0.0'
Sep  7 01:17:01 123-123-123-123 CRON[17479]: (root) CMD (   cd / 
run-parts --report /etc/cron.hourly)

That IP address is not in our kannel.conf file. I am not sure what these
errors are about. I might need to investigate this further. I am not
security expert so I have no idea if this is malicious or not.

This is what appears in the bearerbox logs at about the same time as the
outage:

2010-09-06 23:02:46 [32641] [12] WARNING: SMPP: Unknown
TLV(0x1406,0x0007,01906032503580) for PDU type (deliver_sm) received!
2010-09-06 23:03:07 [32641] [12] WARNING: SMPP: Unknown
TLV(0x1406,0x0007,01906032605180) for PDU type (deliver_sm) received!
2010-09-06 23:08:04 [32641] [10] WARNING: SMPP: Unknown
TLV(0x1406,0x0007,01906032113180) for PDU type (deliver_sm) received!
2010-09-06 23:14:32 [32641] [9] WARNING: SMPP: Unknown
TLV(0x1406,0x0007,01906032711480) for PDU type (deliver_sm) received!
2010-09-06 23:26:12 [32641] [6] ERROR: SMPP[AAA]: I/O error or other error.
Re-connecting.
2010-09-06 23:26:12 [32641] [6] ERROR: SMPP[AAA]: Couldn't connect to SMS
center (retrying in 10 seconds).
2010-09-06 23:26:12 [32641] [18] WARNING: SMPP[BBB]: Not ACKED message
found, will retransmit. SENT94sec. ago, SEQ423861, DST+x
2010-09-06 23:26:12 [32641] [18] WARNING: SMPP[BBB]: Not ACKED message
found, will retransmit. SENT94sec. ago, SEQ423862, DST+x
2010-09-06 23:26:12 [32641] [18] ERROR: SMPP[BBB]: I/O error or other error.
Re-connecting.
2010-09-06 23:26:12 [32641] [18] ERROR: SMPP[BBB]: Couldn't connect to SMS
center (retrying in 10 seconds).
2010-09-06 23:26:12 [32641] [24] WARNING: Time-out waiting for concatenated
message ''+x' '+yyy' 'EEE' '10' '2' '''. Send message
parts as is.
2010-09-06 23:26:12 [32641] [24] WARNING: Time-out waiting for concatenated
message ''+x' '+yyy' 'EEE' '85' '2' '''. Send message
parts as is.
2010-09-06 23:26:12 [32641] [24] WARNING: Time-out waiting for concatenated
message ''+x' '+yyy' 'EEE' '152' '2' '''. Send message
parts as is.
2010-09-06 23:26:42 [32641] [17] ERROR: SMPP[CCC]: I/O error or other error.
Re-connecting.
2010-09-06 23:26:42 [32641] [17] ERROR: SMPP[CCC]: Couldn't connect to SMS
center (retrying in 10 seconds).
2010-09-06 23:27:08 [32641] [13] WARNING: SMPP: Unknown
TLV(0x1406,0x0007,01906032035180) for PDU type (deliver_sm) received!
2010-09-06 23:27:12 [32641] [19] ERROR: SMPP[BBB]: I/O error or other error.
Re-connecting.
2010-09-06 23:27:12 [32641] [19] ERROR: SMPP[BBB]: Couldn't connect to SMS
center (retrying in 10 seconds).
2010

Fwd: Weird binding issue that causes queues to build up.

2010-09-09 Thread brett skinner
Thanks Alvaro for your response.

I am running a build from SVN from about a 2 weeks ago. I am bit weary of
turning the loggers to debug mode because we are doing a lot of traffic and
debug mode is very verbose we will eat through our disk in no time. It would
be different if it was reproducible or if we could anticipate the problem
because we could just turn on the loggers at the right time. This happens so
sporadically we would have to leave the loggers in debug mode. The last time
this happened was last week.

I will go check out that tool you mentioned.

I am not that interested in the extra TLVs. They were just making a bit of
noise in our logs :)

Thanks again for your help.



On Thu, Sep 9, 2010 at 3:35 PM, Alvaro Cornejo cornejo.alv...@gmail.comwrote:

 Have you checked what does the system logs in debug mode?

 Regarding the queue, there is a tool created by Alejandro Guerreri
 that allows you to view the queue content and delete messages... well
 kannel does have several queues, so I don't know if it does wirk for
 the one you mention. I don't remember the details but you can check
 his blog. http://www.blogalex.com/archives/72

 About the TLV's you are receiving, you should ask yoru provider to see
 what does they mean and what info are they sending. If its of your
 interest, you can configure meta-data so you can capture that info;
 otherwise you can safely ignore. As the PDU type is deliver_sm, I
 suspect that it might be the dlr status... and that is why you have
 that queue.

 Also if you upgrade to a recent version, the status page was improved
 and it shows now separate counters for MT and dlrs. in older versions
 MT/dlr counters were mixed


 Hope helps

 Alvaro

 |-|
 Envíe y Reciba Datos y mensajes de Texto (SMS) hacia y desde cualquier
 celular y Nextel
 en el Perú, México y en mas de 180 paises. Use aplicaciones 2 vias via
 SMS y GPRS online
   Visitenos en www.perusms.NET www.smsglobal.com.mx y
 www.pravcom.com



 On Thu, Sep 9, 2010 at 2:42 AM, brett skinner tatty.dishcl...@gmail.com
 wrote:
  Hi everyone
  Just wondering if anyone has had a chance to look at this yet?
  Thanks and appreciate any help.
 
  -- Forwarded message --
  From: brett skinner tatty.dishcl...@gmail.com
  Date: Tue, Sep 7, 2010 at 10:47 AM
  Subject: Weird binding issue that causes queues to build up.
  To: Users users@kannel.org
 
 
  Hi
  We are experiencing a rather weird occasional issue with Kannel. We have
 two
  different boxes each with a Kannel installation. Every now and then one
 of
  the boxes stops processing SMS queues and the queues just build up. This
  happens to both boxes (just not at the same time) When we have a look at
 the
  status page we can see the queue and there are sms queued to the
 bearerbox.
  I assume that it is the bearerbox queue. It looks as followed (from the
  status page)
  SMS: received 123 (0 queued), sent 123 (456 queued), store size -1
  It is the 456 queued part that we are concerned about. All the binds
 report
  as being online with 0 in the queues but that 456 queue does not
 disappear.
  If I sit trying to restart bind after bind one of them usually does the
  trick and queue disappears. The problem is we usually have no idea which
  bind it is and they are all reporting as being online. I have noticed
  looking through our logs from upstream applications that it appears that
  there was a network outage at round about the same time. I have not yet
  confirmed this with the hosting company. Also this is what appears in the
  syslog.
  Sep  6 23:02:46 123-123-123-123 avahi-daemon[17943]: Received response
 from
  host 64.150.181.120 with invalid source port 53756 on interface 'eth0.0'
  Sep  6 23:17:01 123-123-123-123 CRON[16934]: (root) CMD (   cd / 
  run-parts --report /etc/cron.hourly)
  Sep  6 23:32:46 123-123-123-123 avahi-daemon[17943]: Received response
 from
  host 64.150.181.120 with invalid source port 33895 on interface 'eth0.0'
  Sep  7 00:02:45 123-123-123-123 avahi-daemon[17943]: Received response
 from
  host 64.150.181.120 with invalid source port 55945 on interface 'eth0.0'
  Sep  7 00:17:01 123-123-123-123 CRON[17231]: (root) CMD (   cd / 
  run-parts --report /etc/cron.hourly)
  Sep  7 00:32:45 123-123-123-123 avahi-daemon[17943]: Received response
 from
  host 64.150.181.120 with invalid source port 45291 on interface 'eth0.0'
  Sep  7 01:02:45 123-123-123-123 avahi-daemon[17943]: Received response
 from
  host 64.150.181.120 with invalid source port 39067 on interface 'eth0.0'
  Sep  7 01:17:01 123-123-123-123 CRON[17479]: (root) CMD (   cd / 
  run-parts --report /etc/cron.hourly)
  That IP address is not in our kannel.conf file. I am not sure what these
  errors are about. I might need to investigate this further. I am not
  security expert so I have no idea if this is malicious

Weird binding issue that causes queues to build up.

2010-09-07 Thread brett skinner
Hi

We are experiencing a rather weird occasional issue with Kannel. We have two
different boxes each with a Kannel installation. Every now and then one of
the boxes stops processing SMS queues and the queues just build up. This
happens to both boxes (just not at the same time) When we have a look at the
status page we can see the queue and there are sms queued to the bearerbox.
I assume that it is the bearerbox queue. It looks as followed (from the
status page)

SMS: received 123 (0 queued), sent 123 (456 queued), store size -1

It is the 456 queued part that we are concerned about. All the binds report
as being online with 0 in the queues but that 456 queue does not disappear.
If I sit trying to restart bind after bind one of them usually does the
trick and queue disappears. The problem is we usually have no idea which
bind it is and they are all reporting as being online. I have noticed
looking through our logs from upstream applications that it appears that
there was a network outage at round about the same time. I have not yet
confirmed this with the hosting company. Also this is what appears in the
syslog.

Sep  6 23:02:46 123-123-123-123 avahi-daemon[17943]: Received response from
host 64.150.181.120 with invalid source port 53756 on interface 'eth0.0'
Sep  6 23:17:01 123-123-123-123 CRON[16934]: (root) CMD (   cd / 
run-parts --report /etc/cron.hourly)
Sep  6 23:32:46 123-123-123-123 avahi-daemon[17943]: Received response from
host 64.150.181.120 with invalid source port 33895 on interface 'eth0.0'
Sep  7 00:02:45 123-123-123-123 avahi-daemon[17943]: Received response from
host 64.150.181.120 with invalid source port 55945 on interface 'eth0.0'
Sep  7 00:17:01 123-123-123-123 CRON[17231]: (root) CMD (   cd / 
run-parts --report /etc/cron.hourly)
Sep  7 00:32:45 123-123-123-123 avahi-daemon[17943]: Received response from
host 64.150.181.120 with invalid source port 45291 on interface 'eth0.0'
Sep  7 01:02:45 123-123-123-123 avahi-daemon[17943]: Received response from
host 64.150.181.120 with invalid source port 39067 on interface 'eth0.0'
Sep  7 01:17:01 123-123-123-123 CRON[17479]: (root) CMD (   cd / 
run-parts --report /etc/cron.hourly)

That IP address is not in our kannel.conf file. I am not sure what these
errors are about. I might need to investigate this further. I am not
security expert so I have no idea if this is malicious or not.

This is what appears in the bearerbox logs at about the same time as the
outage:

2010-09-06 23:02:46 [32641] [12] WARNING: SMPP: Unknown
TLV(0x1406,0x0007,01906032503580) for PDU type (deliver_sm) received!
2010-09-06 23:03:07 [32641] [12] WARNING: SMPP: Unknown
TLV(0x1406,0x0007,01906032605180) for PDU type (deliver_sm) received!
2010-09-06 23:08:04 [32641] [10] WARNING: SMPP: Unknown
TLV(0x1406,0x0007,01906032113180) for PDU type (deliver_sm) received!
2010-09-06 23:14:32 [32641] [9] WARNING: SMPP: Unknown
TLV(0x1406,0x0007,01906032711480) for PDU type (deliver_sm) received!
2010-09-06 23:26:12 [32641] [6] ERROR: SMPP[AAA]: I/O error or other error.
Re-connecting.
2010-09-06 23:26:12 [32641] [6] ERROR: SMPP[AAA]: Couldn't connect to SMS
center (retrying in 10 seconds).
2010-09-06 23:26:12 [32641] [18] WARNING: SMPP[BBB]: Not ACKED message
found, will retransmit. SENT94sec. ago, SEQ423861, DST+x
2010-09-06 23:26:12 [32641] [18] WARNING: SMPP[BBB]: Not ACKED message
found, will retransmit. SENT94sec. ago, SEQ423862, DST+x
2010-09-06 23:26:12 [32641] [18] ERROR: SMPP[BBB]: I/O error or other error.
Re-connecting.
2010-09-06 23:26:12 [32641] [18] ERROR: SMPP[BBB]: Couldn't connect to SMS
center (retrying in 10 seconds).
2010-09-06 23:26:12 [32641] [24] WARNING: Time-out waiting for concatenated
message ''+x' '+yyy' 'EEE' '10' '2' '''. Send message
parts as is.
2010-09-06 23:26:12 [32641] [24] WARNING: Time-out waiting for concatenated
message ''+x' '+yyy' 'EEE' '85' '2' '''. Send message
parts as is.
2010-09-06 23:26:12 [32641] [24] WARNING: Time-out waiting for concatenated
message ''+x' '+yyy' 'EEE' '152' '2' '''. Send message
parts as is.
2010-09-06 23:26:42 [32641] [17] ERROR: SMPP[CCC]: I/O error or other error.
Re-connecting.
2010-09-06 23:26:42 [32641] [17] ERROR: SMPP[CCC]: Couldn't connect to SMS
center (retrying in 10 seconds).
2010-09-06 23:27:08 [32641] [13] WARNING: SMPP: Unknown
TLV(0x1406,0x0007,01906032035180) for PDU type (deliver_sm) received!
2010-09-06 23:27:12 [32641] [19] ERROR: SMPP[BBB]: I/O error or other error.
Re-connecting.
2010-09-06 23:27:12 [32641] [19] ERROR: SMPP[BBB]: Couldn't connect to SMS
center (retrying in 10 seconds).
2010-09-06 23:27:14 [32641] [12] WARNING: SMPP: Unknown
TLV(0x1406,0x0007,01906032031280) for PDU type (deliver_sm) received!
2010-09-06 23:27:25 [32641] [16] ERROR: SMPP[CCC]: I/O error or other error.
Re-connecting.
2010-09-06 23:27:25 [32641] [16] ERROR: SMPP[CCC]: Couldn't connect to SMS
center (retrying in 10 seconds).

Re: Kannel with vb6

2010-08-30 Thread brett skinner
VB 6 is no longer supported and is definitely not VB.net. In any event, if
you want to use Kannel on Windows the recommendation is that you use
something like Cygwin. Another option is to use Mono to run .Net
applications on a Linux box. Not sure if the Mono project compiles VB.Net
but I am sure you could find out pretty easily. I am assuming that it does.
Third and final option is that you can have a windows application posting to
Kannel on a Linux machine.

As for examples. There are plenty PHP examples that I have come across. The
idea is pretty basic. What ever language you are using, you need to post to
a URL that Kannel is listening to. The contents of that URL can be found in
the UG.

On Fri, Aug 27, 2010 at 4:56 AM, Niko nick_p_z...@yahoo.com wrote:

  marcelo.olivas at up-mobile.com writes:

 
  Hi Denis, I am not sure what you mean by work.
 If you want to use kannel and
 then build your app to sent and
  receive sms, then yes. Kannel does the conversion
  of smpp to http awesome, so
 in reality you can use
  wathever framework/language you want as long as
  it can use the http stack. Hope
 that helps.


 Hi Marcelo, can u please give me a tutor of how to
 use kannel and then build my app to send sms,
 like u said before? Using http stack or whatever it is.
 I cant find how to do this on the web (not yet, maybe),
 so if u know about that,
 please kindly give me some example.
 I want to use kannel in windows and then build my app in VB.net 2008.
 My app will do something like sms broadcasting, using several
 GSM modem (as I have read that kannel supports multiple virtual SMSC).
 Thanks in advance.

 *Replies from any others of you who know how to do this
  is highly expected too.

 Niko.





Re: How does Kannel handle DLRs from multiple binds to the same SMSC

2010-08-26 Thread brett skinner
Hi Juan

Thanks. I am using MySQL storage. After reading the UG again I see that this
is what I should be doing. No matter how many times I read the thing I
always find something new.

Regards,

On Wed, Aug 25, 2010 at 11:23 PM, Juan Nin jua...@gmail.com wrote:

 Also, both binds will need to use the same smsc-id, since the SQL
 queries that search for the DLR info use the smsc-id on its WHERE
 conditions.

 Use smsc-admin-id to control each bind individually (start/stop/etc),
 but specify the same smsc-id on both



 On Wed, Aug 25, 2010 at 6:18 PM, Juan Nin jua...@gmail.com wrote:
  You need to use an external DLR storage (DB).
 
  If you use internal DLR storage, which is in memory, each Kannel
  server will store the info from the DLRs originated via that server,
  so if the SMSC send the DLR via the other server, it won't find it.
 
  See the external DB DLR storage options here:
 
 http://www.kannel.org/download/kannel-userguide-snapshot/userguide.html#AEN3170
 
 
  On Wed, Aug 25, 2010 at 5:09 PM, brett skinner
  tatty.dishcl...@gmail.com wrote:
  Hi
 
  In an effort to increase through put our SMSC suggested that we created
  another bind to them with the exact same details. I.e. username,
 password,
  IP address and port. In our configuration file I have created a second
 bind
  with a different ID but have set both SMPP connections to use the same
  allowed-smsc-id. The SMSC did mention that they would load balance the
 DLRs
  across the binds and feed to which ever bind had the least traffic.
 
  Looking through the bearerbox logs I don't not see any rejected DLRs.
 But we
  are missing an unusally large number of DLRs.
 
  Were we incorrect in our assumption that Kannel would be able to match
 the
  DLRs even if the original sms went out on one bind and came back in on
  another bind?
 
  Regards,
 
 
 
 




Re: Kannel restart command

2010-08-24 Thread brett skinner
@Alvaro: As Nikos said. According to UG it is only the DLRs that are safe
and my question is about queued SMS not DLR.

@Nikos. Thanks, it is in the configuration file already. There didn't appear
to be a restart-smsc so I used so stop-smsc and start-smsc and that did the
trick. Something else you said reminded me of a question I had been meaning
to ask. If we wanted to add an SMSC to our configuration would it be
possible to start that bind without having to restart the bearerbox. I
attempted to add a new bind yesterday and use the start-smsc command but I
kept getting could not restart smsc response from Kannel. I looked in the
logs but didn't see any errors or warnings. I restarted Kannel and the bind
connected straight away.

Regards,

2010/8/24 Nikos Balkanas nbalka...@gmail.com

 Not quite. Internal storage refers to dlr-storage. You can start bearerbox
 without *any* storage specified and that would do the trick, but that is
 extreme operation and asking for trouble.

 @brett: Alvaro is mostly right, but there is still a chance of loosing 1-2
 SMS, accepted by bb, before they are stored to filesystem. Your best bet
 would be to switch it first to isolated or suspended (don't remember which -
 check user's guide) wait a couple of minutes and then restart.

 However, if your inactive SMSc is already in your configuration file, you
 can just go tyo http admin and choose restart-smsc without the need to
 restart bearerbox.

 BR,
 Nikos
 - Original Message - From: Alvaro Cornejo 
 cornejo.alv...@gmail.com
 To: brett skinner tatty.dishcl...@gmail.com
 Cc: Users users@kannel.org
 Sent: Monday, August 23, 2010 5:57 PM
 Subject: Re: Kannel restart command



 If you do have setup kannel to store the messages on a file or store,
 you wont loose any message. You will if you do use internal storage
 that is held in RAM



 |-|
 Envνe y Reciba Datos y mensajes de Texto (SMS) hacia y desde cualquier
 celular y Nextel
 en el Perϊ, Mιxico y en mas de 180 paises. Use aplicaciones 2 vias via

 SMS y GPRS online
 Visitenos en www.perusms.NET www.smsglobal.com.mx y
 www.pravcom.com



 On Mon, Aug 23, 2010 at 2:38 AM, brett skinner
 tatty.dishcl...@gmail.com wrote:

 Hi Users
 We had a situation on Saturday where one of our SMSC experienced
 connection
 difficulties with their ISP. When they came back 2 of the 3 binds were
 re-established correctly. The 3rd bind reported being connected but all
 messages to that bind were getting queued to the bearerbox. I looked at
 the
 user guide for a way to drop and re-establish the connection without
 losing
 all the SMS traffic in memory. I saw the restart but it didn't say if it
 would destroy the in memory queue.
 Is there a way to re-establish the connections without loosing the in
 memory
 queues? Will the restart command do that?
 Regards,





Re: Kannel restart command

2010-08-24 Thread brett skinner
Works like a charm. I also tested remove-smsc too.

Sorry I was looking in the UG I downloaded off the website. I have no idea
if the add-smsc/remove-smsc is in the UG in trunk. I guess that is where I
should have been looking.

Thanks again.

2010/8/24 Nikos Balkanas nbalka...@gmail.com

 Add a new smsc in your configuration, while bb is running. Then, from the
 admin page choose:

 add-smsc

 Let me know how it works.

 BR,
 Nikos
 - Original Message - From: brett skinner
 To: Users
 Sent: Tuesday, August 24, 2010 12:17 PM

 Subject: Re: Kannel restart command


 @Alvaro: As Nikos said. According to UG it is only the DLRs that are safe
 and my question is about queued SMS not DLR.


 @Nikos. Thanks, it is in the configuration file already. There didn't
 appear to be a restart-smsc so I used so stop-smsc and start-smsc and that
 did the trick. Something else you said reminded me of a question I had been
 meaning to ask. If we wanted to add an SMSC to our configuration would it be
 possible to start that bind without having to restart the bearerbox. I
 attempted to add a new bind yesterday and use the start-smsc command but I
 kept getting could not restart smsc response from Kannel. I looked in the
 logs but didn't see any errors or warnings. I restarted Kannel and the bind
 connected straight away.


 Regards,


 2010/8/24 Nikos Balkanas nbalka...@gmail.com

 Not quite. Internal storage refers to dlr-storage. You can start bearerbox
 without *any* storage specified and that would do the trick, but that is
 extreme operation and asking for trouble.

 @brett: Alvaro is mostly right, but there is still a chance of loosing 1-2
 SMS, accepted by bb, before they are stored to filesystem. Your best bet
 would be to switch it first to isolated or suspended (don't remember which -
 check user's guide) wait a couple of minutes and then restart.

 However, if your inactive SMSc is already in your configuration file, you
 can just go tyo http admin and choose restart-smsc without the need to
 restart bearerbox.

 BR,
 Nikos
 - Original Message - From: Alvaro Cornejo 
 cornejo.alv...@gmail.com
 To: brett skinner tatty.dishcl...@gmail.com
 Cc: Users users@kannel.org
 Sent: Monday, August 23, 2010 5:57 PM
 Subject: Re: Kannel restart command



 If you do have setup kannel to store the messages on a file or store,
 you wont loose any message. You will if you do use internal storage
 that is held in RAM



 |-|

 EnvΞ½e y Reciba Datos y mensajes de Texto (SMS) hacia y desde cualquier
 celular y Nextel
 en el PerΟ , MΞΉxico y en mas de 180 paises. Use aplicaciones 2 vias via


 SMS y GPRS online
 Visitenos en www.perusms.NET www.smsglobal.com.mx y
 www.pravcom.com



 On Mon, Aug 23, 2010 at 2:38 AM, brett skinner
 tatty.dishcl...@gmail.com wrote:

 Hi Users
 We had a situation on Saturday where one of our SMSC experienced connection
 difficulties with their ISP. When they came back 2 of the 3 binds were
 re-established correctly. The 3rd bind reported being connected but all
 messages to that bind were getting queued to the bearerbox. I looked at the
 user guide for a way to drop and re-establish the connection without losing
 all the SMS traffic in memory. I saw the restart but it didn't say if it
 would destroy the in memory queue.
 Is there a way to re-establish the connections without loosing the in
 memory
 queues? Will the restart command do that?
 Regards,



Kannel restart command

2010-08-23 Thread brett skinner
Hi Users

We had a situation on Saturday where one of our SMSC experienced connection
difficulties with their ISP. When they came back 2 of the 3 binds were
re-established correctly. The 3rd bind reported being connected but all
messages to that bind were getting queued to the bearerbox. I looked at the
user guide for a way to drop and re-establish the connection without losing
all the SMS traffic in memory. I saw the restart but it didn't say if it
would destroy the in memory queue.

Is there a way to re-establish the connections without loosing the in memory
queues? Will the restart command do that?

Regards,


Re: Queue Size from status page

2010-08-18 Thread brett skinner
 [4912] [6] DEBUG:   type_name: submit_sm
2010-08-17 17:38:23 [4912] [6] DEBUG:   command_id: 4 = 0x0004
2010-08-17 17:38:23 [4912] [6] DEBUG:   command_status: 0 = 0x
2010-08-17 17:38:23 [4912] [6] DEBUG:   sequence_number: 6 = 0x0006
2010-08-17 17:38:23 [4912] [6] DEBUG:   service_type: NULL
2010-08-17 17:38:23 [4912] [6] DEBUG:   source_addr_ton: 1 = 0x0001
2010-08-17 17:38:23 [4912] [6] DEBUG:   source_addr_npi: 1 = 0x0001
2010-08-17 17:38:23 [4912] [6] DEBUG:   source_addr: 
2010-08-17 17:38:23 [4912] [6] DEBUG:   dest_addr_ton: 1 = 0x0001
2010-08-17 17:38:23 [4912] [6] DEBUG:   dest_addr_npi: 1 = 0x0001
2010-08-17 17:38:23 [4912] [6] DEBUG:   destination_addr: XXX
2010-08-17 17:38:23 [4912] [6] DEBUG:   esm_class: 3 = 0x0003
2010-08-17 17:38:23 [4912] [6] DEBUG:   protocol_id: 0 = 0x
2010-08-17 17:38:23 [4912] [6] DEBUG:   priority_flag: 0 = 0x
2010-08-17 17:38:23 [4912] [6] DEBUG:   schedule_delivery_time: NULL
2010-08-17 17:38:23 [4912] [6] DEBUG:   validity_period: NULL
2010-08-17 17:38:23 [4912] [6] DEBUG:   registered_delivery: 0 = 0x
2010-08-17 17:38:23 [4912] [6] DEBUG:   replace_if_present_flag: 0 =
0x
2010-08-17 17:38:23 [4912] [6] DEBUG:   data_coding: 0 = 0x
2010-08-17 17:38:23 [4912] [6] DEBUG:   sm_default_msg_id: 0 = 0x
2010-08-17 17:38:23 [4912] [6] DEBUG:   sm_length: 4 = 0x0004
2010-08-17 17:38:23 [4912] [6] DEBUG:   short_message: lost
2010-08-17 17:38:23 [4912] [6] DEBUG: SMPP PDU dump ends.
2010-08-17 17:38:23 [4912] [6] DEBUG: SMPP[SMSC-XXX]: throughput limit
exceeded (1.00,0.05)
2010-08-17 17:38:24 [4912] [6] DEBUG: SMPP[SMSC-XXX]: throughput (0.00,0.05)
2010-08-17 17:38:24 [4912] [6] DEBUG: SMPP[SMSC-XXX]: Got PDU:
2010-08-17 17:38:24 [4912] [6] DEBUG: SMPP PDU 0x232f260 dump:
2010-08-17 17:38:24 [4912] [6] DEBUG:   type_name: submit_sm_resp
2010-08-17 17:38:24 [4912] [6] DEBUG:   command_id: 2147483652 = 0x8004
2010-08-17 17:38:24 [4912] [6] DEBUG:   command_status: 0 = 0x
2010-08-17 17:38:24 [4912] [6] DEBUG:   sequence_number: 6 = 0x0006
2010-08-17 17:38:24 [4912] [6] DEBUG:   message_id: 20081717383633022
2010-08-17 17:38:24 [4912] [6] DEBUG: SMPP PDU dump ends.
2010-08-17 17:38:24 [4912] [6] DEBUG: SMPP[SMSC-XXX]: throughput (0.00,0.05)
2010-08-17 17:38:25 [4912] [16] DEBUG: boxc_receiver: sms received
2010-08-17 17:38:25 [4912] [16] DEBUG: send_msg: sending msg to box:
127.0.0.1
2010-08-17 17:38:25 [4912] [6] DEBUG: SMPP[SMSC-XXX]: throughput (0.00,0.05)
2010-08-17 17:38:25 [4912] [6] DEBUG: SMPP[SMSC-XXX]: Sending PDU:
2010-08-17 17:38:25 [4912] [6] DEBUG: SMPP PDU 0x232f260 dump:
2010-08-17 17:38:25 [4912] [6] DEBUG:   type_name: submit_sm
2010-08-17 17:38:25 [4912] [6] DEBUG:   command_id: 4 = 0x0004
2010-08-17 17:38:25 [4912] [6] DEBUG:   command_status: 0 = 0x
2010-08-17 17:38:25 [4912] [6] DEBUG:   sequence_number: 7 = 0x0007
2010-08-17 17:38:25 [4912] [6] DEBUG:   service_type: NULL
2010-08-17 17:38:25 [4912] [6] DEBUG:   source_addr_ton: 1 = 0x0001
2010-08-17 17:38:25 [4912] [6] DEBUG:   source_addr_npi: 1 = 0x0001
2010-08-17 17:38:25 [4912] [6] DEBUG:   source_addr: 
2010-08-17 17:38:25 [4912] [6] DEBUG:   dest_addr_ton: 1 = 0x0001
2010-08-17 17:38:25 [4912] [6] DEBUG:   dest_addr_npi: 1 = 0x0001
2010-08-17 17:38:25 [4912] [6] DEBUG:   destination_addr: XXX
2010-08-17 17:38:25 [4912] [6] DEBUG:   esm_class: 3 = 0x0003
2010-08-17 17:38:25 [4912] [6] DEBUG:   protocol_id: 0 = 0x
2010-08-17 17:38:25 [4912] [6] DEBUG:   priority_flag: 0 = 0x
2010-08-17 17:38:25 [4912] [6] DEBUG:   schedule_delivery_time: NULL
2010-08-17 17:38:25 [4912] [6] DEBUG:   validity_period: NULL
2010-08-17 17:38:25 [4912] [6] DEBUG:   registered_delivery: 0 = 0x
2010-08-17 17:38:25 [4912] [6] DEBUG:   replace_if_present_flag: 0 =
0x
2010-08-17 17:38:25 [4912] [6] DEBUG:   data_coding: 0 = 0x
2010-08-17 17:38:25 [4912] [6] DEBUG:   sm_default_msg_id: 0 = 0x
2010-08-17 17:38:25 [4912] [6] DEBUG:   sm_length: 6 = 0x0006
2010-08-17 17:38:25 [4912] [6] DEBUG:   short_message: muppet
2010-08-17 17:38:25 [4912] [6] DEBUG: SMPP PDU dump ends.
2010-08-17 17:38:25 [4912] [6] DEBUG: SMPP[SMSC-XXX]: throughput limit
exceeded (1.00,0.05)
2010-08-17 17:38:25 [4912] [6] DEBUG: SMPP[SMSC-XXX]: throughput limit
exceeded

It seems like I have been able to send 5 messages in 5 seconds which 1
msg/sec and I set it to 0.05. I could be missing the obvious.

Regards,


2010/8/18 Nikos Balkanas nbalka...@gmail.com

 Don't worry,

 bearerbox does smsc load balance, and everything else been equal it will
 send through SMSc with mallest queue.


 BR,
 Nikos
 - Original Message - From: brett skinner
 To: Rene Kluwen
 Cc: Users
 Sent: Tuesday, August 17, 2010 8:04 PM
 Subject: Re: Queue Size from status page



 What does the queue size for the bearerbox represent? I thought this was
 the total in the system and would

Re: Queue Size from status page

2010-08-18 Thread brett skinner
Hi All

Please disregard the previous email. I have managed to test for a queue on a
real smsc. Although I did set the throughput to an integer value and not a
float. I don't feel like testing it again (I am still deleting the 20 or so
messages I sent to myself).

Regards,

On Wed, Aug 18, 2010 at 10:07 AM, brett skinner
tatty.dishcl...@gmail.comwrote:

 Hi Nikos

 We already have all of messages load balanced by an upstream application.
 When the messages hit Kannel we are forcing them to go via a certain smsc
 using the smsc flag and the allowed-smsc-id in the config file. We have
 considered rather just letting Kannel do it but upstream application was
 used with another product previously which didn't load balance. We need to
 add Kannel to the existing mix and then phase out the others as our Kannel
 implementation becomes stable. So it is on the roadmap but is not urgent.

 One thing that I may have noticed during my testing is that I can't seem to
 create a queue on a real smsc bind and not the fake one. If I set the
 throughput flag on to 0.05 (msg/sec, according to UG this is float value)
 and I then send some messages and check the status page I do not see a queue
 for that SMSC. If I look in the logs I see messages about the throughput
 being exceeded but it then seems to send anyway. Am I missing something?

 2010-08-17 17:38:16 [4912] [6] DEBUG: SMPP[SMSC-XXX]: throughput
 (0.00,0.05)
 2010-08-17 17:38:17 [4912] [5] INFO: Client connected from 127.0.0.1
 2010-08-17 17:38:17 [4912] [5] DEBUG: Started thread 16
 (gw/bb_boxc.c:function)
 2010-08-17 17:38:17 [4912] [16] DEBUG: Thread 16 (gw/bb_boxc.c:function)
 maps to pid 4912.
 2010-08-17 17:38:17 [4912] [16] DEBUG: Started thread 17
 (gw/bb_boxc.c:boxc_sender)
 2010-08-17 17:38:17 [4912] [17] DEBUG: Thread 17 (gw/bb_boxc.c:boxc_sender)
 maps to pid 4912.
 2010-08-17 17:38:20 [4912] [16] DEBUG: boxc_receiver: sms received
 2010-08-17 17:38:20 [4912] [6] DEBUG: SMPP[SMSC-XXX]: throughput
 (0.00,0.05)
 2010-08-17 17:38:20 [4912] [6] DEBUG: SMPP[SMSC-XXX]: Sending PDU:
 2010-08-17 17:38:20 [4912] [6] DEBUG: SMPP PDU 0x2331e90 dump:
 2010-08-17 17:38:20 [4912] [6] DEBUG:   type_name: submit_sm
 2010-08-17 17:38:20 [4912] [6] DEBUG:   command_id: 4 = 0x0004
 2010-08-17 17:38:20 [4912] [6] DEBUG:   command_status: 0 = 0x
 2010-08-17 17:38:20 [4912] [6] DEBUG:   sequence_number: 3 = 0x0003
 2010-08-17 17:38:20 [4912] [6] DEBUG:   service_type: NULL
 2010-08-17 17:38:20 [4912] [6] DEBUG:   source_addr_ton: 1 = 0x0001
 2010-08-17 17:38:20 [4912] [6] DEBUG:   source_addr_npi: 1 = 0x0001
 2010-08-17 17:38:20 [4912] [6] DEBUG:   source_addr: 
 2010-08-17 17:38:20 [4912] [6] DEBUG:   dest_addr_ton: 1 = 0x0001
 2010-08-17 17:38:20 [4912] [6] DEBUG:   dest_addr_npi: 1 = 0x0001
 2010-08-17 17:38:20 [4912] [6] DEBUG:   destination_addr: XXX
 2010-08-17 17:38:20 [4912] [6] DEBUG:   esm_class: 3 = 0x0003
 2010-08-17 17:38:20 [4912] [6] DEBUG:   protocol_id: 0 = 0x
 2010-08-17 17:38:20 [4912] [6] DEBUG:   priority_flag: 0 = 0x
 2010-08-17 17:38:20 [4912] [6] DEBUG:   schedule_delivery_time: NULL
 2010-08-17 17:38:20 [4912] [6] DEBUG:   validity_period: NULL
 2010-08-17 17:38:20 [4912] [6] DEBUG:   registered_delivery: 0 = 0x
 2010-08-17 17:38:20 [4912] [6] DEBUG:   replace_if_present_flag: 0 =
 0x
 2010-08-17 17:38:20 [4912] [6] DEBUG:   data_coding: 0 = 0x
 2010-08-17 17:38:20 [4912] [6] DEBUG:   sm_default_msg_id: 0 = 0x
 2010-08-17 17:38:20 [4912] [6] DEBUG:   sm_length: 19 = 0x0013
 2010-08-17 17:38:20 [4912] [6] DEBUG:   short_message: foo
 2010-08-17 17:38:20 [4912] [6] DEBUG: SMPP PDU dump ends.
 2010-08-17 17:38:20 [4912] [6] DEBUG: SMPP[SMSC-XXX]: throughput limit
 exceeded (1.00,0.05)
 2010-08-17 17:38:20 [4912] [16] DEBUG: send_msg: sending msg to box:
 127.0.0.1
 2010-08-17 17:38:20 [4912] [6] DEBUG: SMPP[SMSC-XXX]: throughput limit
 exceeded (1.00,0.05)
 2010-08-17 17:38:20 [4912] [6] DEBUG: SMPP[SMSC-XXX]: Got PDU:
 2010-08-17 17:38:20 [4912] [6] DEBUG: SMPP PDU 0x232f260 dump:
 2010-08-17 17:38:20 [4912] [6] DEBUG:   type_name: submit_sm_resp
 2010-08-17 17:38:20 [4912] [6] DEBUG:   command_id: 2147483652 = 0x8004
 2010-08-17 17:38:20 [4912] [6] DEBUG:   command_status: 0 = 0x
 2010-08-17 17:38:20 [4912] [6] DEBUG:   sequence_number: 3 = 0x0003
 2010-08-17 17:38:20 [4912] [6] DEBUG:   message_id: 20081717383293102
 2010-08-17 17:38:20 [4912] [6] DEBUG: SMPP PDU dump ends.
 2010-08-17 17:38:20 [4912] [6] DEBUG: SMPP[SMSC-XXX]: throughput limit
 exceeded (1.00,0.05)
 2010-08-17 17:38:21 [4912] [16] DEBUG: boxc_receiver: sms received
 2010-08-17 17:38:21 [4912] [16] DEBUG: send_msg: sending msg to box:
 127.0.0.1
 2010-08-17 17:38:21 [4912] [6] DEBUG: SMPP[SMSC-XXX]: throughput
 (0.00,0.05)
 2010-08-17 17:38:21 [4912] [6] DEBUG: SMPP[SMSC-XXX]: Sending PDU:
 2010-08-17 17:38:21 [4912] [6] DEBUG: SMPP PDU 0x232f260 dump:
 2010-08-17 17:38:21 [4912

Re: Queue Size from status page

2010-08-17 Thread brett skinner
What does the queue size for the bearerbox represent? I thought this was the
total in the system and would be the summation of the individual SMSCs?

Maybe I should start off with the goal. What we are trying to do is to make
sure that we don't give Kannel too much work to do. So we want to be able to
back off until the queue size (the number of SMSs it still needs to send
on to SMSCs) has fallen to a certain level and then submit again until it
reaches an upper level and then back off again. Which queue size should I be
using for this?

Regards,

On Tue, Aug 17, 2010 at 6:05 PM, Rene Kluwen rene.klu...@chimit.nl wrote:

  I think you guessed the answer yourself already. You have to add the
 queue sizes.



 Queue size in bearerbox is one.  Then you have a queue size in smsbox… and
 one in the smsc driver as well.



 == Rene





 *From:* users-boun...@kannel.org [mailto:users-boun...@kannel.org] *On
 Behalf Of *brett skinner
 *Sent:* Tuesday, 17 August, 2010 17:32
 *To:* Users
 *Subject:* Queue Size from status page



 Hi



 I have looked through the user guide for further explanation of the various
 queue sizes from the status page but I have found none. Please view the
 attached jpg. I have circled two queue sizes in red. I have been using the
 top queue size because I was under the impression that this was the queue
 size for all messages waiting to be sent out by Kannel. The bottom queue
 size appears to be the only one that moves. In order to test this I had to
 attach a fake smsc, set the throughput to 1 and bombarded it with messages.



 Am I correct and there should be a total queue size for Kannel? Or do I
 have to go through each individual SMSC and add the queue sizes together?



 Regards,



Re: Queue Size from status page

2010-08-17 Thread brett skinner
Hi

Thanks Rene. Yes I have been using the XML page. Mostly because I am lazy
and use some 3rd party Java libraries to parse the XML. :)

Regards,

On Tue, Aug 17, 2010 at 7:16 PM, Rene Kluwen rene.klu...@chimit.nl wrote:

  Bearerbox passes messages through from smsbox to the smsc driver,
 handling them in its own queue.



 The queue size you want is probably the one that your messages get stuck
 in. In this case the smsc queue.



 What I advise you is to request the xml status feed from bearerbox. Parse
 that file… and add all the queue sizes together.



 You will end up with the figure you probably want to.



 == Rene





 *From:* brett skinner [mailto:tatty.dishcl...@gmail.com]
 *Sent:* Tuesday, 17 August, 2010 19:05
 *To:* Rene Kluwen
 *Cc:* Users
 *Subject:* Re: Queue Size from status page



 What does the queue size for the bearerbox represent? I thought this was
 the total in the system and would be the summation of the individual SMSCs?



 Maybe I should start off with the goal. What we are trying to do is to make
 sure that we don't give Kannel too much work to do. So we want to be able to
 back off until the queue size (the number of SMSs it still needs to send
 on to SMSCs) has fallen to a certain level and then submit again until it
 reaches an upper level and then back off again. Which queue size should I be
 using for this?



 Regards,



 On Tue, Aug 17, 2010 at 6:05 PM, Rene Kluwen rene.klu...@chimit.nl
 wrote:

 I think you guessed the answer yourself already. You have to add the queue
 sizes.



 Queue size in bearerbox is one.  Then you have a queue size in smsbox… and
 one in the smsc driver as well.



 == Rene





 *From:* users-boun...@kannel.org [mailto:users-boun...@kannel.org] *On
 Behalf Of *brett skinner
 *Sent:* Tuesday, 17 August, 2010 17:32
 *To:* Users
 *Subject:* Queue Size from status page



 Hi



 I have looked through the user guide for further explanation of the various
 queue sizes from the status page but I have found none. Please view the
 attached jpg. I have circled two queue sizes in red. I have been using the
 top queue size because I was under the impression that this was the queue
 size for all messages waiting to be sent out by Kannel. The bottom queue
 size appears to be the only one that moves. In order to test this I had to
 attach a fake smsc, set the throughput to 1 and bombarded it with messages.



 Am I correct and there should be a total queue size for Kannel? Or do I
 have to go through each individual SMSC and add the queue sizes together?



 Regards,





Re: How do i unsubscribe?

2010-08-12 Thread brett skinner
Also you should receive once a month an automated email asking if you still
want to be part of the mailing list. There are hyperlinks in that email to
go to the website where you unsubscribe. It really shouldn't be that hard
unless the system is broken which I doubt. Does this email look familiar

*This is a reminder, sent out once a month, about your
**kannel.org*http://kannel.org/
*
mailing list memberships.  It includes your subscription info and how
to use it to change it or unsubscribe from a list.

You can visit the URLs to change your membership status or
configuration, including unsubscribing, setting digest-style delivery
or disabling delivery altogether (e.g., for a vacation), and so on.

In addition to the URL interfaces, you can also use email to make such
changes.  For more info, send a message to the '-request' address of
the list (for example, **mailman-requ...@kannel.org*mailman-requ...@kannel.org
*) containing just the
word 'help' in the message body, and an email message will be sent to
you with instructions.

If you have questions, problems, comments, etc, send them to
**mailman-ow...@kannel.org* mailman-ow...@kannel.org*.  Thanks!

Passwords for **

List Password // URL
 
**us...@kannel.org* users@kannel.org* 
**http://www.kannel.org/mailman/options/users/http://www.kannel.org/mailman/options/users/tatty.dishcloth%40gmail.com
x*

On Wed, Aug 11, 2010 at 6:37 PM, Alejandro Guerrieri 
alejandro.guerri...@gmail.com wrote:

 Hint: have you tried going to Kannel's site and looking into the mailing
 lists section?

 http://www.kannel.org/lists.shtml



 On Wed, Aug 11, 2010 at 5:55 PM, Steve Rothwell 
 st...@eagleeyetechnology.com wrote:

 Wish I knew been trying for a year now

 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
 * * * * * * * * * * * * * * * * * * *
 This e-mail, the information contained in it and any files or
 attachments transmitted with it are confidential and may be legally
 privileged. They are intended solely for the use of the intended
 recipient(s). Access to this e-mail by anyone else is unauthorised.
 The content of this e-mail and any files or attachments transmitted with
 it may have been changed or replaced without the consent of the author,
 and in circumstances where the content of this e-mail is important you
 should not rely on its integrity without checking it by telephone or
 fax. Eagle Eye SOlutions does not accept any responsibility for any
 breach of confidence which may arise from the use of e-mail as a means
 of communication If you are not the intended recipient, any review,
 dissemination, disclosure, alteration, printing, copying, transmission
 or other use of this e-mail is prohibited and may, in certain
 circumstances, be a criminal offence, as may any action taken or omitted
 to be taken in reliance on it.
 Please also note that any views, opinions or advice contained in this
 e-mail are those of the sending individual, except where the sender
 specifically states them to be the views of Eagle Eye Solutions.
 * * * * * * * * * * * * * * * * * * * * * * * * * * * *  * * * * * * * *
 * * * * * * * * * * * * * * * * * *
 Eagle Eye Solutions Limited
 Registered in the UK Company Registration Number: 04745717
 Registered Address: 3rd Floor, City View Place, 67, Sydenham Road,
 Guildford, Surrey. GU1 3RY
 * * * * * * * * * * * * * * * * * * * * * * * * * * * *  * * * * * * * *
 * * * * * * * * * * * * * * * * * *

 -Original Message-
 From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On
 Behalf Of Marc Cuypers
 Sent: 11 August 2010 15:59
 To: 'Kannel list'
 Subject: How do i unsubscribe?

 Hi,

 How do i unsubscribe from the mailinglist?

 --
 Marc


 __
 This email has been scanned by the MessageLabs Email Security System.
 For more information please visit http://www.messagelabs.com/email
 __

 __
 This email has been scanned by the MessageLabs Email Security System.
 For more information please visit http://www.messagelabs.com/email
 __





Re: Kannel performance benchmarking

2010-08-10 Thread brett skinner
Hi Nikos

Thanks for the extra information. What was the motivation for using MyISAM?
My reading lead me to believe that MyISAM was not that well suited for
interleaved reads and writes due to table locking which is why I opted to
use InnoDB. From what I assumed about how Kannel worked is that
reading/writing to the DLR table would be interleaved. I may be quite badly
mistaken and might perhaps need to switch to MyISAM as a few others have
recommended.

In your opinion what should Kannel be able to handle sustained (assuming
normal business hours)? And what should Kannel be able to burst to? I know
some of these questions are a bit like how long is a piece of string but I
really do value all and any of your feedback.

Regards,

2010/8/10 Nikos Balkanas nbalka...@gmail.com

 Try valgrind in linux.

 BR,
 Nikos
 - Original Message - From: sangprabv sangpr...@gmail.com
 To: Nikos Balkanas nbalka...@gmail.com
 Cc: brett skinner tatty.dishcl...@gmail.com; kannel users 
 users@kannel.org
 Sent: Tuesday, August 10, 2010 3:35 AM

 Subject: Re: Kannel performance benchmarking


 Yeah I understand that. But when the there is no traffic. Kannel doesn't
 release the cached or buffered memory it used.  Do you have any solution?
 What command to list down or trace the memory usage by Kannel? So maybe we
 can investigate which function or module in Kannel is eating the memory.
 Thanks




 sangprabv
 sangpr...@gmail.com
 http://www.petitiononline.com/froyo/


 On Aug 9, 2010, at 11:19 PM, Nikos Balkanas wrote:

  No memory problems. It is reasonable that kannel will use more memory in
 higher traffic, since all queues are in memory, as long as it drops to
 nominal levels once the traffic is gone.

 BR,
 Nikos
 - Original Message - From: sangprabv
 To: brett skinner
 Cc: Nikos Balkanas ; kannel users
 Sent: Monday, August 09, 2010 5:59 PM
 Subject: Re: Kannel performance benchmarking


 Hi Nikos,
 Do you experience memory problem? In my case Kannel is eating the memory
 on high load traffics. I always need to restart the box to get more memory.
 I even give 3 on /proc/sys/vm/drop_caches but still Kannel eat the memory :(






 sangprabv
 sangpr...@gmail.com
 http://www.petitiononline.com/froyo/




 On Aug 9, 2010, at 9:42 PM, brett skinner wrote:


 Hi Nikos

 Out of curiosity can you go into more detail regarding what hardware you
 were running and your setup for MySql? Were you using Innodb or MyIsam. If
 you were using Innodb did you make any other configuration changes to MySql
 to accommodate Innodb.

 From the user guide it is implied that the bottle neck for Kannel is the
 number of messages that the SMSC can accommodate per second. Is this still
 the case?

 Regards,


 2010/8/8 Nikos Balkanas nbalka...@gmail.com

 Hi,

 I have run some benchmarking for a client using fakesmpp. Using the
 default service for MO's I got:

 MO's: 1400 SMS/s
 MT + DLRs (internal): 747 SMS/s
 MT + DLRs (MySql): 434 SMS/s

 BR,
 Nikos
 - Original Message - From: ha...@aeon.pk
 To: kannel users
 Sent: Sunday, August 08, 2010 4:22 PM
 Subject: Kannel performance benchmarking



 Hi,


 I am interested to know about the kannel performance benchmarking,
 especially in terms of speed (msgs/sec), MO or MT. I assume that multiple
 smsboxes does not have any effect over kannel performance, since the
 front-end talking to SMSC is the main bearerbox. What is the max speed that
 could be attained by kannel and/or bearerbox?


 Regards,


 Hamza





Re: Kannel performance benchmarking

2010-08-10 Thread brett skinner
Hi Alex

That is why I have chosen Innodb for the tables we use for the application
that surround Kannel. MyISAM definitely beat Innodb out the box but Innodb
does seem to be better in terms of the issues you have pointed out. The
other thing that I have read is that Innodb is incredibly slow with the
stock standard configuration. I read through the following blog and followed
their advice which increased its performance quite drastically.

http://www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimization-basics/

http://www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimization-basics/If
you have a moment you can give that a read. Or if you have any other good
references please send them a long. I am still rather new to MySql. Thanks
:)

Regards,

On Tue, Aug 10, 2010 at 10:56 AM, Alejandro Guerrieri 
alejandro.guerri...@gmail.com wrote:

 Well, if it weren't for the SELECT COUNT(*) slowness would be my preferred
 option here as well. Despite seeming slower at first (specially on small
 tables) InnoDB performs row-locking on index-based queries, which indeed
 improves things quite a bit on big tables with lots of simultaneous reads
 and writes.

 Regards,

 Alex


 2010/8/10 Nikos Balkanas nbalka...@gmail.com

 Indeed. InnoDB is much slower overall compared to MyIsam. However, it has
 its use for some jobs (archive_logs, hot backups, etc.)

 The figures I gave were sustained rates simulated with a 1-SMS batch.
 Count was sufficient to reach sustainability and reproducibility, yet short
 enough to get results fast.

 When i submitted fakesmpp, I also released similar data from a 64bit
 Solaris 10 server.

 BR,
 Nikos
 - Original Message - From: alejandro.guerri...@gmail.com
 To: brett skinner ; users-boun...@kannel.org ; us...@kannel.users@Kannel.Org
 Sent: Tuesday, August 10, 2010 11:21 AM

 Subject: Re: Kannel performance benchmarking


 Brett,

 The DLR engine uses SELECT COUNT(*) from the admin interface, which is
 painfully slow on InnoDB for moderately big tables.

 While InnoDB would theoretically be the best option, MyIsam performs quite
 better in this case.

 Regards,

 Alex
 BlackBerry de movistar, allν donde estιs estα tu oficin@




 From: brett skinner tatty.dishcl...@gmail.com
 Sender: users-boun...@kannel.org
 Date: Tue, 10 Aug 2010 10:13:54 +0200
 To: Usersusers@kannel.org
 Subject: Re: Kannel performance benchmarking


 Hi Nikos


 Thanks for the extra information. What was the motivation for using
 MyISAM? My reading lead me to believe that MyISAM was not that well suited
 for interleaved reads and writes due to table locking which is why I opted
 to use InnoDB. From what I assumed about how Kannel worked is that
 reading/writing to the DLR table would be interleaved. I may be quite badly
 mistaken and might perhaps need to switch to MyISAM as a few others have
 recommended.


 In your opinion what should Kannel be able to handle sustained (assuming
 normal business hours)? And what should Kannel be able to burst to? I know
 some of these questions are a bit like how long is a piece of string but I
 really do value all and any of your feedback.


 Regards,


 2010/8/10 Nikos Balkanas nbalka...@gmail.com

 Try valgrind in linux.

 BR,
 Nikos
 - Original Message - From: sangprabv sangpr...@gmail.com
 To: Nikos Balkanas nbalka...@gmail.com
 Cc: brett skinner tatty.dishcl...@gmail.com; kannel users 
 users@kannel.org
 Sent: Tuesday, August 10, 2010 3:35 AM

 Subject: Re: Kannel performance benchmarking


 Yeah I understand that. But when the there is no traffic. Kannel doesn't
 release the cached or buffered memory it used.  Do you have any solution?
 What command to list down or trace the memory usage by Kannel? So maybe we
 can investigate which function or module in Kannel is eating the memory.
 Thanks




 sangprabv
 sangpr...@gmail.com
 http://www.petitiononline.com/froyo/


 On Aug 9, 2010, at 11:19 PM, Nikos Balkanas wrote:


 No memory problems. It is reasonable that kannel will use more memory in
 higher traffic, since all queues are in memory, as long as it drops to
 nominal levels once the traffic is gone.

 BR,
 Nikos
 - Original Message - From: sangprabv
 To: brett skinner
 Cc: Nikos Balkanas ; kannel users
 Sent: Monday, August 09, 2010 5:59 PM
 Subject: Re: Kannel performance benchmarking


 Hi Nikos,
 Do you experience memory problem? In my case Kannel is eating the memory
 on high load traffics. I always need to restart the box to get more memory.
 I even give 3 on /proc/sys/vm/drop_caches but still Kannel eat the memory :(






 sangprabv
 sangpr...@gmail.com
 http://www.petitiononline.com/froyo/




 On Aug 9, 2010, at 9:42 PM, brett skinner wrote:


 Hi Nikos

 Out of curiosity can you go into more detail regarding what hardware you
 were running and your setup for MySql? Were you using Innodb or MyIsam. If
 you were using Innodb did you make any other configuration changes to MySql
 to accommodate Innodb.

 From

Re: Kannel performance benchmarking

2010-08-10 Thread brett skinner
Thanks for your feedback.

Guess it is the age old tao of computer science. Space vs Time, always space
vs time. :)

Regards,

On Tue, Aug 10, 2010 at 11:52 AM, Alejandro Guerrieri 
alejandro.guerri...@gmail.com wrote:

 Oh yes, I read that blog quite frequently :) There's a lot of stuff to say
 about optimizing InnoDB, but it's definitely off-topic here and wouldn't fit
 on a single email of course.

 We've gone thru a series of optimization cycles on our platform and, with
 respect to Kannel, ended up using MyIsam for DLR's. We don't have any
 locking issues, the only detail is we need to be careful when expiring old
 entries to do it in small batches and not on peak hours.

 For the rest of our applications, except for small and mostly read-only
 tables, we use InnoDB and while seems slower when you do a couple of
 requests, it's a _lot_ faster if you are under heavy traffic because of the
 row locking instead of table locking.

 Anyway, there's no a one-size-fits-all solution and if you really need to
 sustain heavy traffic I'd recommend you do a lot of profiling and find the
 bottlenecks either on the DB and the rest of your platform.

 Regards,

 Alex

 On Tue, Aug 10, 2010 at 11:15 AM, brett skinner tatty.dishcl...@gmail.com
  wrote:

 Hi Alex

 That is why I have chosen Innodb for the tables we use for the application
 that surround Kannel. MyISAM definitely beat Innodb out the box but Innodb
 does seem to be better in terms of the issues you have pointed out. The
 other thing that I have read is that Innodb is incredibly slow with the
 stock standard configuration. I read through the following blog and followed
 their advice which increased its performance quite drastically.


 http://www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimization-basics/

 http://www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimization-basics/If
 you have a moment you can give that a read. Or if you have any other good
 references please send them a long. I am still rather new to MySql. Thanks
 :)

 Regards,


 On Tue, Aug 10, 2010 at 10:56 AM, Alejandro Guerrieri 
 alejandro.guerri...@gmail.com wrote:

 Well, if it weren't for the SELECT COUNT(*) slowness would be my
 preferred option here as well. Despite seeming slower at first (specially
 on small tables) InnoDB performs row-locking on index-based queries, which
 indeed improves things quite a bit on big tables with lots of simultaneous
 reads and writes.

 Regards,

 Alex


 2010/8/10 Nikos Balkanas nbalka...@gmail.com

 Indeed. InnoDB is much slower overall compared to MyIsam. However, it
 has its use for some jobs (archive_logs, hot backups, etc.)

 The figures I gave were sustained rates simulated with a 1-SMS
 batch. Count was sufficient to reach sustainability and reproducibility, 
 yet
 short enough to get results fast.

 When i submitted fakesmpp, I also released similar data from a 64bit
 Solaris 10 server.

 BR,
 Nikos
 - Original Message - From: alejandro.guerri...@gmail.com
 To: brett skinner ; users-boun...@kannel.org ; 
 us...@kannel.users@Kannel.Org
 Sent: Tuesday, August 10, 2010 11:21 AM

 Subject: Re: Kannel performance benchmarking


 Brett,

 The DLR engine uses SELECT COUNT(*) from the admin interface, which is
 painfully slow on InnoDB for moderately big tables.

 While InnoDB would theoretically be the best option, MyIsam performs
 quite better in this case.

 Regards,

 Alex
 BlackBerry de movistar, allν donde estιs estα tu oficin@




 From: brett skinner tatty.dishcl...@gmail.com
 Sender: users-boun...@kannel.org
 Date: Tue, 10 Aug 2010 10:13:54 +0200
 To: Usersusers@kannel.org
 Subject: Re: Kannel performance benchmarking


 Hi Nikos


 Thanks for the extra information. What was the motivation for using
 MyISAM? My reading lead me to believe that MyISAM was not that well suited
 for interleaved reads and writes due to table locking which is why I opted
 to use InnoDB. From what I assumed about how Kannel worked is that
 reading/writing to the DLR table would be interleaved. I may be quite badly
 mistaken and might perhaps need to switch to MyISAM as a few others have
 recommended.


 In your opinion what should Kannel be able to handle sustained (assuming
 normal business hours)? And what should Kannel be able to burst to? I know
 some of these questions are a bit like how long is a piece of string but I
 really do value all and any of your feedback.


 Regards,


 2010/8/10 Nikos Balkanas nbalka...@gmail.com

 Try valgrind in linux.

 BR,
 Nikos
 - Original Message - From: sangprabv sangpr...@gmail.com
 To: Nikos Balkanas nbalka...@gmail.com
 Cc: brett skinner tatty.dishcl...@gmail.com; kannel users 
 users@kannel.org
 Sent: Tuesday, August 10, 2010 3:35 AM

 Subject: Re: Kannel performance benchmarking


 Yeah I understand that. But when the there is no traffic. Kannel doesn't
 release the cached or buffered memory it used.  Do you have any solution?
 What command to list down or trace

How does Kannel handle DLR for concatenated sms

2010-08-10 Thread brett skinner
Hi

I have sent through a couple of long messages. Looking through the logs I
can see multiple messages submitted to the SMSC via submit_sm PDUs. However
these is only one deliver_sm coming back from the SMSC (at least according
to the logs). Is the number of deliver_sm PDUs implementation specific and
differ between SMSCs? Is this expected behavior? Or has Kannel done some
behind the scenes magic because I have the concatenated flag set to true?

Regards,


Large and growing number of queued DLR

2010-08-06 Thread brett skinner
Hi

We have been sending sms successfully and receiving the DLRs. As far as I
can tell we have been processing them correctly and all the logs in the web
application point to no failures. I had a look at the logs for smsbox and
there were a couple of URLs that it could not fetch but those have already
been fixed and read in from the log file. However the DLR storage number is
still growing and there have been no further errors in the logs.

Is there a rate at which Kannel tries to post the DLR to the specified URL?
Is it perhaps because Kannel may have been restarted and now it has no
knowledge of those DLR because the information that it needs to do the look
up is now gone?

Regards


Fwd: Large and growing number of queued DLR

2010-08-06 Thread brett skinner
Hi

Sorry forgot to add that I am using mysql storage

-- Forwarded message --
From: brett skinner tatty.dishcl...@gmail.com
Date: Fri, Aug 6, 2010 at 4:06 PM
Subject: Large and growing number of queued DLR
To: Users users@kannel.org


Hi

We have been sending sms successfully and receiving the DLRs. As far as I
can tell we have been processing them correctly and all the logs in the web
application point to no failures. I had a look at the logs for smsbox and
there were a couple of URLs that it could not fetch but those have already
been fixed and read in from the log file. However the DLR storage number is
still growing and there have been no further errors in the logs.

Is there a rate at which Kannel tries to post the DLR to the specified URL?
Is it perhaps because Kannel may have been restarted and now it has no
knowledge of those DLR because the information that it needs to do the look
up is now gone?

Regards


SendSMS - HTTP 400 response from Java application but works through Lynx

2010-07-30 Thread brett skinner
Hi All

Sorry to ask here but I am not sure where I should be looking for answer. I
have message that I am submitting to an SMSC, it is WAP push message SI SMS.
We are not going to handle any WAP, we are just sending it from our system.
Someone else has handled that part. I have created a java application to
submit to kannel via HTTP. If I run my application I get a HTTP 400 response
wrapped in an IOException when I try to open the stream. I looked through
the bearerbox.log and smsbox.log and there is nothing there. The following
is the only thing that I could see.

2010-07-30 16:17:59 [14867] [2] DEBUG: HTTP: Creating HTTPClient for
`127.0.0.1'.
2010-07-30 16:17:59 [14867] [2] DEBUG: HTTP: Created HTTPClient area
0xddfc90.
2010-07-30 16:17:59 [14867] [3] DEBUG: sql: SELECT count(*) FROM
delivery_receipts;
2010-07-30 16:17:59 [14867] [3] DEBUG: HTTP: Resetting HTTPClient for
`127.0.0.1'.
2010-07-30 16:18:03 [14867] [1] DEBUG: HTTP: Destroying HTTPClient area
0xddfc90.
2010-07-30 16:18:03 [14867] [1] DEBUG: HTTP: Destroying HTTPClient for
`127.0.0.1'.

I dumped the URL to the console and used lynx and then Kannel accepted and
forwarded the sms and I got a Wap Push SI on my mobile.

This is the URL that is generated and does not work in java application but
does work through lynx

http://localhost:1/cgi-bin/sendsms?username=password=to=%2B123123123from=%2B123123456smsc=Kannel_TTTtext=%05%06%01%AE%02%05%6A%00%45%C6%0C%03http://www.google.com%00%07%01%03WapPush%00%01%01udh=%06%05%04%0B%84%23%F0mclass=1validity=240dlr-mask=23dlr-url=http%3A%2F%2Flocalhost%3A8080%2Fwebapp%2Freceipt%3Fid%3D740944995%26pid%3D11%26rid%3D12%26nid%3D297%26sid%3D%25i%26origin%3D123456789%26destination%3D78945631%26status%3D%25d%26delivery_report%3D%25A

Does anyone have any clue where to start scratching to try figure out the
problem? I haven't submitted anything more because looking through the logs
there is nothing. But shout if you would like me to add something.

Thanks in advance.


Fwd: SendSMS - HTTP 400 response from Java application but works through Lynx

2010-07-30 Thread brett skinner
Sorry all

Please disregard the previous mail. I was being an idiot. The text parameter
was not URL encoded. I think lynx will take care of that for you.

Apologies. It has been a long week!

Regards,

-- Forwarded message --
From: brett skinner tatty.dishcl...@gmail.com
Date: Fri, Jul 30, 2010 at 4:40 PM
Subject: SendSMS - HTTP 400 response from Java application but works through
Lynx
To: Users users@kannel.org


Hi All

Sorry to ask here but I am not sure where I should be looking for answer. I
have message that I am submitting to an SMSC, it is WAP push message SI SMS.
We are not going to handle any WAP, we are just sending it from our system.
Someone else has handled that part. I have created a java application to
submit to kannel via HTTP. If I run my application I get a HTTP 400 response
wrapped in an IOException when I try to open the stream. I looked through
the bearerbox.log and smsbox.log and there is nothing there. The following
is the only thing that I could see.

2010-07-30 16:17:59 [14867] [2] DEBUG: HTTP: Creating HTTPClient for
`127.0.0.1'.
2010-07-30 16:17:59 [14867] [2] DEBUG: HTTP: Created HTTPClient area
0xddfc90.
2010-07-30 16:17:59 [14867] [3] DEBUG: sql: SELECT count(*) FROM
delivery_receipts;
2010-07-30 16:17:59 [14867] [3] DEBUG: HTTP: Resetting HTTPClient for
`127.0.0.1'.
2010-07-30 16:18:03 [14867] [1] DEBUG: HTTP: Destroying HTTPClient area
0xddfc90.
2010-07-30 16:18:03 [14867] [1] DEBUG: HTTP: Destroying HTTPClient for
`127.0.0.1'.

I dumped the URL to the console and used lynx and then Kannel accepted and
forwarded the sms and I got a Wap Push SI on my mobile.

This is the URL that is generated and does not work in java application but
does work through lynx

http://localhost:1/cgi-bin/sendsms?username=password=to=%2B123123123from=%2B123123456smsc=Kannel_TTTtext=%05%06%01%AE%02%05%6A%00%45%C6%0C%03http://www.google.com%00%07%01%03WapPush%00%01%01udh=%06%05%04%0B%84%23%F0mclass=1validity=240dlr-mask=23dlr-url=http%3A%2F%2Flocalhost%3A8080%2Fwebapp%2Freceipt%3Fid%3D740944995%26pid%3D11%26rid%3D12%26nid%3D297%26sid%3D%25i%26origin%3D123456789%26destination%3D78945631%26status%3D%25d%26delivery_report%3D%25A

Does anyone have any clue where to start scratching to try figure out the
problem? I haven't submitted anything more because looking through the logs
there is nothing. But shout if you would like me to add something.

Thanks in advance.


Re: Cannot upgrade Kannel

2010-07-27 Thread brett skinner
Hi

I would prefer to not have to compile but to get the package. Is what I have
done look correct?

On Tue, Jul 27, 2010 at 1:17 PM, seikath seik...@gmail.com wrote:

 its better to compile the cvs version for sure.

 http://kannel.org/download.shtml



 On 07/27/2010 02:11 PM, brett skinner wrote:
  Hi
 
  This might not be the best place to ask this question. If it isn't then
  please just let me know. During testing I used Ubuntu 10.4 (Lucid Lynx).
  Our production servers are running Ubuntu Server 8.04 (Hardy Heron). It
  appears that the version of Kannel that comes with that version of
  Ubuntu is 1.4.1. I am trying to upgrade just Kannel to 1.4.3.
 
  Firstly will Kannel 1.4.3 work on Ubuntu Server 8.04?
  Secondly if it will how can I upgrade to the correct version?
 
  On the Kannel website it said that I should add the following if I
  wanted the stable release (called woody?)
 
  # /For Woody/stable/
  deb http://www.litux.org/debian woody/
 
  I only want the binaries not the source so i left deb-src out. Now when
  i do an apt-get update there is this failure:
  *W: Failed to fetch http://www.litux.org/debian/woody/Packages.gz  404
  Not Found*
  *
  *
  Have I done something incorrectly here?
 
  I then looked in the Userguide which suggested all I had to was get hold
  of the .deb file. I cannot find a download link on the Kannel downloads
  page for kannel-1.4.3.deb. I can see for 1.4.1.
 
  I apologize if I am missing the obvious and have wasted your time.
 
  Regards,




Re: Cannot upgrade Kannel

2010-07-27 Thread brett skinner
Hi Seikath

I know that Kannel is in Lucid, but I am on Hardy Heron. Are you suggesting
to upgrade to Lucid or is there a way that I can get apt-get to install
kannel from the Lucid sources list?

Regards,

On Tue, Jul 27, 2010 at 1:25 PM, seikath seik...@gmail.com wrote:

 http://packages.ubuntu.com/lucid/net/

 kannel (1.4.3-0ubuntu2) [universe]
WAP and SMS gateway
 kannel-docs (1.4.3-0ubuntu2) [universe]
WAP and SMS gateway documentation
 kannel-extras (1.4.3-0ubuntu2) [universe]
WAP and SMS gateway extras
 kannel-sqlbox (0.7.2-2) [universe]


 On 07/27/2010 02:21 PM, brett skinner wrote:
  Hi
 
  I would prefer to not have to compile but to get the package. Is what I
  have done look correct?
 
  On Tue, Jul 27, 2010 at 1:17 PM, seikath seik...@gmail.com
  mailto:seik...@gmail.com wrote:
 
  its better to compile the cvs version for sure.
 
  http://kannel.org/download.shtml
 
 
 
  On 07/27/2010 02:11 PM, brett skinner wrote:
   Hi
  
   This might not be the best place to ask this question. If it isn't
  then
   please just let me know. During testing I used Ubuntu 10.4 (Lucid
  Lynx).
   Our production servers are running Ubuntu Server 8.04 (Hardy
  Heron). It
   appears that the version of Kannel that comes with that version of
   Ubuntu is 1.4.1. I am trying to upgrade just Kannel to 1.4.3.
  
   Firstly will Kannel 1.4.3 work on Ubuntu Server 8.04?
   Secondly if it will how can I upgrade to the correct version?
  
   On the Kannel website it said that I should add the following if I
   wanted the stable release (called woody?)
  
   # /For Woody/stable/
   deb http://www.litux.org/debian woody/
  
   I only want the binaries not the source so i left deb-src out. Now
  when
   i do an apt-get update there is this failure:
   *W: Failed to fetch http://www.litux.org/debian/woody/Packages.gz 404
   Not Found*
   *
   *
   Have I done something incorrectly here?
  
   I then looked in the Userguide which suggested all I had to was
  get hold
   of the .deb file. I cannot find a download link on the Kannel
  downloads
   page for kannel-1.4.3.deb. I can see for 1.4.1.
  
   I apologize if I am missing the obvious and have wasted your time.
  
   Regards,
 
 




Re: Sending SMS from HTTP

2010-07-27 Thread brett skinner
Hi

Can you also send the URL that you used and the logs from the bearerbox and
the smsbox

On Tue, Jul 27, 2010 at 1:01 PM, li...@eliud.co.cc wrote:

 Hi,

 Am new to this kannel business, was able to configure kannel to receive
 sms but am having the following errors when sending out from a http call

 2010-07-27 14:11:31 [5656] [16] DEBUG: boxc_receiver: sms received
 2010-07-27 14:11:31 [5656] [16] WARNING: Cannot find SMSCConn for message
 to 25472580770, rejected.
 2010-07-27 14:11:31 [5656] [16] WARNING: Message rejected by bearerbox, no
 router!

 group = smsbox
 bearerbox-host = localhost
 sendsms-port = 13003
 sendsms-chars = 0123456789 +-
 global-sender = 254717848xxx
 log-level = 0
 log-file = /var/log/kannel/smsbox.log
 access-log = /var/log/kannel/smsbox-access.log

 Regards,
 Eliud





Re: Sending SMS from HTTP

2010-07-27 Thread brett skinner
Hi

Where is the configuration for your smsc? I see you don't have something
like

group = smsc
smsc = smpp
.
.
.
etc etc

On Tue, Jul 27, 2010 at 1:15 PM, li...@eliud.co.cc wrote:

 Hi Brett,

 Find below the url and the logs

 url =

 http://localhost:13003/cgi-bin/sendsms?username=adminpassword=kingsxxxto=25472580xxxtext=test
 sms 1

 bearerbox
 --
 2010-07-27 14:10:34 [5656] [6] DEBUG: AT2[huawei_e160]: -- OK
 2010-07-27 14:10:34 [5656] [6] DEBUG: AT2[huawei_e160]: -- AT+CPMS=sm^M
 2010-07-27 14:10:34 [5656] [6] DEBUG: AT2[huawei_e160]: -- +CPMS:
 0,20,0,20,0,20
 2010-07-27 14:10:34 [5656] [6] DEBUG: AT2[huawei_e160]: -- OK
 2010-07-27 14:10:34 [5656] [6] INFO: AT2[huawei_e160]: AT SMSC
 successfully opened.
 2010-07-27 14:10:34 [5656] [6] DEBUG: AT2[huawei_e160]: --
 ^BOOT:34326076,0,0,0,75
 2010-07-27 14:10:36 [5656] [6] DEBUG: AT2[huawei_e160]: -- AT+CPMS?^M
 2010-07-27 14:10:36 [5656] [6] DEBUG: AT2[huawei_e160]: -- +CPMS:
 SM,0,20,SM,0,20,SM,0,20
 2010-07-27 14:10:36 [5656] [6] DEBUG: AT2[huawei_e160]: -- OK
 2010-07-27 14:11:04 [5656] [6] DEBUG: AT2[huawei_e160]: --
 ^BOOT:34326076,0,0,0,75
 2010-07-27 14:11:31 [5656] [16] DEBUG: boxc_receiver: sms received
 2010-07-27 14:11:31 [5656] [16] WARNING: Cannot find SMSCConn for message
 to 25472580770, rejected.
 2010-07-27 14:11:31 [5656] [16] WARNING: Message rejected by bearerbox, no
 router!
 2010-07-27 14:11:31 [5656] [16] DEBUG: send_msg: sending msg to box:
 127.0.0.1
 2010-07-27 14:11:34 [5656] [6] DEBUG: AT2[huawei_e160]: --
 ^BOOT:34326076,0,0,0,75
 2010-07-27 14:11:38 [5656] [6] DEBUG: AT2[huawei_e160]: -- AT+CPMS?^M
 2010-07-27 14:11:38 [5656] [6] DEBUG: AT2[huawei_e160]: -- +CPMS:
 SM,0,20,SM,0,20,SM,0,20
 2010-07-27 14:11:38 [5656] [6] DEBUG: AT2[huawei_e160]: -- OK
 2010-07-27 14:12:04 [5656] [6] DEBUG: AT2[huawei_e160]: --
 ^BOOT:34326076,0,0,0,75
 2010-07-27 14:12:34 [5656] [6] DEBUG: AT2[huawei_e160]: --
 ^BOOT:34326076,0,0,0,75
 2010-07-27 14:12:40 [5656] [6] DEBUG: AT2[huawei_e160]: -- AT+CPMS?^M
 2010-07-27 14:12:40 [5656] [6] DEBUG: AT2[huawei_e160]: -- +CPMS:
 SM,0,20,SM,0,20,SM,0,20
 2010-07-27 14:12:40 [5656] [6] DEBUG: AT2[huawei_e160]: -- OK
 2010-07-27 14:13:04 [5656] [6] DEBUG: AT2[huawei_e160]: --
 ^BOOT:34326076,0,0,0,75
 2010-07-27 14:13:34 [5656] [6] DEBUG: AT2[huawei_e160]: --
 ^BOOT:34326076,0,0,0,75
 2010-07-27 14:13:42 [5656] [6] DEBUG: AT2[huawei_e160]: -- AT+CPMS?^M
 2010-07-27 14:13:42 [5656] [6] DEBUG: AT2[huawei_e160]: -- +CPMS:
 SM,0,20,SM,0,20,SM,0,20
 2010-07-27 14:13:42 [5656] [6] DEBUG: AT2[huawei_e160]: -- OK

 smsbox log
 ---
 2010-07-27 14:54:08 [5677] [3] INFO: smsbox: Got HTTP request
 /cgi-bin/sendsms from 127.0.0.1
 2010-07-27 14:54:08 [5677] [3] INFO: sendsms used by admin
 2010-07-27 14:54:08 [5677] [3] INFO: sendsms sender:admin:254717848xxx
 (127.0.0.1) to:25472580xxx msg:Thanks for reppin. Kings SMS.
 2010-07-27 14:54:08 [5677] [3] DEBUG: Stored UUID
 b2114636-c178-433f-891d-4f76a2c568e3
 2010-07-27 14:54:08 [5677] [3] DEBUG: message length 29, sending 1
 messages
 2010-07-27 14:54:08 [5677] [3] DEBUG: Status: 202 Answer: Sent.
 2010-07-27 14:54:08 [5677] [3] DEBUG: Delayed reply - wait for bearerbox
 2010-07-27 14:54:08 [5677] [0] DEBUG: Got ACK (1) of
 b2114636-c178-433f-891d-4f76a2c568e3
 2010-07-27 14:54:08 [5677] [0] DEBUG: HTTP: Resetting HTTPClient for
 `127.0.0.1'.
 2010-07-27 14:54:08 [5677] [1] DEBUG: HTTP: Destroying HTTPClient area
 0x17e4dc0.
 2010-07-27 14:54:08 [5677] [1] DEBUG: HTTP: Destroying HTTPClient for
 `127.0.0.1'.

 Regards,
 Eliud

 On Tue, 27 Jul 2010 13:49:06 +0200, brett skinner
 tatty.dishcl...@gmail.com wrote:
  Hi
 
  Can you also send the URL that you were using.
 
  On Tue, Jul 27, 2010 at 1:01 PM, li...@eliud.co.cc wrote:
 
  Hi,
 
  Am new to this kannel business, was able to configure kannel to receive
  sms but am having the following errors when sending out from a http
 call
 
  2010-07-27 14:11:31 [5656] [16] DEBUG: boxc_receiver: sms received
  2010-07-27 14:11:31 [5656] [16] WARNING: Cannot find SMSCConn for
 message
  to 25472580770, rejected.
  2010-07-27 14:11:31 [5656] [16] WARNING: Message rejected by bearerbox,
  no
  router!
 
  group = smsbox
  bearerbox-host = localhost
  sendsms-port = 13003
  sendsms-chars = 0123456789 +-
  global-sender = 254717848xxx
  log-level = 0
  log-file = /var/log/kannel/smsbox.log
  access-log = /var/log/kannel/smsbox-access.log
 
  Regards,
  Eliud
 
 
 




Re: dlr table always empty

2010-07-23 Thread brett skinner
Sorry I forgot that second point which Alex made. If you want to do any sort
of extra processing or storage then you need to create the other end of the
dlr-url parameter. Use something like java servlet or a php script. Look in
the userguide to see how to get those values again.

Regards,

On Fri, Jul 23, 2010 at 2:20 PM, Alejandro Guerrieri 
alejandro.guerri...@gmail.com wrote:

 You're mixing things.

 The dlr table is used internally by Kannel to keep track of the _pending_
 dlrs. As soon as they're received, the dlrs are deleted from the table. You
 need to create a simple web application to store it, and point dlr-url to
 it.

 Regards,

 Alex

 On Fri, Jul 23, 2010 at 1:55 PM, Imran Aghayev 
 imran.agha...@hotmail.co.uk wrote:

  I have sqlbox running.

 I have dlr table which is always empty.

 How to request delivery report and how-to have that table filled wih
 delivery report data ?

 Imran


 --
 Get a free e-mail account with Hotmail. Sign-up 
 now.http://clk.atdmt.com/UKM/go/19780/direct/01/





SMS Push reply codes

2010-07-22 Thread brett skinner
Hi

Is table 6-15 in the user guide an exhaustive list of the possible reply
codes from Kannel? In essence either 0 or 3. Sent or enqueued. I recall
seeing other messages such as Authorization failed for sendsms but there
was no reply code in front. Is it then safe to assume that any response from
Kannel that is not 0 or 3 is a failure? I am aware that there could be other
HTTP response codes but those are due to transport level errors etc which I
can deal with. I am more concerned about getting a complete list of possible
outcomes from Kannel's perspective.

Regards,


What does Kannel do when an error occurs while requesting URLs

2010-07-16 Thread brett skinner
Hi

I search through the documentation but I couldn't find an answer to my
question. It might be there I just could not find. I would like to know what
Kannel does when either:

1. Trying to do the HTTP get request for the DLR if you are using the
dlr-mask and the dlr-url when sending an SMS via the http interface.
2. Trying to do a HTTP request to post SMSC originated SMS (I am using the
get-url parameter in the sms-service group).

And the one of the following situations occur.

1. The URL is unreachable (webserver has not yet started)
2. The http response code is something other than 2xx. (Something happends
during processing and perhaps the response code is 500)

Regards,


Re: Mysql Timestamp issue

2010-07-15 Thread brett skinner
Hi

Are you using SMPP? If so then the ts field although it would seem is a
timestamp but it acutally maps to the unique ID provided by the SMSC for
that message. I asked this question a little while ago and that was the
answer I got and it seems to be correct from my testing. The group can
correct me if I am wrong.

Regards,

On Thu, Jul 15, 2010 at 10:43 AM, N'Golé Christian 
ing_christian2...@yahoo.fr wrote:

 Heemmo Group,

 I still have problem with mysql ts value. when kannel gets dlrs from my
 smsc the field ts has the same value.

 2010-07-14 06:32:42 [31512] [10] DEBUG: DLR[mysql]: Looking for DLR
 smsc=vodoosms, ts=10, dst=22507484497, type=1
 2010-07-14 06:32:42 [31512] [10] DEBUG: sql: SELECT mask, service, url,
 source, destination, boxc FROM kannel_dlrs WHERE smsc='vodoosms' AND
 ts='10';

 I contacted my smsc but he told me that this is kannel issue.

 Please i need help.





Re: Mysql Timestamp issue

2010-07-15 Thread brett skinner
Firstly that table is for use by Kannel as a storage so that you do not lose
any DLR if the box goes down.

If you want more information for DLRs when sending sms you need to append
the dlr-url parameter to the end of the URL that you are using. Also make
sure that you are using the dlr-mask parameter. In that URL you can specify
what information you would like posted back.

Please see the user guide for details.

Regards,

On Thu, Jul 15, 2010 at 11:11 AM, N'Golé Christian 
ing_christian2...@yahoo.fr wrote:

 yes i use kannel as smpp client. So please what must i do to solve this
 issue ?

 *Christian N'GOLE*



 http://www.smseco.com

   General Manager WEB PLURIEL


 Abidjan - Cocody

 *Adresse* : 27 BP 1222 Abj 27

 *Email* : supp...@smseco.com

 *Tel* : +225 22 42 89 62

 *Cel* : +225 07 74 97 97

 *Site Web* : www.smseco.com


 --- En date de : *Jeu 15.7.10, brett skinner tatty.dishcl...@gmail.com*a 
 écrit :


 De: brett skinner tatty.dishcl...@gmail.com
 Objet: Re: Mysql Timestamp issue
 À: N'Golé Christian ing_christian2...@yahoo.fr
 Cc: users@kannel.org
 Date: Jeudi 15 juillet 2010, 11h02


 Hi

 Are you using SMPP? If so then the ts field although it would seem is a
 timestamp but it acutally maps to the unique ID provided by the SMSC for
 that message. I asked this question a little while ago and that was the
 answer I got and it seems to be correct from my testing. The group can
 correct me if I am wrong.

 Regards,

 On Thu, Jul 15, 2010 at 10:43 AM, N'Golé Christian 
 ing_christian2...@yahoo.frhttp://mc/compose?to=ing_christian2...@yahoo.fr
  wrote:

 Heemmo Group,

 I still have problem with mysql ts value. when kannel gets dlrs from my
 smsc the field ts has the same value.

 2010-07-14 06:32:42 [31512] [10] DEBUG: DLR[mysql]: Looking for DLR
 smsc=vodoosms, ts=10, dst=22507484497, type=1
 2010-07-14 06:32:42 [31512] [10] DEBUG: sql: SELECT mask, service, url,
 source, destination, boxc FROM kannel_dlrs WHERE smsc='vodoosms' AND
 ts='10';

 I contacted my smsc but he told me that this is kannel issue.

 Please i need help.







Re: Mysql Timestamp issue

2010-07-15 Thread brett skinner
If *ALL *the sm_submit_resp PDUs are coming back from the SMSC with the
exact same ts value then I would suggest that SMSC is at fault. The ts value
works perfectly for me and the SMSC I use. Perhaps I am wrong and the group
can correct me. You sent us 2 lines from the log so I cannot see if
*EVERY *message
you send to your SMSC is getting the same SMSC ID of 10. Can you test with a
couple of sends and attach the logs.

On Thu, Jul 15, 2010 at 11:31 AM, N'Golé Christian 
ing_christian2...@yahoo.fr wrote:

 but when kannel look for dlrsuch this :
 DEBUG: sql: SELECT mask, service, url, source, destination, boxc FROM
 kannel_dlrs WHERE smsc='voodosms' AND ts='10';

 It could get wrong value because all dlrs from this smsc have the same ts
 value. So my script gets wrong parameters so. You see or i'm wrong ?


 *Christian N'GOLE*



 http://www.smseco.com

   General Manager WEB PLURIEL


 Abidjan - Cocody

 *Adresse* : 27 BP 1222 Abj 27

 *Email* : supp...@smseco.com

 *Tel* : +225 22 42 89 62

 *Cel* : +225 07 74 97 97

 *Site Web* : www.smseco.com


 --- En date de : *Jeu 15.7.10, brett skinner tatty.dishcl...@gmail.com*a 
 écrit :


 De: brett skinner tatty.dishcl...@gmail.com
 Objet: Re: Mysql Timestamp issue
 À: N'Golé Christian ing_christian2...@yahoo.fr
 Date: Jeudi 15 juillet 2010, 11h19


 No it is for Kannel use only. If you want to do extra processing on DLR
 then do it through script that handles the HTTP post to the specified URL.

 On Thu, Jul 15, 2010 at 11:18 AM, N'Golé Christian 
 ing_christian2...@yahoo.frhttp://mc/compose?to=ing_christian2...@yahoo.fr
  wrote:

 yes i know that ! so if i understand this value is not important for dlrs
 managing ?


 *Christian N'GOLE*



 http://www.smseco.com

   General Manager WEB PLURIEL


 Abidjan - Cocody

 *Adresse* : 27 BP 1222 Abj 27

 *Email* : supp...@smseco.com http://mc/compose?to=supp...@smseco.com

 *Tel* : +225 22 42 89 62

 *Cel* : +225 07 74 97 97

 *Site Web* : www.smseco.com


 --- En date de : *Jeu 15.7.10, brett skinner 
 tatty.dishcl...@gmail.comhttp://mc/compose?to=tatty.dishcl...@gmail.com
 * a écrit :


 De: brett skinner 
 tatty.dishcl...@gmail.comhttp://mc/compose?to=tatty.dishcl...@gmail.com
 
 Objet: Re: Mysql Timestamp issue
 À: N'Golé Christian 
 ing_christian2...@yahoo.frhttp://mc/compose?to=ing_christian2...@yahoo.fr
 
 Cc: users@kannel.org http://mc/compose?to=us...@kannel.org
 Date: Jeudi 15 juillet 2010, 11h15


 Firstly that table is for use by Kannel as a storage so that you do not
 lose any DLR if the box goes down.

 If you want more information for DLRs when sending sms you need to append
 the dlr-url parameter to the end of the URL that you are using. Also make
 sure that you are using the dlr-mask parameter. In that URL you can specify
 what information you would like posted back.

 Please see the user guide for details.

 Regards,

 On Thu, Jul 15, 2010 at 11:11 AM, N'Golé Christian 
 ing_christian2...@yahoo.frhttp://mc/compose?to=ing_christian2...@yahoo.fr
  wrote:

 yes i use kannel as smpp client. So please what must i do to solve this
 issue ?

 *Christian N'GOLE*



 http://www.smseco.com

   General Manager WEB PLURIEL


 Abidjan - Cocody

 *Adresse* : 27 BP 1222 Abj 27

 *Email* : supp...@smseco.com http://mc/compose?to=supp...@smseco.com

 *Tel* : +225 22 42 89 62

 *Cel* : +225 07 74 97 97

 *Site Web* : www.smseco.com


 --- En date de : *Jeu 15.7.10, brett skinner 
 tatty.dishcl...@gmail.comhttp://mc/compose?to=tatty.dishcl...@gmail.com
 * a écrit :


 De: brett skinner 
 tatty.dishcl...@gmail.comhttp://mc/compose?to=tatty.dishcl...@gmail.com
 
 Objet: Re: Mysql Timestamp issue
 À: N'Golé Christian 
 ing_christian2...@yahoo.frhttp://mc/compose?to=ing_christian2...@yahoo.fr
 
 Cc: users@kannel.org http://mc/compose?to=us...@kannel.org
 Date: Jeudi 15 juillet 2010, 11h02


 Hi

 Are you using SMPP? If so then the ts field although it would seem is a
 timestamp but it acutally maps to the unique ID provided by the SMSC for
 that message. I asked this question a little while ago and that was the
 answer I got and it seems to be correct from my testing. The group can
 correct me if I am wrong.

 Regards,

 On Thu, Jul 15, 2010 at 10:43 AM, N'Golé Christian 
 ing_christian2...@yahoo.frhttp://mc/compose?to=ing_christian2...@yahoo.fr
  wrote:

 Heemmo Group,

 I still have problem with mysql ts value. when kannel gets dlrs from my
 smsc the field ts has the same value.

 2010-07-14 06:32:42 [31512] [10] DEBUG: DLR[mysql]: Looking for DLR
 smsc=vodoosms, ts=10, dst=22507484497, type=1
 2010-07-14 06:32:42 [31512] [10] DEBUG: sql: SELECT mask, service, url,
 source, destination, boxc FROM kannel_dlrs WHERE smsc='vodoosms' AND
 ts='10';

 I contacted my smsc but he told me that this is kannel issue.

 Please i need help.











Re: Mysql Timestamp issue

2010-07-15 Thread brett skinner
Hi

The zip file appears to be corrupted.

On Thu, Jul 15, 2010 at 11:58 AM, N'Golé Christian 
ing_christian2...@yahoo.fr wrote:

 Ok i send parts of smsc log.

 THANKS YOU FOR YOUR TIME !


 *Christian N'GOLE*



 http://www.smseco.com

   General Manager WEB PLURIEL


 Abidjan - Cocody

 *Adresse* : 27 BP 1222 Abj 27

 *Email* : supp...@smseco.com

 *Tel* : +225 22 42 89 62

 *Cel* : +225 07 74 97 97

 *Site Web* : www.smseco.com


 --- En date de : *Jeu 15.7.10, Nikos Balkanas nbalka...@gmail.com* a
 écrit :


 De: Nikos Balkanas nbalka...@gmail.com

 Objet: Re: Mysql Timestamp issue
 À: N'Gole Christian ing_christian2...@yahoo.fr, brett skinner 
 tatty.dishcl...@gmail.com
 Cc: users@kannel.org
 Date: Jeudi 15 juillet 2010, 11h34

 Hi,

 No, ts is the single most important value for dlr matching. Can't do it
 without it.
 Could be an issue with message-id-type, but your description doesn't make
 any sense.

 Listen, if you ask for help you need to post detailed smsc logs as i asked
 in a previous mail.

 BR,
 Nikos
 - Original Message - From: N'Gole Christian
 To: brett skinner
 Cc: users@kannel.org http://mc/compose?to=us...@kannel.org
 Sent: Thursday, July 15, 2010 12:18 PM
 Subject: Re: Mysql Timestamp issue


 yes i know that ! so if i understand this value is not important for dlrs
 managing ?


 Christian N'GOLE



 General Manager WEB PLURIEL



 Abidjan - Cocody
 Adresse : 27 BP 1222 Abj 27
 Email : supp...@smseco.com http://mc/compose?to=supp...@smseco.com
 Tel : +225 22 42 89 62
 Cel : +225 07 74 97 97
 Site Web : www.smseco.com


 --- En date de : Jeu 15.7.10, brett skinner 
 tatty.dishcl...@gmail.comhttp://mc/compose?to=tatty.dishcl...@gmail.com
 a ιcrit :



 De: brett skinner 
 tatty.dishcl...@gmail.comhttp://mc/compose?to=tatty.dishcl...@gmail.com
 
 Objet: Re: Mysql Timestamp issue
 ΐ: N'Golι Christian 
 ing_christian2...@yahoo.frhttp://mc/compose?to=ing_christian2...@yahoo.fr
 

 Cc: users@kannel.org http://mc/compose?to=us...@kannel.org
 Date: Jeudi 15 juillet 2010, 11h15


 Firstly that table is for use by Kannel as a storage so that you do not
 lose any DLR if the box goes down.


 If you want more information for DLRs when sending sms you need to append
 the dlr-url parameter to the end of the URL that you are using. Also make
 sure that you are using the dlr-mask parameter. In that URL you can specify
 what information you would like posted back.


 Please see the user guide for details.


 Regards,


 On Thu, Jul 15, 2010 at 11:11 AM, N'Golι Christian 
 ing_christian2...@yahoo.frhttp://mc/compose?to=ing_christian2...@yahoo.fr
 wrote:

 yes i use kannel as smpp client. So please what must i do to solve this
 issue ?


 Christian N'GOLE



 General Manager WEB PLURIEL



 Abidjan - Cocody
 Adresse : 27 BP 1222 Abj 27
 Email : supp...@smseco.com http://mc/compose?to=supp...@smseco.com
 Tel : +225 22 42 89 62
 Cel : +225 07 74 97 97
 Site Web : www.smseco.com


 --- En date de : Jeu 15.7.10, brett skinner 
 tatty.dishcl...@gmail.comhttp://mc/compose?to=tatty.dishcl...@gmail.com
 a ιcrit :



 De: brett skinner 
 tatty.dishcl...@gmail.comhttp://mc/compose?to=tatty.dishcl...@gmail.com
 
 Objet: Re: Mysql Timestamp issue
 ΐ: N'Golι Christian 
 ing_christian2...@yahoo.frhttp://mc/compose?to=ing_christian2...@yahoo.fr
 

 Cc: users@kannel.org http://mc/compose?to=us...@kannel.org
 Date: Jeudi 15 juillet 2010, 11h02



 Hi


 Are you using SMPP? If so then the ts field although it would seem is a
 timestamp but it acutally maps to the unique ID provided by the SMSC for
 that message. I asked this question a little while ago and that was the
 answer I got and it seems to be correct from my testing. The group can
 correct me if I am wrong.


 Regards,


 On Thu, Jul 15, 2010 at 10:43 AM, N'Golι Christian 
 ing_christian2...@yahoo.frhttp://mc/compose?to=ing_christian2...@yahoo.fr
 wrote:

 Heemmo Group,

 I still have problem with mysql ts value. when kannel gets dlrs from my
 smsc the field ts has the same value.

 2010-07-14 06:32:42 [31512] [10] DEBUG: DLR[mysql]: Looking for DLR
 smsc=vodoosms, ts=10, dst=22507484497, type=1
 2010-07-14 06:32:42 [31512] [10] DEBUG: sql: SELECT mask, service, url,
 source, destination, boxc FROM kannel_dlrs WHERE smsc='vodoosms' AND
 ts='10';

 I contacted my smsc but he told me that this is kannel issue.

 Please i need help.





Re: Mysql Timestamp issue

2010-07-15 Thread brett skinner
Hi

Sorry my experience is very limited so someone better than me is going to
have to respond.

From what I can see it looks like the SMSC keeps sending you delivery
receipts and Kannel is acknowledging them so no problem there. The problem
it seems is Kannel cannot find a particular DLR in the temporary table for
the given arguments. In particular it seems to be looking for DLR from the
SMSC with an id given to it by the SMSC of 4294967295 (or the ts values). I
am not sure if this is the case and why Kannel keeps retrying that one or
how to reset it.

@Nikos: Sorry I tried to help but I think your wisdom is needed. Mine is not
enough and I might be totally off the target. :)

Regards,

2010/7/15 Nikos Balkanas nbalka...@gmail.com

 Hi,

 1) You have not posted *any* submit_sm pdus (the ones you are trying to
 send) as requested.
 2) Your SMSc is right. It is you fault. Where did you find ts = 10?
 3) Fix your msg-id-type. Read User's guide about it.


 BR,
 Nikos
 - Original Message - From: N'Gole Christian
 To: brett skinner
 Cc: Nikos Balkanas ; users@kannel.org
 Sent: Thursday, July 15, 2010 2:57 PM

 Subject: Re: Mysql Timestamp issue


 sorry i send txt format.


 Christian N'GOLE



  General Manager WEB PLURIEL



 Abidjan - Cocody
 Adresse : 27 BP 1222 Abj 27
 Email : supp...@smseco.com
 Tel : +225 22 42 89 62
 Cel : +225 07 74 97 97
 Site Web : www.smseco.com


 --- En date de : Jeu 15.7.10, brett skinner tatty.dishcl...@gmail.com a
 Γ©crit :



 De: brett skinner tatty.dishcl...@gmail.com
 Objet: Re: Mysql Timestamp issue
 Γ€: N'GolΓ© Christian ing_christian2...@yahoo.fr

 Cc: Nikos Balkanas nbalka...@gmail.com, users@kannel.org
 Date: Jeudi 15 juillet 2010, 13h38


 Hi


 The zip file appears to be corrupted.


 On Thu, Jul 15, 2010 at 11:58 AM, N'GolΓ© Christian 
 ing_christian2...@yahoo.fr wrote:

 Ok i send parts of smsc log.

 THANKS YOU FOR YOUR TIME !



 Christian N'GOLE



  General Manager WEB PLURIEL



 Abidjan - Cocody
 Adresse : 27 BP 1222 Abj 27
 Email : supp...@smseco.com
 Tel : +225 22 42 89 62
 Cel : +225 07 74 97 97
 Site Web : www.smseco.com



 --- En date de : Jeu 15.7.10, Nikos Balkanas nbalka...@gmail.com a
 Γ©crit :



 De: Nikos Balkanas nbalka...@gmail.com

 Objet: Re: Mysql Timestamp issue

 Γ€: N'Gole Christian ing_christian2...@yahoo.fr, brett skinner 
 tatty.dishcl...@gmail.com

 Cc: users@kannel.org
 Date: Jeudi 15 juillet 2010, 11h34


 Hi,

 No, ts is the single most important value for dlr matching. Can't do it
 without it.
 Could be an issue with message-id-type, but your description doesn't make
 any sense.

 Listen, if you ask for help you need to post detailed smsc logs as i asked
 in a previous mail.

 BR,
 Nikos
 - Original Message - From: N'Gole Christian
 To: brett skinner
 Cc: users@kannel.org
 Sent: Thursday, July 15, 2010 12:18 PM
 Subject: Re: Mysql Timestamp issue



 yes i know that ! so if i understand this value is not important for dlrs
 managing ?


 Christian N'GOLE



 General Manager WEB PLURIEL



 Abidjan - Cocody
 Adresse : 27 BP 1222 Abj 27
 Email : supp...@smseco.com
 Tel : +225 22 42 89 62
 Cel : +225 07 74 97 97
 Site Web : www.smseco.com



 --- En date de : Jeu 15.7.10, brett skinner tatty.dishcl...@gmail.com a
 ΞΉcrit :




 De: brett skinner tatty.dishcl...@gmail.com
 Objet: Re: Mysql Timestamp issue

 Ξ : N'GolΞΉ Christian ing_christian2...@yahoo.fr


 Cc: users@kannel.org
 Date: Jeudi 15 juillet 2010, 11h15


 Firstly that table is for use by Kannel as a storage so that you do not
 lose any DLR if the box goes down.


 If you want more information for DLRs when sending sms you need to append
 the dlr-url parameter to the end of the URL that you are using. Also make
 sure that you are using the dlr-mask parameter. In that URL you can specify
 what information you would like posted back.


 Please see the user guide for details.


 Regards,



 On Thu, Jul 15, 2010 at 11:11 AM, N'GolΞΉ Christian 
 ing_christian2...@yahoo.fr wrote:

 yes i use kannel as smpp client. So please what must i do to solve this
 issue ?


 Christian N'GOLE



 General Manager WEB PLURIEL



 Abidjan - Cocody
 Adresse : 27 BP 1222 Abj 27
 Email : supp...@smseco.com
 Tel : +225 22 42 89 62
 Cel : +225 07 74 97 97
 Site Web : www.smseco.com



 --- En date de : Jeu 15.7.10, brett skinner tatty.dishcl...@gmail.com a
 ΞΉcrit :




 De: brett skinner tatty.dishcl...@gmail.com
 Objet: Re: Mysql Timestamp issue

 Ξ : N'GolΞΉ Christian ing_christian2...@yahoo.fr


 Cc: users@kannel.org
 Date: Jeudi 15 juillet 2010, 11h02



 Hi


 Are you using SMPP? If so then the ts field although it would seem is a
 timestamp but it acutally maps to the unique ID provided by the SMSC for
 that message. I asked this question a little while ago and that was the
 answer I got and it seems to be correct from my testing. The group can
 correct me if I am wrong.


 Regards,



 On Thu, Jul 15, 2010 at 10:43 AM, N'GolΞΉ Christian 
 ing_christian2

Preferred engine type for MySql DLR storage

2010-07-14 Thread brett skinner
Hi Users

I know this question is more to do with MySQL than Kannel but does anyone
here have a recommendation on the engine type for the MySQL table. Does
Kannel have a preference? At the moment I am using innoDB.

With regards to indexes on the table are there any recommendations? Looking
at the debug it seems that the delete statement is using the smsc and the
received columns so an index covering those columns should be fine. Although
because this table seems to hold transient data so the amount of data in
here should be minimal and table scans would probably be quicker than using
the index. Also maintaining an index is additional work for the MySQL DB so
I would be inclined to leave the table with no indexes. Does anyone have any
experience in this area and anything recommendations?

Regards,


Re: Preferred engine type for MySql DLR storage

2010-07-14 Thread brett skinner
Thanks for the feedback Alex. Are you suggesting that MyISAM is perhaps
better?

On Wed, Jul 14, 2010 at 3:57 PM, Alejandro Guerrieri 
alejandro.guerri...@gmail.com wrote:

 InnoDB is a bad idea if you're expecting to have a big number of DLR's
 waiting: The DLR engine uses SELECT COUNT(*) which happens to be painfully
 slow on InnoDB.

 The data won't be minimal, and you'll end up having to manually purge old
 records (sometimes not all DLR's are received back from the carrier).

 I suggest you to have two indexes: one on smsc + ts and the other one on
 stamp (to be able to delete old records).

 Regards,

 Alex


 On Wed, Jul 14, 2010 at 9:40 AM, brett skinner 
 tatty.dishcl...@gmail.comwrote:

 Hi Users

 I know this question is more to do with MySQL than Kannel but does anyone
 here have a recommendation on the engine type for the MySQL table. Does
 Kannel have a preference? At the moment I am using innoDB.

 With regards to indexes on the table are there any recommendations?
 Looking at the debug it seems that the delete statement is using the smsc
 and the received columns so an index covering those columns should be fine.
 Although because this table seems to hold transient data so the amount of
 data in here should be minimal and table scans would probably be quicker
 than using the index. Also maintaining an index is additional work for the
 MySQL DB so I would be inclined to leave the table with no indexes. Does
 anyone have any experience in this area and anything recommendations?

 Regards,





Re: Preferred engine type for MySql DLR storage

2010-07-14 Thread brett skinner
Thanks that is very interesting. I will give it a try with MyISAM. Did you
guys change the default InnoDB settings because I know with the defaults
that it is painful to say the least.

Regards,

On Wed, Jul 14, 2010 at 4:00 PM, Alejandro Guerrieri 
alejandro.guerri...@gmail.com wrote:

 Yes, definitely. We tried both, MyISAM performs way better.


 On Wed, Jul 14, 2010 at 9:58 AM, brett skinner 
 tatty.dishcl...@gmail.comwrote:

 Thanks for the feedback Alex. Are you suggesting that MyISAM is perhaps
 better?


 On Wed, Jul 14, 2010 at 3:57 PM, Alejandro Guerrieri 
 alejandro.guerri...@gmail.com wrote:

 InnoDB is a bad idea if you're expecting to have a big number of DLR's
 waiting: The DLR engine uses SELECT COUNT(*) which happens to be painfully
 slow on InnoDB.

 The data won't be minimal, and you'll end up having to manually purge old
 records (sometimes not all DLR's are received back from the carrier).

 I suggest you to have two indexes: one on smsc + ts and the other one on
 stamp (to be able to delete old records).

 Regards,

 Alex


 On Wed, Jul 14, 2010 at 9:40 AM, brett skinner 
 tatty.dishcl...@gmail.com wrote:

 Hi Users

 I know this question is more to do with MySQL than Kannel but does
 anyone here have a recommendation on the engine type for the MySQL table.
 Does Kannel have a preference? At the moment I am using innoDB.

 With regards to indexes on the table are there any recommendations?
 Looking at the debug it seems that the delete statement is using the smsc
 and the received columns so an index covering those columns should be fine.
 Although because this table seems to hold transient data so the amount of
 data in here should be minimal and table scans would probably be quicker
 than using the index. Also maintaining an index is additional work for the
 MySQL DB so I would be inclined to leave the table with no indexes. Does
 anyone have any experience in this area and anything recommendations?

 Regards,







Query regarding validity period

2010-07-12 Thread brett skinner
Hi All

I read the following in the user guide regarding validity period

*Optional. If given, Kannel will*
*inform SMS Center that it should*
*only try to send the message for*
*this many minutes. If the*
*destination mobile is off other*
*situation that it cannot receive*
*the sms, the smsc discards the*
*message. Note: you must have*
*your Kannel box time*
*synchronized with the SMS*
*Center.*
*
*
Why is it important to have the time synchronized with the SMSC? If for
example I have a message that is sent at 10:00 and I do not want the
receiver to get it past 17:00 then surely I would set the validity flag to
420 (60min * 7 hours)? Looking at the SMPP spec it says that the
validity_period can be specified in either absolute or relative terms. Which
does Kannel do? Also it seems looking at the encoding of the datetime type
it seems that it can specify the difference between local time and UTC.

I am not sure where this leaves me. What is the practice here? Does Kannel
send in local time and give the difference between UTC? Should I setup the
server to use UTC rather or will Kannel take care of all of this for me? Or
is my original thought correct and Kannel will just send the validity period
forward in relative terms i.e. valid for 420 minutes after you receive this
message? Appreciate any guidance that you can give me?

Regards,


Re: Query regarding validity period

2010-07-12 Thread brett skinner
Hi

Thanks Nikos. Did you mean though:

*Kannel sends to SMSc absolute GMT + your input.*
*
*
*because my input should already be in minutes according to the user guide.
Is that correct?*
*
*
*Regards,
*
2010/7/12 Nikos Balkanas nbalka...@gmail.com

 Hi,

 You input relative validity period. Kannel sends to SMSc absolute GMT +
 your input * 60.

 BR,
 Nikos
 - Original Message - From: brett skinner
 To: users@kannel.org
 Sent: Monday, July 12, 2010 11:39 AM
 Subject: Query regarding validity period



 Hi All


 I read the following in the user guide regarding validity period


 Optional. If given, Kannel will
 inform SMS Center that it should
 only try to send the message for
 this many minutes. If the
 destination mobile is off other
 situation that it cannot receive
 the sms, the smsc discards the
 message. Note: you must have
 your Kannel box time
 synchronized with the SMS
 Center.


 Why is it important to have the time synchronized with the SMSC? If for
 example I have a message that is sent at 10:00 and I do not want the
 receiver to get it past 17:00 then surely I would set the validity flag to
 420 (60min * 7 hours)? Looking at the SMPP spec it says that the
 validity_period can be specified in either absolute or relative terms. Which
 does Kannel do? Also it seems looking at the encoding of the datetime type
 it seems that it can specify the difference between local time and UTC.


 I am not sure where this leaves me. What is the practice here? Does Kannel
 send in local time and give the difference between UTC? Should I setup the
 server to use UTC rather or will Kannel take care of all of this for me? Or
 is my original thought correct and Kannel will just send the validity period
 forward in relative terms i.e. valid for 420 minutes after you receive this
 message? Appreciate any guidance that you can give me?


 Regards,



Re: Query regarding validity period

2010-07-12 Thread brett skinner
Hi

Thanks for the information. I did not know that. :)

2010/7/12 Nikos Balkanas nbalka...@gmail.com

 Nope, I meant what I said. Kannel, at least the smpp driver, sends seconds
 to SMSc.


 BR,
 Nikos
 - Original Message - From: brett skinner
 To: Nikos Balkanas
 Cc: users@kannel.org
 Sent: Monday, July 12, 2010 12:28 PM
 Subject: Re: Query regarding validity period



 Hi


 Thanks Nikos. Did you mean though:


 Kannel sends to SMSc absolute GMT + your input.


 because my input should already be in minutes according to the user guide.
 Is that correct?


 Regards,


 2010/7/12 Nikos Balkanas nbalka...@gmail.com

 Hi,

 You input relative validity period. Kannel sends to SMSc absolute GMT +
 your input * 60.

 BR,
 Nikos
 - Original Message - From: brett skinner
 To: users@kannel.org
 Sent: Monday, July 12, 2010 11:39 AM
 Subject: Query regarding validity period



 Hi All


 I read the following in the user guide regarding validity period


 Optional. If given, Kannel will
 inform SMS Center that it should
 only try to send the message for
 this many minutes. If the
 destination mobile is off other
 situation that it cannot receive
 the sms, the smsc discards the
 message. Note: you must have
 your Kannel box time
 synchronized with the SMS
 Center.


 Why is it important to have the time synchronized with the SMSC? If for
 example I have a message that is sent at 10:00 and I do not want the
 receiver to get it past 17:00 then surely I would set the validity flag to
 420 (60min * 7 hours)? Looking at the SMPP spec it says that the
 validity_period can be specified in either absolute or relative terms. Which
 does Kannel do? Also it seems looking at the encoding of the datetime type
 it seems that it can specify the difference between local time and UTC.


 I am not sure where this leaves me. What is the practice here? Does Kannel
 send in local time and give the difference between UTC? Should I setup the
 server to use UTC rather or will Kannel take care of all of this for me? Or
 is my original thought correct and Kannel will just send the validity period
 forward in relative terms i.e. valid for 420 minutes after you receive this
 message? Appreciate any guidance that you can give me?


 Regards,



Processing reply messages/SMS messages sent from SMSC

2010-07-02 Thread brett skinner
Hi

Firstly I would like to thank the group for all the help that I have
received. I really appreciate it. Secondly I have found usig Kannel to be a
very pleasant experience so thanks for all the hard work. I unfortunately
know absolutely nothing about C and I think my Java knowledge just won't cut
it so I won't be able to make any contributions in terms of code.

I would just like to double check something with the group because the user
guide wasn't clear regarding my scenario. I would like to be able to process
replies SMSs to messages that I have been sent. The SMSC has given us some
numbers to use as the origin (or sender) number. If the person replies to
the message it will go the SMSC who then forwards it to us. From the logs it
appears as they are forwarding the messages to us as deliver_sm PDUs.

When I get the message I would like to be able to process it. I don't want
to answer the message or do anything else. From what I gather I need to
setup an sms-service group as follows:

group = sms-service
keyword-regex = .*
catch-all = yes
get-url = http://localhost:/Replies.php?params;
omit-empty = true

I want all SMS messages to be handled in the same way regardless of their
origins or keywords etc. I am also not looking to do any shortcode magic or
any replies. This is why I setup the keyword-regex to * so that this occurs
for all messages. I don't want to send anything back to their handset, this
is why I have included omit-empty = true. I found without this option that
the handset would receive Empty reply from service provider.

Is this the preferred way to achieve what I am aiming for?
Is there anything that I should be aware of or any complications that might
arise?

Regards,


Re: Processing reply messages/SMS messages sent from SMSC

2010-07-02 Thread brett skinner
Hi

Last thing, when receiving SMSes from the SMSC, is there a setting that will
instruct Kannel to concatenate long messages into a single message before
calling the URL. I tried using the combine-concatenated-mo = true option on
core group but this didn't work. I can understand why it didn't work because
technically it isn't a mobile originated. I did a search for concat and
couldn't find anything else in the user-guide,

Thanks for your assistance.

On Fri, Jul 2, 2010 at 2:48 PM, Rene Kluwen rene.klu...@chimit.nl wrote:

  Small hint: You can also contribute making the documentation clearer ;=).



 I use:



 group = sms-service

 keyword = default

 catch-all = true

 get-url =
 http://www.mydomain.com/sms/process_mo.php?text=%afrom=%pto=%Ptime=%Tbilling=%Bsmsc=%i

 accepted-smsc = my_smsc

 omit-empty = true

 accept-x-kannel-headers = true



 I guess there is more than one way to achieve what you want and one doesn’t
 necessarily needs to be better than the other one.



 == Rene





 *From:* users-boun...@kannel.org [mailto:users-boun...@kannel.org] *On
 Behalf Of *brett skinner
 *Sent:* vrijdag 2 juli 2010 14:33
 *To:* users@kannel.org
 *Subject:* Processing reply messages/SMS messages sent from SMSC



 Hi



 Firstly I would like to thank the group for all the help that I have
 received. I really appreciate it. Secondly I have found usig Kannel to be a
 very pleasant experience so thanks for all the hard work. I unfortunately
 know absolutely nothing about C and I think my Java knowledge just won't cut
 it so I won't be able to make any contributions in terms of code.



 I would just like to double check something with the group because the user
 guide wasn't clear regarding my scenario. I would like to be able to process
 replies SMSs to messages that I have been sent. The SMSC has given us some
 numbers to use as the origin (or sender) number. If the person replies to
 the message it will go the SMSC who then forwards it to us. From the logs it
 appears as they are forwarding the messages to us as deliver_sm PDUs.



 When I get the message I would like to be able to process it. I don't want
 to answer the message or do anything else. From what I gather I need to
 setup an sms-service group as follows:



 group = sms-service

 keyword-regex = .*

 catch-all = yes

 get-url = http://localhost:/Replies.php?params;

 omit-empty = true



 I want all SMS messages to be handled in the same way regardless of their
 origins or keywords etc. I am also not looking to do any shortcode magic or
 any replies. This is why I setup the keyword-regex to * so that this occurs
 for all messages. I don't want to send anything back to their handset, this
 is why I have included omit-empty = true. I found without this option that
 the handset would receive Empty reply from service provider.



 Is this the preferred way to achieve what I am aiming for?

 Is there anything that I should be aware of or any complications that might
 arise?



 Regards,



Re: Open DLRs

2010-07-01 Thread brett skinner
Hi

I am assuming because I had bound as a transmitter and was sending submit_sm
packets that they were responding with submit_sm_resp. I think that is
according to SMPP 3.4 spec. The only problem is that I was not getting the
delivery receipts. It seems that Kannel treats the a positive submit_sm_resp
as a DLR to say enqueued.

Regards,

2010/6/30 Nikos Balkanas nbalka...@gmail.com

 Hi,

 How then did you get the submit_sm_resp from the SMSc?


 BR,
 Nikos
 - Original Message - From: brett skinner
 To: users@kannel.org
 Sent: Wednesday, June 30, 2010 12:37 PM

 Subject: Re: Open DLRs


 Hi


 It turns out that I had commented out the section where I put the bind into
 transceiver mode. Everything is working as expected.


 Thank you for the help.


 2010/6/30 Nikos Balkanas nbalka...@gmail.com

 Hi,

 No. You have done all you needed from kannel's side. If not seeing
 deliver_sm, try talking to your SMSc.


 BR,
 Nikos
 - Original Message - From: brett skinner
 To: users@kannel.org

 Sent: Wednesday, June 30, 2010 11:17 AM
 Subject: Re: Open DLRs



 Hi Nikos


 Thanks for your reply. That is the impression that I got. The only thing
 that is a little confusing right now is that I am not seeing the temporary
 DLRs in the MySQL table ever being removed. I am using SMPP and am testing
 by sending to an actual SMSC and I am getting the message on my handset. I
 see the submit_sm and submit_sm_resp in the logs. But no where do I see any
 deliver_sm in the logs. Do I need to specify anything extra when calling the
 sends_sms URL? (I didn't see any additional parameters in the user guide). I
 have waited a couple of hours after I received the SMS on my handset and
 still nothing from the SMSC and the DLRs are still in the table.


 Last question: How does Kannel do the lookup to remove the DLR once it is
 received? Does it use the smsc and the ts fields assuming you are using
 SMPP?


 Regards,



 2010/6/30 Nikos Balkanas nbalka...@gmail.com

 Hi,

 The documentation is correct. DLR entries (internal to kannel but without
 final status) are created and inserted when the SMS is accepted by the SMSc
 and deleted when the external DLR (with final status) arrives from the SMSc.
 This could last for the time it takes to deliver the SMS to the mobile. It
 could be anything from a few minutes to a couple of days. If DLRs are in
 memory, bb is restarted, and the final DLR from the SMSc is still pending,
 the entries will be erased from memory. The result is that when the external
 status DLR arrives from the SMSc, there is no corresponding entry to match
 in kannel, and discarded. This doesn't happen if you use a DB for
 dlr-storage.

 The DLR tables are to be used only internally by kannel. You can see the
 DLR from bb access logs and you can even store it in your external web
 application by specifying a dlr-url to your push SMS. You will have to
 supply a msg-id to that dlr-url, unique for each MT, since msgid is internal
 to kannel and not sent over the dlr-url.

 For more info read User's Guide.

 BR,
 Nikos

 - Original Message - From: brett skinner
 To: users@kannel.org
 Sent: Wednesday, June 30, 2010 10:44 AM
 Subject: Open DLRs



 Hi


 Reading through the documentation I came across this statement:


 This is problematic if bearerbox crashes or you take the process down in a
 controlled way, but there are still DLRs open. Therefore you may use
 external DLR storage places, i.e. a MySQL database.


 Does that mean that the MySQL is temporary storage and that at some point
 when the DLR is deemed to be closed that the row will be removed? If so then


 When is a DLR closed?
 Should we be using the MySQL table to get extra information about the DLR?
 If not what should we be using?
 Can we get Kannel to send us information about the fields in the DLR in the
 URL. Such as message_id field from submit_sm_resp?
 Thank you. I really appreciate all the help.



Re: Open DLRs

2010-07-01 Thread brett skinner
It makes perfect sense according to the SMPP specification.

A connection is either bound as transmitter, receiver or both (transceiver).

A transmitter is for messages set to SMSC from ESME.
A receiver is for messages from SMSC to EMSE.
Transceiver does both.

So a submit_sm is a request to SMSC from ESME and the EMSE
will acknowledge via a sm_submit_resp.

The deliver_sm is an SMSC originated message and will therefore go the
receiver not the submitted. But all of this I am sure you know.

I had not set up a receiver port because I had intended to be in transceiver
mode but during all my testing I had commented out the transceiver-mode line
so effectively had this in my config.

#transceiver-mode = true

As soon as I took away the comments and started up again I received all the
deliver_sm from the SMSC that had been queuing.

I have not submitted any logs or config because I have resolved my issue and
what happened can be easily explained by the SMPP protocol. Everything seems
to be working as designed.


2010/7/1 Nikos Balkanas nbalka...@gmail.com

 Hi,

 Nope. The same way you were getting submit_sm_resp, you should have gotten
 deliver_sm. What you say doesn't make much sense, but is difficult to say,
 since you never submitted any logs.


 BR,
 Nikos
 - Original Message - From: brett skinner
 To: users@kannel.org
 Sent: Thursday, July 01, 2010 10:26 AM

 Subject: Re: Open DLRs


 Hi


 I am assuming because I had bound as a transmitter and was sending
 submit_sm packets that they were responding with submit_sm_resp. I think
 that is according to SMPP 3.4 spec. The only problem is that I was not
 getting the delivery receipts. It seems that Kannel treats the a positive
 submit_sm_resp as a DLR to say enqueued.


 Regards,


 2010/6/30 Nikos Balkanas nbalka...@gmail.com

 Hi,

 How then did you get the submit_sm_resp from the SMSc?


 BR,
 Nikos
 - Original Message - From: brett skinner
 To: users@kannel.org

 Sent: Wednesday, June 30, 2010 12:37 PM

 Subject: Re: Open DLRs


 Hi


 It turns out that I had commented out the section where I put the bind into
 transceiver mode. Everything is working as expected.


 Thank you for the help.


 2010/6/30 Nikos Balkanas nbalka...@gmail.com

 Hi,

 No. You have done all you needed from kannel's side. If not seeing
 deliver_sm, try talking to your SMSc.


 BR,
 Nikos
 - Original Message - From: brett skinner
 To: users@kannel.org

 Sent: Wednesday, June 30, 2010 11:17 AM
 Subject: Re: Open DLRs



 Hi Nikos


 Thanks for your reply. That is the impression that I got. The only thing
 that is a little confusing right now is that I am not seeing the temporary
 DLRs in the MySQL table ever being removed. I am using SMPP and am testing
 by sending to an actual SMSC and I am getting the message on my handset. I
 see the submit_sm and submit_sm_resp in the logs. But no where do I see any
 deliver_sm in the logs. Do I need to specify anything extra when calling the
 sends_sms URL? (I didn't see any additional parameters in the user guide). I
 have waited a couple of hours after I received the SMS on my handset and
 still nothing from the SMSC and the DLRs are still in the table.


 Last question: How does Kannel do the lookup to remove the DLR once it is
 received? Does it use the smsc and the ts fields assuming you are using
 SMPP?


 Regards,



 2010/6/30 Nikos Balkanas nbalka...@gmail.com

 Hi,

 The documentation is correct. DLR entries (internal to kannel but without
 final status) are created and inserted when the SMS is accepted by the SMSc
 and deleted when the external DLR (with final status) arrives from the SMSc.
 This could last for the time it takes to deliver the SMS to the mobile. It
 could be anything from a few minutes to a couple of days. If DLRs are in
 memory, bb is restarted, and the final DLR from the SMSc is still pending,
 the entries will be erased from memory. The result is that when the external
 status DLR arrives from the SMSc, there is no corresponding entry to match
 in kannel, and discarded. This doesn't happen if you use a DB for
 dlr-storage.

 The DLR tables are to be used only internally by kannel. You can see the
 DLR from bb access logs and you can even store it in your external web
 application by specifying a dlr-url to your push SMS. You will have to
 supply a msg-id to that dlr-url, unique for each MT, since msgid is internal
 to kannel and not sent over the dlr-url.

 For more info read User's Guide.

 BR,
 Nikos

 - Original Message - From: brett skinner
 To: users@kannel.org
 Sent: Wednesday, June 30, 2010 10:44 AM
 Subject: Open DLRs



 Hi


 Reading through the documentation I came across this statement:


 This is problematic if bearerbox crashes or you take the process down in a
 controlled way, but there are still DLRs open. Therefore you may use
 external DLR storage places, i.e. a MySQL database.


 Does that mean that the MySQL is temporary storage and that at some point
 when

Open DLRs

2010-06-30 Thread brett skinner
Hi

Reading through the documentation I came across this statement:

This is problematic if bearerbox crashes or you take the process down in
a controlled way, but there are still DLRs open. Therefore you may use
external DLR storage places, i.e. a MySQL database.

Does that mean that the MySQL is temporary storage and that at some point
when the DLR is deemed to be closed that the row will be removed? If so then


   - When is a DLR closed?
   - Should we be using the MySQL table to get extra information about the
   DLR?
   - If not what should we be using?
   - Can we get Kannel to send us information about the fields in the DLR in
   the URL. Such as message_id field from submit_sm_resp?

Thank you. I really appreciate all the help.


Re: Open DLRs

2010-06-30 Thread brett skinner
Hi Nikos

Thanks for your reply. That is the impression that I got. The only thing
that is a little confusing right now is that I am not seeing the temporary
DLRs in the MySQL table ever being removed. I am using SMPP and am testing
by sending to an actual SMSC and I am getting the message on my handset. I
see the submit_sm and submit_sm_resp in the logs. But no where do I see any
deliver_sm in the logs. Do I need to specify anything extra when calling the
sends_sms URL? (I didn't see any additional parameters in the user guide). I
have waited a couple of hours after I received the SMS on my handset and
still nothing from the SMSC and the DLRs are still in the table.

Last question: How does Kannel do the lookup to remove the DLR once it is
received? Does it use the smsc and the ts fields assuming you are using
SMPP?

Regards,


2010/6/30 Nikos Balkanas nbalka...@gmail.com

 Hi,

 The documentation is correct. DLR entries (internal to kannel but without
 final status) are created and inserted when the SMS is accepted by the SMSc
 and deleted when the external DLR (with final status) arrives from the SMSc.
 This could last for the time it takes to deliver the SMS to the mobile. It
 could be anything from a few minutes to a couple of days. If DLRs are in
 memory, bb is restarted, and the final DLR from the SMSc is still pending,
 the entries will be erased from memory. The result is that when the external
 status DLR arrives from the SMSc, there is no corresponding entry to match
 in kannel, and discarded. This doesn't happen if you use a DB for
 dlr-storage.

 The DLR tables are to be used only internally by kannel. You can see the
 DLR from bb access logs and you can even store it in your external web
 application by specifying a dlr-url to your push SMS. You will have to
 supply a msg-id to that dlr-url, unique for each MT, since msgid is internal
 to kannel and not sent over the dlr-url.

 For more info read User's Guide.

 BR,
 Nikos

 - Original Message - From: brett skinner
 To: users@kannel.org
 Sent: Wednesday, June 30, 2010 10:44 AM
 Subject: Open DLRs



 Hi


 Reading through the documentation I came across this statement:


 This is problematic if bearerbox crashes or you take the process down in a
 controlled way, but there are still DLRs open. Therefore you may use
 external DLR storage places, i.e. a MySQL database.


 Does that mean that the MySQL is temporary storage and that at some point
 when the DLR is deemed to be closed that the row will be removed? If so then


 When is a DLR closed?
 Should we be using the MySQL table to get extra information about the DLR?
 If not what should we be using?
 Can we get Kannel to send us information about the fields in the DLR in the
 URL. Such as message_id field from submit_sm_resp?
 Thank you. I really appreciate all the help.



Re: Open DLRs

2010-06-30 Thread brett skinner
Hi

It turns out that I had commented out the section where I put the bind into
transceiver mode. Everything is working as expected.

Thank you for the help.

2010/6/30 Nikos Balkanas nbalka...@gmail.com

 Hi,

 No. You have done all you needed from kannel's side. If not seeing
 deliver_sm, try talking to your SMSc.


 BR,
 Nikos
 - Original Message - From: brett skinner
 To: users@kannel.org
 Sent: Wednesday, June 30, 2010 11:17 AM
 Subject: Re: Open DLRs



 Hi Nikos


 Thanks for your reply. That is the impression that I got. The only thing
 that is a little confusing right now is that I am not seeing the temporary
 DLRs in the MySQL table ever being removed. I am using SMPP and am testing
 by sending to an actual SMSC and I am getting the message on my handset. I
 see the submit_sm and submit_sm_resp in the logs. But no where do I see any
 deliver_sm in the logs. Do I need to specify anything extra when calling the
 sends_sms URL? (I didn't see any additional parameters in the user guide). I
 have waited a couple of hours after I received the SMS on my handset and
 still nothing from the SMSC and the DLRs are still in the table.


 Last question: How does Kannel do the lookup to remove the DLR once it is
 received? Does it use the smsc and the ts fields assuming you are using
 SMPP?


 Regards,



 2010/6/30 Nikos Balkanas nbalka...@gmail.com

 Hi,

 The documentation is correct. DLR entries (internal to kannel but without
 final status) are created and inserted when the SMS is accepted by the SMSc
 and deleted when the external DLR (with final status) arrives from the SMSc.
 This could last for the time it takes to deliver the SMS to the mobile. It
 could be anything from a few minutes to a couple of days. If DLRs are in
 memory, bb is restarted, and the final DLR from the SMSc is still pending,
 the entries will be erased from memory. The result is that when the external
 status DLR arrives from the SMSc, there is no corresponding entry to match
 in kannel, and discarded. This doesn't happen if you use a DB for
 dlr-storage.

 The DLR tables are to be used only internally by kannel. You can see the
 DLR from bb access logs and you can even store it in your external web
 application by specifying a dlr-url to your push SMS. You will have to
 supply a msg-id to that dlr-url, unique for each MT, since msgid is internal
 to kannel and not sent over the dlr-url.

 For more info read User's Guide.

 BR,
 Nikos

 - Original Message - From: brett skinner
 To: users@kannel.org
 Sent: Wednesday, June 30, 2010 10:44 AM
 Subject: Open DLRs



 Hi


 Reading through the documentation I came across this statement:


 This is problematic if bearerbox crashes or you take the process down in a
 controlled way, but there are still DLRs open. Therefore you may use
 external DLR storage places, i.e. a MySQL database.


 Does that mean that the MySQL is temporary storage and that at some point
 when the DLR is deemed to be closed that the row will be removed? If so then


 When is a DLR closed?
 Should we be using the MySQL table to get extra information about the DLR?
 If not what should we be using?
 Can we get Kannel to send us information about the fields in the DLR in the
 URL. Such as message_id field from submit_sm_resp?
 Thank you. I really appreciate all the help.



Datatype for timestamp for mysql dlr storage

2010-06-29 Thread brett skinner
Hi

I am using the mysql dlr storage type. I have everything working except for
the timestamp. This is the output from debug mode

sql: INSERT INTO delivery_receipts (smsc, received, source, destination,
service, url, mask, boxc, status) VALUES ('XXXYYYXXX', '50062911024679487',
'+123123123', '+123123123', 'simple', '', '31', '', '0');

I set the delivery_receipts table received column to timestamp but when I
query it I get this -00-00 00:00:00

What should the datatype of the received column be? I see in some places
people have left it as varchar. Is it up to me to do the translation.

Thanks and appreciate any assistance.

Regards,


Re: Datatype for timestamp for mysql dlr storage

2010-06-29 Thread brett skinner
Hi

Thanks for your response Konstantin. So if I am understanding you correctly
the problem is that every SMSC is responding according to their own specific
implementation. So for timestamps I will need to implement something such as
a column with a default value.

Thanks for your input.

On Tue, Jun 29, 2010 at 11:53 AM, Konstantin Vayner pon...@appcell.netwrote:

 Problem is - Kannel stores the TS in different formats, depending on remote
 SMSC protocol and implementation.
 Sometimes i see numeric values, sometimes hex

 So i dont think really anything but varchar would work well

 2010/6/29 Nikos Balkanas nbalka...@gmail.com

 Hi,


 Please consult the online Mysql reference. This is not a kannel question.
 If you use varchar or even datetime type column column, you better provide
 the value yourself. If you use timestamp type column, you can have mysql
 initialize it to current time.

 BR,
 Nikos
 - Original Message - From: brett skinner
 To: users@kannel.org
 Sent: Tuesday, June 29, 2010 12:12 PM
 Subject: Datatype for timestamp for mysql dlr storage



 Hi

 I am using the mysql dlr storage type. I have everything working except
 for the timestamp. This is the output from debug mode

 sql: INSERT INTO delivery_receipts (smsc, received, source, destination,
 service, url, mask, boxc, status) VALUES ('XXXYYYXXX', '50062911024679487',
 '+123123123', '+123123123', 'simple', '', '31', '', '0');

 I set the delivery_receipts table received column to timestamp but when I
 query it I get this -00-00 00:00:00

 What should the datatype of the received column be? I see in some places
 people have left it as varchar. Is it up to me to do the translation.

 Thanks and appreciate any assistance.

 Regards,





Does Kannel always place the message_id from a submit_sm_resp into timestamp for a DLR using SMPP 3.4

2010-06-29 Thread brett skinner
Hi

I was checking in the SMPP 3.4 spec and came across the submit_sm_resp PDU
which specifies a message_id field. According to the spec:

This field contains the SMSC
message ID of the submitted
message. It may be used at a
later stage to query the status
of a message, cancel or
replace the message.

We are using MySql DLR. Looking at the debug output from Kannel:

2010-06-29 13:13:31 [3124] [6] DEBUG:   message_id: 50062913133840086
2010-06-29 13:13:31 [3124] [6] DEBUG: SMPP PDU dump ends.
2010-06-29 13:13:31 [3124] [6] DEBUG: DLR[mysql]: Adding DLR smsc=,
ts=50062913133840086, src=+1231234, dst=+1231234, mask=31, boxc=

It seems that it is placing the message_id into the ts field. Is this always
the case?

Regards,