Hi, Kneeoh!
Currently the event_rabbitmq module does not need expiration. Since it
is a connection oriented protocol, if the external application does not
want to receive messages any more, it should close the connection. If
you really need the expire feature in the near future, please open a
ticket for it[1].
Changing the RabbitMQ servers is not that easy as it looks. You can't
transparently simply change the connection to a different server,
because you have to re-do the handshake (like authentication) with the
new server. Therefore, the only method to fallback to a different server
is to close the ongoing connection and open a new one.
If you need to unsubscribe a server, the following snippet should work:
subscribe_event("E_ACC_CDR", "rabbitmq:cdr:[email protected]/cdr1", 0)
[1]
https://github.com/OpenSIPS/opensips/issues?direction=desc&sort=created&state=open
Best regards,
Razvan Crainea
OpenSIPS Core Developer
http://www.opensips-solutions.com
On 06/05/2014 11:00 PM, Kneeoh wrote:
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:[email protected]/cdr1 expire=never
Event:: E_ACC_CDR id=7
Subscriber:: socket=rabbitmq:[email protected]/cdr1 expire=never
Event:: E_ACC_MISSED_EVENT id=8
Subscriber:: socket=rabbitmq:[email protected]/cdr1 expire=never
Event:: E_CHANNEL_LIMIT id=9
Subscriber:: socket=rabbitmq:[email protected]/limits expire=never
Event:: E_CPS_LIMIT id=10
Subscriber:: socket=rabbitmq:[email protected]/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 <[email protected]>
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: [email protected]: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: [email protected]: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: [email protected]: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: [email protected]: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: [email protected]: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: [email protected]: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: [email protected]: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: [email protected]: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: [email protected]: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: [email protected]: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: [email protected]:5672/cdr1
Jun 5 14:19:33 opensips /usr/local/sbin/opensips[19027]: Subscribing to MISSED
Event
Jun 5 14:19:33 opensips /usr/local/sbin/opensips[19027]:
DBG:event_rabbitmq:rmq_match: socket matched: [email protected]:5672/cdr1
Jun 5 14:19:33 opensips /usr/local/sbin/opensips[19027]: Subscribing to
CHANNEL Event
The above works and sends an event to RabbitMQ via 192.168.2.30 (the virtual IP
of haproxy)
FAIL OVER HAPROXY - IP moves to backup HAProxy identical to the first Opensips
is none the wiser.
NEW CALL
Jun 5 14:20:17 opensips /usr/local/sbin/opensips[19027]:
DBG:event_rabbitmq:rmq_match: socket matched: [email protected]:5672/limits
Jun 5 14:20:20 opensips /usr/local/sbin/opensips[19020]: Enforcing Limits
Jun 5 14:20:20 opensips /usr/local/sbin/opensips[19020]: Account Channel Limit
OK. Channels Up: 0 Channel Limit: 1
Jun 5 14:20:20 opensips /usr/local/sbin/opensips[19020]: Call Rejected due to
Account CPS Limit. CPS Limit: 0
Jun 5 14:20:20 opensips /usr/local/sbin/opensips[19012]:
ERROR:event_rabbitmq:rmq_process: cannot send message
Jun 5 14:20:20 opensips /usr/local/sbin/opensips[19012]:
ERROR:event_rabbitmq:rmq_process: cannot send message
Jun 5 14:20:20 opensips /usr/local/sbin/opensips[19012]:
ERROR:event_rabbitmq:rmq_process: cannot send message
Jun 5 14:20:20 opensips /usr/local/sbin/opensips[19021]: ACK - Attempting to
match dialog
Jun 5 14:20:21 opensips /usr/local/sbin/opensips[19027]: Subscribing to CDR
Event
Jun 5 14:20:21 opensips /usr/local/sbin/opensips[19027]:
DBG:event_rabbitmq:rmq_match: socket matched: [email protected]:5672/cdr1
Jun 5 14:20:21 opensips /usr/local/sbin/opensips[19027]: Subscribing to ACC
Event
Jun 5 14:20:21 opensips /usr/local/sbin/opensips[19027]:
DBG:event_rabbitmq:rmq_match: socket matched: [email protected]:5672/cdr1
Jun 5 14:20:21 opensips /usr/local/sbin/opensips[19027]: Subscribing to MISSED
Event
Jun 5 14:20:21 opensips /usr/local/sbin/opensips[19027]:
DBG:event_rabbitmq:rmq_match: socket matched: [email protected]:5672/cdr1
Jun 5 14:20:21 opensips /usr/local/sbin/opensips[19027]: Subscribing to
CHANNEL Event
Jun 5 14:20:21 opensips /usr/local/sbin/opensips[19027]:
DBG:event_rabbitmq:rmq_match: socket matched: [email protected]:5672/limits
FAILs to send event to RabbitMQ
On Thursday, June 5, 2014 7:57 AM, Bogdan-Andrei Iancu <[email protected]>
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:[email protected]/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:[email protected]/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
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
