24 Oct
2009
24 Oct
'09
9:29 a.m.
eu is asking operators to provide all kinds of statistics about their
telephone service.
one of the attributes is routing time of sip request, i.e., in/out delay
of sip requests.
in order to be able to do something like that, we could have a pseudo
variable that provides ms timestamp value or, perhaps better, a way to
zero a ms counter and then store its current value to a pseudo variable
in onsend_route. the problems seems to be that according to core
cookbook, it is not possible to set pseudo variables in onsend_route.
comments?
-- juha
24 Oct
24 Oct
12:43 p.m.
Hi Juha,
On Sat, Oct 24, 2009 at 9:29 AM, Juha Heinanen <jh(a)tutpro.com> wrote:
eu is asking operators to provide all kinds of
statistics about their
telephone service.
Could you please share any document/info you might have on this?
Cheers,
--
Victor Pascual Ávila
26 Oct
26 Oct
11:17 a.m.
On Samstag, 24. Oktober 2009, Juha Heinanen wrote:
Victor Pascual Avila writes:
Hi Juha,
never heard of this so far.. So you think they really want to have a exact
measurement for all and every call and not e.g. a average value?
I've searched a bit for this directive, and at least the (german/ austrian)
source i found only mentioned a max. average call-setup time of 3 seconds, and
95% of all connections should be setup in 4s. But this applies only to
national calls, otherwise it would be a bit harder to pass, if you look at
mobile calls, for example.
We generate values like this for our internal QoS monitoring from our
accounting.
Regards,
Henning
Could you please share any document/info you
might have on this?
victor,
EU directive is 2002/22/EU and QoS measurement requirements are based on
ETSI standard EG 202 057-1. i have not read them.
1:56 p.m.
Henning Westerholt writes:
I've searched a bit for this directive, and at
least the (german/ austrian)
source i found only mentioned a max. average call-setup time of 3
seconds, and
95% of all connections should be setup in 4s. But this applies only to
national calls, otherwise it would be a bit harder to pass, if you look at
mobile calls, for example.
henning,
in the finnish version, operator is required to measure availability of
service (99.9% target), blocked calls percentage (1% target), and then
the one that was the topic of my mail, i.e., call setup time.
data for the first two can be produced from accounting and monitoring
data, but i don't know any means on how to measure call setup time,
i.e., invite out time stamp - invite in time stamp.
-- juha
3:26 p.m.
On Montag, 26. Oktober 2009, Juha Heinanen wrote:
Hi Juha,
ah, i think we get this from a custom header extensions added from the UA
(FritzBox). It measures the time from the sended INVITE to the first received
provisional response or 200 OK. Not sure if you've this UA in your user set.
Another option that i got from the german version is that is possible to use
some external monitoring, i.e. just do some sampling.
Regards,
Henning
I've
searched a bit for this directive, and at least the (german/
austrian) source i found only mentioned a max. average call-setup time
of 3 seconds, and
95% of all connections should be setup in 4s. But this applies only to
national calls, otherwise it would be a bit harder to pass, if you look
at mobile calls, for example.
in the finnish version, operator is required to measure availability of
service (99.9% target), blocked calls percentage (1% target), and then
the one that was the topic of my mail, i.e., call setup time.
data for the first two can be produced from accounting and monitoring
data, but i don't know any means on how to measure call setup time,
i.e., invite out time stamp - invite in time stamp.
3:37 p.m.
Henning Westerholt writes:
ah, i think we get this from a custom header
extensions added from
the UA (FritzBox). It measures the time from the sended INVITE to
the first received
this does not measure "call setup time", i.e., invite in-out from
proxy.
provisional response or 200 OK. Not sure if you've
this UA in your user set.
Another option that i got from the german version is that is possible to use
some external monitoring, i.e. just do some sampling.
yes, you can use a monitoring tool that sends requests to proxy and then
calculates availability and blocking.
-- juha
4:16 p.m.
On Sat, Oct 24, 2009 at 8:29 AM, Juha Heinanen <jh(a)tutpro.com> wrote:
eu is asking operators to provide all kinds of
statistics about their
telephone service.
one of the attributes is routing time of sip request, i.e., in/out delay
of sip requests.
in order to be able to do something like that, we could have a pseudo
variable that provides ms timestamp value or, perhaps better, a way to
zero a ms counter and then store its current value to a pseudo variable
in onsend_route. the problems seems to be that according to core
cookbook, it is not possible to set pseudo variables in onsend_route.
comments?
Wouldn't it be possible to store the timestamp of request arrival in
an AVP at the beginning of request processing and then calculate the
difference from the current timestamp in on-send route?
Also, where do you want to store the resulting delay value, in the SIP
request itself?
-- Jan
4:15 p.m.
Jan Janak writes:
Wouldn't it be possible to store the timestamp of
request arrival in
an AVP at the beginning of request processing and then calculate the
difference from the current timestamp in on-send route?
that would be possible too, but it needs to be a ms timestamp, which
would not fit into an int. a ms counter that would start counting from
zero, would fit.
Also, where do you want to store the resulting delay
value, in the SIP
request itself?
no, to an avp from which i could then add it to radius accounting record
when response to invite arrives.
-- juha
5:24 p.m.
On Mon, Oct 26, 2009 at 4:15 PM, Juha Heinanen <jh(a)tutpro.com> wrote:
Jan Janak writes:
How about using ticks then? Ticks fit into a 32-bit number. By default
there are 16 ticks per second (but you can change it in
timer_ticks.h), would that provide enough precision?
See sip-router/timer_ticks.h
-- Jan
Wouldn't it be possible to store the
timestamp of request arrival in
an AVP at the beginning of request processing and then calculate the
difference from the current timestamp in on-send route?
that would be possible too, but it needs to be a ms timestamp, which
would not fit into an int. a ms counter that would start counting from
zero, would fit.
5:52 p.m.
On Mon, Oct 26, 2009 at 5:11 PM, Juha Heinanen <jh(a)tutpro.com> wrote:
Jan Janak writes:
OK, then I think everything you need should already be there. You can
use get_ticks_raw() to get the ticks value and store it in an AVP.
Various macros for comparison and conversion of ticks are in
timer_ticks.h.
Some documentation (written by Andrei) is in doc/timers.txt
-- Jan
How about using ticks then? Ticks fit into a
32-bit number. By default
there are 16 ticks per second (but you can change it in
timer_ticks.h), would that provide enough precision?
yes, 16 ticks per second would be enough.
5:35 p.m.
Jan Janak writes:
OK, then I think everything you need should already be
there. You can
use get_ticks_raw() to get the ticks value and store it in an AVP.
Various macros for comparison and conversion of ticks are in
timer_ticks.h.
the problem may be writing tick difference to an avp in onsend_route
block. is that possible and allowed?
-- juha
6:29 p.m.
26 okt 2009 kl. 17.52 skrev Jan Janak:
On Mon, Oct 26, 2009 at 5:11 PM, Juha Heinanen
<jh(a)tutpro.com> wrote:
Now found on this URL in doxygen:
http://sip-router.org/doxygen/sip-router/branch/master/TimerDoc.html
:-)
/O
Jan Janak writes:
OK, then I think everything you need should already be there. You can
use get_ticks_raw() to get the ticks value and store it in an AVP.
Various macros for comparison and conversion of ticks are in
timer_ticks.h.
Some documentation (written by Andrei) is in doc/timers.txt How about using ticks then? Ticks fit into a
32-bit number. By
default
there are 16 ticks per second (but you can change
it in
timer_ticks.h), would that provide enough precision?
yes, 16 ticks per second would be enough. 
27 Oct
27 Oct
12:45 p.m.
On Oct 24, 2009 at 10:29, Juha Heinanen <jh(a)tutpro.com> wrote:
eu is asking operators to provide all kinds of
statistics about their
telephone service.
one of the attributes is routing time of sip request, i.e., in/out delay
of sip requests.
in order to be able to do something like that, we could have a pseudo
variable that provides ms timestamp value or, perhaps better, a way to
zero a ms counter and then store its current value to a pseudo variable
in onsend_route. the problems seems to be that according to core
cookbook, it is not possible to set pseudo variables in onsend_route.
The problem is pseudo-vars can do a lot of stuff, not all of which would
be safe from an onsend_route (anything modifying the message is not
allowed), so everything is disabled (upon future review).
It would be better/safer to write a module function for this.
Besides this I'm not sure it would be useful. I assume the routing time
should include the full time between a request being seen on the wire
and the forwarded request making back to "the wire" and not only the
script routing delay.
Most of the times if you don't do a lot of db stuff and the dns lookups
hit the cache, you should have very low script running times (not sure
ms is enough to measure them). However the send() operation can take a
lot of time (both on udp and especially on tcp or sctp). Using
onsend_route you won't see the send delay. To be able to see the
complete receive and send delays you will need external monitoring.
Timing the script execution from the moment the request is seen by sr
(which is not always the time the request was received by the network
card) to the moment just before the request is sent can be used to
raise alarms when script execution takes too much, but I doubt it has
any value in calculating the routing delay of the whole box.
Andrei
1:03 p.m.
andrei,
thanks for your explanation about onsend_route. it is indeed a better
idea to use an external monitoring tool to measure sr's switching
delay.
-- juha
5319
days inactive
5322
days old
16 comments
6 participants
participants (6)
-
Andrei Pelinescu-Onciul -
Henning Westerholt -
Jan Janak -
jh＠tutpro.com -
Olle E. Johansson -
Victor Pascual Avila