True. You have the same smsbox-id for both smsbox and sqlbox. It should be different.
But... probably sqlbox isn't going to send an ACK. At least I didn't put it in the code. Maybe someone else. == Rene -----Original Message----- From: Nikos Balkanas [mailto:[email protected]] Sent: Monday, 09 August, 2010 19:07 To: Toby Phipps; 'Rene Kluwen'; [email protected] Subject: Re: Life without smsbox I reiterate. SQLbox shouldn't have such an error. Your smsbox-route is not correct, you need to specify smsc-id. Read User's guide about it. You should still be getting that WARNING. Solve that, and you should be set. BR, Nikos ----- Original Message ----- From: "Toby Phipps" <[email protected]> To: "'Nikos Balkanas'" <[email protected]>; "'Rene Kluwen'" <[email protected]>; <[email protected]> Sent: Monday, August 09, 2010 7:59 PM Subject: RE: Life without smsbox > Hmm, OK. Interesting. I've reverted to the SVN head of sqlbox and > configured > the following: > > group = smsbox > bearerbox-host = localhost > smsbox-id = sqlbox > > group = smsbox-route > smsbox-id = sqlbox > > 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 > > Now, I see the following in bearerbox.log: > > 2010-08-10 00:53:11 [1691] [13] DEBUG: boxc_receiver: sms received > 2010-08-10 00:53:11 [1691] [13] DEBUG: send_msg: sending msg to boxc: > <sqlbox> > 2010-08-10 00:53:11 [1691] [14] DEBUG: send_msg: sending msg to boxc: > <sqlbox> > 2010-08-10 00:53:11 [1691] [14] DEBUG: boxc_sender: sent message to > <127.0.0.1> > 2010-08-10 00:53:17 [1691] [14] DEBUG: send_msg: sending msg to boxc: > <sqlbox> > 2010-08-10 00:53:17 [1691] [14] DEBUG: boxc_sender: sent message to > <127.0.0.1> > > The lines at 00:53:11 are written when the MT is sent out. The lines at > 00:53:17 are written when the DLR arrives. > > And... unfortunately the queuing is back - here's the relevant status > output: > > SMS: received 0 (0 queued), sent 2 (0 queued), store size 4 > SMS: inbound (0.00,0.00,0.00) msg/sec, outbound (0.01,0.01,0.01) msg/sec > > DLR: received 4, sent 0 > DLR: inbound (0.02,0.01,0.01) msg/sec, outbound (0.00,0.00,0.00) msg/sec > DLR: 262 queued, using mysql storage > > Box connections: > smsbox:sqlbox, IP 127.0.0.1 (4 queued), (on-line 0d 0h 4m 39s) > > I still chalk the queuing up to a missing ACK from sqlbox - the following > line is missing from the logs: > DEBUG: boxc_receiver: got ack > > When I had smsbox running and calling a dummy URL to get rid of DLRs, that > ack would appear each time a message (MT or DLR) was sent to sqlbox. > > So, I'm still convinced that the DLR routing to sqlbox is happening, and > that bearerbox is just getting upset as it gets no ACK from sqlbox. My > hypothesis regarding the "WARNING: smsbox_list empty!" message is that > bearerbox isn't getting a smsbox registration message (as sqlbox doesn't > generate one, and relies on the non-existent smsbox to do so), but is > still > routing both MT notifications and DLRs to sqlbox as it's been instructed > to > do. I'd be happy to be proved wrong though! > > Thanks, > Toby. > > > -----Original Message----- > From: Nikos Balkanas [mailto:[email protected]] > Sent: Tuesday, 10 August 2010 12:31 AM > To: Toby Phipps; 'Rene Kluwen'; [email protected] > 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" <[email protected]> > To: "'Nikos Balkanas'" <[email protected]>; "'Rene Kluwen'" > <[email protected]>; <[email protected]> > 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:[email protected]] >> Sent: Tuesday, 10 August 2010 12:08 AM >> To: Toby Phipps; 'Rene Kluwen'; [email protected] >> 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" <[email protected]> >> To: "'Nikos Balkanas'" <[email protected]>; "'Rene Kluwen'" >> <[email protected]>; <[email protected]> >> 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:[email protected]] >>> Sent: Monday, 9 August 2010 2:17 AM >>> To: Toby Phipps; 'Rene Kluwen'; [email protected] >>> 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" <[email protected]> >>> To: "'Rene Kluwen'" <[email protected]>; <[email protected]> >>> 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. >>>> >>>> >>>> >>> >>> >> >> > >
