-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, from my point of view, you can disable this feature. I use the siptrace module "only" for supporting lawful interception on signalling level. There I think I can do without ACKs since ACKs are not containing too much usefull informations. Further, debugging of sipflows is done with a separate tool. regards Helmut Bogdan-Andrei Iancu schrieb: | 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 | | _______________________________________________ | Users mailing list | Users(a)lists.openser.org | http://lists.openser.org/cgi-bin/mailman/listinfo/users | |

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 ;).

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

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(a)lists.openser.org >> http://lists.openser.org/cgi-bin/mailman/listinfo/devel

I'm not referring to dialog tracing, but to setting siptracing only for certain cases (and not for all calls).

Hmm...that will be an idea - If I remember correctly, setting siptrace user will override the global tracing flag.