From jmr.richardson@gmail.com Mon Jun 28 23:39:37 2010
From: JR Richardson <jmr.richardson@gmail.com>
To: sr-users@lists.kamailio.org
Subject: [SR-Users] Dispatcher module problem or feature?
Date: Mon, 28 Jun 2010 16:39:36 -0500
Message-ID: <AANLkTin9TeMTr81YfoGSAqUBSxj8xRFuw77REVZpYQCi@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1347897550=="

--===============1347897550==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

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


--===============1347897550==--


From miconda@gmail.com Tue Jun 29 17:25:54 2010
From: Daniel-Constantin Mierla <miconda@gmail.com>
To: sr-users@lists.kamailio.org
Subject: Re: [SR-Users] Dispatcher module problem or feature?
Date: Tue, 29 Jun 2010 17:25:44 +0200
Message-ID: <4C2A1078.8030204@gmail.com>
In-Reply-To: <AANLkTin9TeMTr81YfoGSAqUBSxj8xRFuw77REVZpYQCi@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1846046750=="

--===============1846046750==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

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.
>   =20

looks like a feature :-) ... Can you print the list of avp holding the=20
destination addresses after you call ds_select_dst()? you can do it with=20
the avp_print() from avpops module or with a 'while' iterating through=20
the avps.

Say you have:

modparam("dispatcher", "dst_avp", "$avp(dst)")

$var(i) =3D 0;
while($(avp(dst)[$var(i)])) {
   xlog(" --- $(avp(dst)[$var(i)]) \n");
   $var(i) =3D $var(i) + 1;
}

Pasting here the parameters you set for dispatcher module would be=20
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=3DA
>          URI:: sip:10.10.14.102:5060 flag=3DA
>          URI:: sip:10.10.14.101:5060 flag=3DA
>
>
> 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=3DA
>          URI:: sip:10.10.14.103:5060 flag=3DA
>
>
> 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
>   =20

--=20
Daniel-Constantin Mierla
http://www.asipto.com/




--===============1846046750==
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.html"
MIME-Version: 1.0

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlvbmFs
Ly9FTiI+CjxodG1sPgo8aGVhZD4KICA8bWV0YSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9
SVNPLTg4NTktMSIKIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSI+CiAgPHRpdGxlPjwvdGl0bGU+
CjwvaGVhZD4KPGJvZHkgYmdjb2xvcj0iI2ZmZmZmZiIgdGV4dD0iIzAwMDAwMCI+CkhpIEpSLDxi
cj4KPGJyPgo8YnI+Cjxicj4KT24gNi8yOC8xMCAxMTozOSBQTSwgSlIgUmljaGFyZHNvbiB3cm90
ZToKPGJsb2NrcXVvdGUKIGNpdGU9Im1pZDpBQU5Ma1RpbjlUZU1UcjgxWWZvR1NBcVVCU3hqOHhS
RnV3NzdSRVZacFlRQ2lAbWFpbC5nbWFpbC5jb20iCiB0eXBlPSJjaXRlIj4KICA8cHJlIHdyYXA9
IiI+SGkgQWxsLAoKSSdtIHRlc3RpbmcgZGlzcGF0Y2hlciBmdW5jdGlvbnMgd2l0aCBrYW1haWxp
byAzLjAgYW5kIHVzaW5nIGRhdGFiYXNlCnRvIGxvYWQgZGVzdGluYXRpb24gYWRkcmVzcy4gIFRo
ZSBwcm9ibGVtIEkgYW0gc2VlaW5nIGlzIHRoZSAxJ3N0CmRlc3RpbmF0aW9uIGFkZHJlc3MgaW4g
YSBncm91cCBpcyBub3QgYmVpbmcgdXNlZCwgdGhlIGRpc3BhdGNoZXIKYWx3YXlzIHN0YXJ0cyBh
dCB0aGUgc2Vjb25kIGRhdGFiYXNlIGVudHJ5LiAgRm9yIGluc3RhbmNlLCBpZiBJIGhhdmUgMgpk
ZXN0aW5hdGlvbiBhZGRyZXNzZXMgbGlzdGVkIGluIHRoZSBkYXRhYmFzZSwgPGEgY2xhc3M9Im1v
ei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0ic2lwOjEwLjEwLjE0LjEwMTo1MDYwIj5zaXA6MTAu
MTAuMTQuMTAxOjUwNjA8L2E+CmFuZCA8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBo
cmVmPSJzaXA6MTAuMTAuMTQuMTAyOjUwNjAiPnNpcDoxMC4xMC4xNC4xMDI6NTA2MDwvYT4sIG9u
bHkgPGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0ic2lwOjEwLjEwLjE0LjEw
Mjo1MDYwIj5zaXA6MTAuMTAuMTQuMTAyOjUwNjA8L2E+IHdpbGwgcmVjZWl2ZQpjYWxscy4gIEJ1
dCBpZiBJIGxpc3QgLjEwMSBpbiB0aGUgZGF0YWJhc2UgdHdpY2UsIHRoZW4gSSB3aWxsIGdldApw
cm9wZXIgZGlzdHJpYnV0aW9uLgogIDwvcHJlPgo8L2Jsb2NrcXVvdGU+Cjxicj4KbG9va3MgbGlr
ZSBhIGZlYXR1cmUgOi0pIC4uLiBDYW4geW91IHByaW50IHRoZSBsaXN0IG9mIGF2cCBob2xkaW5n
IHRoZQpkZXN0aW5hdGlvbiBhZGRyZXNzZXMgYWZ0ZXIgeW91IGNhbGwgZHNfc2VsZWN0X2RzdCgp
PyB5b3UgY2FuIGRvIGl0CndpdGggdGhlIGF2cF9wcmludCgpIGZyb20gYXZwb3BzIG1vZHVsZSBv
ciB3aXRoIGEgJ3doaWxlJyBpdGVyYXRpbmcKdGhyb3VnaCB0aGUgYXZwcy48YnI+Cjxicj4KU2F5
IHlvdSBoYXZlOjxicj4KPG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0
ZXh0L2h0bWw7IGNoYXJzZXQ9SVNPLTg4NTktMSI+CjxwcmUgY2xhc3M9InByb2dyYW1saXN0aW5n
Ij5tb2RwYXJhbSgiZGlzcGF0Y2hlciIsICJkc3RfYXZwIiwgIiRhdnAoZHN0KSIpCjwvcHJlPgok
dmFyKGkpID0gMDs8YnI+CndoaWxlKCQoYXZwKGRzdClbJHZhcihpKV0pKSB7PGJyPgombmJzcDsg
eGxvZygiIC0tLSAkKGF2cChkc3QpWyR2YXIoaSldKSBcbiIpOzxicj4KJm5ic3A7ICR2YXIoaSkg
PSAkdmFyKGkpICsgMTs8YnI+Cn08YnI+Cjxicj4KUGFzdGluZyBoZXJlIHRoZSBwYXJhbWV0ZXJz
IHlvdSBzZXQgZm9yIGRpc3BhdGNoZXIgbW9kdWxlIHdvdWxkIGJlCmhlbHBmdWwgYXMgd2VsbC48
YnI+Cjxicj4KQ2hlZXJzLDxicj4KRGFuaWVsPGJyPgo8YnI+CjxibG9ja3F1b3RlCiBjaXRlPSJt
aWQ6QUFOTGtUaW45VGVNVHI4MVlmb0dTQXFVQlN4ajh4UkZ1dzc3UkVWWnBZUUNpQG1haWwuZ21h
aWwuY29tIgogdHlwZT0iY2l0ZSI+CiAgPHByZSB3cmFwPSIiPgpTbyBoZXJlIGlzIG15IHNldHVw
IGFuZCBzb21lIGRlYnVnIHRyYWZmaWM6CgpzaXBwJmd0OyZsdDtzci1yb3V0ZXImZ3Q7Jmx0O2Rp
c3BhdGNoZXIgcm91bmQgcm9iaW4gZ3JvdXAgMSZndDsmbHQ7MTAuMTAuMTQuMTAxLAoxMC4xMC4x
NC4xMDIsIDEwLjEwLjE0LjEwMQoKVGhpcyB3aWxsIHNlbmQgY2FsbHMgdG8gYm90aCAuMTAxIGFu
ZCAxMDIgZXZlbmx5LgoKc2lwLXJvdXRlcjI6fiMga2FtY3RsIGZpZm8gZHNfbGlzdApTRVQ6OiAx
CiAgICAgICAgVVJJOjogPGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0ic2lw
OjEwLjEwLjE0LjEwMTo1MDYwIj5zaXA6MTAuMTAuMTQuMTAxOjUwNjA8L2E+IGZsYWc9QQogICAg
ICAgIFVSSTo6IDxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9InNpcDoxMC4x
MC4xNC4xMDI6NTA2MCI+c2lwOjEwLjEwLjE0LjEwMjo1MDYwPC9hPiBmbGFnPUEKICAgICAgICBV
Ukk6OiA8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJzaXA6MTAuMTAuMTQu
MTAxOjUwNjAiPnNpcDoxMC4xMC4xNC4xMDE6NTA2MDwvYT4gZmxhZz1BCgoKZmlyc3QgY2FsbCB0
byBkaXNwYXRjaGVyOgoKIDAoNDc4MCkgREVCVUc6IGRpc3BhdGNoZXIgW2Rpc3BhdGNoLmM6MTEx
MV06IHNldCBbMV0KIDAoNDc4MCkgREVCVUc6IGRpc3BhdGNoZXIgW2Rpc3BhdGNoLmM6MTE4NV06
IGFsZyBoYXNoIFswXQogMCg0NzgwKSBERUJVRzogZGlzcGF0Y2hlciBbZGlzcGF0Y2guYzoxMjIz
XTogc2VsZWN0ZWQgWzQtMS8wXQo8YSBjbGFzcz0ibW96LXR4dC1saW5rLXJmYzIzOTZFIiBocmVm
PSJzaXA6MTAuMTAuMTQuMTAxOjUwNjAiPiZsdDtzaXA6MTAuMTAuMTQuMTAxOjUwNjAmZ3Q7PC9h
PgogMCg0NzgwKSBERUJVRzogZGlzcGF0Y2hlciBbZGlzcGF0Y2guYzoxMjU3XTogdXNpbmcgZW50
cnkgWzEvMV0KIDAoNDc4MCkgSU5GTzogJmx0O3NjcmlwdCZndDs6IGRzX2Rpc3BhdGNoZXIgPGEg
Y2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0ic2lwOjEwLjEwLjE0LjEwMTo1MDYw
Ij5zaXA6MTAuMTAuMTQuMTAxOjUwNjA8L2E+IDEgMwoKc2Vjb25kIGNhbGwgdG8gZGlzcGF0Y2hl
cjoKCiAwKDQ3ODApIERFQlVHOiBkaXNwYXRjaGVyIFtkaXNwYXRjaC5jOjExMTFdOiBzZXQgWzFd
CiAwKDQ3ODApIERFQlVHOiBkaXNwYXRjaGVyIFtkaXNwYXRjaC5jOjExODVdOiBhbGcgaGFzaCBb
MV0KIDAoNDc4MCkgREVCVUc6IGRpc3BhdGNoZXIgW2Rpc3BhdGNoLmM6MTIyM106IHNlbGVjdGVk
IFs0LTEvMV0KPGEgY2xhc3M9Im1vei10eHQtbGluay1yZmMyMzk2RSIgaHJlZj0ic2lwOjEwLjEw
LjE0LjEwMjo1MDYwIj4mbHQ7c2lwOjEwLjEwLjE0LjEwMjo1MDYwJmd0OzwvYT4KIDAoNDc4MCkg
REVCVUc6IGRpc3BhdGNoZXIgW2Rpc3BhdGNoLmM6MTI0NV06IHVzaW5nIGVudHJ5IFsxLzBdCiAw
KDQ3ODApIElORk86ICZsdDtzY3JpcHQmZ3Q7OiBkc19kaXNwYXRjaGVyIDxhIGNsYXNzPSJtb3ot
dHh0LWxpbmstZnJlZXRleHQiIGhyZWY9InNpcDoxMC4xMC4xNC4xMDI6NTA2MCI+c2lwOjEwLjEw
LjE0LjEwMjo1MDYwPC9hPiAxIDMKCnRoaXJkIGNhbGwgdG8gZGlzcGF0Y2hlciBnb2VzIGJhY2sg
dG8gLjEwMSwgdGhlbiAuMTAyLCBlY3QuCgoKc2lwcCZndDsmbHQ7c3Itcm91dGVyJmd0OyZsdDtk
aXNwYXRjaGVyIHJvdW5kIHJvYmluIGdyb3VwIDImZ3Q7Jmx0OzEwLjEwLjE0LjEwMyBhbmQgMTAu
MTAuMTQuMTA0CgpUaGlzIHdpbGwgc2VuZCBjYWxscyBvbmx5IHRvIC4xMDQKCnNpcC1yb3V0ZXIy
On4jIGthbWN0bCBmaWZvIGRzX2xpc3QKU0VUX05POjogMgpTRVQ6OiAyCiAgICAgICAgVVJJOjog
PGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0ic2lwOjEwLjEwLjE0LjEwNDo1
MDYwIj5zaXA6MTAuMTAuMTQuMTA0OjUwNjA8L2E+IGZsYWc9QQogICAgICAgIFVSSTo6IDxhIGNs
YXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9InNpcDoxMC4xMC4xNC4xMDM6NTA2MCI+
c2lwOjEwLjEwLjE0LjEwMzo1MDYwPC9hPiBmbGFnPUEKCgpmaXJzdCBjYWxsIHRvIGRpc3BhdGNo
ZXI6CgogMCg0NzgwKSBERUJVRzogZGlzcGF0Y2hlciBbZGlzcGF0Y2guYzoxMTExXTogc2V0IFsy
XQogMCg0NzgwKSBERUJVRzogZGlzcGF0Y2hlciBbZGlzcGF0Y2guYzoxMTg1XTogYWxnIGhhc2gg
WzBdCiAwKDQ3ODApIERFQlVHOiBkaXNwYXRjaGVyIFtkaXNwYXRjaC5jOjEyMjNdOiBzZWxlY3Rl
ZCBbNC0yLzBdCjxhIGNsYXNzPSJtb3otdHh0LWxpbmstcmZjMjM5NkUiIGhyZWY9InNpcDoxMC4x
MC4xNC4xMDQ6NTA2MCI+Jmx0O3NpcDoxMC4xMC4xNC4xMDQ6NTA2MCZndDs8L2E+CiAwKDQ3ODAp
IElORk86ICZsdDtzY3JpcHQmZ3Q7OiBkc19kaXNwYXRjaGVyIDxhIGNsYXNzPSJtb3otdHh0LWxp
bmstZnJlZXRleHQiIGhyZWY9InNpcDoxMC4xMC4xNC4xMDQ6NTA2MCI+c2lwOjEwLjEwLjE0LjEw
NDo1MDYwPC9hPiAyIDIKCgpzZWNvbmQgY2FsbCB0byBkaXNwYXRjaGVyOgoKIDAoNDc4MCkgREVC
VUc6IGRpc3BhdGNoZXIgW2Rpc3BhdGNoLmM6MTExMV06IHNldCBbMl0KIDAoNDc4MCkgREVCVUc6
IGRpc3BhdGNoZXIgW2Rpc3BhdGNoLmM6MTE4NV06IGFsZyBoYXNoIFsxXQogMCg0NzgwKSBERUJV
RzogZGlzcGF0Y2hlciBbZGlzcGF0Y2guYzoxMjIzXTogc2VsZWN0ZWQgWzQtMi8wXQo8YSBjbGFz
cz0ibW96LXR4dC1saW5rLXJmYzIzOTZFIiBocmVmPSJzaXA6MTAuMTAuMTQuMTA0OjUwNjAiPiZs
dDtzaXA6MTAuMTAuMTQuMTA0OjUwNjAmZ3Q7PC9hPgogMCg0NzgwKSBJTkZPOiAmbHQ7c2NyaXB0
Jmd0OzogZHNfZGlzcGF0Y2hlciA8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVm
PSJzaXA6MTAuMTAuMTQuMTA0OjUwNjAiPnNpcDoxMC4xMC4xNC4xMDQ6NTA2MDwvYT4gMiAyCgpT
byBpdCBhcHBlYXJzIHdpdGggb25seSAyIGVudHJpZXMgbG9hZGVkIGluIHRoZSBkYXRhYmFzZSwg
dGhlcmUgaXMgYQptaXNzaW5nICJERUJVRzogZGlzcGF0Y2hlciBbZGlzcGF0Y2guYzoxMjQ1XTog
dXNpbmcgZW50cnkgWzEvMF0iICBUaGlzCmlzIHRoZSBvbmx5IGRpZmZlcmVuY2UgSSBjYW4gc2Vl
IGJldHdlZW4gdGhlIGNhbGwgZXhlY3V0aW9ucyBiZXR3ZWVuCnRoZSB0d28gZ3JvdXBzLiBCdXQg
SSBkb24ndCByZWFsbHkga25vdyB3aGF0IHRoYXQgbWVhbnMuCgpJIGNhbiByZXByb2R1Y2UgdGhl
c2Ugc3ltcHRvbXMgb24ga2FtYWlsaW8gMy4wLCAxLjUueCBhbmQgb2xkZXIKdmVyc2lvbnMuICBU
aGUgc2FtZSB0aGluZyBoYXBwZW5zIHdoZW4gdGhlIGRlc3RpbmF0aW9ucyBhcmUgbG9hZGVkIHZp
YQpjb25maWcgZmlsZSBkaXNwYXRjaGVyLmxzdC4KCkkgYW0gdXNpbmcgZGViaWFuIExlbm55IHdp
dGggc2lyZW1pcyB3ZWIgaW50ZXJmYWNlLgoKbXlzcWwmZ3Q7IHNlbGVjdCAqIGZyb20gZGlzcGF0
Y2hlclxHOwoqKioqKioqKioqKioqKioqKioqKioqKioqKiogMS4gcm93ICoqKioqKioqKioqKioq
KioqKioqKioqKioqKgogICAgICAgICBpZDogMQogICAgICBzZXRpZDogMQpkZXN0aW5hdGlvbjog
PGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0ic2lwOjEwLjEwLjE0LjEwMTo1
MDYwIj5zaXA6MTAuMTAuMTQuMTAxOjUwNjA8L2E+CiAgICAgIGZsYWdzOiAwCiAgIHByaW9yaXR5
OiAwCmRlc2NyaXB0aW9uOiBsYWIxCioqKioqKioqKioqKioqKioqKioqKioqKioqKiAyLiByb3cg
KioqKioqKioqKioqKioqKioqKioqKioqKioqCiAgICAgICAgIGlkOiAyCiAgICAgIHNldGlkOiAx
CmRlc3RpbmF0aW9uOiA8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJzaXA6
MTAuMTAuMTQuMTAyOjUwNjAiPnNpcDoxMC4xMC4xNC4xMDI6NTA2MDwvYT4KICAgICAgZmxhZ3M6
IDAKICAgcHJpb3JpdHk6IDAKZGVzY3JpcHRpb246IGxhYjIKKioqKioqKioqKioqKioqKioqKioq
KioqKioqIDMuIHJvdyAqKioqKioqKioqKioqKioqKioqKioqKioqKioKICAgICAgICAgaWQ6IDMK
ICAgICAgc2V0aWQ6IDIKZGVzdGluYXRpb246IDxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRl
eHQiIGhyZWY9InNpcDoxMC4xMC4xNC4xMDM6NTA2MCI+c2lwOjEwLjEwLjE0LjEwMzo1MDYwPC9h
PgogICAgICBmbGFnczogMAogICBwcmlvcml0eTogMApkZXNjcmlwdGlvbjogbGFiMwoqKioqKioq
KioqKioqKioqKioqKioqKioqKiogNC4gcm93ICoqKioqKioqKioqKioqKioqKioqKioqKioqKgog
ICAgICAgICBpZDogNAogICAgICBzZXRpZDogMgpkZXN0aW5hdGlvbjogPGEgY2xhc3M9Im1vei10
eHQtbGluay1mcmVldGV4dCIgaHJlZj0ic2lwOjEwLjEwLjE0LjEwNDo1MDYwIj5zaXA6MTAuMTAu
MTQuMTA0OjUwNjA8L2E+CiAgICAgIGZsYWdzOiAwCiAgIHByaW9yaXR5OiAwCmRlc2NyaXB0aW9u
OiBsYWI0CioqKioqKioqKioqKioqKioqKioqKioqKioqKiA1LiByb3cgKioqKioqKioqKioqKioq
KioqKioqKioqKioqCiAgICAgICAgIGlkOiA1CiAgICAgIHNldGlkOiAxCmRlc3RpbmF0aW9uOiA8
YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJzaXA6MTAuMTAuMTQuMTAxOjUw
NjAiPnNpcDoxMC4xMC4xNC4xMDE6NTA2MDwvYT4KICAgICAgZmxhZ3M6IDAKICAgcHJpb3JpdHk6
IDAKZGVzY3JpcHRpb246IGxhYjEKNSByb3dzIGluIHNldCAoMC4wMCBzZWMpCgpJcyB0aGlzIGEg
YnVnPwoKVGhhbmtzLgoKSlIKICA8L3ByZT4KPC9ibG9ja3F1b3RlPgo8YnI+CjxwcmUgY2xhc3M9
Im1vei1zaWduYXR1cmUiIGNvbHM9IjcyIj4tLSAKRGFuaWVsLUNvbnN0YW50aW4gTWllcmxhCjxh
IGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Imh0dHA6Ly93d3cuYXNpcHRvLmNv
bS8iPmh0dHA6Ly93d3cuYXNpcHRvLmNvbS88L2E+CjwvcHJlPgo8L2JvZHk+CjwvaHRtbD4K

--===============1846046750==--


From jmr.richardson@gmail.com Tue Jun 29 18:17:36 2010
From: JR Richardson <jmr.richardson@gmail.com>
To: sr-users@lists.kamailio.org
Subject: Re: [SR-Users] Dispatcher module problem or feature?
Date: Tue, 29 Jun 2010 11:17:34 -0500
Message-ID: <AANLkTimNDMhvTn9Lb2wwK40YiEsMqav2jICyO7162REt@mail.gmail.com>
In-Reply-To: <4C2A1078.8030204@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2087687366=="

--===============2087687366==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

On Tue, Jun 29, 2010 at 10:25 AM, Daniel-Constantin Mierla
<miconda(a)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.

Thanks.

JR
-- 
JR Richardson
Engineering for the Masses


--===============2087687366==--


From miconda@gmail.com Tue Jun 29 18:33:51 2010
From: Daniel-Constantin Mierla <miconda@gmail.com>
To: sr-users@lists.kamailio.org
Subject: Re: [SR-Users] Dispatcher module problem or feature?
Date: Tue, 29 Jun 2010 18:33:43 +0200
Message-ID: <4C2A2067.7070209@gmail.com>
In-Reply-To: <AANLkTimNDMhvTn9Lb2wwK40YiEsMqav2jICyO7162REt@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0247871496=="

--===============0247871496==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable



On 6/29/10 6:17 PM, JR Richardson wrote:
> On Tue, Jun 29, 2010 at 10:25 AM, Daniel-Constantin Mierla
> <miconda(a)gmail.com>  wrote:
>   =20
>> 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 t=
he
>> avp_print() from avpops module or with a 'while' iterating through the avp=
s.
>>
>> Say you have:
>>
>> modparam("dispatcher", "dst_avp", "$avp(dst)")
>>
>> $var(i) =3D 0;
>> while($(avp(dst)[$var(i)])) {
>>    xlog(" --- $(avp(dst)[$var(i)]) \n");
>>    $var(i) =3D $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=3DA
>>          URI:: sip:10.10.14.102:5060 flag=3DA
>>          URI:: sip:10.10.14.101:5060 flag=3DA
>> 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=3DA
>>          URI:: sip:10.10.14.103:5060 flag=3DA
>> 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/
>>
>>     =20
>
> 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.
>   =20

Try with:

modparam("dispatcher", "use_default", 0)

You have it set to 1, which means the last address in set in not loaded=20
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=20
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) =3D 0;
   while($(avp(i:271)[$var(i)])!=3D$null) {
   xlog("L_INFO", " --- $(avp(i:271)[$var(i)]) \n");
   $var(i) =3D $var(i) + 1;
  }

If still nothing, use avp_print().

Cheers,
Daniel

--=20
Daniel-Constantin Mierla
http://www.asipto.com/




--===============0247871496==
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.html"
MIME-Version: 1.0

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlvbmFs
Ly9FTiI+CjxodG1sPgo8aGVhZD4KICA8bWV0YSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9
SVNPLTg4NTktMSIKIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSI+CjwvaGVhZD4KPGJvZHkgYmdj
b2xvcj0iI2ZmZmZmZiIgdGV4dD0iIzAwMDAwMCI+Cjxicj4KPGJyPgpPbiA2LzI5LzEwIDY6MTcg
UE0sIEpSIFJpY2hhcmRzb24gd3JvdGU6CjxibG9ja3F1b3RlCiBjaXRlPSJtaWQ6QUFOTGtUaW1O
RE1odlRuOUxiMnd3SzQwWWlFc01xYXYyaklDeU83MTYyUkV0QG1haWwuZ21haWwuY29tIgogdHlw
ZT0iY2l0ZSI+CiAgPHByZSB3cmFwPSIiPk9uIFR1ZSwgSnVuIDI5LCAyMDEwIGF0IDEwOjI1IEFN
LCBEYW5pZWwtQ29uc3RhbnRpbiBNaWVybGEKPGEgY2xhc3M9Im1vei10eHQtbGluay1yZmMyMzk2
RSIgaHJlZj0ibWFpbHRvOm1pY29uZGFAZ21haWwuY29tIj4mbHQ7bWljb25kYUBnbWFpbC5jb20m
Z3Q7PC9hPiB3cm90ZToKICA8L3ByZT4KICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4KICAgIDxw
cmUgd3JhcD0iIj5IaSBKUiwKCgoKT24gNi8yOC8xMCAxMTozOSBQTSwgSlIgUmljaGFyZHNvbiB3
cm90ZToKCkhpIEFsbCwKSSdtIHRlc3RpbmcgZGlzcGF0Y2hlciBmdW5jdGlvbnMgd2l0aCBrYW1h
aWxpbyAzLjAgYW5kIHVzaW5nIGRhdGFiYXNlCnRvIGxvYWQgZGVzdGluYXRpb24gYWRkcmVzcy4g
IFRoZSBwcm9ibGVtIEkgYW0gc2VlaW5nIGlzIHRoZSAxJ3N0CmRlc3RpbmF0aW9uIGFkZHJlc3Mg
aW4gYSBncm91cCBpcyBub3QgYmVpbmcgdXNlZCwgdGhlIGRpc3BhdGNoZXIKYWx3YXlzIHN0YXJ0
cyBhdCB0aGUgc2Vjb25kIGRhdGFiYXNlIGVudHJ5LiAgRm9yIGluc3RhbmNlLCBpZiBJIGhhdmUg
MgpkZXN0aW5hdGlvbiBhZGRyZXNzZXMgbGlzdGVkIGluIHRoZSBkYXRhYmFzZSwgPGEgY2xhc3M9
Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0ic2lwOjEwLjEwLjE0LjEwMTo1MDYwIj5zaXA6
MTAuMTAuMTQuMTAxOjUwNjA8L2E+CmFuZCA8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0
IiBocmVmPSJzaXA6MTAuMTAuMTQuMTAyOjUwNjAiPnNpcDoxMC4xMC4xNC4xMDI6NTA2MDwvYT4s
IG9ubHkgPGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0ic2lwOjEwLjEwLjE0
LjEwMjo1MDYwIj5zaXA6MTAuMTAuMTQuMTAyOjUwNjA8L2E+IHdpbGwgcmVjZWl2ZQpjYWxscy4g
IEJ1dCBpZiBJIGxpc3QgLjEwMSBpbiB0aGUgZGF0YWJhc2UgdHdpY2UsIHRoZW4gSSB3aWxsIGdl
dApwcm9wZXIgZGlzdHJpYnV0aW9uLgoKCmxvb2tzIGxpa2UgYSBmZWF0dXJlIDotKSAuLi4gQ2Fu
IHlvdSBwcmludCB0aGUgbGlzdCBvZiBhdnAgaG9sZGluZyB0aGUKZGVzdGluYXRpb24gYWRkcmVz
c2VzIGFmdGVyIHlvdSBjYWxsIGRzX3NlbGVjdF9kc3QoKT8geW91IGNhbiBkbyBpdCB3aXRoIHRo
ZQphdnBfcHJpbnQoKSBmcm9tIGF2cG9wcyBtb2R1bGUgb3Igd2l0aCBhICd3aGlsZScgaXRlcmF0
aW5nIHRocm91Z2ggdGhlIGF2cHMuCgpTYXkgeW91IGhhdmU6Cgptb2RwYXJhbSgiZGlzcGF0Y2hl
ciIsICJkc3RfYXZwIiwgIiRhdnAoZHN0KSIpCgokdmFyKGkpID0gMDsKd2hpbGUoJChhdnAoZHN0
KVskdmFyKGkpXSkpIHsKJm5ic3A7IHhsb2coIiAtLS0gJChhdnAoZHN0KVskdmFyKGkpXSkgXG4i
KTsKJm5ic3A7ICR2YXIoaSkgPSAkdmFyKGkpICsgMTsKfQoKUGFzdGluZyBoZXJlIHRoZSBwYXJh
bWV0ZXJzIHlvdSBzZXQgZm9yIGRpc3BhdGNoZXIgbW9kdWxlIHdvdWxkIGJlIGhlbHBmdWwKYXMg
d2VsbC4KCkNoZWVycywKRGFuaWVsCgpTbyBoZXJlIGlzIG15IHNldHVwIGFuZCBzb21lIGRlYnVn
IHRyYWZmaWM6CnNpcHAmZ3Q7Jmx0O3NyLXJvdXRlciZndDsmbHQ7ZGlzcGF0Y2hlciByb3VuZCBy
b2JpbiBncm91cCAxJmd0OyZsdDsxMC4xMC4xNC4xMDEsCjEwLjEwLjE0LjEwMiwgMTAuMTAuMTQu
MTAxClRoaXMgd2lsbCBzZW5kIGNhbGxzIHRvIGJvdGggLjEwMSBhbmQgMTAyIGV2ZW5seS4Kc2lw
LXJvdXRlcjI6fiMga2FtY3RsIGZpZm8gZHNfbGlzdApTRVQ6OiAxCiAgICAgICAgVVJJOjogPGEg
Y2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0ic2lwOjEwLjEwLjE0LjEwMTo1MDYw
Ij5zaXA6MTAuMTAuMTQuMTAxOjUwNjA8L2E+IGZsYWc9QQogICAgICAgIFVSSTo6IDxhIGNsYXNz
PSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9InNpcDoxMC4xMC4xNC4xMDI6NTA2MCI+c2lw
OjEwLjEwLjE0LjEwMjo1MDYwPC9hPiBmbGFnPUEKICAgICAgICBVUkk6OiA8YSBjbGFzcz0ibW96
LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJzaXA6MTAuMTAuMTQuMTAxOjUwNjAiPnNpcDoxMC4x
MC4xNC4xMDE6NTA2MDwvYT4gZmxhZz1BCmZpcnN0IGNhbGwgdG8gZGlzcGF0Y2hlcjoKIDAoNDc4
MCkgREVCVUc6IGRpc3BhdGNoZXIgW2Rpc3BhdGNoLmM6MTExMV06IHNldCBbMV0KIDAoNDc4MCkg
REVCVUc6IGRpc3BhdGNoZXIgW2Rpc3BhdGNoLmM6MTE4NV06IGFsZyBoYXNoIFswXQogMCg0Nzgw
KSBERUJVRzogZGlzcGF0Y2hlciBbZGlzcGF0Y2guYzoxMjIzXTogc2VsZWN0ZWQgWzQtMS8wXQo8
YSBjbGFzcz0ibW96LXR4dC1saW5rLXJmYzIzOTZFIiBocmVmPSJzaXA6MTAuMTAuMTQuMTAxOjUw
NjAiPiZsdDtzaXA6MTAuMTAuMTQuMTAxOjUwNjAmZ3Q7PC9hPgogMCg0NzgwKSBERUJVRzogZGlz
cGF0Y2hlciBbZGlzcGF0Y2guYzoxMjU3XTogdXNpbmcgZW50cnkgWzEvMV0KIDAoNDc4MCkgSU5G
TzogJmx0O3NjcmlwdCZndDs6IGRzX2Rpc3BhdGNoZXIgPGEgY2xhc3M9Im1vei10eHQtbGluay1m
cmVldGV4dCIgaHJlZj0ic2lwOjEwLjEwLjE0LjEwMTo1MDYwIj5zaXA6MTAuMTAuMTQuMTAxOjUw
NjA8L2E+IDEgMwpzZWNvbmQgY2FsbCB0byBkaXNwYXRjaGVyOgogMCg0NzgwKSBERUJVRzogZGlz
cGF0Y2hlciBbZGlzcGF0Y2guYzoxMTExXTogc2V0IFsxXQogMCg0NzgwKSBERUJVRzogZGlzcGF0
Y2hlciBbZGlzcGF0Y2guYzoxMTg1XTogYWxnIGhhc2ggWzFdCiAwKDQ3ODApIERFQlVHOiBkaXNw
YXRjaGVyIFtkaXNwYXRjaC5jOjEyMjNdOiBzZWxlY3RlZCBbNC0xLzFdCjxhIGNsYXNzPSJtb3ot
dHh0LWxpbmstcmZjMjM5NkUiIGhyZWY9InNpcDoxMC4xMC4xNC4xMDI6NTA2MCI+Jmx0O3NpcDox
MC4xMC4xNC4xMDI6NTA2MCZndDs8L2E+CiAwKDQ3ODApIERFQlVHOiBkaXNwYXRjaGVyIFtkaXNw
YXRjaC5jOjEyNDVdOiB1c2luZyBlbnRyeSBbMS8wXQogMCg0NzgwKSBJTkZPOiAmbHQ7c2NyaXB0
Jmd0OzogZHNfZGlzcGF0Y2hlciA8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVm
PSJzaXA6MTAuMTAuMTQuMTAyOjUwNjAiPnNpcDoxMC4xMC4xNC4xMDI6NTA2MDwvYT4gMSAzCnRo
aXJkIGNhbGwgdG8gZGlzcGF0Y2hlciBnb2VzIGJhY2sgdG8gLjEwMSwgdGhlbiAuMTAyLCBlY3Qu
CnNpcHAmZ3Q7Jmx0O3NyLXJvdXRlciZndDsmbHQ7ZGlzcGF0Y2hlciByb3VuZCByb2JpbiBncm91
cCAyJmd0OyZsdDsxMC4xMC4xNC4xMDMgYW5kCjEwLjEwLjE0LjEwNApUaGlzIHdpbGwgc2VuZCBj
YWxscyBvbmx5IHRvIC4xMDQKc2lwLXJvdXRlcjI6fiMga2FtY3RsIGZpZm8gZHNfbGlzdApTRVRf
Tk86OiAyClNFVDo6IDIKICAgICAgICBVUkk6OiA8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0
ZXh0IiBocmVmPSJzaXA6MTAuMTAuMTQuMTA0OjUwNjAiPnNpcDoxMC4xMC4xNC4xMDQ6NTA2MDwv
YT4gZmxhZz1BCiAgICAgICAgVVJJOjogPGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIg
aHJlZj0ic2lwOjEwLjEwLjE0LjEwMzo1MDYwIj5zaXA6MTAuMTAuMTQuMTAzOjUwNjA8L2E+IGZs
YWc9QQpmaXJzdCBjYWxsIHRvIGRpc3BhdGNoZXI6CiAwKDQ3ODApIERFQlVHOiBkaXNwYXRjaGVy
IFtkaXNwYXRjaC5jOjExMTFdOiBzZXQgWzJdCiAwKDQ3ODApIERFQlVHOiBkaXNwYXRjaGVyIFtk
aXNwYXRjaC5jOjExODVdOiBhbGcgaGFzaCBbMF0KIDAoNDc4MCkgREVCVUc6IGRpc3BhdGNoZXIg
W2Rpc3BhdGNoLmM6MTIyM106IHNlbGVjdGVkIFs0LTIvMF0KPGEgY2xhc3M9Im1vei10eHQtbGlu
ay1yZmMyMzk2RSIgaHJlZj0ic2lwOjEwLjEwLjE0LjEwNDo1MDYwIj4mbHQ7c2lwOjEwLjEwLjE0
LjEwNDo1MDYwJmd0OzwvYT4KIDAoNDc4MCkgSU5GTzogJmx0O3NjcmlwdCZndDs6IGRzX2Rpc3Bh
dGNoZXIgPGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0ic2lwOjEwLjEwLjE0
LjEwNDo1MDYwIj5zaXA6MTAuMTAuMTQuMTA0OjUwNjA8L2E+IDIgMgpzZWNvbmQgY2FsbCB0byBk
aXNwYXRjaGVyOgogMCg0NzgwKSBERUJVRzogZGlzcGF0Y2hlciBbZGlzcGF0Y2guYzoxMTExXTog
c2V0IFsyXQogMCg0NzgwKSBERUJVRzogZGlzcGF0Y2hlciBbZGlzcGF0Y2guYzoxMTg1XTogYWxn
IGhhc2ggWzFdCiAwKDQ3ODApIERFQlVHOiBkaXNwYXRjaGVyIFtkaXNwYXRjaC5jOjEyMjNdOiBz
ZWxlY3RlZCBbNC0yLzBdCjxhIGNsYXNzPSJtb3otdHh0LWxpbmstcmZjMjM5NkUiIGhyZWY9InNp
cDoxMC4xMC4xNC4xMDQ6NTA2MCI+Jmx0O3NpcDoxMC4xMC4xNC4xMDQ6NTA2MCZndDs8L2E+CiAw
KDQ3ODApIElORk86ICZsdDtzY3JpcHQmZ3Q7OiBkc19kaXNwYXRjaGVyIDxhIGNsYXNzPSJtb3ot
dHh0LWxpbmstZnJlZXRleHQiIGhyZWY9InNpcDoxMC4xMC4xNC4xMDQ6NTA2MCI+c2lwOjEwLjEw
LjE0LjEwNDo1MDYwPC9hPiAyIDIKU28gaXQgYXBwZWFycyB3aXRoIG9ubHkgMiBlbnRyaWVzIGxv
YWRlZCBpbiB0aGUgZGF0YWJhc2UsIHRoZXJlIGlzIGEKbWlzc2luZyAiREVCVUc6IGRpc3BhdGNo
ZXIgW2Rpc3BhdGNoLmM6MTI0NV06IHVzaW5nIGVudHJ5IFsxLzBdIiAgVGhpcwppcyB0aGUgb25s
eSBkaWZmZXJlbmNlIEkgY2FuIHNlZSBiZXR3ZWVuIHRoZSBjYWxsIGV4ZWN1dGlvbnMgYmV0d2Vl
bgp0aGUgdHdvIGdyb3Vwcy4gQnV0IEkgZG9uJ3QgcmVhbGx5IGtub3cgd2hhdCB0aGF0IG1lYW5z
LgpJIGNhbiByZXByb2R1Y2UgdGhlc2Ugc3ltcHRvbXMgb24ga2FtYWlsaW8gMy4wLCAxLjUueCBh
bmQgb2xkZXIKdmVyc2lvbnMuICBUaGUgc2FtZSB0aGluZyBoYXBwZW5zIHdoZW4gdGhlIGRlc3Rp
bmF0aW9ucyBhcmUgbG9hZGVkIHZpYQpjb25maWcgZmlsZSBkaXNwYXRjaGVyLmxzdC4KSSBhbSB1
c2luZyBkZWJpYW4gTGVubnkgd2l0aCBzaXJlbWlzIHdlYiBpbnRlcmZhY2UuCm15c3FsJmd0OyBz
ZWxlY3QgKiBmcm9tIGRpc3BhdGNoZXJcRzsKKioqKioqKioqKioqKioqKioqKioqKioqKioqIDEu
IHJvdyAqKioqKioqKioqKioqKioqKioqKioqKioqKioKICAgICAgICAgaWQ6IDEKICAgICAgc2V0
aWQ6IDEKZGVzdGluYXRpb246IDxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9
InNpcDoxMC4xMC4xNC4xMDE6NTA2MCI+c2lwOjEwLjEwLjE0LjEwMTo1MDYwPC9hPgogICAgICBm
bGFnczogMAogICBwcmlvcml0eTogMApkZXNjcmlwdGlvbjogbGFiMQoqKioqKioqKioqKioqKioq
KioqKioqKioqKiogMi4gcm93ICoqKioqKioqKioqKioqKioqKioqKioqKioqKgogICAgICAgICBp
ZDogMgogICAgICBzZXRpZDogMQpkZXN0aW5hdGlvbjogPGEgY2xhc3M9Im1vei10eHQtbGluay1m
cmVldGV4dCIgaHJlZj0ic2lwOjEwLjEwLjE0LjEwMjo1MDYwIj5zaXA6MTAuMTAuMTQuMTAyOjUw
NjA8L2E+CiAgICAgIGZsYWdzOiAwCiAgIHByaW9yaXR5OiAwCmRlc2NyaXB0aW9uOiBsYWIyCioq
KioqKioqKioqKioqKioqKioqKioqKioqKiAzLiByb3cgKioqKioqKioqKioqKioqKioqKioqKioq
KioqCiAgICAgICAgIGlkOiAzCiAgICAgIHNldGlkOiAyCmRlc3RpbmF0aW9uOiA8YSBjbGFzcz0i
bW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJzaXA6MTAuMTAuMTQuMTAzOjUwNjAiPnNpcDox
MC4xMC4xNC4xMDM6NTA2MDwvYT4KICAgICAgZmxhZ3M6IDAKICAgcHJpb3JpdHk6IDAKZGVzY3Jp
cHRpb246IGxhYjMKKioqKioqKioqKioqKioqKioqKioqKioqKioqIDQuIHJvdyAqKioqKioqKioq
KioqKioqKioqKioqKioqKioKICAgICAgICAgaWQ6IDQKICAgICAgc2V0aWQ6IDIKZGVzdGluYXRp
b246IDxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9InNpcDoxMC4xMC4xNC4x
MDQ6NTA2MCI+c2lwOjEwLjEwLjE0LjEwNDo1MDYwPC9hPgogICAgICBmbGFnczogMAogICBwcmlv
cml0eTogMApkZXNjcmlwdGlvbjogbGFiNAoqKioqKioqKioqKioqKioqKioqKioqKioqKiogNS4g
cm93ICoqKioqKioqKioqKioqKioqKioqKioqKioqKgogICAgICAgICBpZDogNQogICAgICBzZXRp
ZDogMQpkZXN0aW5hdGlvbjogPGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0i
c2lwOjEwLjEwLjE0LjEwMTo1MDYwIj5zaXA6MTAuMTAuMTQuMTAxOjUwNjA8L2E+CiAgICAgIGZs
YWdzOiAwCiAgIHByaW9yaXR5OiAwCmRlc2NyaXB0aW9uOiBsYWIxCjUgcm93cyBpbiBzZXQgKDAu
MDAgc2VjKQpJcyB0aGlzIGEgYnVnPwpUaGFua3MuCkpSCgoKLS0KRGFuaWVsLUNvbnN0YW50aW4g
TWllcmxhCjxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Imh0dHA6Ly93d3cu
YXNpcHRvLmNvbS8iPmh0dHA6Ly93d3cuYXNpcHRvLmNvbS88L2E+CgogICAgPC9wcmU+CiAgPC9i
bG9ja3F1b3RlPgogIDxwcmUgd3JhcD0iIj4KCkhlcmUgaXMgbXkgY29uZmlnLCBkc19saXN0IGFu
ZCBzaXAgY2FsbCBkZWJ1ZzoKCjxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9
Imh0dHA6Ly9wYXN0ZWJpbi5jb20vTnNOWnl6ZGsiPmh0dHA6Ly9wYXN0ZWJpbi5jb20vTnNOWnl6
ZGs8L2E+CgpJIHB1dCB0aGUgJ3doaWxlJyBzbmlwIGluIHRoZSBjb25maWcgYnV0IEkgZG9uJ3Qg
d2VlIHdoZXJlIGl0IHByaW50ZWQKYW55dGhpbmcgaW4gdGhlIGRlYnVnLgogIDwvcHJlPgo8L2Js
b2NrcXVvdGU+Cjxicj4KVHJ5IHdpdGg6PGJyPgo8YnI+CjxtZXRhIGh0dHAtZXF1aXY9ImNvbnRl
bnQtdHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PUlTTy04ODU5LTEiPgptb2RwYXJh
bSgiZGlzcGF0Y2hlciIsICJ1c2VfZGVmYXVsdCIsIDApPGJyPgo8YnI+CllvdSBoYXZlIGl0IHNl
dCB0byAxLCB3aGljaCBtZWFucyB0aGUgbGFzdCBhZGRyZXNzIGluIHNldCBpbiBub3QgbG9hZGVk
CmluIGRpc3BhdGNoaW5nIGFsZ29yaXRobSAtIHN0aWxsIGl0IHNob3VsZCBiZSBpbiB0aGUgbGlz
dCBvZiBkc3QgYXZwcy4KPGRpdiBjbGFzcz0iZGUxIj48YnI+Ck5vdCBzdXJlIHdoeSB0aGUgYXZw
cyBhcmUgbm90IHByaW50ZWQsIHRyeSBhZGQgb25lIGxvZyBtZXNzYWdlIGZvciB0aGUKZmlyc3Qg
YW5kIGNvbXBhcmUgYWdhaW5zdCAkbnVsbCwgbGlrZTo8YnI+Cjxicj4KaWYoZHNfc2VsZWN0X2Rv
bWFpbigiJGF2cChzOmRzdGdycCkiLCAiNCIpKSB7PGJyPgo8YnI+CiZuYnNwOyB4bG9nKCJMX0lO
Rk8iLCAiIC0tLSBmaXJzdCBkc3QgYXZwOiAkYXZwKGk6MjcxKSBcbiIpOzxicj4KPC9kaXY+Cjxk
aXYgY2xhc3M9ImRlMSI+PGJyPgombmJzcDsgJHZhcihpKSA9IDA7PC9kaXY+CjxkaXYgY2xhc3M9
ImRlMiI+Jm5ic3A7IHdoaWxlKCQoYXZwKGk6MjcxKVskdmFyKGkpXSkhPSRudWxsKSB7PC9kaXY+
CjxkaXYgY2xhc3M9ImRlMSI+Jm5ic3A7IHhsb2coIkxfSU5GTyIsICIgLS0tICQoYXZwKGk6Mjcx
KVskdmFyKGkpXSkgXG4iKTs8L2Rpdj4KJm5ic3A7ICR2YXIoaSkgPSAkdmFyKGkpICsgMTsKPGRp
diBjbGFzcz0iZGUxIj4mbmJzcDt9PC9kaXY+Cjxicj4KSWYgc3RpbGwgbm90aGluZywgdXNlIGF2
cF9wcmludCgpLjxicj4KPGJyPgpDaGVlcnMsPGJyPgpEYW5pZWw8YnI+CjxwcmUgY2xhc3M9Im1v
ei1zaWduYXR1cmUiIGNvbHM9IjcyIj4tLSAKRGFuaWVsLUNvbnN0YW50aW4gTWllcmxhCjxhIGNs
YXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Imh0dHA6Ly93d3cuYXNpcHRvLmNvbS8i
Pmh0dHA6Ly93d3cuYXNpcHRvLmNvbS88L2E+CjwvcHJlPgo8L2JvZHk+CjwvaHRtbD4K

--===============0247871496==--


From jmr.richardson@gmail.com Tue Jun 29 18:49:44 2010
From: JR Richardson <jmr.richardson@gmail.com>
To: sr-users@lists.kamailio.org
Subject: Re: [SR-Users] Dispatcher module problem or feature?
Date: Tue, 29 Jun 2010 11:49:42 -0500
Message-ID: <AANLkTilR7bWCNwobiSg07ZviGQsaAmghwnHvylKRB4eT@mail.gmail.com>
In-Reply-To: <4C2A2067.7070209@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2054878798=="

--===============2054878798==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

On Tue, Jun 29, 2010 at 11:33 AM, Daniel-Constantin Mierla
<miconda(a)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(a)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.

Best Regards,

Thanks

JR
-- 
JR Richardson
Engineering for the Masses


--===============2054878798==--


From miconda@gmail.com Tue Jun 29 19:02:38 2010
From: Daniel-Constantin Mierla <miconda@gmail.com>
To: sr-users@lists.kamailio.org
Subject: Re: [SR-Users] Dispatcher module problem or feature?
Date: Tue, 29 Jun 2010 19:02:29 +0200
Message-ID: <4C2A2725.5070007@gmail.com>
In-Reply-To: <AANLkTilR7bWCNwobiSg07ZviGQsaAmghwnHvylKRB4eT@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1203467385=="

--===============1203467385==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable



On 6/29/10 6:49 PM, JR Richardson wrote:
> On Tue, Jun 29, 2010 at 11:33 AM, Daniel-Constantin Mierla
> <miconda(a)gmail.com>  wrote:
>   =20
>>
>> On 6/29/10 6:17 PM, JR Richardson wrote:
>>
>> On Tue, Jun 29, 2010 at 10:25 AM, Daniel-Constantin Mierla
>> <miconda(a)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 t=
he
>> avp_print() from avpops module or with a 'while' iterating through the avp=
s.
>> Say you have:
>> modparam("dispatcher", "dst_avp", "$avp(dst)")
>> $var(i) =3D 0;
>> while($(avp(dst)[$var(i)])) {
>>    xlog(" --- $(avp(dst)[$var(i)]) \n");
>>    $var(i) =3D $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=3DA
>>          URI:: sip:10.10.14.102:5060 flag=3DA
>>          URI:: sip:10.10.14.101:5060 flag=3DA
>> 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=3DA
>>          URI:: sip:10.10.14.103:5060 flag=3DA
>> 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 fir=
st
>> 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) =3D 0;
>>    while($(avp(i:271)[$var(i)])!=3D$null) {
>>    xlog("L_INFO", " --- $(avp(i:271)[$var(i)]) \n");
>>    $var(i) =3D $var(i) + 1;
>>   }
>> If still nothing, use avp_print().
>>
>> Cheers,
>> Daniel
>>
>> --
>> Daniel-Constantin Mierla
>> http://www.asipto.com/
>>
>>     =20
> 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.
>
>   =20
I will try to make that more clear in documentation. The order in the=20
destination set is pretty random if you don't set priority, being added=20
as mysql returns the rows in the result.

However, that address (first, last, whatsoever ...) should have been in=20
avp list and used as last option. Do you still get nothing printed for=20
dst avps?

Thanks,
Daniel


--=20
Daniel-Constantin Mierla
http://www.asipto.com/



--===============1203467385==--


From jmr.richardson@gmail.com Tue Jun 29 20:02:14 2010
From: JR Richardson <jmr.richardson@gmail.com>
To: sr-users@lists.kamailio.org
Subject: Re: [SR-Users] Dispatcher module problem or feature?
Date: Tue, 29 Jun 2010 13:02:13 -0500
Message-ID: <AANLkTinRiGVS1deLK190pEkN3uuav-x6XN4Wgs9cqVGa@mail.gmail.com>
In-Reply-To: <4C2A2067.7070209@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0544958100=="

--===============0544958100==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 29, 2010 at 11:33 AM, Daniel-Constantin Mierla
<miconda(a)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(a)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) =3D 0;
> while($(avp(dst)[$var(i)])) {
> =C2=A0 xlog(" --- $(avp(dst)[$var(i)]) \n");
> =C2=A0 $var(i) =3D $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=3DA
>         URI:: sip:10.10.14.102:5060 flag=3DA
>         URI:: sip:10.10.14.101:5060 flag=3DA
> 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=3DA
>         URI:: sip:10.10.14.103:5060 flag=3DA
> 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")) {
>
> =C2=A0 xlog("L_INFO", " --- first dst avp: $avp(i:271) \n");
>
> =C2=A0 $var(i) =3D 0;
> =C2=A0 while($(avp(i:271)[$var(i)])!=3D$null) {
> =C2=A0 xlog("L_INFO", " --- $(avp(i:271)[$var(i)]) \n");
> =C2=A0 $var(i) =3D $var(i) + 1;
> =C2=A0}
> If still nothing, use avp_print().
>
> Cheers,
> Daniel

Yes it printed now:

First invite:

 0(6435) INFO: <script>: ********** INCOMING MESSAGE FOR
sip:2165(a)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 requ=
est
 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(a)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 requ=
est
 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
--=20
JR Richardson
Engineering for the Masses


--===============0544958100==--