Re: [SR-Users] Dispatcher module problem or feature?
On Tue, Jun 29, 2010 at 10:25 AM, Daniel-Constantin Mierla
mico...@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:
sippsr-routerdispatcher round robin group 110.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:]: 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:]: 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.
sippsr-routerdispatcher round robin group 210.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:]: 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:]: 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.
Thanks.
JR
--
JR Richardson
Engineering for the Masses
___
SIP Express Router (SER) and
Re: [SR-Users] Dispatcher module problem or feature?
On 6/29/10 6:17 PM, JR Richardson wrote:
On Tue, Jun 29, 2010 at 10:25 AM, Daniel-Constantin Mierla
mico...@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:
sippsr-routerdispatcher round robin group 110.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:]: 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:]: 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.
sippsr-routerdispatcher round robin group 210.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:]: 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:]: 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 -
Re: [SR-Users] Dispatcher module problem or feature?
On 6/29/10 6:49 PM, JR Richardson wrote:
On Tue, Jun 29, 2010 at 11:33 AM, Daniel-Constantin Mierla
mico...@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
mico...@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:
sippsr-routerdispatcher round robin group 110.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:]: 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:]: 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.
sippsr-routerdispatcher round robin group 210.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:]: 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:]: 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)
Re: [SR-Users] Dispatcher module problem or feature?
On Tue, Jun 29, 2010 at 11:33 AM, Daniel-Constantin Mierla
mico...@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
mico...@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:
sippsr-routerdispatcher round robin group 110.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:]: 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:]: 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.
sippsr-routerdispatcher round robin group 210.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:]: 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:]: 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:
[SR-Users] Dispatcher module problem or feature?
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: sippsr-routerdispatcher round robin group 110.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:]: 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:]: 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. sippsr-routerdispatcher round robin group 210.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:]: 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:]: 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 ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
