2 Jun
2004
2 Jun
'04
1:36 p.m.
Guys,
For those relying on Radius accounting generated by SER beware that the
combination of RadAcctId-AcctSessionId is not at all unique. If you
use MySQL for storage of radius accounting you will miss CDRs every now
and then (because is a unique index) and the update queries will
update calls from the past as a result, calls with huge duration are
being generated.
The problem is generated by a combination of factors:
1. Some UAs reuse same call id among multiple calls (Grandstream
systematically show this behaviour)
2. The Acct-Unique-Session-Id is not unique either, it repeats itself
every now and then.
I would appreciate to see reactions for this problem from the
developers.
Regards,
Adrian
2 Jun
2 Jun
3:01 p.m.
New subject: [Serusers] Re: [Serdev] Radius accounting unreliable
At 01:36 PM 6/2/2004, AG Projects support wrote:
Guys,
For those relying on Radius accounting generated by SER beware that the combination of
RadAcctId-AcctSessionId is not at all unique. If you use MySQL for storage of radius
accounting you will miss CDRs every now and then (because is a unique index) and the
update queries will update calls from the past as a result, calls with huge duration are
being generated.
The problem is generated by a combination of factors:
1. Some UAs reuse same call id among multiple calls (Grandstream systematically show this
behaviour)
Indeed, that's why serweb uses combination of callid with from and to-tags
for accounting, something similar can be certainly used with Radius+mysql.
-jiri
3:35 p.m.
New subject: [Serusers] Re: [Serdev] Radius accounting unreliable
We do that "as a dirty trick " but looking in my statistics those tags
are repeating themselves at a far higher rate than Radius ids. It seems
a matter of luck of having a unique combination.
If Acct-Unique-Session-Id would be unique it solve the problem at
radius server level independent of broken UAs who are reusing
Acct-Session-Id.
Do you know where is the Acct-Unique-Session-Id generated, is it radius
client or SER ?
Adrian
On Jun 2, 2004, at 3:01 PM, Jiri Kuthan wrote:
At 01:36 PM 6/2/2004, AG Projects support wrote:
Guys,
For those relying on Radius accounting generated by SER beware that
the combination of RadAcctId-AcctSessionId is not at all unique. If
you use MySQL for storage of radius accounting you will miss CDRs
every now and then (because is a unique index) and the update
queries will update calls from the past as a result, calls with huge
duration are being generated.
The problem is generated by a combination of factors:
1. Some UAs reuse same call id among multiple calls (Grandstream
systematically show this behaviour)
Indeed, that's why serweb uses combination of callid with from and
to-tags
for accounting, something similar can be certainly used with
Radius+mysql.
-jiri
_______________________________________________
Serdev mailing list
serdev(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serdev 
3:37 p.m.
New subject: [Serusers] Re: [Serdev] Radius accounting unreliable
We do that "as a dirty trick " but looking in my statistics those tags
are repeating themselves at a far higher rate than Radius ids. It seems
a matter of luck of having a unique combination.
If Acct-Unique-Session-Id had been unique it would solve the problem at
RADIUS server level independent of broken UAs who are reusing
Acct-Session-Id (the SIP call id).
Do you know where is the Acct-Unique-Session-Id generated, is it radius
client or SER ?
Adrian
On Jun 2, 2004, at 3:01 PM, Jiri Kuthan wrote:
At 01:36 PM 6/2/2004, AG Projects support wrote:
Guys,
For those relying on Radius accounting generated by SER beware that
the combination of RadAcctId-AcctSessionId is not at all unique. If
you use MySQL for storage of radius accounting you will miss CDRs
every now and then (because is a unique index) and the update
queries will update calls from the past as a result, calls with huge
duration are being generated.
The problem is generated by a combination of factors:
1. Some UAs reuse same call id among multiple calls (Grandstream
systematically show this behaviour)
Indeed, that's why serweb uses combination of callid with from and
to-tags
for accounting, something similar can be certainly used with
Radius+mysql.
-jiri
_______________________________________________
Serdev mailing list
serdev(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serdev 
4:14 p.m.
New subject: [Serusers] Monitoring tool
Hi all,
What software do you use for making sure that your sipserver(s) are online
and working?
I'm on the lookout for something that I can use with Nagios (ie anything
that I can run from a shellprompt).
I have tried sipsak but it's not working on solaris (some strange
bind/socket operations that breaks the program)
I would like the same feature as sipsak has,
1. Register account
2. Call account
3. Check for invite
Doing an external call to a free number would also be nice, just wait for
the 200 OK and then cancel the call.
Best regards,
Thomas Björklund
4:38 p.m.
New subject: [Serusers] Monitoring tool
we usa nagios with sipsak on linux. I don't know how sipsak is doing
on solaris. (sipsak author cc-ed). We register only. cancelling when
a 200 comes back does not work, that's too late already.
-jiri
At 04:14 PM 6/2/2004, Tomas Björklund wrote:
Hi all,
What software do you use for making sure that your sipserver(s) are online
and working?
I'm on the lookout for something that I can use with Nagios (ie anything
that I can run from a shellprompt).
I have tried sipsak but it's not working on solaris (some strange
bind/socket operations that breaks the program)
I would like the same feature as sipsak has,
1. Register account
2. Call account
3. Check for invite
Doing an external call to a free number would also be nice, just wait for
the 200 OK and then cancel the call.
Best regards,
Thomas Björklund
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
Jiri Kuthan http://iptel.org/~jiri/
3 Jun
3 Jun
12:04 p.m.
New subject: [Serusers] Monitoring tool
On Wed, 2 Jun 2004, Jiri Kuthan wrote:
we usa nagios with sipsak on linux. I don't know
how sipsak is doing
on solaris. (sipsak author cc-ed). We register only. cancelling when
a 200 comes back does not work, that's too late already.
-jiri
Thanks Jiri,
I'll try to solve this with Nils outside of the mailinglist.
Best regards,
Thomas Björklund
6 Jun
6 Jun
9:50 p.m.
New subject: [Serusers] Monitoring tool
Hello,
to keep you informed: the problem with Tomas server was that is does signale
asymmetric (it sends responses from another port the the listening port).
I just committed the new release 0.8.9 of sipsak, which should fix this
problem.
Thomas: can you please verify and confirm if this new sipsak version works
with your server or not?
Thanks and greetings
Nils
On Thursday 03 June 2004 12:04, Tomas Björklund wrote:
On Wed, 2 Jun 2004, Jiri Kuthan wrote:
we usa nagios with sipsak on linux. I don't
know how sipsak is doing
on solaris. (sipsak author cc-ed). We register only. cancelling when
a 200 comes back does not work, that's too late already.
-jiri
Thanks Jiri,
I'll try to solve this with Nils outside of the mailinglist.
Best regards,
Thomas Björklund
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
7 Jun
7 Jun
10:03 a.m.
New subject: [Serusers] Monitoring tool
On Sun, 6 Jun 2004, Nils Ohlmeier wrote:
I just committed the new release 0.8.9 of sipsak,
which should fix this
problem.
Thomas: can you please verify and confirm if this new sipsak version works
with your server or not?
Thanks and greetings
Nils
Nils and the list,
I'm sorry to report that there still is some problems using it with the
Cisco SIP Proxy server.
I'll take it offlist with ju Nils.
Best regards,
Thomas Björklund
10:45 a.m.
New subject: [Serusers] Monitoring tool
At 10:03 AM 6/7/2004, Tomas Björklund wrote:
On Sun, 6 Jun 2004, Nils Ohlmeier wrote:
may I suggest you to use SER -- I'm confident your problem will be easy to
fix then.
Andy
I just committed the new release 0.8.9 of sipsak,
which should fix this
problem.
Thomas: can you please verify and confirm if this new sipsak version works
with your server or not?
Thanks and greetings
Nils
Nils and the list,
I'm sorry to report that there still is some problems using it with the
Cisco SIP Proxy server.
2 Jun
2 Jun
5:18 p.m.
New subject: [Serusers] Monitoring tool
Hello,
On Wednesday 02 June 2004 16:14, Tomas Björklund wrote:
What software do you use for making sure that your
sipserver(s) are online
and working?
I'm on the lookout for something that I can use with Nagios (ie anything
that I can run from a shellprompt).
I have tried sipsak but it's not working on solaris (some strange
bind/socket operations that breaks the program)
Please send me the exact error messages. I'll then try to fix it. But a few
weeks ago it worked for me on Solaris. Anyway, sent me any input that i can
try to fix it. I have no Solaris machine availbale.
I would like the same feature as sipsak has,
1. Register account
2. Call account
3. Check for invite
Doing an external call to a free number would also be nice, just wait for
the 200 OK and then cancel the call.
I'll not add any feature which establishes a dialog with another SIP UA,
because sipsak has no SIP stack and the results would be probably horrible.
But with sipsak you can first register a user and then sipsak tries to call
itself on this just before registered account. This should show if your
normal INVITE processing is still working (Note: sipsak does not support
record-routing yet).
Greetings
Nils
3 Jun
3 Jun
1:11 a.m.
New subject: [Serusers] Re: [Serdev] Radius accounting unreliable
At 03:37 PM 6/2/2004, Adrian Georgescu wrote:
We do that "as a dirty trick " but looking in
my statistics those tags are repeating themselves at a far higher rate than Radius ids. It
seems a matter of luck of having a unique combination.
I don't think that including tags is a dirty trick. Dialogs are idenfitied by
triple callid-fromtag-totag, an INVITE may initiate multiple dialogs, and keeping
the information complete is clean. This information should be relatively unique
even if UAC fails to generate random values -- callee's From tag will be good then.
If Acct-Unique-Session-Id had been unique it would
solve the problem at RADIUS server level independent of broken UAs who are reusing
Acct-Session-Id (the SIP call id).
Do you know where is the Acct-Unique-Session-Id generated, is it radius client or SER ?
I'm not sure.
-jiri
10:16 a.m.
New subject: [Serusers] Re: [Serdev] Radius accounting unreliable
I realize now that the triplet has tags from both user agents so it
should be safe enough.
Thanks Jiri
Adrian
On Jun 3, 2004, at 1:11 AM, Jiri Kuthan wrote:
At 03:37 PM 6/2/2004, Adrian Georgescu wrote:
We do that "as a dirty trick " but
looking in my statistics those
tags are repeating themselves at a far higher rate than Radius ids.
It seems a matter of luck of having a unique combination.
I don't think that including tags is a dirty trick. Dialogs are
idenfitied by
triple callid-fromtag-totag, an INVITE may initiate multiple dialogs,
and keeping
the information complete is clean. This information should be
relatively unique
even if UAC fails to generate random values -- callee's From tag will
be good then.
If Acct-Unique-Session-Id had been unique it
would solve the problem
at RADIUS server level independent of broken UAs who are reusing
Acct-Session-Id (the SIP call id).
Do you know where is the Acct-Unique-Session-Id generated, is it
radius client or SER ?
I'm not sure.
-jiri
2:27 a.m.
New subject: [Serusers] Re: [Serdev] Radius accounting unreliable
It is generated by the radiusclient library. I found the following using
google:
http://lists.cistron.nl/pipermail/freeradius-devel/2002-September/003530.ht…
Maybe you could find some solution if you google more.
Jan.
On 02-06 15:37, Adrian Georgescu wrote:
We do that "as a dirty trick " but looking
in my statistics those tags
are repeating themselves at a far higher rate than Radius ids. It seems
a matter of luck of having a unique combination.
If Acct-Unique-Session-Id had been unique it would solve the problem at
RADIUS server level independent of broken UAs who are reusing
Acct-Session-Id (the SIP call id).
Do you know where is the Acct-Unique-Session-Id generated, is it radius
client or SER ?
Adrian
On Jun 2, 2004, at 3:01 PM, Jiri Kuthan wrote:
At 01:36 PM 6/2/2004, AG Projects support wrote:
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers Guys,
For those relying on Radius accounting generated by SER beware that
the combination of RadAcctId-AcctSessionId is not at all unique. If
you use MySQL for storage of radius accounting you will miss CDRs
every now and then (because is a unique index) and the update
queries will update calls from the past as a result, calls with huge
duration are being generated.
The problem is generated by a combination of factors:
1. Some UAs reuse same call id among multiple calls (Grandstream
systematically show this behaviour)
Indeed, that's why serweb uses combination of callid with from and
to-tags
for accounting, something similar can be certainly used with
Radius+mysql.
-jiri
_______________________________________________
Serdev mailing list
serdev(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serdev
7426
days inactive
7431
days old
14 comments
7 participants
participants (7)
-
Adrian Georgescu -
AG Projects support -
Andy Blen -
Jan Janak -
Jiri Kuthan -
Nils Ohlmeier -
Tomas Björklund