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
-----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@lists.openser.org | http://lists.openser.org/cgi-bin/mailman/listinfo/users | |
Hi Helmut,
As explaining to Dan, this discussion is only about ACK resulting from sl_send_reply(negative reply)). 200 OK ACKs and statefull ACKs will still be logged.
Regards, Bogdan
Helmut Kuper wrote:
-----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@lists.openser.org | http://lists.openser.org/cgi-bin/mailman/listinfo/users | | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkgq5YMACgkQ4tZeNddg3dyJCACgopF5ByV+nMwcj7JNbsL5vu06 aIYAn09xRZMDP2ecEs6r7swma969ZNVd =LBFW -----END PGP SIGNATURE-----
On Thursday 15 May 2008, Bogdan-Andrei Iancu wrote:
Hi Helmut,
As explaining to Dan, this discussion is only about ACK resulting from sl_send_reply(negative reply)). 200 OK ACKs and statefull ACKs will still be logged.
If one uses it for debugging purposes than seeing every incoming and outgoing packet is helpful to trace problems. Right now we do not see the outgoing ACK that comes after a 200 OK. The ACK to stateless replies was also not available in the beginning and was only added later. I would hate to see it removed again. Lets rather disable it if global tracing is not enabled so that all users are happy. Ideally we should find a better solution and also find a solution to log the outgoing e2e ACKs.
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@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
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@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
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".
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.
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@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
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@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
On Thursday 15 May 2008, Bogdan-Andrei Iancu wrote:
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).
Yes, but if you want to trace all requests that belong to a dialog then you have to connect the dots, since siptrace is not dialog aware. When one logs everything it doesn't matter, but when one only wants to log certain users, then you have to keep track of the dialog yourself in the script.
Hmm...that will be an idea - If I remember correctly, setting siptrace user will override the global tracing flag.
That's correct. If the global tracing flag is not set, but the user avp is set it will do per user tracing.
-
Bogdan-Andrei Iancu -
Dan Pascu -
Helmut Kuper