i noticed that if i add ;alias param to contact header that does not
surround its contact uri in <>s like this:
Contact: sip:foo@bar;alias=value
then some sip entities interpret ;alias as header param rather than uri
param.
so i went and added <>s if they are not present resulting to this:
Contact: <sip:foo@bar;alias=value>
i have tried to figure out from rfc3261 what kind of param ;alias is in
the first example, but have not found the answer. looks like it is
unspecified in rfc3261.
any comments on this?
-- juha
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#105 - $Ts returns wrong timestamp
User who did this - Alex Hermann (axlh)
----------
Ok, that explains the first case in technical terms. Logically i still find it strange the $Ts in failure_route is not the same as the one in request_route because it is supposed to handle the same message/request.
The 2nd case of the timestamp being from an entirely different message is a bit more worrying. Besides the annoyance of the wrong timestamp, I fear the timestamp may not be the only variable not correctly being cleared/initialized when a fake reply is created. I still haven't dared to look into tm though, so can't say for sure.
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=105#comment140
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#105 - $Ts returns wrong timestamp
User who did this - Daniel-Constantin Mierla (miconda)
----------
The caching is done based on message id and process handling the message.
So it should be same value for a request all along to forward in a route block. But for failure_route can be another process, therefore it is different except a very unlikely case when it is same process that did the forward and was no other message processed there meanwhile.
Also, reply processing in onreply route is a different message than reprocessing request again in failure route even due to that reply.
There is a small potential of overlapping because of using only message ids for caching (this is not only for $Ts) -- there were some discussions to add PID as part of the ID for a better message unique key.
if you need the time of the moment when the request was received, the option is to store it in avp.
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=105#comment139
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
Daniel-Constantin Mierla has taken ownership of the following task:
FS#105 - $Ts returns wrong timestamp
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=105
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#105 - $Ts returns wrong timestamp
User who did this - Alex Hermann (axlh)
----------
Changed my mind, I still don't understand the first case.
In failure_route I would expect $Ts is either the same as $Ts in request_route for the same request or the same as $Ts in reply_route, certainly not yet another value.
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=105#comment138
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#105 - $Ts returns wrong timestamp
User who did this - Alex Hermann (axlh)
----------
Ok, the first case I can understand if the timestamp is strictly bound to the message, not the request. I can workaround it by storing the timestamp in an avp while handling the initial message.
But the 2nd case (the locally generated reply) seems to point to a serious failure to initialize memory locations.
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=105#comment137
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A user has added themself to the list of users assigned to this task.
FS#105 - $Ts returns wrong timestamp
User who did this - Alex Hermann (axlh)
http://sip-router.org/tracker/index.php?do=details&task_id=105
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A new Flyspray task has been opened. Details are below.
User who did this - Alex Hermann (axlh)
Attached to Project - sip-router
Summary - $Ts returns wrong timestamp
Task Type - Bug Report
Category - Core
Status - Assigned
Assigned To - Andrei Pelinescu-Onciul
Operating System - All
Severity - Low
Priority - Normal
Reported Version - Development
Due in Version - Undecided
Due Date - Undecided
Details - According to the docs on the wiki, $Ts should always return the same time for the same message. It doesn't, it returns the same time as $TS in most cases. It gets worse if the reply is locally generated (408), then the timestamp of the previous request handled by that process is returned.
Reproduce:
<code>
route {
xlog("Ts:$Ts TS:$TS request");
t_on_reply(REPLY);
t_on_failure(FAILURE);
t_relay();
}
on_reply_route[REPLY] {
xlog("Ts:$Ts TS:$TS reply");
}
failure_route[FAILURE] {
sleep(1);
xlog("Ts:$Ts TS:$TS failure");
}
</code>
Log:
First call:
<code>
Nov 26 14:10:08 wsproxy1[29897]: ERROR: <script>: Ts:1290777008 TS:1290777008 request
Nov 26 14:10:08 wsproxy1[29901]: ERROR: <script>: Ts:1290777008 TS:1290777008 reply
Nov 26 14:10:09 wsproxy1[29901]: ERROR: <script>: Ts:1290777009 TS:1290777009 failure
</code>
Expected would be that $Ts would always read 1290777008 for this call. As in failure_route the original request is handled, the expected value of $Ts would be the same as the initial value.
Next call:
<code>
Nov 26 14:10:09 wsproxy1[29908]: ERROR: <script>: Ts:1290777009 TS:1290777009 failure
</code>
Last call:
<code>
Nov 26 14:10:15 wsproxy1[29900]: ERROR: <script>: Ts:1290777015 TS:1290777015 request
<timeout>
Nov 26 14:10:16 wsproxy1[29908]: ERROR: <script>: Ts:1290777009 TS:1290777016 failure
</code>
Expected would be that $Ts would always read 1290777015 for this call, certainly not 1290777009.
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=105
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.