Hi,

Thanks for your comments, Alok. In reality I do believe that log parsing 
exceeds the DLR mechanism, and offers much more information. I was just trying 
to scope whether there would be interest for such a tool in maintree kannel.

Therefore, it is of interest to me, as well, to see that log format is 
preserved. Of course if it were part of the maintree, anytime logs would 
change, the analyzer would be updated accordingly.

In the userguide it describes:

" Result: Send, failed, DLR (deliver report), Received, etc."

The file gw/bb_smscconn.c has not changed according to the CVS for at least 3 
years.

Points raised:

1) MTs are reported as MOs: "Receive SMS"
2) MOs are no longer discriminated from DLRs: "Receive SMS".
3) No text status is given (i.e. Failed SMS).

Checking at last week's CVS sources, (no smsc connection to try out):

1) Code discriminates between sent and received SMS:

Sent SMS
Receive SMS
Receive DLR

I have verified the logs in the MO case. Can someone confirm it for MTs?

2) Code clearly separates between MOs and DLRs:

Receive SMS
Receive DLR

3) The following text statuses are supported:

DISCARDED SMS
FAILED Send SMS
REJECTED - not white-listed SMS
REJECTED - not white-regex-listed SMS
REJECTED - black-listed SMS
REJECTED - black-regex-listed SMS
DROPPED Received DLR
DROPPED Received SMS

This is an all-inclusive list of all text tokens in bb's access logs. I see no 
evidence of something been removed from the code, and nothing of the sort 
described in CVS history.

BR,
Nikos
  ----- Original Message ----- 
  From: Alejandro Guerrieri 
  To: Alok Vaidya 
  Cc: Kannel Devel 
  Sent: Saturday, September 19, 2009 6:13 PM
  Subject: Re: access log format


  What's the issue? Sorry after so many garbage on the thread I still not see 
what's the point. Logs are fine and any changes made on the format are 
documented on ChangeLog.


  If your software croaks with the new format, either define a custom log 
format or change your software to use the new one. You don't expect that 
everybody else should accommodate to your particular requirements right?


  Regards,
  --
  Alejandro Guerrieri
  [email protected]



  [..snip..]

Reply via email to