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:bog...@opensips.org]
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

Users@lists.opensips.org<mailto:Users@lists.opensips.org>

http://lists.opensips.org/cgi-bin/mailman/listinfo/users

_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Reply via email to