2010/3/16 mustafa rifaee mustafa.rifaee@gmail.com:
Hi all, I would like to asking you
Hi, it's just better to keep the thread in the maillist.
about the Time-stamp header in SIP messages, and why this header does not supported in most open SIP servers, Is it recommended or not?
Is this fact true ?? I think The problem is that both UAS and UAC must have the same system time to generate a useful result. So therefore both or all SIP devices (think about an intermediate proxy) must have NTP activated.
That's not true. The request can contain a header like:
TimeStamp: 25
and the proxy/server replies in the 100 Trying:
TimeStamp: 25 0.001
This means that it has token 0.001 seconds to the server in order to process the request and generate the 100 response.
-- Iñaki Baz Castillo ibc@aliax.net
On 03/16/2010 01:12 PM, Iñaki Baz Castillo wrote:
That's not true. The request can contain a header like:
TimeStamp: 25
and the proxy/server replies in the 100 Trying:
TimeStamp: 25 0.001
It seems to me that the a proxy processing an initial request directed to it should be able to insert such a header in a reply, but that Kamailio does not have support for timing functions that perform these measurements automatically. Would you agree?
2010/3/16 Alex Balashov abalashov@evaristesys.com:
It seems to me that the a proxy processing an initial request directed to it should be able to insert such a header in a reply, but that Kamailio does not have support for timing functions that perform these measurements automatically. Would you agree?
Well, a workaround could be take the current time at the top of the script, then just before the t_relay (the real time it takes to the proxy to process the request) calculate the delta time and generate a stateless 100 reply adding suche header. Then call to t_relay with the proper flag to avoid sending a new 100 response.
On 03/16/2010 01:54 PM, Iñaki Baz Castillo wrote:
2010/3/16 Alex Balashovabalashov@evaristesys.com:
It seems to me that the a proxy processing an initial request directed to it should be able to insert such a header in a reply, but that Kamailio does not have support for timing functions that perform these measurements automatically. Would you agree?
Well, a workaround could be take the current time at the top of the script, then just before the t_relay (the real time it takes to the proxy to process the request) calculate the delta time and generate a stateless 100 reply adding suche header. Then call to t_relay with the proper flag to avoid sending a new 100 response.
Sure. What I meant is that apart from $Ts in K >= 3.0.x, there aren't really any ways to compute the delay on that level of time resolution. Are there?
2010/3/16 Alex Balashov abalashov@evaristesys.com:
Sure. What I meant is that apart from $Ts in K >= 3.0.x, there aren't really any ways to compute the delay on that level of time resolution. Are there?
Yes, right. I did something similar long time ago and just got seconds precision :)
Hello,
On 03/16/2010 07:03 PM, Iñaki Baz Castillo wrote:
2010/3/16 Alex Balashovabalashov@evaristesys.com:
Sure. What I meant is that apart from $Ts in K>= 3.0.x, there aren't really any ways to compute the delay on that level of time resolution. Are there?
Yes, right. I did something similar long time ago and just got seconds precision :)
one of the old function in textops is append_time() which adds a date header, with complete date and time, still up to second precision. http://kamailio.org/docs/modules/3.0.x/modules_k/textops.html#id2494947
It is true that before 3.0.0 there was no script variable returning better time precision than second, devel has it as timeval variable: http://sip-router.org/wiki/cookbooks/pseudo-variables/devel#timeval
But there are options to do it in case you really need better precision, using sql query, exec or perl. Not only those, because benchmark has a nicer way to get the difference of time for config execution: http://kamailio.org/docs/modules/stable/modules_k/benchmark.html#id2521780
Then adding a header to a local generated reply is easy.
Cheers, Daniel
You could also send the 100 trying response at the beginning of the script. the the processing delay is almost 0 :-)
klaus
Am 16.03.2010 18:54, schrieb Iñaki Baz Castillo:
2010/3/16 Alex Balashovabalashov@evaristesys.com:
It seems to me that the a proxy processing an initial request directed to it should be able to insert such a header in a reply, but that Kamailio does not have support for timing functions that perform these measurements automatically. Would you agree?
Well, a workaround could be take the current time at the top of the script, then just before the t_relay (the real time it takes to the proxy to process the request) calculate the delta time and generate a stateless 100 reply adding suche header. Then call to t_relay with the proper flag to avoid sending a new 100 response.
True. :)
-- Sent from mobile device
On Mar 16, 2010, at 3:15 PM, Klaus Darilion <klaus.mailinglists@pernau.at
wrote:
You could also send the 100 trying response at the beginning of the script. the the processing delay is almost 0 :-)
klaus
Am 16.03.2010 18:54, schrieb Iñaki Baz Castillo:
2010/3/16 Alex Balashovabalashov@evaristesys.com:
It seems to me that the a proxy processing an initial request directed to it should be able to insert such a header in a reply, but that Kamailio does not have support for timing functions that perform these measurements automatically. Would you agree?
Well, a workaround could be take the current time at the top of the script, then just before the t_relay (the real time it takes to the proxy to process the request) calculate the delta time and generate a stateless 100 reply adding suche header. Then call to t_relay with the proper flag to avoid sending a new 100 response.
2010/3/16 Klaus Darilion klaus.mailinglists@pernau.at:
You could also send the 100 trying response at the beginning of the script. the the processing delay is almost 0 :-)
Yes, and you can also reply "200 OK" at the beginning of the script in order no call to fail XDDDDDDDDD