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
Hi Juha,
On Sat, Oct 24, 2009 at 9:29 AM, Juha Heinanen jh@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,
On Samstag, 24. Oktober 2009, Juha Heinanen wrote:
Victor Pascual Avila writes:
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.
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
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
On Montag, 26. Oktober 2009, Juha Heinanen wrote:
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.
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
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
On Sat, Oct 24, 2009 at 8:29 AM, Juha Heinanen jh@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
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
On Mon, Oct 26, 2009 at 4:15 PM, Juha Heinanen jh@tutpro.com wrote:
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.
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
On Mon, Oct 26, 2009 at 5:11 PM, Juha Heinanen jh@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?
yes, 16 ticks per second would be enough.
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
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
26 okt 2009 kl. 17.52 skrev Jan Janak:
On Mon, Oct 26, 2009 at 5:11 PM, Juha Heinanen jh@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?
yes, 16 ticks per second would be enough.
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
Now found on this URL in doxygen:
http://sip-router.org/doxygen/sip-router/branch/master/TimerDoc.html
:-)
/O
On Oct 24, 2009 at 10:29, Juha Heinanen jh@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
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
-
Andrei Pelinescu-Onciul -
Henning Westerholt -
Jan Janak -
jh＠tutpro.com -
Olle E. Johansson -
Victor Pascual Avila