On 6/29/10 6:49 PM, JR Richardson wrote:
On Tue, Jun 29, 2010 at 11:33 AM, Daniel-Constantin Mierla
<mico...@gmail.com> wrote:
On 6/29/10 6:17 PM, JR Richardson wrote:
On Tue, Jun 29, 2010 at 10:25 AM, Daniel-Constantin Mierla
<mico...@gmail.com> wrote:
Hi JR,
On 6/28/10 11:39 PM, JR Richardson wrote:
Hi All,
I'm testing dispatcher functions with kamailio 3.0 and using database
to load destination address. The problem I am seeing is the 1'st
destination address in a group is not being used, the dispatcher
always starts at the second database entry. For instance, if I have 2
destination addresses listed in the database, sip:10.10.14.101:5060
and sip:10.10.14.102:5060, only sip:10.10.14.102:5060 will receive
calls. But if I list .101 in the database twice, then I will get
proper distribution.
looks like a feature :-) ... Can you print the list of avp holding the
destination addresses after you call ds_select_dst()? you can do it with the
avp_print() from avpops module or with a 'while' iterating through the avps.
Say you have:
modparam("dispatcher", "dst_avp", "$avp(dst)")
$var(i) = 0;
while($(avp(dst)[$var(i)])) {
xlog(" --- $(avp(dst)[$var(i)]) \n");
$var(i) = $var(i) + 1;
}
Pasting here the parameters you set for dispatcher module would be helpful
as well.
Cheers,
Daniel
So here is my setup and some debug traffic:
sipp><sr-router><dispatcher round robin group 1><10.10.14.101,
10.10.14.102, 10.10.14.101
This will send calls to both .101 and 102 evenly.
sip-router2:~# kamctl fifo ds_list
SET:: 1
URI:: sip:10.10.14.101:5060 flag=A
URI:: sip:10.10.14.102:5060 flag=A
URI:: sip:10.10.14.101:5060 flag=A
first call to dispatcher:
0(4780) DEBUG: dispatcher [dispatch.c:1111]: set [1]
0(4780) DEBUG: dispatcher [dispatch.c:1185]: alg hash [0]
0(4780) DEBUG: dispatcher [dispatch.c:1223]: selected [4-1/0]
<sip:10.10.14.101:5060>
0(4780) DEBUG: dispatcher [dispatch.c:1257]: using entry [1/1]
0(4780) INFO:<script>: ds_dispatcher sip:10.10.14.101:5060 1 3
second call to dispatcher:
0(4780) DEBUG: dispatcher [dispatch.c:1111]: set [1]
0(4780) DEBUG: dispatcher [dispatch.c:1185]: alg hash [1]
0(4780) DEBUG: dispatcher [dispatch.c:1223]: selected [4-1/1]
<sip:10.10.14.102:5060>
0(4780) DEBUG: dispatcher [dispatch.c:1245]: using entry [1/0]
0(4780) INFO:<script>: ds_dispatcher sip:10.10.14.102:5060 1 3
third call to dispatcher goes back to .101, then .102, ect.
sipp><sr-router><dispatcher round robin group 2><10.10.14.103 and
10.10.14.104
This will send calls only to .104
sip-router2:~# kamctl fifo ds_list
SET_NO:: 2
SET:: 2
URI:: sip:10.10.14.104:5060 flag=A
URI:: sip:10.10.14.103:5060 flag=A
first call to dispatcher:
0(4780) DEBUG: dispatcher [dispatch.c:1111]: set [2]
0(4780) DEBUG: dispatcher [dispatch.c:1185]: alg hash [0]
0(4780) DEBUG: dispatcher [dispatch.c:1223]: selected [4-2/0]
<sip:10.10.14.104:5060>
0(4780) INFO:<script>: ds_dispatcher sip:10.10.14.104:5060 2 2
second call to dispatcher:
0(4780) DEBUG: dispatcher [dispatch.c:1111]: set [2]
0(4780) DEBUG: dispatcher [dispatch.c:1185]: alg hash [1]
0(4780) DEBUG: dispatcher [dispatch.c:1223]: selected [4-2/0]
<sip:10.10.14.104:5060>
0(4780) INFO:<script>: ds_dispatcher sip:10.10.14.104:5060 2 2
So it appears with only 2 entries loaded in the database, there is a
missing "DEBUG: dispatcher [dispatch.c:1245]: using entry [1/0]" This
is the only difference I can see between the call executions between
the two groups. But I don't really know what that means.
I can reproduce these symptoms on kamailio 3.0, 1.5.x and older
versions. The same thing happens when the destinations are loaded via
config file dispatcher.lst.
I am using debian Lenny with siremis web interface.
mysql> select * from dispatcher\G;
*************************** 1. row ***************************
id: 1
setid: 1
destination: sip:10.10.14.101:5060
flags: 0
priority: 0
description: lab1
*************************** 2. row ***************************
id: 2
setid: 1
destination: sip:10.10.14.102:5060
flags: 0
priority: 0
description: lab2
*************************** 3. row ***************************
id: 3
setid: 2
destination: sip:10.10.14.103:5060
flags: 0
priority: 0
description: lab3
*************************** 4. row ***************************
id: 4
setid: 2
destination: sip:10.10.14.104:5060
flags: 0
priority: 0
description: lab4
*************************** 5. row ***************************
id: 5
setid: 1
destination: sip:10.10.14.101:5060
flags: 0
priority: 0
description: lab1
5 rows in set (0.00 sec)
Is this a bug?
Thanks.
JR
--
Daniel-Constantin Mierla
http://www.asipto.com/
Here is my config, ds_list and sip call debug:
http://pastebin.com/NsNZyzdk
I put the 'while' snip in the config but I don't wee where it printed
anything in the debug.
Try with:
modparam("dispatcher", "use_default", 0)
You have it set to 1, which means the last address in set in not loaded in
dispatching algorithm - still it should be in the list of dst avps.
Not sure why the avps are not printed, try add one log message for the first
and compare against $null, like:
if(ds_select_domain("$avp(s:dstgrp)", "4")) {
xlog("L_INFO", " --- first dst avp: $avp(i:271) \n");
$var(i) = 0;
while($(avp(i:271)[$var(i)])!=$null) {
xlog("L_INFO", " --- $(avp(i:271)[$var(i)]) \n");
$var(i) = $var(i) + 1;
}
If still nothing, use avp_print().
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com/
Ok, modparam("dispatcher", "use_default", 0) is the key, when set to 1
it will skip the first entry in the database and not send any calls to
that destination unless all other destinations have failed. So set
use_default to "0" and the dispatcher behaves as expected. I guess I
was confused, the description on the modules page was not clear to me,
I did not realize the action was to skip entry 1 (when loaded is the
last entry). Maybe that can be clarified on the modules page?
Thanks for pointing that out, I probably would have left it at "1" and
just keep putting a third entry in the database with the same
destination as entry 1.
I will try to make that more clear in documentation. The order in the
destination set is pretty random if you don't set priority, being added
as mysql returns the rows in the result.
However, that address (first, last, whatsoever ...) should have been in
avp list and used as last option. Do you still get nothing printed for
dst avps?
Thanks,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com/
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
