Re: [OpenSIPS-Users] SIP/2.0 500 Server error occurred (6/SL)
I think we're running out of branches.. I believe the default is 12. Would this result in an internal 500 6/SL? What would I need to change and recompile to increase this? ERROR:tm:add_uac: maximum number of branches exceeded ERROR:tm:t_forward_nonack: failure to add branches On Thursday, October 27, 2022, 12:29:26 PM EDT, Bogdan-Andrei Iancu wrote: Hi, Do you see any error logs ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Bootcamp 5-16 Dec 2022, online https://www.opensips.org/training/OpenSIPS_eBootcamp_2022/ On 10/27/22 6:51 PM, Kneeoh via Users wrote: Hi all, i'm trying to track down the root cause of a SIP/2.0 500 Server error occurred (6/SL) response from Opensips and can't find any definition for what type of issue would cause this. It seems to happen after receiving several 503s from downstream endpoints, then this internal error is generated and sent. Any guidance is appreciated, Thanks in advance. ___ 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 ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] SIP/2.0 500 Server error occurred (6/SL)
Hi all, i'm trying to track down the root cause of a SIP/2.0 500 Server error occurred (6/SL) response from Opensips and can't find any definition for what type of issue would cause this. It seems to happen after receiving several 503s from downstream endpoints, then this internal error is generated and sent. Any guidance is appreciated, Thanks in advance.___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Fwd: STIR/Shaken payload issue.
Sunil,
I was having a similar issue... it looks like part 2 of the base64 string
decodes to:
{"attest"8""Â#§²'Fâ#¥²#““S333ƒ#sR%×ÒÂ&–B#£c#“ssrÂ&÷&–r#§²'Fâ#¢#““S333ƒ#sb'ÒÂ&÷&–v–B#¢ÖG6F6B×5ds"}
My problem was that I was using sngrep to find my identity header and it
appears to have been truncating my string. upon using ngrep to get the raw
packet data I found the identity string was totally different and decoded
properly.
On Monday, May 24, 2021, 02:13:08 AM EDT, Sunil More
wrote:
Hello All,
I tried the same with Opensips version 3.1.2 , Still the same result. The
Payload is not a valid JSON.
version: opensips 3.1.2 (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, Q_MALLOC,
F_MALLOC, HP_MALLOC, DBG_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll, sigio_rt, select.
git revision: 539ab0b3a
main.c compiled on 05:43:20 May 24 2021 with gcc 7
Regards,Sunil More
-- Forwarded message -
From: Sunil More
Date: Thu, 20 May 2021 at 15:55
Subject: STIR/Shaken payload issue.
To: users@lists.opensips.org
Hello All,
I was working to use stir shaken module. The certificates are put in place and
Identity Header is also created. However the Identity when tried to put on
JWT.io for validation , I can observe that the payload is not good.
Here is the identity Heade
Identity:
eyJhbGciOiJFUzI1NiIsInBwdCI6InNoYWtlbiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9hcHBzLnNhbWVzcGFjZS5jb20vc2VydmVyLmNydCJ9.eyJhdHRlc3QiOCIiwiZGVzdCI6eyJ0biI6WyI5MTk1MDMzMzgyNzUiXX0sImlhdCI6MTYyMDkxMDc3Nywib3JpZyI6eyJ0biI6IjkxOTUwMzMzODI3NiJ9LCJvcmlnaWQiOiJkc2FkYXNhc2Zkcy1kc2FkYXNkLXNWRzIn0.JzYHlbStXK7gpmRWVZY_IC8VmeZfaKWBzGTOfGU82OQ3w28lctaYv-YAzBdjqjUGJKISid327KSzUGGvpXYBSg;info=;ppt="shaken"
After JWT.io
Header for algorithm and token type looks ok ..
{
"alg": "ES256",
"ppt": "shaken",
"typ": "passport",
"x5u": "https://apps.samespace.com/server.crt;
}
However payload looks like this which is probably some invalid JSON, I am not
sure what could cause this.
"{\"attest\"8\"\"�#��'F�#��#�\u0013�S\u000�#sR%���&�\u0017B#�\u0013c#\u0003�\u0013\u0003ssr�&�&�r#��'F�#�#�\u0013�S\u000�#sb'��&�&�v�B#�\u0016F\u00176\u00176fG2�G6\u0016F\u00176B�5ds\"}"
Here is the code snippet used .
stir_shaken_auth("B", $var(origid),$var(cert),
$var(privKey),"https://apps.samespace.com/server.crt","919503338276","919503338275;);
I am using opensips version as below
version: opensips 3.1.1 (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, Q_MALLOC,
F_MALLOC, HP_MALLOC, DBG_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll, sigio_rt, select.
git revision: 229ec0793
main.c compiled on 11:50:44 Jan 15 2021 with gcc 7
Kindly let me know if there is something wrong that I could be doing. I checked
the sample from https://transnexus.com/whitepapers/understanding-stir-shaken/
The Identity from this example shows a good payload.
Regards,
Sunil More
Phone : 919503338275
Sent from Mail for Windows 10
___
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] Stir/Shaken Certificate Failed to Load
Hi, following the docs and blog post here:
https://opensips.org/docs/modules/3.1.x/stir_shaken.html and here:
https://blog.opensips.org/2020/01/23/shaken-not-stirred/
I'm getting an error regarding certificate parsing and loading. I'm guessing
it's got to do with how I'm loading the certs. I just want to see if I can
make it add the identity header and this is a test run so it's just a simple
hard code:
# Do Stir/Shaken Signing
$var(cert) = "/home/homey/key.pem-public.pem";
$var(privKey) = "/home/homey/private_key.pem";
stir_shaken_auth("A", "$ci", "$var(cert)", "$var(privKey)",
"https://certs.example.org/cert.pem;);
results in no identity header and the following in the logs:
May 20 18:16:10 stir-shaken /usr/local/sbin/opensips[65744]:
ERROR:stir_shaken:load_cert: Failed to parse certificate
May 20 18:16:10 stir-shaken /usr/local/sbin/opensips[65744]:
ERROR:stir_shaken:w_stir_auth: Failed to load certificate
Any guidance would be appreciated.
--
Sent from:
http://opensips-open-sip-server.1449251.n2.nabble.com/OpenSIPS-Users-f1449235.html
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] siptrace trace_dialog() not capturing ACKs or other replies 1.11.11
I've followed the documentation for using the siptrace module to capture
packets and transmit them to a sipcapture node. Things are kind of working,
however, I'm not getting ACKs or other replies in the capture node. I'm using
the following in my script. Any ideas or pointers on what I might be doing
wrong?
SIP Trace moduleloadmodule "siptrace.so"modparam("siptrace", "db_url",
"mysql://user:passwd@host/dbname")modparam("siptrace", "duplicate_uri",
"sip:10.10.61.191:9060")modparam("siptrace", "duplicate_with_hep",
1)modparam("siptrace", "trace_to_database", 0)modparam("siptrace",
"enable_ack_trace", 1)modparam("siptrace", "trace_on", 1)modparam("siptrace",
"trace_flag", "TRACE_FLAG")modparam("siptrace", "hep_version", 2)
# create dialog with timeout and hide topology if ( !create_dialog("B") ) {
xlog("L_INFO", "Unable to create dialog \n"); send_reply("500","Internal Server
Error"); exit;
} else {
# We have a dialog, Lets hide the topology from where the call originated
topology_hiding(); $T_fr_timeout = 5; }
# Trace this dialog setflag(TRACE_FLAG); #sip_trace(); trace_dialog();___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] RabbitMQ Heartbeat issue
kneeoh: Hello, I'm trying to chase down an issue where opensips simply breaks
it's connection with rabbitmq, howerver opensipsctl fifo subscribers_list shows
3 active subscriptions. Rabbitmq shows NO connections, I even have a timer
route that runs every 30 seconds that executes even subscribe. I have heartbeat
set: modparam("event_rabbitmq", "heartbeat", 3) and rabbitmq is running on the
localhost. Has anyone ever dealt with this? [5:56pm] kneeoh: opensipsctl fifo
subscribers_list[5:56pm] kneeoh: Event:: E_ACC_EVENT id=4[5:56pm] kneeoh:
Subscriber:: socket=rabbitmq:rabbit@localhost/whsl_cdrs expire=never[5:56pm]
kneeoh: Event:: E_ACC_CDR id=5[5:56pm] kneeoh: Subscriber::
socket=rabbitmq:rabbit@localhost/whsl_cdrs expire=never[5:56pm] kneeoh: Event::
E_ACC_MISSED_EVENT id=6[5:56pm] kneeoh: Subscriber::
socket=rabbitmq:rabbit@localhost/whsl_missed expire=never[6:10pm] kneeoh:
opensipsctl fifo version[6:10pm] kneeoh: Server:: OpenSIPS (1.11.3-notls
(x86_64/linux))[6:10pm] kneeoh: librabbitmq-dev 0.4.1-1
I also re-compiled to 1.11.11 and am still getting connections closed. I had to
remove the heartbeat modparam to get this working, but I'm still concerned that
threads will lock if there is an issue writing to rabbitmq.___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] SIPTrace not sending to duplicate_uri
Apparently setting the trace flag is required before trace_dialog() contrary to
the docs. I've set that and am seeing packets egress (although I don't think
I'm seeing the full dialog trace. Only 3 packets on a call setup) It looks like
i'm not getting the replys. Do I need to arm trace_dialog() again in the
on_reply route? My understanding was that you only have to set it once.
Issue 2: SIP traffic goes across eth0, my public facing interface. I want the
siptrace module to shoot trace data out of eth1, my private interface. The
kernel has a static route that says to get to my duplicate_uri host, use eth1.
Which works at the kernel level. I can issue a ping to the duplicate_uri host
and I see requests going out the private and replys, etc.
However, when running tcpdump and placing a call via this opensips box, I see
that eth0 is the egress interface that is being used to try to reach the
duplicate_uri host. I've tried adding a separate listen statement for that
private interface, but that didn't do anything. I thought perhaps the
trace_local_ip parameter controlled, this but was informed by Liviu that this
was not the case. Any idea on how to solve this problem or the problem with
missing replys when using trace_dialog()?
Thanks in advance! (I'm on IRC if anyone has any more detailed questions...or
just ask here.)
On Wednesday, March 30, 2016 11:49 AM, Kneeoh <kne...@yahoo.com> wrote:
Hi Liviu, I did confirm that trace_on was already set to 1. I did define the
trace flag as you suggested and tried it with both trace_dialog() and
sip_trace() but am still not seeing any packets egress from the source host to
the dest host. Here's what I have set up. I had to fill in a bogus DB (not
using it anyway) because it wouldn't let me start opensips if it wasn't
defined. My goal is to have this sip_trace node send captures to a sipcapture
(homer) node.
SIP Trace module
loadmodule "siptrace.so"
modparam("siptrace", "db_url", "mysql://user:passwd@host/dbname")
modparam("siptrace", "duplicate_uri", "sip:192.168.2.142:9060")
modparam("siptrace", "duplicate_with_hep", 1)
modparam("siptrace", "trace_to_database", 0)
modparam("siptrace", "trace_on", 1)
modparam("siptrace", "trace_flag", "TRACE_FLAG")
modparam("siptrace", "hep_version", 2)
INSIDE MAIN ROUTE BLOCK:
# create dialog with timeout and hide topology
if ( !create_dialog("B") ) {
xlog("L_INFO", "Unable to create dialog \n");
send_reply("500","Internal Server Error");
exit;
} else {
# We have a dialog, Lets hide the topology from where the call
originated
topology_hiding();
}
# Trace this dialog
setflag(TRACE_FLAG);
sip_trace();
#trace_dialog();
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] SIPTrace not sending to duplicate_uri
Hi Liviu, I did confirm that trace_on was already set to 1. I did define the
trace flag as you suggested and tried it with both trace_dialog() and
sip_trace() but am still not seeing any packets egress from the source host to
the dest host. Here's what I have set up. I had to fill in a bogus DB (not
using it anyway) because it wouldn't let me start opensips if it wasn't
defined. My goal is to have this sip_trace node send captures to a sipcapture
(homer) node.
SIP Trace module
loadmodule "siptrace.so"
modparam("siptrace", "db_url", "mysql://user:passwd@host/dbname")
modparam("siptrace", "duplicate_uri", "sip:192.168.2.142:9060")
modparam("siptrace", "duplicate_with_hep", 1)
modparam("siptrace", "trace_to_database", 0)
modparam("siptrace", "trace_on", 1)
modparam("siptrace", "trace_flag", "TRACE_FLAG")
modparam("siptrace", "hep_version", 2)
INSIDE MAIN ROUTE BLOCK:
# create dialog with timeout and hide topology
if ( !create_dialog("B") ) {
xlog("L_INFO", "Unable to create dialog \n");
send_reply("500","Internal Server Error");
exit;
} else {
# We have a dialog, Lets hide the topology from where the call
originated
topology_hiding();
}
# Trace this dialog
setflag(TRACE_FLAG);
sip_trace();
#trace_dialog();
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] SIPTrace not sending to duplicate_uri
Hi Liviu, Thanks for responding. I did not set the parameters you mention b/c the documentation said I didn't need to. "1.4.2. trace_dialog() The function triggers the tracing of all messages belonging to a dialog. The function must be called for the initial request (that starts the dialog) and it will automatically take care of tracing evertyhing related to that dialog. When using this function, you do not have to explicity set any tracing flag or to explicitly call anothe trace function. This function can be used from REQUEST_ROUTE." I'll re-test with the parameters and report back to you. trace_on makes sense...that's probably my problem. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] SIPTrace not sending to duplicate_uri
I need a little help figuring out why my implementation of the siptrace module
isn't working as expected. I've placed:# Trace this dialog
trace_dialog();
In my main route block right after:if ( !create_dialog("B") ) {
xlog("L_INFO", "Unable to create dialog \n");
send_reply("500","Internal Server Error");
exit;
}
When I place a call and tcpdump the destination host defined
in:modparam("siptrace", "duplicate_uri", "sip:192.168.2.142:9060")
I do not see any packets heading towards that host. I've run a debug 4 and am
getting the following output. Which is confusing me, since I've established a
dialog and have issued the trace_dialog command. There should be "something to
trace here". Where am I going wrong? I'm on 1.11.5
DBG:siptrace:trace_dialog: Nothing to trace here
DBG:siptrace:trace_sl_onreply_out: trace slonreply out
DBG:siptrace:trace_sl_onreply_out: nothing to trace...
DBG:siptrace:trace_onreq_in: trace on req in
DBG:siptrace:trace_onreq_in: nothing to trace...
DBG:siptrace:trace_msg_out: trace off...
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Opensips 2.1.x siptrace not sending packet to homer
I have the same issue in 1.11.5. Did you ever get a resolution to this? -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/Opensips-2-1-x-siptrace-not-sending-packet-to-homer-tp7595668p7602360.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
[OpenSIPS-Users] Segfault 1.11.5
Any ideas on what this may be? I just had a segfault / crash of opensips. Looks like something in the TM module. opensips[17425]: segfault at c ip 7f24be7da046 sp 7fff4cb3bf00 error 4 in tm.so[7f24be799000+64000] I don't see anything else interesting in the logs. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Couchbase Integration Issues with RateLimit Module
Hi I've been using the couchbase module for cachedb for a while now with no issues. Recently I started tracking and enforcing channels w/ the dialog module and shared profiles as well as CPS via the ratelimit module. For the past week I've been getting sporadic opensips crashes (b/c all of the children fill up) and it looks related to the rl module not being able to increase the counter. I've attached the logs before it crashes. ERROR:cachedb_couchbase:couchbase_arithmetic_cb: Failure to perform arithmetic termlimit_total_cps - The key does not exist on the server ERROR:ratelimit:rl_change_counter: cannot change counter for pipe total_cps with 1 ERROR:ratelimit:w_rl_check_3: cannot increase counter ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] For-Each Example
Thanks Bogdan, that did the trick.
On Wednesday, September 9, 2015 6:14 AM, Bogdan-Andrei Iancu
<bog...@opensips.org> wrote:
Hi,
If you have an AVP holding multiple value (instances), you can iterate through
all of them as:
$var(n) = 0;
while ( $(avp(my_avp)[$var(n)]) != NULL ) {
xlog("value of my avp on position $var(n) is $(avp(my_avp)[$var(n)]) \n");
$var(n) = $var(n) + 1 ;
}
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com On 09.09.2015 00:01, Kneeoh wrote:
I'm trying to figure out how to iterate through an indexed $avp that holds
json query results. The docs are kind of spotty. Can someone share a working
snippet of code that iterates through an $avp ? This one isn't quite working
for me. First off it says only $var and $avp can be iterated, but this example
has a $json var.
# iterate through all JSON documents returned by a MongoDB query
cache_raw_query("mongodb:location", "{... find ...}", "$avp(res)");
for ($json(contact) in $(avp(res)[*]))
xlog("Found: $json(contact/phone) $json(contact/email)\n");
___
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] For-Each Example
I'm trying to figure out how to iterate through an indexed $avp that holds json
query results. The docs are kind of spotty. Can someone share a working snippet
of code that iterates through an $avp ? This one isn't quite working for me.
First off it says only $var and $avp can be iterated, but this example has a
$json var.
# iterate through all JSON documents returned by a MongoDB query
cache_raw_query("mongodb:location", "{... find ...}", "$avp(res)");
for ($json(contact) in $(avp(res)[*]))
xlog("Found: $json(contact/phone) $json(contact/email)\n");
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Failed to replicate Dialog
Liviu, I'm still getting the stream of errors on the back up host with the configuration I've posted on this thread and -m 2048 -M 512 on both hosts. I'm running around 4-500 CPS at the moment. I saw some notes that this has since been moved to TCP in opensips 2. I'm guessing the replicated dialogs are greater than 1500 bytes and are truncated when received on the backup host. That's all I can figure w/o doing a tcp dump on the replication port to confirm...I'll do that next. On Wednesday, June 10, 2015 10:04 AM, Kneeoh <kne...@yahoo.com> wrote: Thanks Liviu, I'm running Opensips with the following memory allocations on both the primary and secondary hosts. Doesn't this mean I'm allocating 2G of shared mem and 512 Megabytes of Pkg mem? I think i'm not running more than 1000 calls per second per your last email which should take only 640Mb of ram. I am running dialog profiling and ratelimit enforcement so I'm not sure how that factors in to increasing the memory requirement or if it's causing the replicated dialog to truncate and miss data. -m 2048 -M 512 On Thursday, June 4, 2015 3:03 PM, Kneeoh <kne...@yahoo.com> wrote: I just popped up to 1.11.5 and am still getting a stream of dialog replication failure even though the non-active host IS listening on the same socket as the primary host. I'm banging my head on the desk, I can't figure out what this isn't working. Host 2 (passive host) Jun 4 18:34:50 /usr/local/sbin/opensips[27448]: ERROR:dialog:receive_binary_packet: Failed to process a binary packet! Jun 4 18:34:50 /usr/local/sbin/opensips[27445]: ERROR:dialog:dlg_replicated_update: dialog not found, building new Jun 4 18:34:50 /usr/local/sbin/opensips[27445]: ERROR:dialog:dlg_replicated_create: Dialog in DB doesn't match any listening sockets Jun 4 18:34:50 /usr/local/sbin/opensips[27445]: ERROR:dialog:receive_binary_packet: Failed to process a binary packet! Netstat on Host 1netstat -nlp | grep opensips udp 0 0 192.168.30.40:5060 0.0.0.0:* 7304/opensips <---virtual ip udp 0 0 192.168.30.39:5060 0.0.0.0:* 7304/opensips <---virtual ip udp 0 0 10.1.0.41:5092 0.0.0.0:* 7304/opensips <---binary replication binding (bin_listen) Netstat on Host 2netstat -nlp | grep opensips udp 0 0 192.168.30.40:5060 0.0.0.0:* 27441/opensips <---virtual ip udp 0 0 192.168.30.39:5060 0.0.0.0:* 27441/opensips <---virtual ip udp 2176 0 10.1.0.42:5092 0.0.0.0:* 27441/opensips <---binary replication binding (bin_listen) On Thursday, May 7, 2015 1:36 PM, Kneeoh <kne...@yahoo.com> wrote: Hi Bogdan, Both Opensips hosts are set to use corosync/heartbeat to failover the two IPs in our config. Both hosts are set to non-localbind and opensips is explicitly listening on both of the VIPs. This is why I'm confused. It seems that everything is configured correctly yet I'm getting these errors on the inactive opensips instance. On Thursday, May 7, 2015 1:05 PM, Bogdan-Andrei Iancu <bog...@opensips.org> wrote: Hi Kneeoh, The dialog replication is done assuming that both opensips servers do share the listening interface (via vrrp, heartbeat, etc). Do you different listening IPs on the 2 opensips instances ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 29.04.2015 20:35, Kneeoh wrote: Hello, I've got two VIPs on two instances of opensips and am doing dialog replication. I'm getting a steady stream of failed to replicate dialog errors in my opensips log. 192.168.30.39 192.168.30.40 are the two VIPs. Both have a listen = on both opensips configs. I'm not sure if this line in the log is the problem but it looks like it: " DBG:core:bin_pop_str: Popped: '' [0]" I'm not sure how the receive IP could be an empty string. debug: DBG:dialog:dlg_replicated_create: Received replicated dialog! DBG:core:bin_pop_str: Popped: 'udp:192.168.30.40:5060' [22] DBG:core:grep_sock_info: checking if host==us: 13==13 && [192.168.30.40] == [192.168.30.39] DBG:core:grep_sock_info: checking if port 5060 matches port 5060 DBG:core:grep_sock_info: checking if host==us: 13==13 && [192.168.30.40] == [192.168.30.40] DBG:core:grep_sock_info: checking if port 5060 matches port 5060 DBG:core:bin_pop_str: Popped: '' [0] ERROR:dialog:dlg_replicated_create: Dialog in DB doesn't match any listening sockets DBG:dialog:destroy_dlg: destroing dialog 0x7f09ddd9f958 DBG:dialog:destroy_dlg: dlg expired or not in list - dlg 0x7f09ddd9f958 [2225:721583693] with clid 'f4f2446c-6937-1233-f798-0024e869f1eb' and tags 'NULL' 'NULL' E
Re: [OpenSIPS-Users] Failed to replicate Dialog
Liviu, I think I have found the problem. I ran a capture of the replicated messages and looked at the payload. It looks to me like opensips is adding an extra 0 to the socket port See the 50600 below? P4CKdialog$ec64e7b6-cd03-1233-be9b-0024e869f3d56B7Baccavm01Hsip:12125551212@55.55.233.248"sip:15194381165@192.168.30.40:5060hrdvudp:192.168.30.40:50600"sip:5194790526@55.55.233.248:5060oU P4CKadialog!51121598_100315427@55.55.65.170gK0c7cc374sip:+13459390626@55.55.65.170sip:+19172000727@192.168.30.40gudp:192.168.30.40:50600$sip:+13459290326@55.55.65.170:5060oU P4CKdialog.159eb04c526111e58ba600151712bf98@55.55.15.58)447782421-3843121490-352364171-2562658839.sip:+13128009168@55.55.15.58:5063;user=phone)sip:+12516444334@192.168.30.39;user=phone4}udp:192.168.30.39:50600.sip:+13128009168@55.55.15.58:5063;user=phoneoU On Thursday, September 3, 2015 1:26 PM, Kneeoh <kne...@yahoo.com> wrote: Liviu, I'm still getting the stream of errors on the back up host with the configuration I've posted on this thread and -m 2048 -M 512 on both hosts. I'm running around 4-500 CPS at the moment. I saw some notes that this has since been moved to TCP in opensips 2. I'm guessing the replicated dialogs are greater than 1500 bytes and are truncated when received on the backup host. That's all I can figure w/o doing a tcp dump on the replication port to confirm...I'll do that next. On Wednesday, June 10, 2015 10:04 AM, Kneeoh <kne...@yahoo.com> wrote: Thanks Liviu, I'm running Opensips with the following memory allocations on both the primary and secondary hosts. Doesn't this mean I'm allocating 2G of shared mem and 512 Megabytes of Pkg mem? I think i'm not running more than 1000 calls per second per your last email which should take only 640Mb of ram. I am running dialog profiling and ratelimit enforcement so I'm not sure how that factors in to increasing the memory requirement or if it's causing the replicated dialog to truncate and miss data. -m 2048 -M 512 On Thursday, June 4, 2015 3:03 PM, Kneeoh <kne...@yahoo.com> wrote: I just popped up to 1.11.5 and am still getting a stream of dialog replication failure even though the non-active host IS listening on the same socket as the primary host. I'm banging my head on the desk, I can't figure out what this isn't working. Host 2 (passive host) Jun 4 18:34:50 /usr/local/sbin/opensips[27448]: ERROR:dialog:receive_binary_packet: Failed to process a binary packet! Jun 4 18:34:50 /usr/local/sbin/opensips[27445]: ERROR:dialog:dlg_replicated_update: dialog not found, building new Jun 4 18:34:50 /usr/local/sbin/opensips[27445]: ERROR:dialog:dlg_replicated_create: Dialog in DB doesn't match any listening sockets Jun 4 18:34:50 /usr/local/sbin/opensips[27445]: ERROR:dialog:receive_binary_packet: Failed to process a binary packet! Netstat on Host 1netstat -nlp | grep opensips udp 0 0 192.168.30.40:5060 0.0.0.0:* 7304/opensips <---virtual ip udp 0 0 192.168.30.39:5060 0.0.0.0:* 7304/opensips <---virtual ip udp 0 0 10.1.0.41:5092 0.0.0.0:* 7304/opensips <---binary replication binding (bin_listen) Netstat on Host 2netstat -nlp | grep opensips udp 0 0 192.168.30.40:5060 0.0.0.0:* 27441/opensips <---virtual ip udp 0 0 192.168.30.39:5060 0.0.0.0:* 27441/opensips <---virtual ip udp 2176 0 10.1.0.42:5092 0.0.0.0:* 27441/opensips <---binary replication binding (bin_listen) On Thursday, May 7, 2015 1:36 PM, Kneeoh <kne...@yahoo.com> wrote: Hi Bogdan, Both Opensips hosts are set to use corosync/heartbeat to failover the two IPs in our config. Both hosts are set to non-localbind and opensips is explicitly listening on both of the VIPs. This is why I'm confused. It seems that everything is configured correctly yet I'm getting these errors on the inactive opensips instance. On Thursday, May 7, 2015 1:05 PM, Bogdan-Andrei Iancu <bog...@opensips.org> wrote: Hi Kneeoh, The dialog replication is done assuming that both opensips servers do share the listening interface (via vrrp, heartbeat, etc). Do you different listening IPs on the 2 opensips instances ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 29.04.2015 20:35, Kneeoh wrote: Hello, I've got two VIPs on two instances of opensips and am doing dialog replication. I'm getting a steady stream of failed to replicate dialog errors in my opensips log. 192.168.30.39 192.168.30.40 are the two VIPs. Both have a listen = on both opensips configs. I'm not sure if this line in the log is the problem but it looks like it: " DBG:core:bin_
Re: [OpenSIPS-Users] OpenSIPS Data Base tables in a MySQL Cluster
Victor, you'll need to change all of the opensips tables to InnoDB (not sure why they're not that way by default) in order for it to be compatible with galera. I do this before installing the DB by cd'ing to the /usr/local/share/opensips/mysql dir and running the following command: sed -i 's/MyISAM/InnoDB/g' * Once done proceed with installing the DB to your galera cluster. Galera and MariaDB works great and has saved my tail several times. Make sure you always have an ODD number of nodes in the cluster to avoid split brain conflicts. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Drouting Probing broken 1.11.1
Hi All, when implementing gateway probing type (2) - probing all the time. If disabled, the destination will be automatically re-enabled when the probing will succeed next time; If a gateway fails it does not come back automatically. I have to go into the DB, set state to 0 and reload drouting. Upon reloading I see opensips probe the gateway and get a response which keeps it active. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] opensipsctl fifo rl_list
When executing opensipsctl fifo rl_list, Does the counter integer represent CPS or do I need to divide that number by the ratelimit modules' interval i.e. 10 by default? ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] missing from user 500 Internal Server Error
Can someone tell me if this is illegal per RFC and if so where the language is? From: sip:20.32.34.55:5063 Opensips is kicking out a 500 Internal Server Error and the following in the logs: ERROR:core:parse_from_header: bad from header ERROR:dialog:pre_match_parse: failed to get From header Id like to either fix it with some Opensips magic, (like ignore from and just pass the call) or point the originator to the right documentation to go fix their switch. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Failed to replicate Dialog
Thanks Liviu, I'm running Opensips with the following memory allocations on both the primary and secondary hosts. Doesn't this mean I'm allocating 2G of shared mem and 512 Megabytes of Pkg mem? I think i'm not running more than 1000 calls per second per your last email which should take only 640Mb of ram. I am running dialog profiling and ratelimit enforcement so I'm not sure how that factors in to increasing the memory requirement or if it's causing the replicated dialog to truncate and miss data. -m 2048 -M 512 On Thursday, June 4, 2015 3:03 PM, Kneeoh kne...@yahoo.com wrote: I just popped up to 1.11.5 and am still getting a stream of dialog replication failure even though the non-active host IS listening on the same socket as the primary host. I'm banging my head on the desk, I can't figure out what this isn't working. Host 2 (passive host) Jun 4 18:34:50 /usr/local/sbin/opensips[27448]: ERROR:dialog:receive_binary_packet: Failed to process a binary packet! Jun 4 18:34:50 /usr/local/sbin/opensips[27445]: ERROR:dialog:dlg_replicated_update: dialog not found, building new Jun 4 18:34:50 /usr/local/sbin/opensips[27445]: ERROR:dialog:dlg_replicated_create: Dialog in DB doesn't match any listening sockets Jun 4 18:34:50 /usr/local/sbin/opensips[27445]: ERROR:dialog:receive_binary_packet: Failed to process a binary packet! Netstat on Host 1netstat -nlp | grep opensips udp 0 0 192.168.30.40:5060 0.0.0.0:* 7304/opensips ---virtual ip udp 0 0 192.168.30.39:5060 0.0.0.0:* 7304/opensips ---virtual ip udp 0 0 10.1.0.41:5092 0.0.0.0:* 7304/opensips ---binary replication binding (bin_listen) Netstat on Host 2netstat -nlp | grep opensips udp 0 0 192.168.30.40:5060 0.0.0.0:* 27441/opensips ---virtual ip udp 0 0 192.168.30.39:5060 0.0.0.0:* 27441/opensips ---virtual ip udp 2176 0 10.1.0.42:5092 0.0.0.0:* 27441/opensips ---binary replication binding (bin_listen) On Thursday, May 7, 2015 1:36 PM, Kneeoh kne...@yahoo.com wrote: Hi Bogdan, Both Opensips hosts are set to use corosync/heartbeat to failover the two IPs in our config. Both hosts are set to non-localbind and opensips is explicitly listening on both of the VIPs. This is why I'm confused. It seems that everything is configured correctly yet I'm getting these errors on the inactive opensips instance. On Thursday, May 7, 2015 1:05 PM, Bogdan-Andrei Iancu bog...@opensips.org wrote: Hi Kneeoh, The dialog replication is done assuming that both opensips servers do share the listening interface (via vrrp, heartbeat, etc). Do you different listening IPs on the 2 opensips instances ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 29.04.2015 20:35, Kneeoh wrote: Hello, I've got two VIPs on two instances of opensips and am doing dialog replication. I'm getting a steady stream of failed to replicate dialog errors in my opensips log. 192.168.30.39 192.168.30.40 are the two VIPs. Both have a listen = on both opensips configs. I'm not sure if this line in the log is the problem but it looks like it: DBG:core:bin_pop_str: Popped: '' [0] I'm not sure how the receive IP could be an empty string. debug: DBG:dialog:dlg_replicated_create: Received replicated dialog! DBG:core:bin_pop_str: Popped: 'udp:192.168.30.40:5060' [22] DBG:core:grep_sock_info: checking if host==us: 13==13 [192.168.30.40] == [192.168.30.39] DBG:core:grep_sock_info: checking if port 5060 matches port 5060 DBG:core:grep_sock_info: checking if host==us: 13==13 [192.168.30.40] == [192.168.30.40] DBG:core:grep_sock_info: checking if port 5060 matches port 5060 DBG:core:bin_pop_str: Popped: '' [0] ERROR:dialog:dlg_replicated_create: Dialog in DB doesn't match any listening sockets DBG:dialog:destroy_dlg: destroing dialog 0x7f09ddd9f958 DBG:dialog:destroy_dlg: dlg expired or not in list - dlg 0x7f09ddd9f958 [2225:721583693] with clid 'f4f2446c-6937-1233-f798-0024e869f1eb' and tags 'NULL' 'NULL' ERROR:dialog:receive_binary_packet: Failed to process a binary packet! ___ 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] Failed to replicate Dialog
I just popped up to 1.11.5 and am still getting a stream of dialog replication failure even though the non-active host IS listening on the same socket as the primary host. I'm banging my head on the desk, I can't figure out what this isn't working. Host 2 (passive host) Jun 4 18:34:50 /usr/local/sbin/opensips[27448]: ERROR:dialog:receive_binary_packet: Failed to process a binary packet! Jun 4 18:34:50 /usr/local/sbin/opensips[27445]: ERROR:dialog:dlg_replicated_update: dialog not found, building new Jun 4 18:34:50 /usr/local/sbin/opensips[27445]: ERROR:dialog:dlg_replicated_create: Dialog in DB doesn't match any listening sockets Jun 4 18:34:50 /usr/local/sbin/opensips[27445]: ERROR:dialog:receive_binary_packet: Failed to process a binary packet! Netstat on Host 1netstat -nlp | grep opensips udp 0 0 192.168.30.40:5060 0.0.0.0:* 7304/opensips ---virtual ip udp 0 0 192.168.30.39:5060 0.0.0.0:* 7304/opensips ---virtual ip udp 0 0 10.1.0.41:5092 0.0.0.0:* 7304/opensips ---binary replication binding (bin_listen) Netstat on Host 2netstat -nlp | grep opensips udp 0 0 192.168.30.40:5060 0.0.0.0:* 27441/opensips ---virtual ip udp 0 0 192.168.30.39:5060 0.0.0.0:* 27441/opensips ---virtual ip udp 2176 0 10.1.0.42:5092 0.0.0.0:* 27441/opensips ---binary replication binding (bin_listen) On Thursday, May 7, 2015 1:36 PM, Kneeoh kne...@yahoo.com wrote: Hi Bogdan, Both Opensips hosts are set to use corosync/heartbeat to failover the two IPs in our config. Both hosts are set to non-localbind and opensips is explicitly listening on both of the VIPs. This is why I'm confused. It seems that everything is configured correctly yet I'm getting these errors on the inactive opensips instance. On Thursday, May 7, 2015 1:05 PM, Bogdan-Andrei Iancu bog...@opensips.org wrote: Hi Kneeoh, The dialog replication is done assuming that both opensips servers do share the listening interface (via vrrp, heartbeat, etc). Do you different listening IPs on the 2 opensips instances ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 29.04.2015 20:35, Kneeoh wrote: Hello, I've got two VIPs on two instances of opensips and am doing dialog replication. I'm getting a steady stream of failed to replicate dialog errors in my opensips log. 192.168.30.39 192.168.30.40 are the two VIPs. Both have a listen = on both opensips configs. I'm not sure if this line in the log is the problem but it looks like it: DBG:core:bin_pop_str: Popped: '' [0] I'm not sure how the receive IP could be an empty string. debug: DBG:dialog:dlg_replicated_create: Received replicated dialog! DBG:core:bin_pop_str: Popped: 'udp:192.168.30.40:5060' [22] DBG:core:grep_sock_info: checking if host==us: 13==13 [192.168.30.40] == [192.168.30.39] DBG:core:grep_sock_info: checking if port 5060 matches port 5060 DBG:core:grep_sock_info: checking if host==us: 13==13 [192.168.30.40] == [192.168.30.40] DBG:core:grep_sock_info: checking if port 5060 matches port 5060 DBG:core:bin_pop_str: Popped: '' [0] ERROR:dialog:dlg_replicated_create: Dialog in DB doesn't match any listening sockets DBG:dialog:destroy_dlg: destroing dialog 0x7f09ddd9f958 DBG:dialog:destroy_dlg: dlg expired or not in list - dlg 0x7f09ddd9f958 [2225:721583693] with clid 'f4f2446c-6937-1233-f798-0024e869f1eb' and tags 'NULL' 'NULL' ERROR:dialog:receive_binary_packet: Failed to process a binary packet! ___ 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] Failed to replicate Dialog
Hi Bogdan, Both Opensips hosts are set to use corosync/heartbeat to failover the two IPs in our config. Both hosts are set to non-localbind and opensips is explicitly listening on both of the VIPs. This is why I'm confused. It seems that everything is configured correctly yet I'm getting these errors on the inactive opensips instance. On Thursday, May 7, 2015 1:05 PM, Bogdan-Andrei Iancu bog...@opensips.org wrote: Hi Kneeoh, The dialog replication is done assuming that both opensips servers do share the listening interface (via vrrp, heartbeat, etc). Do you different listening IPs on the 2 opensips instances ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 29.04.2015 20:35, Kneeoh wrote: Hello, I've got two VIPs on two instances of opensips and am doing dialog replication. I'm getting a steady stream of failed to replicate dialog errors in my opensips log. 192.168.30.39 192.168.30.40 are the two VIPs. Both have a listen = on both opensips configs. I'm not sure if this line in the log is the problem but it looks like it: DBG:core:bin_pop_str: Popped: '' [0] I'm not sure how the receive IP could be an empty string. debug: DBG:dialog:dlg_replicated_create: Received replicated dialog! DBG:core:bin_pop_str: Popped: 'udp:192.168.30.40:5060' [22] DBG:core:grep_sock_info: checking if host==us: 13==13 [192.168.30.40] == [192.168.30.39] DBG:core:grep_sock_info: checking if port 5060 matches port 5060 DBG:core:grep_sock_info: checking if host==us: 13==13 [192.168.30.40] == [192.168.30.40] DBG:core:grep_sock_info: checking if port 5060 matches port 5060 DBG:core:bin_pop_str: Popped: '' [0] ERROR:dialog:dlg_replicated_create: Dialog in DB doesn't match any listening sockets DBG:dialog:destroy_dlg: destroing dialog 0x7f09ddd9f958 DBG:dialog:destroy_dlg: dlg expired or not in list - dlg 0x7f09ddd9f958 [2225:721583693] with clid 'f4f2446c-6937-1233-f798-0024e869f1eb' and tags 'NULL' 'NULL' ERROR:dialog:receive_binary_packet: Failed to process a binary packet! ___ 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] Failed to replicate Dialog
Hello, I've got two VIPs on two instances of opensips and am doing dialog replication. I'm getting a steady stream of failed to replicate dialog errors in my opensips log. 192.168.30.39192.168.30.40are the two VIPs. Both have a listen = on both opensips configs. I'm not sure if this line in the log is the problem but it looks like it: DBG:core:bin_pop_str: Popped: '' [0] I'm not sure how the receive IP could be an empty string. debug: DBG:dialog:dlg_replicated_create: Received replicated dialog! DBG:core:bin_pop_str: Popped: 'udp:192.168.30.40:5060' [22] DBG:core:grep_sock_info: checking if host==us: 13==13 [192.168.30.40] == [192.168.30.39] DBG:core:grep_sock_info: checking if port 5060 matches port 5060 DBG:core:grep_sock_info: checking if host==us: 13==13 [192.168.30.40] == [192.168.30.40] DBG:core:grep_sock_info: checking if port 5060 matches port 5060 DBG:core:bin_pop_str: Popped: '' [0] ERROR:dialog:dlg_replicated_create: Dialog in DB doesn't match any listening sockets DBG:dialog:destroy_dlg: destroing dialog 0x7f09ddd9f958 DBG:dialog:destroy_dlg: dlg expired or not in list - dlg 0x7f09ddd9f958 [2225:721583693] with clid 'f4f2446c-6937-1233-f798-0024e869f1eb' and tags 'NULL' 'NULL' ERROR:dialog:receive_binary_packet: Failed to process a binary packet! ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Opensips 1.11.3 crash (Federico Edorna)
Ok I wasn't able to get a core file generated...looking in to that now. However, at debug 6 here is what I get in my log file when I run opensipsctl fifo get_statistics all | grep udp. The first time it works, the second time I get this and a crash: Apr 7 14:42:45 osipslb03 /usr/local/sbin/opensips[17299]: DBG:tm:insert_timer_unsafe: [6]: 0x7fee1b3f6ac8 (9900) Apr 7 14:42:45 osipslb03 /usr/local/sbin/opensips[17299]: DBG:tm:retransmission_handler: retransmission_handler : done Apr 7 14:42:45 osipslb03 /usr/local/sbin/opensips[17299]: DBG:tm:utimer_routine: timer routine:5,tl=0x7fee1a9fdb38 next=0x7fee1a9f9d18, timeout=9700 Apr 7 14:42:49 osipslb03 /usr/local/sbin/opensips[17277]: DBG:mi_fifo:mi_parse_tree: adding node ; val all Apr 7 14:42:49 osipslb03 /usr/local/sbin/opensips[17277]: DBG:mi_fifo:mi_parse_node: end of input tree Apr 7 14:42:49 osipslb03 /usr/local/sbin/opensips[17277]: DBG:mi_fifo:mi_fifo_server: done parsing the mi tree Apr 7 14:42:49 osipslb03 /usr/local/sbin/opensips[17311]: CRITICAL:core:receive_fd: EOF on 16 Apr 7 14:42:49 osipslb03 /usr/local/sbin/opensips[17311]: DBG:core:handle_ser_child: dead child 10, pid 17286 (shutting down?) Apr 7 14:42:49 osipslb03 /usr/local/sbin/opensips[17311]: DBG:core:io_watch_del: io_watch_del op on index -1 16 (0x812d00, 16, -1, 0x0,0x1) fd_no=44 called Apr 7 14:42:49 osipslb03 /usr/local/sbin/opensips[17275]: DBG:core:handle_sigs: status = 139 Apr 7 14:42:49 osipslb03 /usr/local/sbin/opensips[17275]: INFO:core:handle_sigs: child process 17286 exited by a signal 11 Apr 7 14:42:49 osipslb03 /usr/local/sbin/opensips[17275]: INFO:core:handle_sigs: core was generated Apr 7 14:42:49 osipslb03 /usr/local/sbin/opensips[17275]: INFO:core:handle_sigs: terminating due to SIGCHLD Apr 7 14:42:49 osipslb03 /usr/local/sbin/opensips[17310]: INFO:core:sig_usr: signal 15 received Apr 7 14:42:49 osipslb03 /usr/local/sbin/opensips[17309]: INFO:core:sig_usr: signal 15 received Apr 7 14:42:49 osipslb03 /usr/local/sbin/opensips[17308]: INFO:core:sig_usr: signal 15 received Apr 7 14:42:49 osipslb03 /usr/local/sbin/opensips[17307]: INFO:core:sig_usr: signal 15 received Apr 7 14:42:49 osipslb03 /usr/local/sbin/opensips[17306]: INFO:core:sig_usr: signal 15 received Apr 7 14:42:49 osipslb03 /usr/local/sbin/opensips[17305]: INFO:core:sig_usr: signal 15 received Apr 7 14:42:49 osipslb03 /usr/local/sbin/opensips[17304]: INFO:core:sig_usr: signal 15 received Apr 7 14:42:49 osipslb03 /usr/local/sbin/opensips[17303]: INFO:core:sig_usr: signal 15 received Apr 7 14:42:49 osipslb03 /usr/local/sbin/opensips[17302]: INFO:core:sig_usr: signal 15 received Apr 7 14:42:49 osipslb03 /usr/local/sbin/opensips[17301]: INFO:core:sig_usr: signal 15 received Apr 7 14:42:49 osipslb03 /usr/local/sbin/opensips[17300]: INFO:core:sig_usr: signal 15 received Apr 7 14:42:49 osipslb03 /usr/local/sbin/opensips[17277]: INFO:core:sig_usr: signal 15 received Apr 7 14:42:49 osipslb03 /usr/local/sbin/opensips[17298]: INFO:core:sig_usr: signal 15 received Apr 7 14:42:49 osipslb03 /usr/local/sbin/opensips[17311]: INFO:core:sig_usr: signal 15 received On Tuesday, April 7, 2015 10:09 AM, Kneeoh kne...@yahoo.com wrote: Federico, we are seeing similar crashes with both 1.11.3 and 1.11.4 when the system is under load and we perform back to back fifo get_statistics all commands (about 10 seconds apart). Opensips will segfault. I'm going to try to get some back traces, but for immediate time being, I'm going to go back to a 1.10 branch and see if it happens there too. My suspicion is that something is broken in the mi in 1.11. In order to prove it we'll have to setup a lab and run sipp against it, i can't afford to play with production. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Opensips 1.11.3 crash (Federico Edorna)
Federico, we are seeing similar crashes with both 1.11.3 and 1.11.4 when the system is under load and we perform back to back fifo get_statistics all commands (about 10 seconds apart). Opensips will segfault. I'm going to try to get some back traces, but for immediate time being, I'm going to go back to a 1.10 branch and see if it happens there too. My suspicion is that something is broken in the mi in 1.11. In order to prove it we'll have to setup a lab and run sipp against it, i can't afford to play with production. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Opensips 1.11.3 crash (Federico Edorna)
I've got a back trace on this issue. Who can I send it to? On Tuesday, April 7, 2015 10:46 AM, Kneeoh kne...@yahoo.com wrote: Ok I wasn't able to get a core file generated...looking in to that now. However, at debug 6 here is what I get in my log file when I run opensipsctl fifo get_statistics all | grep udp. The first time it works, the second time I get this and a crash: Apr 7 14:42:45 osipslb03 /usr/local/sbin/opensips[17299]: DBG:tm:insert_timer_unsafe: [6]: 0x7fee1b3f6ac8 (9900) Apr 7 14:42:45 osipslb03 /usr/local/sbin/opensips[17299]: DBG:tm:retransmission_handler: retransmission_handler : done Apr 7 14:42:45 osipslb03 /usr/local/sbin/opensips[17299]: DBG:tm:utimer_routine: timer routine:5,tl=0x7fee1a9fdb38 next=0x7fee1a9f9d18, timeout=9700 Apr 7 14:42:49 osipslb03 /usr/local/sbin/opensips[17277]: DBG:mi_fifo:mi_parse_tree: adding node ; val all Apr 7 14:42:49 osipslb03 /usr/local/sbin/opensips[17277]: DBG:mi_fifo:mi_parse_node: end of input tree Apr 7 14:42:49 osipslb03 /usr/local/sbin/opensips[17277]: DBG:mi_fifo:mi_fifo_server: done parsing the mi tree Apr 7 14:42:49 osipslb03 /usr/local/sbin/opensips[17311]: CRITICAL:core:receive_fd: EOF on 16 Apr 7 14:42:49 osipslb03 /usr/local/sbin/opensips[17311]: DBG:core:handle_ser_child: dead child 10, pid 17286 (shutting down?) Apr 7 14:42:49 osipslb03 /usr/local/sbin/opensips[17311]: DBG:core:io_watch_del: io_watch_del op on index -1 16 (0x812d00, 16, -1, 0x0,0x1) fd_no=44 called Apr 7 14:42:49 osipslb03 /usr/local/sbin/opensips[17275]: DBG:core:handle_sigs: status = 139 Apr 7 14:42:49 osipslb03 /usr/local/sbin/opensips[17275]: INFO:core:handle_sigs: child process 17286 exited by a signal 11 Apr 7 14:42:49 osipslb03 /usr/local/sbin/opensips[17275]: INFO:core:handle_sigs: core was generated Apr 7 14:42:49 osipslb03 /usr/local/sbin/opensips[17275]: INFO:core:handle_sigs: terminating due to SIGCHLD Apr 7 14:42:49 osipslb03 /usr/local/sbin/opensips[17310]: INFO:core:sig_usr: signal 15 received Apr 7 14:42:49 osipslb03 /usr/local/sbin/opensips[17309]: INFO:core:sig_usr: signal 15 received Apr 7 14:42:49 osipslb03 /usr/local/sbin/opensips[17308]: INFO:core:sig_usr: signal 15 received Apr 7 14:42:49 osipslb03 /usr/local/sbin/opensips[17307]: INFO:core:sig_usr: signal 15 received Apr 7 14:42:49 osipslb03 /usr/local/sbin/opensips[17306]: INFO:core:sig_usr: signal 15 received Apr 7 14:42:49 osipslb03 /usr/local/sbin/opensips[17305]: INFO:core:sig_usr: signal 15 received Apr 7 14:42:49 osipslb03 /usr/local/sbin/opensips[17304]: INFO:core:sig_usr: signal 15 received Apr 7 14:42:49 osipslb03 /usr/local/sbin/opensips[17303]: INFO:core:sig_usr: signal 15 received Apr 7 14:42:49 osipslb03 /usr/local/sbin/opensips[17302]: INFO:core:sig_usr: signal 15 received Apr 7 14:42:49 osipslb03 /usr/local/sbin/opensips[17301]: INFO:core:sig_usr: signal 15 received Apr 7 14:42:49 osipslb03 /usr/local/sbin/opensips[17300]: INFO:core:sig_usr: signal 15 received Apr 7 14:42:49 osipslb03 /usr/local/sbin/opensips[17277]: INFO:core:sig_usr: signal 15 received Apr 7 14:42:49 osipslb03 /usr/local/sbin/opensips[17298]: INFO:core:sig_usr: signal 15 received Apr 7 14:42:49 osipslb03 /usr/local/sbin/opensips[17311]: INFO:core:sig_usr: signal 15 received On Tuesday, April 7, 2015 10:09 AM, Kneeoh kne...@yahoo.com wrote: Federico, we are seeing similar crashes with both 1.11.3 and 1.11.4 when the system is under load and we perform back to back fifo get_statistics all commands (about 10 seconds apart). Opensips will segfault. I'm going to try to get some back traces, but for immediate time being, I'm going to go back to a 1.10 branch and see if it happens there too. My suspicion is that something is broken in the mi in 1.11. In order to prove it we'll have to setup a lab and run sipp against it, i can't afford to play with production. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Users Digest, Vol 81, Issue 7
Hi Liviu. Thanks for replying. Can you give me a bit more detail on what I should be looking for? I've put the listen and bin_listen ips and ports above along with the netstat for opensips. Is there something else I should be checking? Thanks. On Monday, April 6, 2015 11:09 AM, users-requ...@lists.opensips.org users-requ...@lists.opensips.org wrote: Send Users mailing list submissions to users@lists.opensips.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.opensips.org/cgi-bin/mailman/listinfo/users or, via email, send a message with subject or body 'help' to users-requ...@lists.opensips.org You can reach the person managing the list at users-ow...@lists.opensips.org When replying, please edit your Subject line so it is more specific than Re: Contents of Users digest... Today's Topics: 1. Failed to Replicate Dialog - Dialog in DB doesn't match any listening sockets (Kneeoh) 2. Re: Failed to Replicate Dialog - Dialog in DB doesn't match any listening sockets (Liviu Chircu) -- Message: 1 Date: Mon, 6 Apr 2015 14:38:23 + (UTC) From: Kneeoh kne...@yahoo.com Subject: [OpenSIPS-Users] Failed to Replicate Dialog - Dialog in DB doesn't match any listening sockets To: Opensips Users users@lists.opensips.org Message-ID: 1744687130.168674.1428331103689.javamail.ya...@mail.yahoo.com Content-Type: text/plain; charset=utf-8 Hello, I'm getting a stream of errors in my log when using binary replication. The error at log level 0 is Dialog in DB doesn't match any listening sockets. However, opensips is infact listening on the socket. I've got non-local-bind set to 1 and opensips is listening on the shared IP. If I tail the log in real time on the standby host, I'm just getting a flood of these socket errors. # opensipsctl fifo version Server:: OpenSIPS (1.11.3-notls (x86_64/linux)) Apr? 6 13:58:32 osips-lb-02 /usr/local/sbin/opensips[18106]: DBG:dialog:build_new_dlg: new dialog 0x7f5d4706f5f0 (c=f066826adc6711e49fb3842b2b73de7a@192.168.0.174,f=sip:192.168.0.174:5062,t=sip:17272428528@192.168.80.2;user=phone,ft=Jxe3T+HAqACuE8bhwKgArhPEe+Ap9QAq) on hash 968 Apr? 6 13:58:32 osips-lb-02 /usr/local/sbin/opensips[18106]: DBG:dialog:dlg_replicated_create: Received replicated dialog! Apr? 6 13:58:32 osips-lb-02 /usr/local/sbin/opensips[18106]: DBG:core:bin_pop_str: Popped: 'udp:192.168.80.2:5060' [22] Apr? 6 13:58:32 osips-lb-02 /usr/local/sbin/opensips[18106]: DBG:core:grep_sock_info: checking if host==us: 13==13 ? [192.168.80.2] == [192.168.80.2] Apr? 6 13:58:32 osips-lb-02 /usr/local/sbin/opensips[18106]: DBG:core:grep_sock_info: checking if port 5060 matches port 5060 Apr? 6 13:58:32 osips-lb-02 /usr/local/sbin/opensips[18106]: DBG:core:bin_pop_str: Popped: '' [0] Apr? 6 13:58:32 osips-lb-02 /usr/local/sbin/opensips[18106]: ERROR:dialog:dlg_replicated_create: Dialog in DB doesn't match any listening sockets # netstat -nlp | grep opensips udp??? 0? 0 192.168.80.2:5060? 0.0.0.0:*?? 18101/opensips? udp??? 0? 0 10.1.0.42:5092??? ?? 0.0.0.0:*?? 18101/opensips?? osips-lb-02 config: # Binary Interface Settings bin_listen=10.1.0.42:5092 bin_children=4 listen=udp:192.168.80.2:5060 modparam(dialog, accept_replicated_dialogs, 1) modparam(dialog, replicate_dialogs_to, 10.1.0.41:5092) osips-lb-01 config: # Binary Interface Settings bin_listen=10.1.0.41:5092 listen=udp:192.168.80.2:5060 modparam(dialog, accept_replicated_dialogs, 1) modparam(dialog, replicate_dialogs_to, 10.1.0.42:5092) # netstat -nlp | grep opensips udp??? 0? 0 192.168.80.2:5060? 0.0.0.0:*?? 31940/opensips? udp??? 0? 0 10.1.0.41:5092 ? ? ? ? 0.0.0.0:*?? 31940/opensips? -- next part -- An HTML attachment was scrubbed... URL: http://lists.opensips.org/pipermail/users/attachments/20150406/18759ee2/attachment-0001.htm -- Message: 2 Date: Mon, 06 Apr 2015 18:09:31 +0300 From: Liviu Chircu li...@opensips.org Subject: Re: [OpenSIPS-Users] Failed to Replicate Dialog - Dialog in DB doesn't match any listening sockets To: users@lists.opensips.org Message-ID: 5522a1ab.10...@opensips.org Content-Type: text/plain; charset=windows-1252; Format=flowed Hi Kneeoh! Your setup looks flawless. By any change, are you advertising different ports on the two 192.168.80.2 listeners? It's the only thing that pops up right now. Best regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 06.04.2015 17:38, Kneeoh wrote: Hello, I'm getting a stream of errors in my log when using binary replication. The error at log level 0 is Dialog in DB doesn't match any listening sockets. However, opensips is infact listening on the socket. I've got non-local-bind set to 1
[OpenSIPS-Users] Failed to Replicate Dialog - Dialog in DB doesn't match any listening sockets
Hello, I'm getting a stream of errors in my log when using binary replication. The error at log level 0 is Dialog in DB doesn't match any listening sockets. However, opensips is infact listening on the socket. I've got non-local-bind set to 1 and opensips is listening on the shared IP. If I tail the log in real time on the standby host, I'm just getting a flood of these socket errors. # opensipsctl fifo version Server:: OpenSIPS (1.11.3-notls (x86_64/linux)) Apr 6 13:58:32 osips-lb-02 /usr/local/sbin/opensips[18106]: DBG:dialog:build_new_dlg: new dialog 0x7f5d4706f5f0 (c=f066826adc6711e49fb3842b2b73de7a@192.168.0.174,f=sip:192.168.0.174:5062,t=sip:17272428528@192.168.80.2;user=phone,ft=Jxe3T+HAqACuE8bhwKgArhPEe+Ap9QAq) on hash 968 Apr 6 13:58:32 osips-lb-02 /usr/local/sbin/opensips[18106]: DBG:dialog:dlg_replicated_create: Received replicated dialog! Apr 6 13:58:32 osips-lb-02 /usr/local/sbin/opensips[18106]: DBG:core:bin_pop_str: Popped: 'udp:192.168.80.2:5060' [22] Apr 6 13:58:32 osips-lb-02 /usr/local/sbin/opensips[18106]: DBG:core:grep_sock_info: checking if host==us: 13==13 [192.168.80.2] == [192.168.80.2] Apr 6 13:58:32 osips-lb-02 /usr/local/sbin/opensips[18106]: DBG:core:grep_sock_info: checking if port 5060 matches port 5060 Apr 6 13:58:32 osips-lb-02 /usr/local/sbin/opensips[18106]: DBG:core:bin_pop_str: Popped: '' [0] Apr 6 13:58:32 osips-lb-02 /usr/local/sbin/opensips[18106]: ERROR:dialog:dlg_replicated_create: Dialog in DB doesn't match any listening sockets # netstat -nlp | grep opensips udp 0 0 192.168.80.2:5060 0.0.0.0:* 18101/opensips udp 0 0 10.1.0.42:5092 0.0.0.0:* 18101/opensips osips-lb-02 config: # Binary Interface Settings bin_listen=10.1.0.42:5092 bin_children=4 listen=udp:192.168.80.2:5060 modparam(dialog, accept_replicated_dialogs, 1) modparam(dialog, replicate_dialogs_to, 10.1.0.41:5092) osips-lb-01 config: # Binary Interface Settings bin_listen=10.1.0.41:5092 listen=udp:192.168.80.2:5060 modparam(dialog, accept_replicated_dialogs, 1) modparam(dialog, replicate_dialogs_to, 10.1.0.42:5092) # netstat -nlp | grep opensips udp 0 0 192.168.80.2:5060 0.0.0.0:* 31940/opensips udp 0 0 10.1.0.41:5092 0.0.0.0:* 31940/opensips ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] 1.11.3 Crash on Fifo query
I just spun up a light system for testing some new things. I've been getting system crashes while running get_statistics. I've included all of the data I have. I was hoping someone could point me towards a solution to fix. Thank you. Environment: Cores: 2 x Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz Memory: 8 Gb Opensips 1.11.3 Children = 4 S_MEMORY=1024 P_MEMORY=64 Command: opensipsctl fifo get_statistics all | grep udp Debug 6 Output during crash: Mar 16 16:47:23 opensips /usr/local/sbin/opensips[17059]: DBG:tm:timer_routine: timer routine:0,tl=0x7f4fda24cf58 next=0x7f4fda575850, timeout=88 Mar 16 16:47:23 opensips /usr/local/sbin/opensips[17059]: DBG:tm:timer_routine: timer routine:0,tl=0x7f4fda575850 next=0x7f4fda5719f8, timeout=88 Mar 16 16:47:23 opensips /usr/local/sbin/opensips[17059]: DBG:tm:timer_routine: timer routine:0,tl=0x7f4fda5719f8 next=0x7f4fda56d798, timeout=88 Mar 16 16:47:23 opensips /usr/local/sbin/opensips[17049]: DBG:mi_fifo:mi_parse_tree: adding node ; val all Mar 16 16:47:23 opensips /usr/local/sbin/opensips[17049]: DBG:mi_fifo:mi_parse_node: end of input tree Mar 16 16:47:23 opensips /usr/local/sbin/opensips[17049]: DBG:mi_fifo:mi_fifo_server: done parsing the mi tree Mar 16 16:47:24 opensips /usr/local/sbin/opensips[17049]: DBG:mi_fifo:mi_parse_tree: adding node ; val all Mar 16 16:47:24 opensips /usr/local/sbin/opensips[17049]: DBG:mi_fifo:mi_parse_node: end of input tree Mar 16 16:47:24 opensips /usr/local/sbin/opensips[17049]: DBG:mi_fifo:mi_fifo_server: done parsing the mi tree Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17049]: DBG:mi_fifo:mi_parse_tree: adding node ; val all Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17049]: DBG:mi_fifo:mi_parse_node: end of input tree Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17049]: DBG:mi_fifo:mi_fifo_server: done parsing the mi tree Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17048]: DBG:core:handle_sigs: status = 139 Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17048]: INFO:core:handle_sigs: child process 17057 exited by a signal 11 Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17048]: INFO:core:handle_sigs: core was generated Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17048]: INFO:core:handle_sigs: terminating due to SIGCHLD Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17051]: INFO:core:sig_usr: signal 15 received Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17050]: INFO:core:sig_usr: signal 15 received Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17053]: INFO:core:sig_usr: signal 15 received Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17052]: INFO:core:sig_usr: signal 15 received Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17049]: INFO:core:sig_usr: signal 15 received Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17058]: INFO:core:sig_usr: signal 15 received Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17048]: INFO:core:cleanup: cleanup Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17048]: NOTICE:cachedb_couchbase:destroy: destroy module cachedb_couchbase ... Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17048]: DBG:tm:tm_shutdown: tm_shutdown : start Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17048]: DBG:tm:unlink_timer_lists: emptying DELETE list for set 0 Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17048]: DBG:tm:tm_shutdown: emptying hash table Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17048]: DBG:tm:tm_shutdown: releasing timers Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17048]: DBG:tm:tm_shutdown: removing semaphores Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17048]: DBG:tm:tm_shutdown: destroying callback lists Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17048]: DBG:tm:tm_shutdown: tm_shutdown : done Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17048]: DBG:core:shm_mem_destroy: destroying the shared memory lock Mar 16 16:47:25 opensips /usr/local/sbin/opensips[17048]: DBG:core:handle_sigs: terminating due to SIGCHLD ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] acc_evi_request firing to incorrect event interface
Per the acc module: acc_evi_request(comment) Like acc_log_request, acc_evi_request reports on a request. The report is packed as an event sent through the OpenSIPS Event Interface as E_ACC_EVENT if the reply code is a positive one (lower than 300), or E_ACC_MISSED_EVENT for negative or no codes. I'm firing an event: acc_evi_request(703 Admin Block); But its being published to the E_ACC_EVENT queue instead of the E_ACC_MISSED_EVENT queue 703 300 so it should be treated as a negative reply. I'm running 1.11.3 ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] $DLG_timeout Not Setting or Printing
Hi. I’m running 1.11.1 and am xloging $DLG_Timeout. it always prints 0 even though I have modparam(dialog, default_timeout, 28800) set Additionally. I try to set $DLG_timeout with $DLG_timeout = $avp(new_timeout) and then xlog and again it’s 0 in the log Am I doing something wrong or is this a bug in my version? ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Binary Dialog Replication + DRouting Polling Feature Request
Hello, after fighting all day trying to maintain drouting polling and binary replication of dialogs between two servers, I had to sacrifice drouting polling to accommodate dialog replication. Scenario 2 Opensips Servers as Load Balancers Corosync/Pacemaker with VIP Drouting as LB engine mhomed=1 OSIPS 1 IP: 10.2.0.11 OSIPS 2 IP: 10.2.0.12 VIP: 10.2.0.10 Issue 1: Drouting polling. In order to check the status of down stream opensips servers drouting is configured to send options pings to each server. On failure it auto disables the server. In order to do this with a VIP config, each host must use it's local IP to poll the servers otherwise the standby server won't have a socket with which to ping from as the active server will own the VIP. Issue 2: Opensips must be running to accept dialog updates from the binary interface, so you can't simply allow Opensips to start/stop with the IP failover or it won't get any dialog updates. Issue 3: When running in mhomed=1 mode, you are letting the kernel decide which IP to use to communicate out. IE, you may get a packet on the VIP: 10.2.0.10 but the Kernel uses 10.2.0.11 to send the packet. This is the IP that the dialog is nailed up on. So if you failover the VIP, the backup server will try to process the incoming packets per the dialg out of the 10.2.0.11 interface which doesn't exist on server 2 and it fails. The only thing I could do was to have both servers listen on the VIP with non-local bind enabled in linux. Then turn off drouting polling so that the standby server wouldn't disable the downstream servers in Drouting. This also ensures that the dialogs are nailed up to the 10.2.0.10 IP and when I failover the IP, the backup server can process the packets. I'd like to put in a request to have the drouting (and other similar modules) have a configurable polling interface which is separate from the socket it uses to send traffic. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Fw: CRITICAL:core:timer_ticker:
Any help would be appreciated. Thank you. On Thursday, November 6, 2014 12:25 PM, Kneeoh kne...@yahoo.com wrote: Hi all, I just stood up a new set of proxies on version: Server:: OpenSIPS (1.11.3-notls (x86_64/linux)) and I'm running the following dialog settings: modparam(dialog,db_mode,2) # Write to DB every 2 minutes modparam(dialog, db_update_period, 120) However, I'm seeing the following in my opensips.log. Does this mean 2 minutes is to aggressive for updating the DB? Or is it indicative of a different problem? Any suggestions or ideas would be awesome. Nov 6 17:13:55 opensips /usr/local/sbin/opensips[21907]: CRITICAL:core:timer_ticker: timer handler dlg-dbupdate lasted (268 us) for more than timer tick (100 us) - potential timer shifting Nov 6 17:15:56 opensips /usr/local/sbin/opensips[21907]: CRITICAL:core:timer_ticker: timer handler dlg-dbupdate lasted (272 us) for more than timer tick (100 us) - potential timer shifting Nov 6 17:17:57 opensips /usr/local/sbin/opensips[21907]: CRITICAL:core:timer_ticker: timer handler dlg-dbupdate lasted (267 us) for more than timer tick (100 us) - potential timer shifting Thanks! ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] CRITICAL:core:timer_ticker:
Hi all, I just stood up a new set of proxies on version: Server:: OpenSIPS (1.11.3-notls (x86_64/linux)) and I'm running the following dialog settings: modparam(dialog,db_mode,2) # Write to DB every 2 minutes modparam(dialog, db_update_period, 120) However, I'm seeing the following in my opensips.log. Does this mean 2 minutes is to aggressive for updating the DB? Or is it indicative of a different problem? Any suggestions or ideas would be awesome. Nov 6 17:13:55 opensips /usr/local/sbin/opensips[21907]: CRITICAL:core:timer_ticker: timer handler dlg-dbupdate lasted (268 us) for more than timer tick (100 us) - potential timer shifting Nov 6 17:15:56 opensips /usr/local/sbin/opensips[21907]: CRITICAL:core:timer_ticker: timer handler dlg-dbupdate lasted (272 us) for more than timer tick (100 us) - potential timer shifting Nov 6 17:17:57 opensips /usr/local/sbin/opensips[21907]: CRITICAL:core:timer_ticker: timer handler dlg-dbupdate lasted (267 us) for more than timer tick (100 us) - potential timer shifting Thanks! ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] RabbitMQ Timer Route Not Working
This did not work either. I've removed the haproxy setup and simply put a
floating vip between the rabbitmq servers. However if I fail the vip to another
rabbit server the connection is dropped. I've tried placing an
unsubscribe/resubscribe in a timer route and have activated the keep alive
modparam, but that is not working. It would be great if there were some sort of
multi entrance or auto-resubscribe function. As it stands right now after
testing with haproxy and with a vip the only thing that works is to restart
opensips if a rabbit node goes down.
loadmodule event_rabbitmq.so
modparam(event_rabbitmq, heartbeat, 3)
startup_route{
if (!subscribe_event(E_KEEPALIVE,
rabbitmq:user:rabbit@192.168.2.70/keepalive)) {
xlog(L_INFO, Can't connect to RabbitMQ E_KEEPALIVE\n);
}
}
timer_route[event_keepalive, 5] {
subscribe_event(E_KEEPALIVE,
rabbitmq:user:rabbit@192.168.2.70/keepalive,0); # I was told this would
unsubscribe
# This does not work
if (!subscribe_event(E_KEEPALIVE,
rabbitmq:user:rabbit@192.168.2.70/keepalive)) {
xlog(L_INFO, Can't connect to RabbitMQ E_KEEPALIVE\n);
}
$json(rabbit_keepalive) := {};
$json(rabbit_keepalive/time) = $time(%Y-%m-%d %T %Z);
$json(rabbit_keepalive/type) = KEEPALIVE;
$avp(rabbit_keepalive) := $json(rabbit_keepalive);
if (!raise_event(E_KEEPALIVE, $avp(rabbit_keepalive))) {
xlog(L_INFO, Can't raise E_KEEPALIVE event\n);
}
}
On Wednesday, June 11, 2014 1:08 PM, Kneeoh kne...@yahoo.com wrote:
Is there an unsubscribe option? I'm going to try removing haproxy and just let
the vip be shared among the rabbit cluster nodes and see if that tricks it.
On Tuesday, June 10, 2014 9:01 AM, Răzvan Crainea raz...@opensips.org wrote:
Hi, Kneeoh!
I think that the only solution that would work properly was your first
approach. However, since this is not yet implemented, all I can think of
is an external process that periodically test if the node is up. If it
is not, unsubscribe it and re-subscribe the second node.
PS: I haven't really used haproxy so I have no idea how it works.
Best regards,
Razvan Crainea
OpenSIPS Core Developer
http://www.opensips-solutions.com
On 06/06/2014 06:15 PM, Kneeoh wrote:
Hi Razvan, thank you for the reply. I don't necessarily need expiration of
subscriptions to rabbit or the timer route per se. I'm just trying to figure
out (with the existing capabilities) how to make opensips fail to another
member in the rabbit cluster in the event that the current node dies. My
first thought was that you could simply stack entry points like:
subscribe_event(E_ACC_CDR,
rabbitmq:rabbitmq:rabbit@192.168.2.30;rabbitmq:rabbit@192.168.2.31;rabbitmq:rabbit@192.168.2.33/cdr1)
However, it sounds like that's not in the present implementation of the
rabbit module.
So my second thought was to trick opensips and put HAProxy between it and
Rabbit, which works, but if I fail an HAProxy via corosync to the other
HAproxy something with the subscription breaks. Since it looked like the two
options were either put the subscribes in the startup route (only happens
once so probably won't failover) OR use the timer route to subscribe (which
is what i'm doing) I figured that in the event of an HAProxy failure, I might
miss a few messages but on the next timer fire opensips would resubscribe to
haproxy which would relay that to the appropriate rabbit server (I haven't
failed over any rabbit servers in this scenario so haproxy2 is talking to the
same rabbit server as haproxy1. All i'm doing is killing haproxy1 right now
and letting the VIP go to haproxy2). However it doesn't look like this is
working and I can't tell if its because the subscription isn't happening, OR
it is happening but opensips sees it already exists in the
subscribers list and does nothing (I think this is the case). If this IS
the case perhaps a solution would be to kill the subscriber entry on new
subscribe. If I'm way off, let me know, I'd really like to figure this out. Am
I going about this all wrong? How would you handle a rabbit node failure?
Regards
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] DRouting Feature Request
| ++-++-+--+-++---+-+ | 1 | 1 | | | 0 | NULL | #cr1,three | NULL | | ++-++-+--+-++---+-+ 1 row in set (0.00 sec) And it works, I get in log (for an xlog(GW IDs are : $(avp(dr_gw)[*]) \n); after do_routing(1) ) : GW IDs are : two, three or GW IDs are : one, three Keep in mind is a probabilistic dispersion (not a rigorous round robin), so running 2-3 times may not be relevant. Do a larger set of tests (like 10 or so). Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 23.07.2014 18:37, Kneeoh wrote: I thought that would work too. But if I put (dr_carriers table) gwlist:gw1=50,gw2=50 flags:3 it Always picks gw1. I want it to alternate between gw1 and gw2 Ultimately I'm trying to do something like: dr_rules: gwlist: #cr1=50,#cr2=50 lets say it picks cr1, then go to the dr_carriers table where it will pick ONE of the carrier gateways based on weight, if that gateway fails or times out use the next carrier cr2, not the next gateway for cr1 On Wednesday, July 23, 2014 10:07 AM, Bogdan-Andrei Iancu bog...@opensips.org wrote: Hi, Actually you can combine the flags and use 0x03 - ordering by weights and use only first. Just give it a try. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 23.07.2014 03:29, Kneeoh wrote: It would be great if you could combine the binary Flags for dr_carrier routing: flags : 0x1 - use weight for sorting the list and not definition order; 0x2 - use only the first gateway from the carrier (depending on the sorting); 0x4 - disable the usage of this carrier such that where 1+2 = 3 the gateways are first sorted by weight then returns only the top result for each carrier. This would allow for equitable distribution between carrier gateways. This way gw1=100,gw2=100 would have a roughly equal chance of being picked (if enabled=true). At present it either cycles through all carrier gateways OR when the binary flag is set to 2, it picks the first gateway ONLY, ALL THE TIME. ___ 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] DRouting Feature Request
Thats b/c the gateways are carrier facing proxies on my network. I pass headers
to them to tell them where to route. Its a pain in the rear to get them to
authorize new IPs so I do it this way. Not so nonsensical. I don't know why
you're getting a different result than me with respect to use_next_gw. I've
shared the tables and config bits, it doesn't sound like you see any issue with
that other than my rather unorthodox gateway setup, no? I'll add the xlogs you
suggest and report back.
On Thursday, July 24, 2014 1:32 PM, Bogdan-Andrei Iancu bog...@opensips.org
wrote:
Hi,
Tested with latest 1.11 and works (with the setup explained below):
$ ./opensips -V
version: opensips 1.11.2-notls (x86_64/linux)
flags: STATS: On, USE_IPV6, USE_TCP, DISABLE_NAGLE, USE_MCAST, SHM_MEM,
SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
git revision: 78a8c5f
main.c compiled on 11:05:33 Jul 24 2014 with gcc 4.8
Works both in terms of randomly selecting the first GW and as using only
one GW (second GW from #cr1 is not used in use_next_gw).
Funny as for all three carriers you use the same set of GW. And for the
rule you have listed all three carriers...Is is a bit of a non-sense as
all three carriers will be used , but only one random GW from each -
you will get a set of 3 GWs in any combination between GW1 and GW2 :D.
Try to add in your script, just after the do_routing():
xlog(GW IDs are : $(avp(dr_gw)[*]) \n);
Also put:
modparam(drouting,gw_id_avp, $avp(dr_gw))
And paste the out of that xlog.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 24.07.2014 17:27, Kneeoh wrote:
I ran 15 - 20 tests and was always getting gw 1 with the same settings. After
digging I found I some how got back on to 1.11.2 not sure if that's relevant.
But I've rolled back to 1.11.1 with the same config and DB settings. Now
almost every other test alternates the gateway which is good. However, it
still rolls to the next carrier gateway on: use_next_gw instead of going to
the next carrier which means that the drouting module is still returning both
gateways per carrier even though I have the flags set to 3 which should sort
on weight and return 1 if I'm not mistaken.
My tables:
select * from dr_rules;
++-++-+--+-+---+---+---+
| ruleid | groupid | prefix | timerec | priority | routeid | gwlist
| attrs | description |
++-++-+--+-+---+---+---+
| 3 | 500 | 1800 | | 100 | NULL | #1=50,#2=50,#3 |
| Toll Free |
select * from dr_carriers;
++---+---+---+---+---+-+
| id | carrierid | gwlist | flags | state | attrs | description |
++---+---+---+---+---+-+
| 3 | 1 | 1=50,2=50 | 3 | 0 | 1 | Carrier 1 Toll Free |
| 6 | 2 | 1=50,2=50 | 3 | 0 | 2 | Carrier 2 Toll Free |
| 9 | 3 | 1=50,2=50 | 3 | 0 | 3 | Carrier 3 Toll Free |
++---+---+---+---+---+-+
select * from dr_gateways;
++--+--++---++---++---++-+
| id | gwid | type | address | strip | pri_prefix | attrs | probe_mode
| state | socket | description |
++--+--++---++---++---++-+
| 3 | 1 | 2 | 192.168.2.2 | 0 | NULL | NULL | 0 |
1 | NULL | gw_01 |
| 6 | 2 | 2 | 192.168.2.3 | 0 | NULL | NULL | 0 |
1 | NULL | gw_02 |
++--+--++---++---++---++-+
My script:
route[sendcall] {
if (is_method(INVITE)) {
t_on_branch(per_branch_ops);
t_on_reply(handle_nat);
t_on_failure(toll free)
xlog(L_INFO, In Toll Free Routing Block \n);
};
do_routing($avp(tf_group),W$avp(carrier_id))
..etc
}
failure_route[tf] {
if (use_next_gw(,,$avp(carrier_id))) {
xlog(L_INFO, Next Gateway $ru - CarrierID: $avp(carrier_id)\n);
t_on_branch(per_branch_ops);
t_on_reply(handle_nat);
t_on_failure(toll free)
t_relay();
exit;
}
else {
xlog(L_INFO, No more Carriers!\n);
t_reply(503, Service Unavailable);
exit;
};
}
My Results:
Using: CarrierID: 2
new branch at sip:18005551212@192.168.2.2
In failure route toll free
Next Gateway sip:18005551212@192.168.2.3 - CarrierID: 2
new branch at sip:18005551212@192.168.2.3
Re: [OpenSIPS-Users] DRouting Feature Request
I thought that would work too. But if I put (dr_carriers table) gwlist:gw1=50,gw2=50 flags:3 it Always picks gw1. I want it to alternate between gw1 and gw2 Ultimately I'm trying to do something like: dr_rules: gwlist: #cr1=50,#cr2=50 lets say it picks cr1, then go to the dr_carriers table where it will pick ONE of the carrier gateways based on weight, if that gateway fails or times out use the next carrier cr2, not the next gateway for cr1 On Wednesday, July 23, 2014 10:07 AM, Bogdan-Andrei Iancu bog...@opensips.org wrote: Hi, Actually you can combine the flags and use 0x03 - ordering by weights and use only first. Just give it a try. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 23.07.2014 03:29, Kneeoh wrote: It would be great if you could combine the binary Flags for dr_carrier routing: flags : 0x1 - use weight for sorting the list and not definition order; 0x2 - use only the first gateway from the carrier (depending on the sorting); 0x4 - disable the usage of this carrier such that where 1+2 = 3 the gateways are first sorted by weight then returns only the top result for each carrier. This would allow for equitable distribution between carrier gateways. This way gw1=100,gw2=100 would have a roughly equal chance of being picked (if enabled=true). At present it either cycles through all carrier gateways OR when the binary flag is set to 2, it picks the first gateway ONLY, ALL THE TIME. ___ 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] DRouting Feature Request
It would be great if you could combine the binary Flags for dr_carrier routing: flags : 0x1 - use weight for sorting the list and not definition order; 0x2 - use only the first gateway from the carrier (depending on the sorting); 0x4 - disable the usage of this carrier such that where 1+2 = 3 the gateways are first sorted by weight then returns only the top result for each carrier. This would allow for equitable distribution between carrier gateways. This way gw1=100,gw2=100 would have a roughly equal chance of being picked (if enabled=true). At present it either cycles through all carrier gateways OR when the binary flag is set to 2, it picks the first gateway ONLY, ALL THE TIME. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] 1.11.2-notls Bug: Extra columns in missed calls
I just rolled back to the 1.11.1 tag. No issues with that tag. On Friday, July 18, 2014 3:43 PM, Kneeoh kne...@yahoo.com wrote: After adding the fields to see what would happen it's putting in values like this: -430292632 Additionally, it is not recording the AVPs in my db_extra statement. On Friday, July 18, 2014 3:18 PM, Kneeoh kne...@yahoo.com wrote: It looks like this may be a bug, but on the latest 1.11 build i'm throwing acc errors b/c the acc module is trying to insert columns into missed_calls that don't exist...and haven't prior. duration and setuptime DBG:db_mysql:db_mysql_do_prepared_query: new query=|insert into missed_calls (method,from_tag,to_tag,callid,sip_code,sip_reason,time,duration,setuptime ) values ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] 1.11.2-notls Bug: Extra columns in missed calls
It looks like this may be a bug, but on the latest 1.11 build i'm throwing acc errors b/c the acc module is trying to insert columns into missed_calls that don't exist...and haven't prior. duration and setuptime DBG:db_mysql:db_mysql_do_prepared_query: new query=|insert into missed_calls (method,from_tag,to_tag,callid,sip_code,sip_reason,time,duration,setuptime ) values ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] 1.11.2-notls Bug: Extra columns in missed calls
After adding the fields to see what would happen it's putting in values like this: -430292632 Additionally, it is not recording the AVPs in my db_extra statement. On Friday, July 18, 2014 3:18 PM, Kneeoh kne...@yahoo.com wrote: It looks like this may be a bug, but on the latest 1.11 build i'm throwing acc errors b/c the acc module is trying to insert columns into missed_calls that don't exist...and haven't prior. duration and setuptime DBG:db_mysql:db_mysql_do_prepared_query: new query=|insert into missed_calls (method,from_tag,to_tag,callid,sip_code,sip_reason,time,duration,setuptime ) values ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Equivalent to Kamailio Async Module
Is there an equivalent to the async module in Kamailio? I want to hold messages on short duration calls to keep my upstreams happy. But I want to use opensips if possible. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Ratelimit Question
Any idea why a lab system with no traffic spits out these errors periodically? Jun 18 21:16:51 osips-01 /usr/local/sbin/opensips[1876]: ERROR:ratelimit:rl_timer: cannot get pipe counter Jun 18 21:17:01 osips-01 /usr/local/sbin/opensips[1876]: ERROR:ratelimit:rl_get_counter: cannot retrieve key Jun 18 21:17:01 osips-01 /usr/local/sbin/opensips[1876]: ERROR:ratelimit:rl_timer: cannot get pipe counter Jun 18 21:17:11 osips-01 /usr/local/sbin/opensips[1876]: ERROR:ratelimit:rl_get_counter: cannot retrieve key Ratelimit module loadmodule ratelimit.so modparam(ratelimit, cachedb_url, couchbase:opensips://cb01:6360;cb02:6360/opensips) modparam(ratelimit, db_prefix, termlimit_) Is it because the key is removed after a period of time and the RL module keeps polling for it on the default 10 second interval? Any way to suppress it? ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] RabbitMQ Timer Route Not Working
Is there an unsubscribe option? I'm going to try removing haproxy and just let the vip be shared among the rabbit cluster nodes and see if that tricks it. On Tuesday, June 10, 2014 9:01 AM, Răzvan Crainea raz...@opensips.org wrote: Hi, Kneeoh! I think that the only solution that would work properly was your first approach. However, since this is not yet implemented, all I can think of is an external process that periodically test if the node is up. If it is not, unsubscribe it and re-subscribe the second node. PS: I haven't really used haproxy so I have no idea how it works. Best regards, Razvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 06/06/2014 06:15 PM, Kneeoh wrote: Hi Razvan, thank you for the reply. I don't necessarily need expiration of subscriptions to rabbit or the timer route per se. I'm just trying to figure out (with the existing capabilities) how to make opensips fail to another member in the rabbit cluster in the event that the current node dies. My first thought was that you could simply stack entry points like: subscribe_event(E_ACC_CDR, rabbitmq:rabbitmq:rabbit@192.168.2.30;rabbitmq:rabbit@192.168.2.31;rabbitmq:rabbit@192.168.2.33/cdr1) However, it sounds like that's not in the present implementation of the rabbit module. So my second thought was to trick opensips and put HAProxy between it and Rabbit, which works, but if I fail an HAProxy via corosync to the other HAproxy something with the subscription breaks. Since it looked like the two options were either put the subscribes in the startup route (only happens once so probably won't failover) OR use the timer route to subscribe (which is what i'm doing) I figured that in the event of an HAProxy failure, I might miss a few messages but on the next timer fire opensips would resubscribe to haproxy which would relay that to the appropriate rabbit server (I haven't failed over any rabbit servers in this scenario so haproxy2 is talking to the same rabbit server as haproxy1. All i'm doing is killing haproxy1 right now and letting the VIP go to haproxy2). However it doesn't look like this is working and I can't tell if its because the subscription isn't happening, OR it is happening but opensips sees it already exists in the subscribers list and does nothing (I think this is the case). If this IS the case perhaps a solution would be to kill the subscriber entry on new subscribe. If I'm way off, let me know, I'd really like to figure this out. Am I going about this all wrong? How would you handle a rabbit node failure? Regards ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] RabbitMQ Timer Route Not Working
Hi Razvan, thank you for the reply. I don't necessarily need expiration of subscriptions to rabbit or the timer route per se. I'm just trying to figure out (with the existing capabilities) how to make opensips fail to another member in the rabbit cluster in the event that the current node dies. My first thought was that you could simply stack entry points like: subscribe_event(E_ACC_CDR, rabbitmq:rabbitmq:rabbit@192.168.2.30;rabbitmq:rabbit@192.168.2.31;rabbitmq:rabbit@192.168.2.33/cdr1) However, it sounds like that's not in the present implementation of the rabbit module. So my second thought was to trick opensips and put HAProxy between it and Rabbit, which works, but if I fail an HAProxy via corosync to the other HAproxy something with the subscription breaks. Since it looked like the two options were either put the subscribes in the startup route (only happens once so probably won't failover) OR use the timer route to subscribe (which is what i'm doing) I figured that in the event of an HAProxy failure, I might miss a few messages but on the next timer fire opensips would resubscribe to haproxy which would relay that to the appropriate rabbit server (I haven't failed over any rabbit servers in this scenario so haproxy2 is talking to the same rabbit server as haproxy1. All i'm doing is killing haproxy1 right now and letting the VIP go to haproxy2). However it doesn't look like this is working and I can't tell if its because the subscription isn't happening, OR it is happening but opensips sees it already exists in the subscribers list and does nothing (I think this is the case). If this IS the case perhaps a solution would be to kill the subscriber entry on new subscribe. If I'm way off, let me know, I'd really like to figure this out. Am I going about this all wrong? How would you handle a rabbit node failure? Regards ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] RabbitMQ Timer Route Not Working
]:
DBG:event_rabbitmq:rmq_match: socket matched: rabbitmq@192.168.2.30:5672/limits
FAILs to send event to RabbitMQ
On Thursday, June 5, 2014 7:57 AM, Bogdan-Andrei Iancu bog...@opensips.org
wrote:
Hi,
Try to get some debug logs from that route. Do:
timer_route[event_subscribe, 4] {
setdebug(4);
xlog(Subscribing from timer route\n);
if (!subscribe_event(E_ACC_CDR, rabbitmq:cdr:rabbit@192.168.2.30/cdr1,
5)) {
xlog(L_INFO, Can't connect to RabbitMQ \n);
}
setdebug();
}
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 02.06.2014 17:55, Kneeoh wrote:
After following the example here:
http://www.opensips.org/Documentation/Tutorials-EventInterface
Shouldn't this resubscribe every 4 seconds and expire in 5 (i.e. never)? in
my script it's not subscribing to rabbit at all. I'm running version:
Server:: OpenSIPS (1.10.1-notls (x86_64/linux))
timer_route[event_subscribe, 4] {
if (!subscribe_event(E_ACC_CDR, rabbitmq:cdr:rabbit@192.168.2.30/cdr1,
5)) {
xlog(L_INFO, Can't connect to RabbitMQ \n);
}
}
root@osips:/var/log# tcpdump -s0 -ni eth1 host 192.168.2.30
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
___
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] RabbitMQ Timer Route Not Working
That's correct, I move the ip via corosync by disabling the active node. Corosync does the moving automatically. The subscriber list never changes, and its odd that expire=never when I have it set to 5 in the opensips subscribe command. root@opensips:/var/log# opensipsctl fifo subscribers_list Event:: E_ACC_EVENT id=6 Subscriber:: socket=rabbitmq:rabbitmq@192.168.2.30/cdr1 expire=never Event:: E_ACC_CDR id=7 Subscriber:: socket=rabbitmq:rabbitmq@192.168.2.30/cdr1 expire=never Event:: E_ACC_MISSED_EVENT id=8 Subscriber:: socket=rabbitmq:rabbitmq@192.168.2.30/cdr1 expire=never Event:: E_CHANNEL_LIMIT id=9 Subscriber:: socket=rabbitmq:rabbitmq@192.168.2.30/limits expire=never Event:: E_CPS_LIMIT id=10 Subscriber:: socket=rabbitmq:rabbitmq@192.168.2.30/limits expire=never I think it may have to do with the fact that the subscription to rabbit comes from the local IP of the haproxy not the VIP. Opensips talks to the VIP, the local IP on the proxy is what shows up on RabbitMQ as the channel. I would think this would resolve via the resubscription I'm doing in the timer route, but it's not. opensips | | 192.168.2.30 (haproxy VIP) / \ / \ 192.168.2.31 (haproxy01) 192.168.2.32 (haproxy02) \ / \ / RabbitMQ01 RabbitMQ02 RabbitMQ03 On Thursday, June 5, 2014 11:33 AM, Bogdan-Andrei Iancu bog...@opensips.org wrote: So it seems the subscribing works fine. You can check that via the subscribers_list MI command (see http://www.opensips.org/Documentation/Interface-CoreMI-1-11#toc18). The problem is when the actual event is generated - it looks like it cannot be delivered via the rabbitmq driver. What you do is you move the IP of the HAproxy on a different machine ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 05.06.2014 17:31, Kneeoh wrote: Jun 5 14:19:24 opensips /usr/local/sbin/opensips[19027]: DBG:event_rabbitmq:rmq_match: socket matched: rabbitmq@192.168.2.30:5672/cdr1 Jun 5 14:19:24 opensips /usr/local/sbin/opensips[19027]: Subscribing to MISSED Event Jun 5 14:19:24 opensips /usr/local/sbin/opensips[19027]: DBG:event_rabbitmq:rmq_match: socket matched: rabbitmq@192.168.2.30:5672/cdr1 Jun 5 14:19:24 opensips /usr/local/sbin/opensips[19027]: Subscribing to CHANNEL Event Jun 5 14:19:24 opensips /usr/local/sbin/opensips[19027]: DBG:event_rabbitmq:rmq_match: socket matched: rabbitmq@192.168.2.30:5672/limits Jun 5 14:19:24 opensips /usr/local/sbin/opensips[19027]: Subscribing to CPS Event Jun 5 14:19:24 opensips /usr/local/sbin/opensips[19027]: DBG:event_rabbitmq:rmq_match: socket matched: rabbitmq@192.168.2.30:5672/limits Jun 5 14:19:29 opensips /usr/local/sbin/opensips[19020]: Enforcing Limits Jun 5 14:19:29 opensips /usr/local/sbin/opensips[19020]: Account Channel Limit OK. Channels Up: 0 Channel Limit: 1 Jun 5 14:19:29 opensips /usr/local/sbin/opensips[19020]: Call Rejected due to Account CPS Limit. CPS Limit: 0 Jun 5 14:19:29 opensips /usr/local/sbin/opensips[19027]: Subscribing to CDR Event Jun 5 14:19:29 opensips /usr/local/sbin/opensips[19027]: DBG:event_rabbitmq:rmq_match: socket matched: rabbitmq@192.168.2.30:5672/cdr1 Jun 5 14:19:29 opensips /usr/local/sbin/opensips[19027]: Subscribing to ACC Event Jun 5 14:19:29 opensips /usr/local/sbin/opensips[19027]: DBG:event_rabbitmq:rmq_match: socket matched: rabbitmq@192.168.2.30:5672/cdr1 Jun 5 14:19:29 opensips /usr/local/sbin/opensips[19027]: Subscribing to MISSED Event Jun 5 14:19:29 opensips /usr/local/sbin/opensips[19027]: DBG:event_rabbitmq:rmq_match: socket matched: rabbitmq@192.168.2.30:5672/cdr1 Jun 5 14:19:29 opensips /usr/local/sbin/opensips[19027]: Subscribing to CHANNEL Event Jun 5 14:19:29 opensips /usr/local/sbin/opensips[19027]: DBG:event_rabbitmq:rmq_match: socket matched: rabbitmq@192.168.2.30:5672/limits Jun 5 14:19:29 opensips /usr/local/sbin/opensips[19027]: Subscribing to CPS Event Jun 5 14:19:29 opensips /usr/local/sbin/opensips[19027]: DBG:event_rabbitmq:rmq_match: socket matched: rabbitmq@192.168.2.30:5672/limits Jun 5 14:19:29 opensips /usr/local/sbin/opensips[19021]: ACK - Attempting to match dialog Jun 5 14:19:33 opensips /usr/local/sbin/opensips[19027]: Subscribing to CDR Event Jun 5 14:19:33 opensips /usr/local/sbin/opensips[19027]: DBG:event_rabbitmq:rmq_match: socket matched: rabbitmq@192.168.2.30:5672/cdr1 Jun 5 14:19:33 opensips /usr/local/sbin/opensips[19027]: Subscribing to ACC Event Jun 5 14:19:33 opensips /usr/local/sbin/opensips[19027]: DBG:event_rabbitmq:rmq_match: socket matched: rabbitmq@192.168.2.30:5672/cdr1 Jun 5 14:19:33 opensips /usr/local/sbin/opensips[19027]: Subscribing to MISSED
[OpenSIPS-Users] RabbitMQ Timer Route Not Working
After following the example here:
http://www.opensips.org/Documentation/Tutorials-EventInterface
Shouldn't this resubscribe every 4 seconds and expire in 5 (i.e. never)? in my
script it's not subscribing to rabbit at all. I'm running version: Server::
OpenSIPS (1.10.1-notls (x86_64/linux))
timer_route[event_subscribe, 4] {
if (!subscribe_event(E_ACC_CDR, rabbitmq:cdr:rabbit@192.168.2.30/cdr1, 5))
{
xlog(L_INFO, Can't connect to RabbitMQ \n);
}
}
root@osips:/var/log# tcpdump -s0 -ni eth1 host 192.168.2.30
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] RabbitMQ multi-entrance points
Thanks Razvan, I'm definitely interested in what you may have in the works. Please see my other post related to using haproxy. Not sure if thats an option you're considering. Regards ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] RabbitMQ multi-entrance points
Is it possible to stack an array of entry points to a rabbitmq cluster like you can with other modules? example: if (!subscribe_event(E_EVENT, rabbitmq:user:password@192.168.1.1;192.168.1.2/queue)) If no, how would you handle a node failure of the defined node? ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] RabbitMQ HAProxy
In order to try to solve my multi-entry point problem to rabbitmq I put in a pair of Haproxy servers in front of the rabbitmq cluster and am running a virtual IP between them. I'm subscribing to the events in a startup route in opensips using the virtual IP and everything works great on initial startup. However, If I force the active haproxy offline and the virtual IP flips to the other host Opensips stops communicating with Rabbit. If I restart opensips it starts working again. I'm thinking that it has something do do with the channel being different but I'm not sure. I was hoping someone may have run in to this issue as well and solved it. If not I was hoping the devs might have an idea on what to do. Opensips error: ERROR:event_rabbitmq:rmq_process: cannot send message Regards ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] dlg_end_dlg ALL?
Thanks Liviu! I was speaking with a colleague yesterday about this and had a great idea for a feature while I have your attention. We thought it would be cool to have a hangup by dialog profile function. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] dlg_end_dlg ALL?
Is there a method to kill ALL calls with dlg_end_dlg blindly? w/o having to pass the hash of the dlg_id? ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] [RFC] Deprecating mi_xmlrpc
I'm all for the deprecation as long as the documentation on the mi_xmlrpc_ng module is updated to a usable level. I find myself referencing the documentation for xmlrpc and hoping that it holds true for xmlrpc_ng. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] codec_delete_except_re SDP Corruption
Sure, I'll get that for you. I've got some additional data that may answer your question. The problem seems to occur when the codec being removed is at the end of the SDP offer. So you'll get something like 0 18 101 19 in the media description line and 19 is the one you remove. It leaves the space after the 101, which is causing the problem. On Wednesday, March 5, 2014 12:57 PM, Bogdan-Andrei Iancu bog...@opensips.org wrote: Hello, Is the codec deletion the only change you do over the SDP (codec related) ? What opensips version are you using ? Also, could you post (privately is needed) the exact original and modified SDP ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 28.02.2014 23:09, Kneeoh wrote: I am using the codec codec_delete_except_re function to remove unwanted codecs: codec_delete_except_re(PCMU|G729|telephone-event); Apparently it is placing or leaving a space (hex 20) at the end of the media description line if the codec at the end of the description is removed by this function. Which I'm told is not syntactically correct. The net result is that upstream vendors 488 the calls on which codecs are removed and have this space at the end of the media description line. Has anyone else encountered this issue and resolved it? Thanks in advance ___ 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] codec_delete_except_re SDP Corruption
I am using the codec codec_delete_except_re function to remove unwanted codecs: codec_delete_except_re(PCMU|G729|telephone-event); Apparently it is placing or leaving a space (hex 20) at the end of the media description line if the codec at the end of the description is removed by this function. Which I'm told is not syntactically correct. The net result is that upstream vendors 488 the calls on which codecs are removed and have this space at the end of the media description line. Has anyone else encountered this issue and resolved it? Thanks in advance ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] [OpenSIPS-Devel] [RELEASES] Planing OpenSIPS 1.11.0 major
Bogdan, what i'm interested in is 3 things. I'll expand on the distributed dialog request: 1. Have multiple Opensips write their dialog data to the cachedb engine of my choice so that if one goes down the others can respond for that dialog. (assuming i do ip failover etc.) I know the Binary interface does this, but I need it in cachedb so my external monitoring can look at the cachedb for certain things in dialogs. 2. Not sure if this an alternative to the above or in addition to. But I would like to have event firing on dialog state change. So if a dialog changes state I can fire something to Rabbit. Right now i can kind of fake it but it's not 100% 3. Expand the DB_CACHEDB to support other NoSQL DBs like Cassandra and Couchbase. The docs say the present iteration only supports MongoDB. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] [OpenSIPS-Devel] [RELEASES] Planing OpenSIPS 1.11.0 major
I'd like to request distributed dialogs via the cachedb interface for couchbase. Thank you ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] 1.10 CacheDB Crash
Hi, I'm having some difficulty hooking up the cachedb to couchbase. Everything appears to be configured for the documentation and Opensips appears to start successfully when looking at the opensipsctl start output (no errors). However, after looking at the process list opensips is not started. A debug level 5 reveals the following output. Any advice / feedback would be greatly appreciated. /usr/local/sbin/opensips[18386]: DBG:core:db_bind_mod: using db bind api for db_cachedb /usr/local/sbin/opensips[18386]: DBG:db_cachedb:db_cachedb_bind_api: BINDING API for : cachedb://couchbase:opensips /usr/local/sbin/opensips[18386]: DBG:db_cachedb:db_cachedb_init: Found matching URL : [couchbase:opensips://192.168.2.2:6360/opensips] /usr/local/sbin/opensips[18386]: DBG:core:cachedb_bind_mod: Binded to mod couchbase /usr/local/sbin/opensips[18386]: DBG:core:parse_cachedb_url: parsing [couchbase:opensips://192.168.2.2:6360/opensips] /usr/local/sbin/opensips[18386]: DBG:core:cachedb_do_init: opening new connection /usr/local/sbin/opensips[18386]: DBG:cachedb_couchbase:couchbase_new_connection: Succesfully connected to Couchbase Server. Host: 192.168.2.2 Bucket: opensips /usr/local/sbin/opensips[18386]: DBG:db_cachedb:db_cachedb_init: Succesfully initiated connection to [couchbase:opensips] opensips: DBG:core:wait_status_code: read code -128 ? rc = 0, errno=Success opensips: INFO:core:daemonize: pre-daemon process exiting with -1 ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Dialog Timeout
I have an odd occurrence and I want to know if I'm on the right track. I have a dialog default_timeout set to 10818 to catch and kill any long calls. The behavior I'm seeing in some cases is that if the UA is sending regular UPDATEs or Re-INVITEs my acc record will show the call ending at 10818 seconds, however the SIP trace shows the call actually lasts longer and I can see the BYE from the UA well after the dialog default_timeout. I THINK it's because I don't have a create_dialog(B); Set anywhere in my script. This being the case, does this behavior sound correct? And would I be able to solve this by inserting the create_dialog(B); in my script? Based on the dialog docs for OpenSIPS 1.8.1 in section 1.6.1 it sounds like it will, and send a BYE in both directions. Am I on the right track with this? Thanks in Advance. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
