huwsc90

Hi @mc_, thanks for the help. There were a couple of instances where the reorder app seemed to be getting in the way, and wasn't something we specifically needed, so we tried disabling it and everything seems to be working so far.

Hi, I'm using Kazoo 4.3 (4.3.165 for Kazoo Apps, 4.3.140 for Kazoo Core). When receiving an incoming call from an Auth by IP device after a period of inactivity from that device, Kazoo seems to only send a route.req AMQP message with a routing key of "route.req.audio.{AUTH_BY_IP_DEVICE_IP}", whereas all subsequent calls from that device result in two AMQP route.req messages, the one mentioned previously, plus "route.req.audio.{ACCOUNT_ID}". My app is only subscribing for route.req messages to a particular account ID, which means when only the first message is sent by Kazoo, my app doesn't get notified, so can't answer the call and instead the caller receives a 604 Nope nope nope. Is there any reason for this behaviour? It seems strange that it only happens when nothing has been received from that device in a while, like Kazoo has a static registration that expires after inactivity? Thanks, Huw

Thanks @mc_, I'm now able to plug in to KAZOO over AMQP and answer an incoming call. I also found it useful inspecting the AMQP messages in a pcap taken from KAZOO when dialling in with a softphone and having Callflows answer the call, to get examples of the messages back and forth. Is there any way I can use AMQP (or even maybe REST/WebSockets) to connect a non-SIP endpoint to a call that comes through KAZOO? I see numerous options in the API to bridge/transfer/redirect, but all options seem to require a SIP call out to the endpoint. Could I use something like FreeSWITCH's mod_verto through KAZOO?

Hi, I have a Java background and have recently started looking into KAZOO. I'm hoping to be able to plug in to KAZOO's AMQP message bus but from outside of KAZOO and with a Java client instead of Erlang, in order to be able to dictate what to do with an incoming call as an internal KAZOO App (such as CallFlows) might do. Is there anywhere that documents some of the lower level AMQP information, such as what queues I can subscribe to, what messages relate to what functionality, etc.? Thanks