[SR-Users] Dispatcher module problem or feature?
Daniel-Constantin Mierla
miconda at gmail.com
Tue Jun 29 19:02:29 CEST 2010
On 6/29/10 6:49 PM, JR Richardson wrote:
> On Tue, Jun 29, 2010 at 11:33 AM, Daniel-Constantin Mierla
> <miconda at 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 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/
>>
>>
> 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/
More information about the sr-users
mailing list