[SR-Users] Dispatcher module problem or feature?
JR Richardson
jmr.richardson at gmail.com
Tue Jun 29 20:02:13 CEST 2010
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
Yes it printed now:
First invite:
0(6435) INFO: <script>: ********** INCOMING MESSAGE FOR
sip:2165 at 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 at 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
--
JR Richardson
Engineering for the Masses
More information about the sr-users
mailing list