On Tue, Jun 29, 2010 at 10:25 AM, Daniel-Constantin Mierla miconda@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.

Thanks.

JR

On Tue, Jun 29, 2010 at 11:33 AM, Daniel-Constantin Mierla miconda@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 miconda@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.

Best Regards,

Thanks

JR

On Tue, Jun 29, 2010 at 11:33 AM, Daniel-Constantin Mierla miconda@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 miconda@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

Yes it printed now:

First invite:

0(6435) INFO: <script>: ********** INCOMING MESSAGE FOR sip:2165@10.10.12.23:5060 ********** 0(6435) INFO: <script>: max forwards is ok, proceed 0(6435) INFO: <script>: sanity check is ok, proceed 0(6435) INFO: <script>: message length is ok 0(6435) INFO: <script>: subnet or sender is trusted, proceed 0(6435) INFO: <script>: message is not an option, proceed 0(6435) INFO: <script>: message did not have to-tag, proceed as initial request 0(6435) INFO: <script>: message is not a CANCEL, proceed 0(6435) INFO: <script>: route has been recorded, proceed 0(6435) INFO: <script>: message is complete, proceed 0(6435) INFO: <script>: call has prefix, route to dispatcher 0(6435) INFO: <script>: enter route dispatcher 0(6435) INFO: <script>: set variable dstgrp to 1 0(6435) INFO: <script>: set variable dstgrp from avp s:dstgrp 1 0(6435) INFO: <script>: --- first dst avp: sip:10.10.14.102:5060 0(6435) INFO: <script>: dispatcher sip:10.10.14.102:5060 0(6435) INFO: <script>: dispatcher sip:10.10.14.101:5060 0(6435) INFO: <script>: dispatcher dest-sip:10.10.14.102:5060 group-1 count-2 0(6435) INFO: <script>: dispatch group 1, check trans then goto route-relay 0(6435) INFO: <script>: t-relay in route-relay 0(6435) INFO: <script>: route 1 exit

second invite:

0(6435) INFO: <script>: ********** INCOMING MESSAGE FOR sip:2165@10.10.12.23:5060 ********** 0(6435) INFO: <script>: max forwards is ok, proceed 0(6435) INFO: <script>: sanity check is ok, proceed 0(6435) INFO: <script>: message length is ok 0(6435) INFO: <script>: subnet or sender is trusted, proceed 0(6435) INFO: <script>: message is not an option, proceed 0(6435) INFO: <script>: message did not have to-tag, proceed as initial request 0(6435) INFO: <script>: message is not a CANCEL, proceed 0(6435) INFO: <script>: route has been recorded, proceed 0(6435) INFO: <script>: message is complete, proceed 0(6435) INFO: <script>: call has prefix, route to dispatcher 0(6435) INFO: <script>: enter route dispatcher 0(6435) INFO: <script>: set variable dstgrp to 1 0(6435) INFO: <script>: set variable dstgrp from avp s:dstgrp 1 0(6435) INFO: <script>: --- first dst avp: sip:10.10.14.101:5060 0(6435) INFO: <script>: dispatcher sip:10.10.14.101:5060 0(6435) INFO: <script>: dispatcher sip:10.10.14.102:5060 0(6435) INFO: <script>: dispatcher dest-sip:10.10.14.101:5060 group-1 count-2 0(6435) INFO: <script>: dispatch group 1, check trans then goto route-relay 0(6435) INFO: <script>: t-relay in route-relay 0(6435) INFO: <script>: route 1 exit

Looks like it is working as expected with modparam("dispatcher", "use_default", 0). Thanks for your guidance.

Thanks.

JR