[SR-Users] Some questions about drouting module

Daniel-Constantin Mierla miconda at gmail.com
Tue Aug 17 12:41:10 CEST 2021


Hello,

On 16.08.21 14:37, Андрей Ярин wrote:
>
> Hello!
>
> I test module on Centos 7, kamailio version 5.5 and found some strange
> things:
>
> 1) Definition of table dr_gateways at
> https://kamailio.org/docs/modules/5.5.x/modules/drouting.html#idm98
> <https://kamailio.org/docs/modules/5.5.x/modules/drouting.html#idm98>
> - in DB there is field 'attrs' and only notice about it is module
> param 3.8. attrs_avp but it doesnt describe table field. [...]
>
> In kamailio this field is deprecated or its only docs misses param?
>
likely the module documentation was not sync'ed with database
definition. In Kamailio we have another place where the database tables
are described for all modules, generated for definition schema -- in
this case, see:

  * https://kamailio.org/docs/db-tables/kamailio-db-5.5.x.html#idm2419


> 2) Previous moment was found when i try to resolve:
>
> WARNING: drouting [dr_load.c:529]: dr_load_routing_info(): route <1>
> does not exist
>
> "Definition of dr_rules table" says that field has type of integer,
> but realy in database its varchar and i think its old docs.
>
Like the above case, docs is out of sync with database table definition
schema. That field is the name of config file route block.
>
> But i use KEMI question is - how i can tell module that it must be
> called in KEMI, not in native?
>
Upon a quick look, this may not support calling a KEMI function instead
of the routing block. You can open an issue in the bug tracker.

For the moment, you can define the route[NAME] { ... } in kamailio.cfg,
then inside it use lua_run()/lua_runstring() to call functions from the
script specified with load modparam -- if you use other KEMI language,
there should be corresponding functions for same purpose.

> 3) Every time when i call 'kamcmd drouting.reload' i get message 
> CRITICAL: <core> [core/mem/q_malloc.c:502]: qm_free(): BUG: bad
> pointer 0x7f3e4cea04c0 (out of memory block!) called from core:
> core/utils/tmrec.c: tmrec_free(393) - ignoring
> I rollback to 5.4 and still get this error. As i understand its old
> module and its can be internal error - how critical this error can be?
>
This needs to be investigated -- you can also open an issue in the bug
tracker not to be forgotten. It may be a result of migrating from using
a clone of tmrec code in module to a version stored in the core, being
also needed by other modules.

You are using time-based matching rules, right?


> 4) Also planned commands like drouting.dump gws|gw_lists|rules?
>
I haven't seen much development activity around this module lately, I do
not know if any other developer plans to work on such extensions.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda




More information about the sr-users mailing list