[OpenSER-Users] [OpenSER-Devel] [RFC] - siptrace change

[Bogdan-Andrei Iancu]

Hi Dan,

Dan Pascu wrote:
> On Thursday 15 May 2008, Bogdan-Andrei Iancu wrote:
>   
>> Hi Dan,
>>
>> First just to be sure - I'm referring to incoming ACKs due negative
>> stateless replies (sl_send_reply). The other ACKs are not affected.
>>
>> yes, the problem has two sides:
>>     - some of us use siptrace to get the traffic for all users (like
>> you) - others are using siptrace to get traffic per user (like me) -
>> and btw, it is not so complicated to do it ;).
>>     
>
> Yes, it is. I have to add a rr param and keep tracing it from the script. 
> Also I need to encode the user I'm tracing somehow in the record route, 
> so I can set the avp with the user for in-dialog requests later. If one 
> wants to use this for legal interception, this is unacceptable as hints 
> about the user being traced will leak into the SIP messages. If you only 
> want to trace some calls for debugging purposes, then it can be done but 
> it is still cumbersome and very "manual".
>
>   
I'm not referring to dialog tracing, but to setting siptracing only for 
certain cases (and not for all calls).

Regards,
Bogdan
>> Now, just to explain my case:
>>
>> Let's assume a platform with 1000 online users. These users generates
>> 10K of calls per day. So, I will have 10k of auth requests (for
>> invite), so 10K of ACK (for to 407).
>> So, if I want to trace one or two users on the system, I will end up
>> with at least 10K of records fir these ACKs I really do not care.
>>
>> Maybe, until the filtering is extended for ACK tracing, I suggest a
>> short patch to enable/disable stateless ACK tracing via a module
>> parameter. This will server the needs of all people, I guess
>>     
>
> Make a module param until a better solution is found then. This is fine 
> with me. Or even better do not log these specific ACKs if global tracing 
> is not enabled. Then no extra parameter is needed.
>   
Hmm...that will be an idea - If I remember correctly, setting siptrace 
user will override the global tracing flag.
>   
>> This should be for 1.3.2 - for 1.4 I hope we can come up with a better
>> solution.
>>
>> Regards,
>> Bogdan
>>
>> Dan Pascu wrote:
>>     
>>> We use it to trace all traffic, at least on small installations and I
>>> wouldn't want to miss those ACKs. I cannot use the per user tracing
>>> capability because it is very cumbersome to trace all the requests
>>> and replies for a certain user with the current implementation.
>>>
>>> On Wednesday 14 May 2008, Bogdan-Andrei Iancu wrote:
>>>       
>>>> Hi,
>>>>
>>>> I would like to get your opinion/comments on some siptrace issue.
>>>>
>>>> In 1.3, a new capability was added in siptrace - to trace the ACK
>>>> resulted from sending stateless replies.
>>>>
>>>> The problem I discovered with this is that it cannot be controlled
>>>> by selecting the messages or transactions to be be traced. Usually
>>>> you use siptrace to trace only certain transactions / messages -
>>>> tracing all traffic is usually not a realistic option.
>>>>
>>>> So, with the stateless ACK, the siptrace module cannot apply the
>>>> selection from script and trace them all, with no filtering at all.
>>>> So, if you want to trace a traffic for a single user, all ACK going
>>>> through the platform will be traced.
>>>>
>>>> This reduces the usability of the module and you get a lot of
>>>> garbage tracing.
>>>>
>>>> My suggestion will be to disable stateless ACK tracing until a way
>>>> to control/filter it is found. I'm asking this considering the
>>>> upcoming 1.3.2 release from tomorrow.
>>>>
>>>> Regards,
>>>> Bogdan
>>>>
>>>> _______________________________________________
>>>> Devel mailing list
>>>> Devel at lists.openser.org
>>>> http://lists.openser.org/cgi-bin/mailman/listinfo/devel
>>>>         
>
>
>
>