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.