ok, no worries :)
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 26.03.2015 17:32, Newlin, Ben wrote:
Bogdan,
After further investigation I have found that the characters are an
artifact of the syslog daemon on the system. When I run with “fork=no”
and “log_stderr=yes” I do not see the characters in the screen output.
I have also now noticed both newline characters - #015 and #012 – at
other places in the logs, which also do not appear when logging to stderr.
Sorry for the false alarm, but I appreciate the help to point me in
the right direction.
Ben Newlin
*From:*[email protected]
[mailto:[email protected]] *On Behalf Of *Newlin, Ben
*Sent:* Thursday, March 26, 2015 10:54 AM
*To:* Bogdan-Andrei Iancu; OpenSIPS users mailling list
*Subject:* Re: [OpenSIPS-Users] DROUTING module changing Carrier IDs
Bogdan,
It did occur to me that the code seemed to be the octal for newline,
but I don’t know what the significance of that could be.
The MI command output does not show the extra characters:
~]$ opensipsctl dr carrier_status
ID:: Level3-VT Enabled=yes
ID:: IndyEdges Enabled=yes
I have also verified that the extra characters do not exist in the DB.
They are also not returned from the DB when queried from anywhere
else, and even the DROUTING module does not return the extra
characters for any of the other string fields it is returning, only
the Carrier ID.
Ben Newlin
*From:*Bogdan-Andrei Iancu [mailto:[email protected]]
*Sent:* Thursday, March 26, 2015 10:02 AM
*To:* OpenSIPS users mailling list; Newlin, Ben
*Subject:* Re: [OpenSIPS-Users] DROUTING module changing Carrier IDs
Hi Ben,
If you run the "dr_carrier_status" MI command, do you see the same
#012 in the ID of the carrier ? #012 is '\n' - are you sure you do not
have it by mistake in DB ?
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 25.03.2015 21:53, Newlin, Ben wrote:
I am using OpenSIPS 1.11 and I am recently getting some weird
behavior from the DROUTING module. The module is corrupting the
Carrier ID that is being returned via AVP. This behavior is
occurring only with the Carrier ID, not the gateway or rule IDs,
and only when it is returned from the DROUTING module via
dr_is_gw() or do_routing(). If I query the database directly using
AVPOPS, the Carrier ID is returned correctly.
I have the following configuration. The startup_route was added
specifically for this issue.
#### Dynamic ROUTING module
loadmodule "drouting.so"
modparam("drouting", "db_url", "CFG_DB_URL")
modparam("drouting", "persistent_state", DISABLE)
modparam("drouting", "probing_interval", ENABLE)
modparam("drouting", "force_dns", ENABLE)
modparam("drouting", "ruri_avp", '$avp(dr_ruri)')
modparam("drouting", "gw_id_avp", '$avp(dr_gw_id)')
modparam("drouting", "gw_priprefix_avp", '$avp(dr_gw_prfx)')
modparam("drouting", "rule_id_avp", '$avp(dr_rule_id)')
modparam("drouting", "rule_prefix_avp", '$avp(dr_rule_prfx)')
modparam("drouting", "carrier_id_avp", '$avp(dr_carr_id)')
.
.
.
startup_route {
avp_db_query("select carrierid from dr_carriers", "$avp(ids)");
for ($var(id) in $(avp(ids)[*]))
xlog("L_INFO", "Carrier ID: $var(id)\n");
}
.
.
.
route[get_route]
{
if (!do_routing("$avp(dr_group)", "", , "$var(rule_attr)",
"$var(gw_attr)", "$var(carr_attr)"))
{
xlog("L_ERR", "get_route: failure from do_routing! $retcode\n");
route(reply_error, "500", "Server Internal Error");
}
xlog("L_INFO", "get_route: rule_attr - $var(rule_attr)\n");
xlog("L_INFO", "get_route: gw_attr - $var(gw_attr)\n");
xlog("L_INFO", "get_route: carr_attr - $var(carr_attr)\n");
xlog("L_INFO", "get_route: ruri - $avp(dr_ruri)\n");
xlog("L_INFO", "get_route: gw_id - $avp(dr_gw_id)\n");
xlog("L_INFO", "get_route: gw_prfx - $avp(dr_gw_prfx)\n");
xlog("L_INFO", "get_route: rule_id - $avp(dr_rule_id)\n");
xlog("L_INFO", "get_route: rule_prfx - $avp(dr_rule_prfx)\n");
xlog("L_INFO", "get_route: carr_id - $avp(dr_carr_id)\n\n");
}
The output from the above execution is:
opensips[9801]: Carrier ID: IndyEdges
opensips[9801]: Carrier ID: Level3-VT
opensips: INFO:core:daemonize: pre-daemon process exiting with 0
opensips[9801]: get_route: rule_attr -
opensips[9801]: get_route: gw_attr -
opensips[9801]: get_route: carr_attr - id=pai;history=hi
opensips[9801]: get_route: ruri - <null>
opensips[9801]: get_route: gw_id - Level3-VT1
opensips[9801]: get_route: gw_prfx - +
opensips[9801]: get_route: rule_id - 4
opensips[9801]: get_route: rule_prfx - 1
opensips[9801]: get_route: carr_id - Level3-VT#012
You can see that the string ‘#012’ has been appended to the
Carrier ID. So far it has always been that string appended to the ID.
It started occurring after I moved from a RHEL 7 server using
MariaDB to a RHEL 6 server using MySQL, but in both cases I am
using the provided OpenSIPS scripts to create all database tables.
Any help would be appreciated.
Ben Newlin
_______________________________________________
Users mailing list
[email protected] <mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
