Re: access log format

Yeah, I've read that, but considering that latest stable is 1.4.3 and  
1.5.0 is still being planned, I don't know what you're talking about...

Are you talking about CVS HEAD? Then, what's the timestamp of your  
checked out version?
--
Alejandro Guerrieri
[email protected]



On 18/09/2009, at 13:51, Alok Vaidya wrote:

> Hi Alenjandro,
>
> I had mentioned about the version in my first mail. It is Kannel -  
> 1.5.0.
>
> Alejandro Guerrieri wrote:
>>
>> Alok,
>>
>> Which version are specifically using to do this tests? CVS? Date?
>>
>> Maybe you have a routing issue and messages are being re-injected?  
>> Or, if you're using 1.4.3 or an old CVS, intermediate DLR's would  
>> be seen as MO's as well.
>>
>> Regards,
>> --
>> Alejandro Guerrieri
>> [email protected]
>>
>>
>>
>> On 18/09/2009, at 12:48, Alok Vaidya wrote:
>>
>>> Hi,
>>>
>>> Thanks for replying. Yes I checked the documentation we can  
>>> certainly have a custom format, but it is about the events that I  
>>> talking here like "Sent SMS"/"FAILED SMS"/"Discarded SMS" etc., I  
>>> see some changes there. Mostly I have figured them out but, I fail  
>>> to understand some other entries which I have mentioned below as  
>>> also I want to know more such changes.
>>>
>>> Let me elaborate why this causes problems. Our parser uses  
>>> patterns such as "Failed SMS" to search for current (14.2 box)  
>>> entries, now this event logging has changed to "FAILED SEND SMS"  
>>> naturally this will not be picked up and hence we loose on such  
>>> entries. That's my point here.
>>>
>>> Entries I cannot figure out:
>>>
>>> [1]
>>> 2009-09-18 13:27:45 Receive SMS [SMSC:smpp_g12] [SVC:]  
>>> [ACT:labroc] [BINF:] [from:sssstest1] [to:+919920315112] [FID:]  
>>> [UUID:48425955-1cad-4fe3-8867-bb56fc0bd685] [flags:-1:2:-1:0:-1]  
>>> [msg: 
>>> 132 
>>> : 
>>> 69643A34383633636164632D633162322D346239662D623335382D623739386336633638356436207375623A30303020646C7672643A303031207375626D697420646174653A30393039313831323033303720646F6E6520646174653A30393039313831323033313220737461743A52454A45435444206572723A30303020746578743A 
>>> ] [udh:6:050003DC0901]
>>>
>>> [2]
>>> 2009-09-18 13:27:45 Receive SMS [SMSC:smpp_g12] [SVC:]  
>>> [ACT:labroc] [BINF:] [from:sssstest1] [to:+919920315112] [FID:]  
>>> [UUID:eed80f6d-3d78-4140-a556-dbb59a856d8f]      
>>> [flags:-1:0:-1:0:-1] [msg:132:id:0f22f6f9-8faf-4290-94c1- 
>>> ce451fa18e21 sub:000 dlvrd:001 submit date:090918120227 done date: 
>>> 090918120242 stat:REJECTD err:000 text:] [udh:6:050003DB0801]
>>>
>>> [3]
>>> 2009-09-18 13:27:45 Receive SMS [SMSC:smpp_g73] [SVC:]  
>>> [ACT:labroc] [BINF:] [from:sssstest1] [to:+919920315112] [FID:]  
>>> [UUID:a935aaad-b36c-4e42-8fee-d8e1f03571bf] [flags:-1:2:-1:0:-1]  
>>> [msg: 
>>> 132 
>>> : 
>>> 69643A66363666323135382D333732352D343337652D616137312D633763333161633234366665207375623A30303020646C7672643A303031207375626D697420646174653A30393039313831323337353720646F6E6520646174653A30393039313831323338323520737461743A52454A45435444206572723A30303020746578743A 
>>> ] [udh:6:050003DD0901]
>>>
>>> The first entry appears to be a normal MT, why then it is named  
>>> "Receive SMS" instead of "Sent SMS" ? The second entry though it  
>>> has the same event "Receive SMS" appears to be a DLR. Again the 3  
>>> rd entry seems to be a notmal MT message. I tried to make sense of  
>>> the flags but to no use.
>>>
>>> Alejandro Guerrieri wrote:
>>>>
>>>> Alok,
>>>>
>>>> Check the documentation, you can specify the access log format to  
>>>> be whatever you like.
>>>>
>>>> Regards,
>>>> --
>>>> Alejandro Guerrieri
>>>> [email protected]
>>>>
>>>>
>>>>
>>>> On 18/09/2009, at 12:23, Alok Vaidya wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I am writing to this list instead of the "users" one because  
>>>>> people from this list are more probable of having an answer to  
>>>>> my question.
>>>>>
>>>>> Can anyone please elaborate the new access-log-format, I know we  
>>>>> have moved from 1.4.x to 1.5, I see some compatibility broken  
>>>>> here. We have a process that parses the log files and this  
>>>>> format change/break could cost us dear.
>>>>> <alok.vcf>
>>>>
>>> <alok.vcf>
>>
> <alok.vcf>