[SR-Users] Dispatcher module problem or feature?

[Daniel-Constantin Mierla]

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/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20100629/51669c29/attachment.htm>