In its default behaviour, bearerbox does the reassembling of fragments of long sms before delivering a one long sms to smsbox, so in access log you'll only see the reassembled sms without udh header set.
Setting sms-combine-concatenated-mo to false will lead bearerbox to not to reassemble fragments, you'll get every fragment in a separate line in access log, but you'll get to reassemble the fragments by yourself in this case and i think this is not what you expect :) There's still two solutions: 1. Set your smsc log to debug and then grep for 'deliver_sm' lines, every deliver_sm is a MO. 2. In case your log will grow quick with high sms traffic when set to debug level, reset the level to its default and play with tcp traffic snooping, some users even made a snort pattern on the deliver_sm pdu and count them using Snort. Regards, Fourat On Sat, Mar 17, 2012 at 10:29 PM, Saad Omer <[email protected]> wrote: > I checked the logs in access file. Incoming long messages do not have udh > starting with 0500 in access-kannel file. Example:**** > > ** ** > > 2011-03-09 15:12:38 Receive SMS [SMSC:710] [SVC:] [ACT:710] [BINF:] [FID:] > [META:?smpp?] [from:xxxxxxxxxxxx] [to:710] [flags:-1:0:-1:0:-1] > [msg:190:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] > [udh:0:]**** > > ** ** > > Am I looking in the wrong file? **** > > ** ** > > Regards,**** > > ** ** > > *From:* Fourat ZOUARI [mailto:[email protected]] > *Sent:* Wednesday, February 22, 2012 11:54 PM > *To:* [email protected] > *Cc:* kannel users > *Subject:* Re: Reconcile of incoming SMS (MO SMS)**** > > ** ** > > You can check if udh starts with 0500, that's a fragmented SMS.**** > > ** ** > > And of course, set sms-combine-concatenated-mo = false**** > > ** ** > > This will lead you to receive long MOs in a parted way, if it's not what > you want, then you can set your smsc log to debug level and grep for > submit_sm PDUs > > **** > > On Mon, Sep 13, 2010 at 2:40 PM, [email protected] <[email protected]> wrote:**** > > Hi,**** > > ** ** > > I need to bill my operator for the incoming SMS to my application (MO > messages). For calculating all the received SMS, I grep the phrase "Receive > SMS" from the access-log file, which should give the me actual count of > incoming SMS. However, there are issues I see by comparing different files: > **** > > ** ** > > - If I get a long SMS (more than 160 characters), the operator counts it > as 2 messages (of course it is logical as per GSM standard), but kannel > considers it as one single message (in access-log file: *EXAMPLE*: 2010-09-09 > 20:00:24 Receive SMS [SMSC:polling] [SVC:] [ACT:] [BINF:] [FID:] > [from:xxxxxxxx] [to:71606] [flags:-1:0:-1:0:-1] > [msg:210:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] > [udh:0:]). Since I grep the word "Receive SMS", I am unable to capture the > additional information of additional SMS unless I do some advanced > scripting.**** > > How to fix this bug in reconcile? Any other log file/method that could > give me correct count for incoming SMS? Can sqlbox do it? Currently I am > not using it.**** > > ** ** > > - I see difference between total counts of received SMS from the kannel > status page (*polling* SMPP:xxx.xx.xx.xxx:17601/17601:716:716 (online > 17563s, rcvd 2454, sent 54088, failed 0, queued 0 msgs) and the count I > get by running grep command on access-log (grep "Receive SMS" > access-log.log). Apparantly, messages reported by kannel status are more > than what I can see in the logs. If I assume that kannel status is > reporting the correct number of incoming SMS including the long message > factor, then how can I extract this count from kannel status, since its > counters are reset everytime I restart bearerbox.**** > > ** ** > > Regards,**** > > ** ** > > Hamza**** > > ** ** >
