26 Jul
2017
26 Jul
'17
6:19 p.m.
Hi,
I've problems using avpops and mongodb, resulting in the error: "ERROR: avpops
[avpops_impl.c:123]: dbrow2avp(): wrong field types in dbrow"
In the database:
In kamailio.cfg:
...
# ---- avpops params ----
modparam("avpops", "db_url", DBURL)
modparam("avpops", "avp_table", "usr_preferences")
...
if ($rU=~"^(555|222)$") {
xlog("bla01");
if (avp_db_load("$to/username",
"$avp(s:email)")) {
xlog("bla02");
}
}
xlog("bla03");
...
The result in syslog:
ERROR: <script>: bla01
DEBUG: db_mongodb [mongodb_dbase.c:864]: db_mongodb_query(): query to collection
[usr_preferences]
DEBUG: db_mongodb [mongodb_dbase.c:898]: db_mongodb_query(): query filter: {
"username" : "555", "attribute" : "email" }
DEBUG: db_mongodb [mongodb_dbase.c:917]: db_mongodb_query(): columns filter: {
"value" : 1, "attribute" : 1, "type" : 1 }
DEBUG: <core> [db_res.c:116]: db_new_result(): allocate 56 bytes for result set at
0x7f82c8f4ae30
DEBUG: db_mongodb [mongodb_dbase.c:349]: db_mongodb_get_columns(): 3 columns returned from
the query
DEBUG: <core> [db_res.c:154]: db_allocate_columns(): allocate 24 bytes for result
names at 0x7f82c8f4fd40
DEBUG: <core> [db_res.c:165]: db_allocate_columns(): allocate 12 bytes for result
types at 0x7f82c8f70df0
DEBUG: db_mongodb [mongodb_dbase.c:377]: db_mongodb_get_columns(): Found a field[0] named:
value
DEBUG: db_mongodb [mongodb_dbase.c:403]: db_mongodb_get_columns(): allocate 16 bytes for
RES_NAMES[0] at 0x7f82c8f70e48
DEBUG: db_mongodb [mongodb_dbase.c:438]: db_mongodb_get_columns(): use DB1_STRING result
type
DEBUG: db_mongodb [mongodb_dbase.c:467]: db_mongodb_get_columns():
RES_NAMES(0x7f82c8f70e48)[0]=[value] (2)
DEBUG: db_mongodb [mongodb_dbase.c:377]: db_mongodb_get_columns(): Found a field[1] named:
attribute
DEBUG: db_mongodb [mongodb_dbase.c:403]: db_mongodb_get_columns(): allocate 16 bytes for
RES_NAMES[1] at 0x7f82c8f4abc8
DEBUG: db_mongodb [mongodb_dbase.c:438]: db_mongodb_get_columns(): use DB1_STRING result
type
DEBUG: db_mongodb [mongodb_dbase.c:467]: db_mongodb_get_columns():
RES_NAMES(0x7f82c8f4abc8)[1]=[attribute] (2)
DEBUG: db_mongodb [mongodb_dbase.c:377]: db_mongodb_get_columns(): Found a field[2] named:
type
DEBUG: db_mongodb [mongodb_dbase.c:403]: db_mongodb_get_columns(): allocate 16 bytes for
RES_NAMES[2] at 0x7f82c8f4aeb0
DEBUG: db_mongodb [mongodb_dbase.c:423]: db_mongodb_get_columns(): use DB1_DOUBLE result
type
DEBUG: db_mongodb [mongodb_dbase.c:467]: db_mongodb_get_columns():
RES_NAMES(0x7f82c8f4aeb0)[2]=[type] (1)
DEBUG: <core> [db_res.c:184]: db_allocate_rows(): allocate 16000 bytes for rows at
0x7f82c8f80820
DEBUG: db_mongodb [mongodb_dbase.c:684]: db_mongodb_convert_result(): selected document: {
"_id" : { "$oid" : "5978ab2850d1be89eb15f434" },
"attribute" : "email", "value" :
"sip:555@sip.bla.bla", "type" : 0.000000 }
DEBUG: <core> [db_row.c:117]: db_allocate_row(): allocate 96 bytes for row values at
0x7f82c8f4af08
DEBUG: db_mongodb [mongodb_dbase.c:529]: db_mongodb_convert_bson(): looking for field[0]
named: value
DEBUG: db_mongodb [mongodb_dbase.c:623]: db_mongodb_convert_bson():
RES_NAMES(0x7f82c8f70e48)[0]=[value] (2)
DEBUG: db_mongodb [mongodb_dbase.c:529]: db_mongodb_convert_bson(): looking for field[1]
named: attribute
DEBUG: db_mongodb [mongodb_dbase.c:623]: db_mongodb_convert_bson():
RES_NAMES(0x7f82c8f4abc8)[1]=[attribute] (2)
DEBUG: db_mongodb [mongodb_dbase.c:529]: db_mongodb_convert_bson(): looking for field[2]
named: type
DEBUG: db_mongodb [mongodb_dbase.c:623]: db_mongodb_convert_bson():
RES_NAMES(0x7f82c8f4aeb0)[2]=[type] (1)
DEBUG: db_mongodb [mongodb_dbase.c:695]: db_mongodb_convert_result(): retrieved number of
rows: 1
ERROR: avpops [avpops_impl.c:123]: dbrow2avp(): wrong field types in dbrow
DEBUG: avpops [avpops_db.c:265]: db_close_query(): close avp query
DEBUG: <core> [db_res.c:79]: db_free_columns(): freeing 3 columns
DEBUG: <core> [db_res.c:83]: db_free_columns(): freeing RES_NAMES[0] at
0x7f82c8f70e48
DEBUG: <core> [db_res.c:83]: db_free_columns(): freeing RES_NAMES[1] at
0x7f82c8f4abc8
DEBUG: <core> [db_res.c:83]: db_free_columns(): freeing RES_NAMES[2] at
0x7f82c8f4aeb0
DEBUG: <core> [db_res.c:92]: db_free_columns(): freeing result names at
0x7f82c8f4fd40
DEBUG: <core> [db_res.c:97]: db_free_columns(): freeing result types at
0x7f82c8f70df0
DEBUG: <core> [db_res.c:52]: db_free_rows(): freeing 1 rows
DEBUG: <core> [db_row.c:95]: db_free_row(): freeing row values at 0x7f82c8f4af08
DEBUG: <core> [db_res.c:60]: db_free_rows(): freeing rows at 0x7f82c8f80820
DEBUG: <core> [db_res.c:134]: db_free_result(): freeing result set at
0x7f82c8f4ae30
DEBUG: avpops [avpops_impl.c:415]: ops_dbload_avps(): loaded avps = 0
ERROR: <script>: bla03
Does anyone know what I'm doing wrong here?
db.usr_preferences.find()
{ "_id" :
ObjectId("5978ab2850d1be89eb15f434"), "uuid" : "",
"attribute" : "email", "value" :
"sip:555@sip.bla.bla", "type" : 0, "username" :
"555", "domain" : null }
26 Jul
26 Jul
7:58 p.m.
Hi,
I've seen this before, but with MySQL. Kamailio is pretty strict with
data types of database fields. IIRC I tried to use it with a view and
the view returned a string value where Kamailio expected an integer
and threw the same error. So maybe you might want to check the
reference structure of the usr_preferences table under
https://github.com/kamailio/kamailio/blob/master/utils/kamctl/mongodb/kamai…
with your local structure.
HTH
Sebastian
28 Jul
28 Jul
7:03 p.m.
It seems I'm missing something when checking the structure. I've multiple entries
in the database now that seem to have exactly the same types, but the config works for
one, and gives an error on the other one:
{ "_id" : ObjectId("597b5698e498421a40458dc3"), "uuid" :
"", "attribute" : "email", "value" :
"sip:555@bla.bla", "type" : 0, "username" : "555",
"domain" : null }
{ "_id" : ObjectId("597b5d9a61d1521f067391ae"), "uuid" :
"", "attribute" : "email", "value" :
"sip:123@bla.bla", "type" : 0, "username" : "666",
"domain" : null }
I compared all the types, and they're the same, using statements like:
typeof db.usr_preferences.findOne({"username":"666"})._id
The first entry has been made by using:
avp_db_delete("$to/username","$avp(s:email)");
avp_printf("$avp(s:email)","$ruri");
avp_db_store("$to/username","$avp(s:email)");
So, using kamailio. The second version has been created by me manually in the database
(which is what I'll do for the real entries).
The first entry now works fine, but the second one gives the following error:
ERROR: <core> [usr_avp.c:424]: search_avp(): 0 ID or NULL NAME AVP!
when using the initial code again:
if (avp_db_load("$to/username",
"$avp(s:email)")) {
xlog("bla02");
}
Where does the second entry differ?
Sent: Wednesday, July 26, 2017 at 6:58 PM
From: "Sebastian Damm" <damm(a)sipgate.de>
To: "Kamailio (SER) - Users Mailing List" <sr-users(a)lists.kamailio.org>
Subject: Re: [SR-Users] error using avp_db_load with mongodb
Hi,
I've seen this before, but with MySQL. Kamailio is pretty strict with
data types of database fields. IIRC I tried to use it with a view and
the view returned a string value where Kamailio expected an integer
and threw the same error. So maybe you might want to check the
reference structure of the usr_preferences table under
https://github.com/kamailio/kamailio/blob/master/utils/kamctl/mongodb/kamai…
with your local structure.
HTH
Sebastian
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
31 Jul
31 Jul
10:10 a.m.
Hi,
On Fri, Jul 28, 2017 at 6:03 PM, hdssdsdsdsfsdf hdssdsdsdsfsdf
<hdssdsdsdsfsdf(a)mail.com> wrote:
if
(avp_db_load("$to/username", "$avp(s:email)")) {
xlog("bla02");
}
$to is not a valid pseudo variable. You probably want to replace
"$to/username" by "$tU" or "$rU" or some variable where the
user you
are searching is written in the SIP packet.
BR
Sebastian
11:55 a.m.
Thanks, I changed that, but that doesn't deal with the original problem.
I still have the situation where I've two mongodb entries that are completely
similar:
{ "_id" : ObjectId("597b5698e498421a40458dc3"), "uuid" :
"", "attribute" : "email", "value" :
"sip:555@bla.bla", "type" : 0, "username" : "555",
"domain" : null }
{ "_id" : ObjectId("597b5d9a61d1521f067391ae"), "uuid" :
"", "attribute" : "email", "value" :
"sip:123@bla.bla", "type" : 0, "username" : "666",
"domain" : null }
with:
avp_db_load("$tu/username", "$avp(s:email)")
succeeding on the first entry (when $tu contains 555) and failing on the second entry
(when $tu contains 666), with error message:
ERROR: <core> [usr_avp.c:424]: search_avp(): 0 ID or NULL NAME AVP!
Sent: Monday, July 31, 2017 at 9:10 AM
From: "Sebastian Damm" <damm(a)sipgate.de>
To: "Kamailio (SER) - Users Mailing List" <sr-users(a)lists.kamailio.org>
Subject: Re: [SR-Users] error using avp_db_load with mongodb
Hi,
On Fri, Jul 28, 2017 at 6:03 PM, hdssdsdsdsfsdf hdssdsdsdsfsdf
<hdssdsdsdsfsdf(a)mail.com> wrote:
if
(avp_db_load("$to/username", "$avp(s:email)")) {
xlog("bla02");
}
$to is not a valid pseudo variable. You probably want to replace
"$to/username" by "$tU" or "$rU" or some variable where the
user you
are searching is written in the SIP packet.
BR
Sebastian
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
12:51 p.m.
Correction, the error is actually:
ERROR: avpops [avpops_impl.c:123]: dbrow2avp(): wrong field types in dbrow
Sent: Monday, July 31, 2017 at 10:55 AM
From: "hdssdsdsdsfsdf hdssdsdsdsfsdf" <hdssdsdsdsfsdf(a)mail.com>
To: sr-users(a)lists.kamailio.org
Cc: "Kamailio (SER) - Users Mailing List" <sr-users(a)lists.kamailio.org>
Subject: Re: [SR-Users] error using avp_db_load with mongodb
Thanks, I changed that, but that doesn't deal with the original problem.
I still have the situation where I've two mongodb entries that are completely
similar:
{ "_id" : ObjectId("597b5698e498421a40458dc3"), "uuid" :
"", "attribute" : "email", "value" :
"sip:555@bla.bla", "type" : 0, "username" : "555",
"domain" : null }
{ "_id" : ObjectId("597b5d9a61d1521f067391ae"), "uuid" :
"", "attribute" : "email", "value" :
"sip:123@bla.bla", "type" : 0, "username" : "666",
"domain" : null }
with:
avp_db_load("$tu/username", "$avp(s:email)")
succeeding on the first entry (when $tu contains 555) and failing on the second entry
(when $tu contains 666), with error message:
ERROR: <core> [usr_avp.c:424]: search_avp(): 0 ID or NULL NAME AVP!
Sent: Monday, July 31, 2017 at 9:10 AM
From: "Sebastian Damm" <damm(a)sipgate.de>
To: "Kamailio (SER) - Users Mailing List" <sr-users(a)lists.kamailio.org>
Subject: Re: [SR-Users] error using avp_db_load with mongodb
Hi,
On Fri, Jul 28, 2017 at 6:03 PM, hdssdsdsdsfsdf hdssdsdsdsfsdf
<hdssdsdsdsfsdf(a)mail.com> wrote:
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
if
(avp_db_load("$to/username", "$avp(s:email)")) {
xlog("bla02");
}
$to is not a valid pseudo variable. You probably want to replace
"$to/username" by "$tU" or "$rU" or some variable where the
user you
are searching is written in the SIP packet.
BR
Sebastian
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
12:59 p.m.
And apologies. Solved it. It was indeed the type problem, where I had to insert the
"type" field as "NumberInt(0)" to prevent it from turning into a float
(which the "typeof" command I use to check if they were the same type didn't
show as different, but just as a number).
Sent: Monday, July 31, 2017 at 11:51 AM
From: "hdssdsdsdsfsdf hdssdsdsdsfsdf" <hdssdsdsdsfsdf(a)mail.com>
To: sr-users(a)lists.kamailio.org
Cc: sr-users(a)lists.kamailio.org
Subject: Re: [SR-Users] error using avp_db_load with mongodb
Correction, the error is actually:
ERROR: avpops [avpops_impl.c:123]: dbrow2avp(): wrong field types in dbrow
Sent: Monday, July 31, 2017 at 10:55 AM
From: "hdssdsdsdsfsdf hdssdsdsdsfsdf" <hdssdsdsdsfsdf(a)mail.com>
To: sr-users(a)lists.kamailio.org
Cc: "Kamailio (SER) - Users Mailing List" <sr-users(a)lists.kamailio.org>
Subject: Re: [SR-Users] error using avp_db_load with mongodb
Thanks, I changed that, but that doesn't deal with the original problem.
I still have the situation where I've two mongodb entries that are completely
similar:
{ "_id" : ObjectId("597b5698e498421a40458dc3"), "uuid" :
"", "attribute" : "email", "value" :
"sip:555@bla.bla", "type" : 0, "username" : "555",
"domain" : null }
{ "_id" : ObjectId("597b5d9a61d1521f067391ae"), "uuid" :
"", "attribute" : "email", "value" :
"sip:123@bla.bla", "type" : 0, "username" : "666",
"domain" : null }
with:
avp_db_load("$tu/username", "$avp(s:email)")
succeeding on the first entry (when $tu contains 555) and failing on the second entry
(when $tu contains 666), with error message:
ERROR: <core> [usr_avp.c:424]: search_avp(): 0 ID or NULL NAME AVP!
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Sent: Monday, July 31, 2017 at 9:10 AM
From: "Sebastian Damm" <damm(a)sipgate.de>
To: "Kamailio (SER) - Users Mailing List" <sr-users(a)lists.kamailio.org>
Subject: Re: [SR-Users] error using avp_db_load with mongodb
Hi,
On Fri, Jul 28, 2017 at 6:03 PM, hdssdsdsdsfsdf hdssdsdsdsfsdf
<hdssdsdsdsfsdf(a)mail.com> wrote:
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
if
(avp_db_load("$to/username", "$avp(s:email)")) {
xlog("bla02");
}
$to is not a valid pseudo variable. You probably want to replace
"$to/username" by "$tU" or "$rU" or some variable where the
user you
are searching is written in the SIP packet.
BR
Sebastian
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
2671
days inactive
2676
days old
6 comments
2 participants
participants (2)
-
hdssdsdsdsfsdf hdssdsdsdsfsdf -
Sebastian Damm