Dear Alex, Rene, Niel et al.,
The solution that Niel describes should work.
However, back in the day, we had to take a different approach because
we were not allowed to have multiple TCP connections to our SMPP
provider's server, if I remember correctly. :-P
Apologies if anything I have written below is crazy and wrong, this
was so long ago, I can barely remember what I did... but basically...
I patched Kannel bearerbox to differentiate between the
@SMSCCONN_ACTIVE@ and @SMSCCONN_ACTIVE_RECV@ states / statuses.
Here is a very old patch chunk... so please do not use it verbatim...
@gw/bb_smscconn.c@
<pre>
@@ -816,8 +821,10 @@
octstr_append(tmp, conn_name);
switch (info.status) {
- case SMSCCONN_ACTIVE:
case SMSCCONN_ACTIVE_RECV:
+ sprintf(tmp3, "online %lds (receive only)", info.online);
+ break;
+ case SMSCCONN_ACTIVE:
sprintf(tmp3, "online %lds", info.online);
break;
case SMSCCONN_DISCONNECTED:
</pre>
And then external to Kannel, I had a Bash shell or Perl script with
curl or something (run from cron but it could well have been Nagios,
Cacti, etc.) to check the connection status.
If the connection status changed to
"online [0-9\.]*s \(receive only\)"
the script would initiate a @stop-smsc@; and log, of course. And then
@start-smsc@ would be called; and logged.
I think I liked the extra detail in the Kannel status; and, the logs and email
notifications generated from the scripts gave a nice indication of the SMPP
service uptime (read: SLA) from the provider. They also served as
monitoring alerts.
There were no logic changes required in the Kannel code. I think the
status is a tiny bit different now with load_get() calls.
h1. Background
h2. Types of bad / stale SMPP connections
We had (at least) two issues with our SMPP provider
* During SMPP connection or re-connection, the provider's SMPP server
used to incorrectly return a bad password. We guessed that this
probably occurred when they restarted their systems. Why they did not just
firewall all incoming TCP connections (and TCP slice) first and wait
until everything was running correctly before accepting incoming TCP
connections, who knows?
* During SMPP connection or (more often) re-connection, an SMPP tranceiver
connection started up, but *only* in receive mode. Again, probably due
to some system restart or maybe a (quasi) race condition at the
provider's end.
On Saturday, 2012-03-24 at 03:56:51 AM, Rene Kluwen scribbled:
> I have the same thing. Smpp connections going stale.
> A possible cause is that the remote smpp connection gets killed and Kannel
> doesn't see that. It thinks that it is still connected.
> Result is that sms messages get queued but not delivered.
>
*snip*
On Saturday, 2012-03-24 at 04:16:23 AM, Niel Smith scribbled:
> Apologies, tranceiver should be tranceiver=false.
>
> On 23 March 2012 19:15, Niel Smith <[email protected]> wrote:
>
> >
> > Can't remember where I read it, but the problem was resolved by creating a
> > duplicate smpp group for each connection, setting the transceiver = true
> > for both. And setting receive-port=0 on one, and port=0 on the other.
> >
> > Example:
> >
> >> group = smsc
> >> smsc = smpp
> >> smsc-id = smsc1
> >> allowed-smsc-id = smsc1
> >> host = <IP HERE>
> >> port = 0
> >> receive-port = <PORT HERE>
> >> smsc-username = <USERNAME HERE>
> >> smsc-password = <PASSWORD HERE>
> >> transceiver-mode = true
> >> system-type = VMA
> >> throughput = 119
> >>
> >> group = smsc
> >> smsc = smpp
> >> smsc-id = smsc1
> >> allowed-smsc-id = smsc1
> >> host = <IP HERE>
> >> port = <PORT HERE>
> >> receive-port = 0
> >> smsc-username = <USERNAME HERE>
> >> smsc-password = <PASSWORD HERE>
> >> transceiver-mode = true
> >> system-type = VMA
> >> throughput = 119
> >>
*snip*
--
Benjamin Lee mailto:[email protected]
Melbourne, Australia http://www.realthought.net
Linux / BSD / GNU tel:+61 4 16 BEN LEE
Open Source "invest in your world"
__________________________________________________________________________
'Martyrdom' is the only way a person can become famous without ability.
-- George Bernard Shaw
