I think you are both right. The smsbox_list empty problem is a bearerbox routing problem. However, AFAIR, sqlbox doesn't send back an ACK to saved messages if it receives them. It sure would be nice if it did.
== Rene -----Original Message----- From: Nikos Balkanas [mailto:nbalka...@gmail.com] Sent: Monday, 09 August, 2010 18:31 To: Toby Phipps; 'Rene Kluwen'; users@kannel.org Subject: Re: Life without smsbox Nope. What you see is entirely different. send_msg is not sending the DLR to sqlbox, but rather responding an ACK to the received MT. I don't know if there is a problem with sqlbox, but I bet I would have heard about it if it were, but revert to the svn version and try smsbox-route. The warning you get is very crucial, you are missing incoming DLRs. You need to fix that, before anything else. BR, Nikos ----- Original Message ----- From: "Toby Phipps" <toby.phi...@nexmedia.com.sg> To: "'Nikos Balkanas'" <nbalka...@gmail.com>; "'Rene Kluwen'" <rene.klu...@chimit.nl>; <users@kannel.org> Sent: Monday, August 09, 2010 7:24 PM Subject: RE: Life without smsbox > Hi Nikos, > > I'll certainly try what you suggest, but I'm not quite sure that's the > issue. Although bearerbox may think it doesn't have any smsboxes > connected, > it's still happily routing messages to sqlbox - here's a brief extract > from > the bearerbox log: > > 2010-08-09 23:46:52 [24133] [4] WARNING: smsbox_list empty! > 2010-08-09 23:46:52 [24133] [4] DEBUG: Thread 4 > (gw/bb_boxc.c:sms_to_smsboxes) terminates. > 2010-08-09 23:46:52 [24133] [14] DEBUG: send_msg: sending msg to boxc: > <sqlbox> > > sqlbox is also getting each message as intended, and I can see it arriving > in its log, and I can also see bearerbox queuing them in the status > output. > > smsbox:sqlbox, IP 127.0.0.1 (110 queued), (on-line 0d 0h 0m 50s) > > The piece that's missing really seems to be the ACK from sqlbox to > bearerbox > for each DLR message it receives. bearerbox is successfully sending each > DLR > to sqlbox, and sqlbox is successfully logging it to the DB. However, as > sqlbox is sending no ACK back, bearerbox has no way of knowing that sqlbox > received the DLR and is therefore queuing it locally, and periodically > re-sending to sqlbox. > > Now I've read the sqlbox code, it seems that it's a thin shell and doesn't > implement ANY of the ACK processing that smsbox does. It simply logs to > the > DB, passes messages to smsbox and hopes that smsbox will pass it back an > ACK > that it can then pass to bearerbox so that the loop can be closed. > However, > without an smsbox connection, sqlbox is simply processing and dumping each > message from bearerbox, leading to the unnecessary queuing in bearerbox. > > Anyway, that's what I've worked out from a few hours of looking through > the > code. This is nothing compared to the years that everyone else has with > it, > and I'm happy to be proved wrong! > > Just as an aside, between the time I sent my earlier email and I saw your > response, I implemented a very rudimentary #2 (ACK in sqlbox) and it seems > to have resolved the issue. All I'm doing is checking on each message > receipt inside sqlbox to see if a smsbox is connected. If so then nothing > changes - if not, then sqlbox returns the successful ACK. > > Thanks, > Toby > > -----Original Message----- > From: Nikos Balkanas [mailto:nbalka...@gmail.com] > Sent: Tuesday, 10 August 2010 12:08 AM > To: Toby Phipps; 'Rene Kluwen'; users@kannel.org > Subject: Re: Life without smsbox > > Hi, > > You are missing an smsbox-route group. Once you configure that, your DLR > problem will disappear. You need to set an smsbox-id in your smsbox group > (I > > remeber you already have a dummy one), that corresponds to the id in your > sqlbox. Then configure that to your smsbox-route group. Right now your bb > is > > getting the DLRs, but doesn't know where to send them. Granted it is > pretty > lame to have only 1 smsbox connected to it, and not know what to do with > it. > > It could be fixed sometime. > > Do not proceed with (2). > > BR, > Nikos > ----- Original Message ----- > From: "Toby Phipps" <toby.phi...@nexmedia.com.sg> > To: "'Nikos Balkanas'" <nbalka...@gmail.com>; "'Rene Kluwen'" > <rene.klu...@chimit.nl>; <users@kannel.org> > Sent: Monday, August 09, 2010 6:17 PM > Subject: RE: Life without smsbox > > >> Hi Nikos, >> >> Thanks again for the feedback. You hit the nail on the head - I am seeing >> "WARNING: smsbox_list empty!" throughout the bearerbox log. Looks like >> running sqlbox alone is not enough to truly emulate a smsbox. >> >> So, I delved into the source for sqlbox, and from what I can see, it has >> no >> ACK response logic at all. It receives the DLR (or MO) from bearerbox, >> writes it to the DB and then passes it to a connected smsbox. It appears >> to >> rely on smsbox to generate the ACK - there's logic in there to pass >> smsbox >> messages back to bearerbox (which I assume would include the ACKs), but >> nothing to handle the situation where there is no smsbox connected. In >> this >> case, the message gets written to the DB then simply dropped, hence the >> queuing in bearerbox that I'm seeing. >> >> So, I'm looking at two options and would very much appreciate advice on >> which one would be most appropriate: >> >> 1. Configure a "dummy" smsbox to receive/ACK the messages from sqlbox but >> do >> nothing else them. Not sure if I can configure smsbox to do this (I'll >> hit >> the doc), whether I'll need to patch it to provide a "ACK and drop" mode, >> or >> whether I should have it call a dummy destination to avoid the patching. >> >> 2. Enhance sqlbox to generate its own ACK if it doesn't have a connected >> smsbox to pass the MO/DLR onto. >> >> Any suggestions? If not, I'll probably start on #2 as it seems much >> cleaner >> to me and avoids the unnecessary overhead of a dummy smsbox process and >> associated IPC. Who is the appropriate sqlbox owner that I should run >> these >> changes by? I'm sure I'm not the only one that has no need for smsbox. >> >> Thanks, >> Toby. >> >> -----Original Message----- >> From: Nikos Balkanas [mailto:nbalka...@gmail.com] >> Sent: Monday, 9 August 2010 2:17 AM >> To: Toby Phipps; 'Rene Kluwen'; users@kannel.org >> Subject: Re: Life without smsbox >> >> Hi, >> >> The only way for bearerbox to remove the DLR from store is to receive an >> upstream ACK (smsbox or sqlbox). That is the architectural spec. If this >> is >> not happenning, sqlbox has a bug. You could check for that in maximum >> detail >> >> bb (and sqlbox) logs. If there is a problem with routing or boxc ids in >> bb, >> you should get a lot of warnings like "Warning: smsbox-list empty!", >> which >> will also build up DLR store queue. >> >> BR, >> Nikos >> >> >> ----- Original Message ----- >> From: "Toby Phipps" <toby.phi...@nexmedia.com.sg> >> To: "'Rene Kluwen'" <rene.klu...@chimit.nl>; <users@kannel.org> >> Sent: Sunday, August 08, 2010 3:26 PM >> Subject: RE: Life without smsbox >> >> >>> Just a follow-up - I also tried setting "smsbox-id = sqlbox" in the >>> "sqlbox" >>> section, and sqlbox starts but I get the same results, which is that the >>> bearerbox store size increments by one for each DLR received, as viewed >>> in >>> the status output. For example: >>> >>> SMS: received 0 (0 queued), sent 13 (0 queued), store size 85 >>> >>> Right now, my sqlbox.conf looks like this: >>> >>> group = sqlbox >>> id = sqlbox >>> smsbox-id = sqlbox >>> bearerbox-port = 13100 >>> bearerbox-host = localhost >>> # smsbox-port = 13200 >>> sql-log-table = smsgw_kannel_sms_result >>> sql-insert-table = smsgw_kannel_sms_queue >>> log-file = /usr/local/kannel/log/sqlbox.log >>> log-level = 0 >>> >>> group = mysql-connection >>> id = sqlbox >>> host = localhost >>> username = <removed> >>> password = <removed> >>> database = <removed> >>> max-connections = 3 >>> >>> As you can see, the smsbox-port is commented out, meaning that I don't >>> want >>> sqlbox to try to talk to smsbox. I've tried with this line commented >>> out, >>> or >>> uncommented (but pointed to a non-listening port). Both result in the >>> same >>> behaviour, >>> >>> Any more ideas anyone? I'm about to start delving into the source... >>> >>> Thanks, >>> Toby. >>> >>> >>> >> >> > >
