Martin Lucina wrotw:
I'm experiencing a problem with Kannel, both with version 1.3.1
and reproducible elsewhere with the current CVS): In a multi-operator
setup I have some SMSC connections which are polled over a dialup link.
There is a script that connects the PPP link periodically, sends a
start-smsc command to Kannel for SMSCs behind that link, polls for
messages for some time, downs the link and sends stop-smsc to Kannel.
If our application attempts to send an SMS via Kannel to one of the
SMSCs when they are down (Kannel status records them as 'dead') then the
following gets logged (CVS version example):
2004-05-24 12:57:44 [7] WARNING: Message rejected by bearerbox, no router!
2004-05-24 12:58:40 [7] WARNING: Cannot find SMSCConn for message to ,
rejected.
The message also (in 1.3.1, not in CVS) gets logged as DISCARDED in the
access log. However -- and this is the problem -- the application never
gets back a FAILED DLR for the message, hence cannot tell whether it
should re-send it or not.
I've spent some time looking through the code paths in an attempt to
figure out what is going on -- comparing sms_router () to
deliver_sms_to_queue () suggests that the following patch should fix the
behaviour to be consistent:
--- bb_boxc.c 16 Feb 2004 19:41:26 - 1.77
+++ bb_boxc.c 24 May 2004 14:05:22 -
@@ -223,21 +223,10 @@
mack-ack.nack = ack_buffered;
break;
case -1: /* no router at all */
- warning(0, Message rejected by bearerbox, no router!);
- /*
-* first create nack for store-file, in order to delete
-* message from store-file.
-*/
- mack_store = msg_create(ack);
- gw_assert(mack_store != NULL);
- uuid_copy(mack_store-ack.id, msg-sms.id);
- mack_store-ack.time = msg-sms.time;
- mack-ack.nack = mack_store-ack.nack = ack_failed;
- store_save(mack_store);
- msg_destroy(mack_store);
-
- /* destroy original message */
- msg_destroy(msg);
+ mack-ack.nack = ack_failed;
+ warning(0, No SMSCes to receive message, discarding it!);
+ bb_smscconn_send_failed(NULL, msg, SMSCCONN_FAILED_DISCARDED,
+ octstr_create(DISCARDED));
break;
}
I've tested it here and it has the desired effect (a NACK/DISCARDED DLR
gets sent back to the application).
-1 on the patch, first of all.
The problem can be described as follows:
your client sends a msg which (in case the smsc link is in dead state)
can not be transported. Kannel treads this msg as untransportable
and hence the mack-ack.nack = ack_failed _is_ send to your client
application (smsbox in the usualy case).
Your argumentation that there is no FAIL DLR that gets back
transported to the the application layer may be reasonable. Kannel
descides if a FAIL DLR is created, after it had _tried_ to deliver the
msg to a routed smsc link. Which is not the case here. Hence Kannel
does never try to transport the msg to an smsc and hence does not
create a DLR for it.
This is more a semantical problem here. We may descide to threat
such unroutable messages with failing DLRs. Any opionions from the
others if this is reasonable?!
BTW, why isn't it an option to let the smsc links online and let them
try to reconnect on their own while you drop of the tcp layer from it?
This would cause Kannel to hold up the msgs in the internal quques and
dispose them when the link is established again. Where the DLRs will
get transported then too.
Stipe
mailto:[EMAIL PROTECTED]
---
Wapme Systems AG
Vogelsanger Weg 80
40470 Düsseldorf, NRW, Germany
phone: +49.211.74845.0
fax: +49.211.74845.299
mailto:[EMAIL PROTECTED]
http://www.wapme-systems.de/
---
-BEGIN PGP PUBLIC KEY BLOCK-
Version: GnuPG v1.2.2 (Cygwin)
mIsEP6mcYwEEAMDnUiUwrbb+xwTFWN6TxF2+XZu7/alwJMeCwMBRvXtPZqfjpPhS
OkBpU0F4TrVuugz1HINTSaJTYq10AzDQXp5NkyWgckqW79nPAWuOX0dicbJk+cN2
nM2TI4KaxUDe6u8hghNEnH/i2lXsUu9apnP/iixzV81VC2je3uc9hZpnAAYptEVT
dGlwZSBUb2xqIChUZWNobm9sb2d5IENlbnRlciAmIFJlc2VhcmNoIExhYikgPHRv
bGpAd2FwbWUtc3lzdGVtcy5kZT6ItAQTAQIAHgUCP6mcYwIbAwYLCQgHAwIDFQID
AxYCAQIeAQIXgAAKCRABV0w1BqPYRuSqA/wPzsQxao2YePENCtgRTrO86U6zg3sl
OcS6CJFI4FZP5h/xD3GRsNH1+MPSvZlomDdpFnr547DGz/Kq9MXuQwVvlVig5yWZ
K5dtKp1r5YLhxJQBhfirZbRFFnYmf19f18J8OoS28tuFVftDl1AIwJS3HLyBTv6H
g2HyLAEKQIp30Q==
=aYCI
-END PGP PUBLIC KEY BLOCK-
