[SR-Users] Dispatcher module problem or feature?

JR Richardson jmr.richardson at gmail.com
Mon Jun 28 23:39:36 CEST 2010


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.

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
-- 
JR Richardson
Engineering for the Masses



More information about the sr-users mailing list