Re: [OpenSIPS-Users] How to get rate(cps) it which calls are hitting opensips
On Thu, Mar 26, 2015 at 7:41 PM, Aqs Younas wrote:
> Hi, users.
>
> I am new to opensips, just started playing with it. Please pardon me for
> my naive question, but I want cps in opensips.
>
> I have tried the following snippet, but still calls went on.
>
> if (is_method("INVITE")) {
> if (!rl_check("$si", "3", "RED")) {
> xlog("L_ERR","Cps limit reached [$fu/$tu/$ru/$ci]");
> sl_send_reply("403", "CPS Limit Exceeded");
> exit;
> };
> setflag(ACC_DO); # do accounting
> }
>
> Found at the following thread.
> http://opensips.org/pipermail/users/2012-April/021478.html
>
> Though this snippet is limiting the cps.(does not work for me) But I want
> is cps on over all opensips.
>
> Can anybody please tell me why this snippet is not working and how can i
> get overall cps on my box.I am using sipp for seding calls.
>
> Thanks for your help.
>
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
With using $si you limiting the individual source IPs.
Take a look at
http://www.opensips.org/html/docs/modules/devel/ratelimit.html#id293757
(the first example)
Also make sure that you set the timer_interval
--
Kind regards,
Laszlo Bekesi
http://voipfreak.net
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] How to get rate(cps) it which calls are hitting opensips
Hi, users.
I am new to opensips, just started playing with it. Please pardon me for my
naive question, but I want cps in opensips.
I have tried the following snippet, but still calls went on.
if (is_method("INVITE")) {
if (!rl_check("$si", "3", "RED")) {
xlog("L_ERR","Cps limit reached [$fu/$tu/$ru/$ci]");
sl_send_reply("403", "CPS Limit Exceeded");
exit;
};
setflag(ACC_DO); # do accounting
}
Found at the following thread.
http://opensips.org/pipermail/users/2012-April/021478.html
Though this snippet is limiting the cps.(does not work for me) But I want
is cps on over all opensips.
Can anybody please tell me why this snippet is not working and how can i
get overall cps on my box.I am using sipp for seding calls.
Thanks for your help.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] DRouting and Range of numbers
Hello, Is it possible to have a rule with a range of numbers in Dynamic routing? For instance I want 8881231231 to 5 to be routed to a specific gw. Can I do this with one rule only? I don't want 8881231236 to 9 to be routed to that gateway. Thanks, Ali Pey ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Opensips 1.11 on Centos 6.6, running but not listening?
thx for the reply, I think I fixed the issue, but do you know why am I seeing so many of these error messages? Is it just means some of the SIP message opensips gets can not be parsed or have some weird stuff in it? I checked these IP, they are from VoIP devices manufactured by Grandstream (e.g. HT501) but when I do some wireshark at my firewall, I don't see these weird characters though, so where they from? (e.g. the opensips said it parsed "°#001°°V•'Ï"ðé", I don't see those weird stuff in data captures at my firewall.) Or maybe I am not looking at the right places? Mar 26 17:22:42 OSIPIBD-4 /usr/local/sbin/opensips[3676]: ERROR:core:receive_msg: Unable to parse msg received from [xxx] Mar 26 17:22:42 OSIPIBD-4 /usr/local/sbin/opensips[3675]: ERROR:nathelper:fix_nated_sdp_f: Unable to get bodies from message Mar 26 17:22:42 OSIPIBD-4 /usr/local/sbin/opensips[3678]: ERROR:core:parse_first_line: bad request first line Mar 26 17:22:42 OSIPIBD-4 /usr/local/sbin/opensips[3678]: ERROR:core:parse_first_line: at line 0 char 14: Mar 26 17:22:42 OSIPIBD-4 /usr/local/sbin/opensips[3678]: ERROR:core:parse_first_line: parsed so far: °#001°°V•'Ï"ðé Mar 26 17:22:42 OSIPIBD-4 /usr/local/sbin/opensips[3678]: ERROR:core:parse_msg: message=<> -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/Opensips-1-11-on-Centos-6-6-running-but-not-listening-tp7596152p7596167.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] DROUTING module changing Carrier IDs
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:*users-boun...@lists.opensips.org
[mailto:users-boun...@lists.opensips.org] *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: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 -
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#
Re: [OpenSIPS-Users] DROUTING module changing Carrier IDs
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: users-boun...@lists.opensips.org
[mailto:users-boun...@lists.opensips.org] 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: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 -
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
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: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 -
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
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
Re: [OpenSIPS-Users] set_advertised_address suspected bug 1.9
I hope it's ok to re-phrase my question in this same email. Where is the best place to change the ip address using set_advertised_address for 200OK being sent out by OpenSIPS to the UAS. T. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] loose_route() sending ACK itself
Hi,
It may possible be that the received ACK is broken, leading to that kind
of looping. By broken I mean heaving wrong RURI or Route headers. Can
you post on a pastebin a sip capture of that call ?
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 26.03.2015 06:09, Satish Patel wrote:
Hi,
senario:
[UA]-[Opensips]-[Freeswitch]
UA sending correct ACK to freeswitch but Opensips loose_route()
sending it to itself and it break dialog, If use fix_dialog_route()
then it works, I don't have any IP address added in domain table also.
How do i check whether Freeswitch using loose_route for strict route?
I have following script:
if (has_totag()) {
if (loose_route()) {
if (is_method("BYE")) {
#setflag(ACC_DO); # do accounting ...
#setflag(ACC_FAILED); # ... even if
the transaction fails
} else if (is_method("INVITE")) {
# even if in most of the cases is
useless, do RR for
# re-INVITEs alos, as some buggy
clients do change route set
# during the dialog.
record_route();
}
if (check_route_param("nat=yes"))
setflag(NAT);
# route it out to whatever destination was set
by loose_route()
# in $du (destination URI).
route(relay);
} else {
if ( is_method("ACK") ) {
if ( t_check_trans() ) {
# non loose-route, but
stateful ACK; must be an ACK after
# a 487 or e.g. 404 from
upstream server
xlog("non loose-route section\n");
#t_relay();
exit;
} else {
# ACK without matching
transaction ->
# ignore and discard
xlog("ACK without matching
transaction\n");
exit;
}
}
___
Users mailing list
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
Re: [OpenSIPS-Users] Opensips 1.11 on Centos 6.6, running but not listening?
Hi, First check if opensips actually started : run "ps auxw | grep opensips" If it didn't , check the logs (messages or syslog) for errors. If you see the process, check with "netstat -lnp | grep opensips" to see the listening interfaces of OpenSIPS. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 25.03.2015 17:41, bluerain wrote: I am currently running Opensips 1.9 on Debian Whizzy, but as stated on my other thread, I am getting some weird error which opensips would suddenly stop working. So, I am starting a new installation of Opensips 1.11 on Centos 6.6 using the yum install method: 1. I was able to install yum opensips install with no issue, but there are some module it didn't install which I need (e.g. db_unixodbc and db_mysql and httpd) 2. So I went ahead download the source and all the dependency files needed and re-complie the oepnsips to get those .so files 3. After some tweaking of the database table structure and some other stuff, I was able to get opensips 1.11 running without error (on the message.log file) using my 1.9 config file. So I did opensipsctl restart (just to make sure opensips starts) I see: INFO: Restarting OpenSIPS : INFO: stopped INFO: Starting OpenSIPS : INFO: Removing stale PID file /var/run/opensips.pid. INFO: started (pid: 2079) but when I try to use a VoIP device to register to it, it doesn't response. thus I did: "sudo netstat -plnt" The only think I see that opensips is listening on is port by PID 2080 (I don't see 2079 at all) So what is happening? why no error and it seems opensips running but yet is not listsening on port 5060? I have 2 nic card and eth0 is the one with public IP and the default route where as the eth1 is the one with private IP and no default route. Thus I am sure everything is route out of the eth0 (public IP). When I do simply the command "opensips", it would simply return: Listening on udp: xxx.xxx.xxx.xxx [xxx.xxx.xxx.xxx]:5060 Aliases: *: (my FQDN):* So it looks like it think is listening on port 5060 but is not? Any help would be appreciated greatly! Thank you! -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/Opensips-1-11-on-Centos-6-6-running-but-not-listening-tp7596152.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. ___ Users mailing list 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
[OpenSIPS-Users] Routing NOTIFY to the phone
Hi all,
again on BLF...i noticed that after correct SUBSCRIPTION on the server
and on the phones of the monitored extension, when one of that change
its status, the NOTIFY was send to the server that reply with 404 and
*not* to the monitoring phone.
Here's a siptrace of what's happens:
U 2015/03/26 14:52:15.359182 172.20.1.47:47362 -> 172.20.1.2:5060
NOTIFY sip:5023@172.20.1.27:32768 SIP/2.0.
Via: SIP/2.0/UDP 172.20.1.47:47362;branch=z9hG4bK-xvlhtivkog2x;rport.
From: ;tag=o5sz371uyn.
To: ;tag=aqhxe3d198.
Call-ID: 5512ce5dc6fa-5z8xbqdcqj6f.
CSeq: 4 NOTIFY.
Max-Forwards: 70.
User-Agent: snom760/8.7.5.13.
Contact: ;reg-id=1.
Event: dialog.
Subscription-State: active.
Content-Type: application/dialog-info+xml.
Content-Length: 619.
.
terminatedsip:5...@voip.unisi.it:5060sip:2169@172.20.1.4:5060
U 2015/03/26 14:52:15.359534 172.20.1.2:5060 -> 172.20.1.47:47362
SIP/2.0 404 Not here.
Via: SIP/2.0/UDP
172.20.1.47:47362;received=172.20.1.47;branch=z9hG4bK-xvlhtivkog2x;rport=47362.
From: ;tag=o5sz371uyn.
To: ;tag=aqhxe3d198.
Call-ID: 5512ce5dc6fa-5z8xbqdcqj6f.
CSeq: 4 NOTIFY.
Server: OpenSIPS (1.11.3-tls (i386/linux)).
Content-Length: 0.
.
Here's the part of opensips.cfg involved:
XCAP modules
loadmodule "xcap.so"
loadmodule "xcap_client.so"
modparam("xcap", "integrated_xcap_server", 1)
PRESENCE modules
loadmodule "presence.so"
loadmodule "presence_mwi.so"
loadmodule "presence_callinfo.so"
loadmodule "presence_xml.so"
loadmodule "presence_dialoginfo.so"
modparam("presence", "db_url", "mysql://")
modparam("presence", "server_address", "sip:voip.unisi.it:5060")
modparam("presence", "notify_offline_body", 1)
modparam("presence", "fallback2db", 1)
modparam("presence", "clean_period", 30)
modparam("presence", "mix_dialog_presence", 1)
modparam("presence_xml","force_active",1)
[...]
route {
[...]
### PRESENCE
if(is_method("PUBLISH|SUBSCRIBE")) {
route(handle_presence);
}
[...]
}
# Presence route
route[handle_presence] {
xlog("L_INFO","Route PRESENCE on $rm [$fd/$fu/$rd/$ru/$si/]\n");
if(!t_newtran()){
sl_reply_error();
exit;
}
if (is_method("PUBLISH")) {
if($hdr(Sender)!= NULL)
handle_publish("$hdr(Sender)");
else
handle_publish();
} else if (is_method("SUBSCRIBE")) {
handle_subscribe();
}
exit;
}
How i can route NOTIFY to the right extensions ?
Thanks, Michele
--
Michele Pinassi
Responsabile Telefonia di Ateneo
Servizio Reti, Sistemi e Sicurezza Informatica - Università degli Studi di Siena
tel: 0577.(23)5000 - fax: 0577.(23)2053
Per trovare una soluzione rapida ai tuoi problemi tecnici
consulta le FAQ di Ateneo, http://www.faq.unisi.it
signature.asc
Description: OpenPGP digital signature
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
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 -
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
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
[OpenSIPS-Users] Dialog hanging at State 5
Hi, Dialog state is hanging at "state 5" when there is no response from the destination. What config we need to add to get the dialog moved to failure_route if, opensips is not receiving any response from destination for any request sent out.? Or How can we drop the dialog instead of moving to failure_route? -- Regards, John Mathew CEO/Director Divox International Inc. Contact: +91-903711 Email/MSN: john.mat...@divoxmedia.com WEB: www.divoxmedia.com ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] loose_route() sending ACK itself
Hi,
senario:
[UA]-[Opensips]-[Freeswitch]
UA sending correct ACK to freeswitch but Opensips loose_route() sending it
to itself and it break dialog, If use fix_dialog_route() then it works, I
don't have any IP address added in domain table also.
How do i check whether Freeswitch using loose_route for strict route?
I have following script:
if (has_totag()) {
if (loose_route()) {
if (is_method("BYE")) {
#setflag(ACC_DO); # do accounting ...
#setflag(ACC_FAILED); # ... even if the
transaction fails
} else if (is_method("INVITE")) {
# even if in most of the cases is useless,
do RR for
# re-INVITEs alos, as some buggy clients do
change route set
# during the dialog.
record_route();
}
if (check_route_param("nat=yes"))
setflag(NAT);
# route it out to whatever destination was set by
loose_route()
# in $du (destination URI).
route(relay);
} else {
if ( is_method("ACK") ) {
if ( t_check_trans() ) {
# non loose-route, but stateful
ACK; must be an ACK after
# a 487 or e.g. 404 from upstream
server
xlog("non loose-route section\n");
#t_relay();
exit;
} else {
# ACK without matching transaction
->
# ignore and discard
xlog("ACK without matching
transaction\n");
exit;
}
}
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
