[SR-Users] Dispatcher module problem or feature?
Daniel-Constantin Mierla
miconda at gmail.com
Tue Jun 29 18:33:43 CEST 2010
On 6/29/10 6:17 PM, JR Richardson wrote:
> On Tue, Jun 29, 2010 at 10:25 AM, Daniel-Constantin Mierla
> <miconda at 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20100629/1cfffb12/attachment.htm>
More information about the sr-users
mailing list