THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#493 - Fix kamalio.spec for Centos
User who did this - Daniel-Constantin Mierla (miconda)
----------
Thanks for this fix. The patch is invalid as it was attached. Can you quickly re-post it, not to add the parts manually?
The error is:
<code>
patch -p0< ~/Downloads/patch-spec.patch
patching file pkg/kamailio/centos/6/kamailio.spec
patch: **** malformed patch at line 21: @@ -706,7 +712,7 @@
</code>
----------
More information can be found at the following URL:
https://sip-router.org/tracker/index.php?do=details&task_id=493#comment1698
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#494 - usrloc: REGISTER with new callid gets updated on memory but not on DB
User who did this - Daniel-Constantin Mierla (miconda)
----------
Default value for db_ops_ruid is 1 salting with 4.2.
If you tested the patch and all is ok, it can be back ported.
----------
More information can be found at the following URL:
https://sip-router.org/tracker/index.php?do=details&task_id=494#comment1697
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.
Víctor Seva has taken ownership of the following task:
FS#494 - usrloc: REGISTER with new callid gets updated on memory but not on DB
More information can be found at the following URL:
https://sip-router.org/tracker/index.php?do=details&task_id=494
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#494 - usrloc: REGISTER with new callid gets updated on memory but not on DB
User who did this - Víctor Seva (linuxmaniac)
----------
> What version are you using? Have you tried with db_ops_ruid parameter set to 1?
This was reported for 4.1.6. No, I did not tried with db_ops_ruid = 1.
> The patch is good anyhow to solve the old db operations mode, you can commit it.
I'm going to commit this to master. I think this should be backported to 4.1/4.2 too.
> In long term, the db update/delete operations should be done on ruid only, the other options should be removed – they are costly due to mach value size (e.g., when someone has a long path set).
Should we change the default value of db_ops_ruid as a first step?
----------
More information can be found at the following URL:
https://sip-router.org/tracker/index.php?do=details&task_id=494#comment1696
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#494 - usrloc: REGISTER with new callid gets updated on memory but not on DB
User who did this - Daniel-Constantin Mierla (miconda)
----------
What version are you using? Have you tried with db_ops_ruid parameter set to 1?
The patch is good anyhow to solve the old db operations mode, you can commit it.
In long term, the db update/delete operations should be done on ruid only, the other options should be removed -- they are costly due to mach value size (e.g., when someone has a long path set).
----------
More information can be found at the following URL:
https://sip-router.org/tracker/index.php?do=details&task_id=494#comment1695
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 - Víctor Seva (linuxmaniac)
Attached to Project - sip-router
Summary - usrloc: REGISTER with new callid gets updated on memory but not on DB
Task Type - Bug Report
Category - Module
Status - New
Assigned To -
Operating System - All
Severity - Low
Priority - Normal
Reported Version - Development
Due in Version - Undecided
Due Date - Undecided
Details - First REGISTER with callid X gets registered with no problem ( mem and db are in sync )
If the UAC send a new REGISTER before getting expire and this new REGISTER has a different callid in memory the register is OK but on DB the register is never updated.
The main problem in my opinion is that we don't obey the match_option at db_update_ucontact_addr nor db_delete_ucontact_addr.
the callid is in the where part of the query.
One or more files have been attached.
More information can be found at the following URL:
https://sip-router.org/tracker/index.php?do=details&task_id=494
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.
Hello,
as most of you know, we have a rather distributed infrastructure, with
servers provided from different companies or persons.
We came to the time when one of the servers is too old and considered to
be decommisioned, so we have to decide how to move on. It is about
sip-router.org, who was offered/sponsored by courtesy of Jan Janak. From
project point of view, the server hosts:
- git repository
- bug tracker
- website and wiki under domain sip-router.org
Given that no matter what we like, there is work to do, I am looking to
see what are the best options out there for everyone involved in the
project.
The sip-router.or wbesite and wiki, which are not really updated anyhow,
will be relocated as virtual host in kamailio.org server and made static
for historic purposes.
For git and tracker, I thought of two variants:
1) move to use an external hosting service - the first candidate and
perhaps the only to be considered is GitHub, we have there already a
real time mirror of git repository. Then we should get a read only
mirror to kamailio.org. If the tracker on github is good enough for
everyone, then we will use it. I could see quickly that lot of kamailio
developers already have an account on github.
2) get a new server and relocate those components there. It will need to
be configured from scratch and the components eventually updated to use
latest versions. In case of tracker, we have eventually to re-evaluate
if flyspray worth keeping, as we had several discussions, due to the
fact that the project doesn't seem to be very active.
My personal preference at this moment is 1), given that offloads
administration works from project.
For 2) we will need someone to commit to a sysadmin job for long time.
As probably you noticed lately, serious security vulnerabilities can
appear and someone needs to take care of proper maintenance of the
server. I don't want to get all services on kamailio.org, as it has
other critical components (mailing lists, releases, website, ...) and
messing it or overloading doesn't make sense.
There is no real pressure to come to a decision, we can still rely on
the server for a while, but I would rather not postpone it for long.
While users are encouraged to give their opinion, I feel that existing
developers should have the main role in decision, being something that
impacts them directly.
Your preference? Any other opinions?
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Nov 24-27, Berlin - http://www.asipto.com