THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task is now closed:
FS#120 - DNS SRV balancing doesn't work
User who did this - Andrei Pelinescu-Onciul (andrei)
Reason for closing: Not a bug
Additional comments about closing: not a bug, expected behaviour for weight == 0 (see comments).
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=120
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#120 - DNS SRV balancing doesn't work
User who did this - Andrei Pelinescu-Onciul (andrei)
----------
It's not a bug, try a non-zero weight and it should work as expected.
0 weights are a special case (the order is not exactly defined in this case and according to the algorithm from rfc2782 if all records have 0 weights, the first will be always selected).
RFC2782 Page 3-4:
Weight
....
<code>
Domain administrators SHOULD use Weight 0 when there isn't any server
selection to do, to make the RR easier to read for humans (less
noisy).
</code>
....
<code>
The following
algorithm SHOULD be used to order the SRV RRs of the same
priority:
To select a target to be contacted next, arrange all SRV RRs
(that have not been ordered yet) in any order, except that all
those with weight 0 are placed at the beginning of the list.
Compute the sum of the weights of those RRs, and with each RR
associate the running sum in the selected order. Then choose a
uniform random number between 0 and the sum computed
(inclusive), and select the RR whose running sum value is the
first in the selected order which is greater than or equal to
the random number selected. The target host specified in the
selected SRV RR is the next one to be contacted by the client.
</code>
....
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=120#comment170
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#120 - DNS SRV balancing doesn't work
User who did this - Alex Hermann (axlh)
----------
It seems to work ok when the weight != 0.
That made me reread rfc2782 and made me conclude that i misread rfc 2782, i now see that this bugreport is invalid.
Sorry for the noise.
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=120#comment169
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 - DNS SRV balancing doesn't work
Task Type - Bug Report
Category - dns / dns cache
Status - Assigned
Assigned To - Andrei Pelinescu-Onciul
Operating System - All
Severity - High
Priority - Normal
Reported Version - 3.1
Due in Version - Undecided
Due Date - Undecided
Details - Request to a domain served by SRV records all go to the same host.
The domain is as follows:
<code>
_sip._udp.srv.test. 44 IN SRV 10 0 5060 172.28.4.250.
_sip._udp.srv.test. 44 IN SRV 10 0 5061 172.28.4.251.
_sip._udp.srv.test. 44 IN SRV 10 0 5062 172.28.4.252.
_sip._udp.srv.test. 44 IN SRV 10 0 5063 172.28.4.253.
</code>
Expected behavior would be that each host would receive an (approximate) equal amount of requests. in practice, one of them gets them all. The winning host changes after most restarts of kamailio, which suggests the randomization is done only once instead of for every request as is necessary.
DNS related settings:
<code>
dns_use_search_list=no
use_dns_failover=yes
dns_srv_lb=yes
</code>
Results from a run of 20 (near simultaneous) calls to the above domain (format <call-number> <destination>):
<code>
1 172.28.4.251:5061
2 172.28.4.251:5061
3 172.28.4.251:5061
4 172.28.4.251:5061
5 172.28.4.251:5061
6 172.28.4.251:5061
7 172.28.4.251:5061
8 172.28.4.251:5061
9 172.28.4.251:5061
10 172.28.4.251:5061
11 172.28.4.251:5061
12 172.28.4.251:5061
13 172.28.4.251:5061
14 172.28.4.251:5061
15 172.28.4.251:5061
16 172.28.4.251:5061
17 172.28.4.251:5061
18 172.28.4.251:5061
19 172.28.4.251:5061
20 172.28.4.251:5061
1 172.28.4.250:5060
2 172.28.4.250:5060
3 172.28.4.250:5060
4 172.28.4.250:5060
5 172.28.4.250:5060
6 172.28.4.250:5060
7 172.28.4.250:5060
8 172.28.4.250:5060
9 172.28.4.250:5060
10 172.28.4.250:5060
11 172.28.4.250:5060
12 172.28.4.250:5060
13 172.28.4.250:5060
14 172.28.4.250:5060
15 172.28.4.250:5060
16 172.28.4.250:5060
17 172.28.4.250:5060
18 172.28.4.250:5060
19 172.28.4.250:5060
20 172.28.4.250:5060
1 172.28.4.253:5063
2 172.28.4.253:5063
3 172.28.4.253:5063
4 172.28.4.253:5063
5 172.28.4.253:5063
6 172.28.4.253:5063
7 172.28.4.253:5063
8 172.28.4.253:5063
9 172.28.4.253:5063
10 172.28.4.253:5063
11 172.28.4.253:5063
12 172.28.4.253:5063
13 172.28.4.253:5063
14 172.28.4.253:5063
15 172.28.4.253:5063
16 172.28.4.253:5063
17 172.28.4.253:5063
18 172.28.4.253:5063
19 172.28.4.253:5063
20 172.28.4.253:5063
1 172.28.4.252:5062
2 172.28.4.252:5062
3 172.28.4.252:5062
4 172.28.4.252:5062
5 172.28.4.252:5062
6 172.28.4.252:5062
7 172.28.4.252:5062
8 172.28.4.252:5062
9 172.28.4.252:5062
10 172.28.4.252:5062
11 172.28.4.252:5062
12 172.28.4.252:5062
13 172.28.4.252:5062
14 172.28.4.252:5062
15 172.28.4.252:5062
16 172.28.4.252:5062
17 172.28.4.252:5062
18 172.28.4.252:5062
19 172.28.4.252:5062
20 172.28.4.252:5062
</code>
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=120
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#120 - DNS SRV balancing doesn't work
User who did this - Alex Hermann (axlh)
http://sip-router.org/tracker/index.php?do=details&task_id=120
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.
Module: sip-router
Branch: master
Commit: 0956052b4e28c941c55c0d5e4b5550ee12b222ed
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=0956052…
Author: Marius Zbihlei <marius.zbihlei(a)1and1.ro>
Committer: Marius Zbihlei <marius.zbihlei(a)1and1.ro>
Date: Mon Mar 21 17:17:12 2011 +0200
modules_k/rr Do not falsely recover after strict route if RURI matches the server
Check if the RURI contains an lr param. If it doesn't, than the request
doesn't come after a strict route server, as Kamailio always adds a lr parameter(always loose routes)
This fixes problems with re-SUBSCRIBEs where RURI identifies the resourse and can be the same as the initial
subscribe.
---
modules_k/rr/loose.c | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/modules_k/rr/loose.c b/modules_k/rr/loose.c
index 9cf1ef9..b34eb65 100644
--- a/modules_k/rr/loose.c
+++ b/modules_k/rr/loose.c
@@ -928,7 +928,15 @@ int loose_route(struct sip_msg* _m)
#else
if (is_myself(&_m->parsed_uri.host, _m->parsed_uri.port_no)) {
#endif
- return after_strict(_m);
+ /* even if RURI is myself check to see if it's really after_strict by
+ looking over the lr param, as kamailio always adds it
+ If lr is missing, than surely this was not after strict
+ */
+ if(!is_strict(GET_RURI(_m))){
+ return after_strict(_m);
+ } else {
+ return after_loose(_m, 0);
+ }
} else {
return after_loose(_m, 0);
}
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 - named flags not working for at least acc module
Task Type - Bug Report
Category - Core
Status - Assigned
Assigned To - Andrei Pelinescu-Onciul
Operating System - All
Severity - Low
Priority - Normal
Reported Version - 3.1
Due in Version - Undecided
Due Date - Undecided
Details - According to the wiki page http://sip-router.org/wiki/cookbooks/core-cookbook/devel#isflagset named flags are supported, but using them for the acc module throws multiple errors:
<code>
flags acc:1
modparam("acc", "log_flag", acc)
</code>
results in:
<code>
0(14923) : <core> [cfg.y:3412]: parse error in config file /etc/kamailio.cfg, line 71, column 29-31: syntax error
0(14923) : <core> [cfg.y:3412]: parse error in config file /etc/kamailio.cfg, line 71, column 29-31: Invalid arguments
0(14923) : <core> [cfg.y:3415]: parse error in config file /etc/kamailio.cfg, line 71, column 32:
ERROR: bad config file (3 errors)
</code>
Where line 71 corresponds to the modparam line.
Quoting the parameter value doesn't help.
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=119
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#119 - named flags not working for at least acc module
User who did this - Alex Hermann (axlh)
http://sip-router.org/tracker/index.php?do=details&task_id=119
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.