Ivan Tazelaar

Good morning community! I am a happy user of the kazoo platform/stack. We've been using it for more than a year now, and it's been awesome, with just a few glitches that were manageable up until today. So I was wondering if someone can help/guide me on how to troubleshoot a couple of problems I am having. We are running Version 4.2. The first problem we are having is related with presence: From time to time, it looks like the PBX forgets some devices are registered, let me explain: It's odd, because I am not getting any timeout email messages, an I do get them when a phone really loses connectivity. When this happens: kazoo-applications status shows different number of devices on Kamailio than on eCallMgr. kazoo-applications status sometimes lists kamailio and sometime it does not. I can see devices randomly go offline and online on MonsterUI if I refresh the screen. Some partial guesses / conclusions: I am prone to believe this happens when, from time to time, Kazoo (eCallMgr) and Kamailio lose connectivity - even while both reside on the same server. Restarting Kamailio seems to fix this issue, at least temporarily. I know this happened once when we lost networking on our Virtual Infrastructure. But I don't know why it didn't recover on it's own. This issue also causes the following: Then the PBX believes the device is offline, it won't even attempt to route the calls, and calls go straight to voicemail. Another less frequent issue we are having, also related with presence, is that after calls terminate, it takes some time for the PBX to realize the device is not busy anymore. We are currently running on 1 server for SBC + Kazoo-Apps + MonsterUI, 2 servers for media and 3 servers for databases, still running on BigCouch. When we first started having the presence issues, when I started using the platform, I managed to reduce most of them by shutting down our secondary SBC, as it was causing a mess due to the lack of cluster configuration. If possible, I would like to learn how to properly configure it as a cluster, so we can have a valid fail-over in case the primary SBC goes down. Any help will be highly appreciated! Thanks much, Ivan

Will the kazoo.log be enough? Shall I grep it somehow? Thanks!

Hi mc_ Thanks for answering! I know I should use the API, but it gives me headaches, I need to authenticate, etc, etc. Are there some tools I can use to simplify this? Calling it with curl from the terminal is very annoying and time-consuming. BTW, all caches have been flushed, and remember the first callflow execution works just fine, and it doesn't play the welcome prompt at all, so it looks like it's reaching the right document, it's only on the second and consecutive call attempts that this issue shows, and only if I don't leave a few seconds between attempts. Could it be something related with the copy that the conferences module does online to register the "opened" conference room? I know it does register the ID somewhere (and maybe some data?) because it uses that reference later to validate if the bridge is open (to allow callers to join if the room is active). Thanks once more! Ivan

Dear Kazoo Team, Good afternoon or evening! Any chance someone can lend me a hand? I am having a strange issue with the conference action in callflows, for a very specific scenario. I am trying to prevent the welcome_prompt from playing, so I created a callflow using monster, and then modified the callflow document flow attribute directly on the database as follows: { "data": { "id": "5e526d64a90c856efb62048d58ffa29f", "moderator": false, "play_entry_tone": false, "play_exit_tone": false, "welcome_prompt": { "play": false } }, "module": "conference", "children": { } } For some reason, this setting only works once (on my first attempt), but the "welcome to the conference" message gets played again on my second and subsequent call attempts. I can make it stop playing (again, only once) by either waiting some seconds and trying again, or by flushing the callflows cache. Could this be a cache issue? Maybe some odd logic not caching the welcome_prompt section or ignoring it if the object was recovered from cache? Thanks much!

Hey @Darren Schreiber, I have already started reviewing a few things, find my comments bellow: (1) Installation Section Installation needs an introduction / overview (probably an architecture overview), so that people understand what they are doing, otherwise it's easy to install a single-server instance because vanilla takes care of most, but it's a whole different story when you try to get a cluster running. (Noticed there's an specific section for cluster installation, but still... either there, or on the installation section, an introduction and architecture overview will definitely be of great help) There's also a guide that we can leverage: https://www.powerpbx.org/content/kazoo-v4-single-server-install-guide-v1 (2) Configuration Section Configuration goes straight into APIs, and this may be confusing with setting up kazoo too. At least I was trying to look for that and ended up finding the usage/configuration. There should be two sub-sections, or maybe a new entire section to cover usage: Configuring Kazoo (or maybe Kazoo Setup?) Using Kazoo (or Kazoo's APIs?) I am still going through all sections, but I believe the actual setup was not addressed (only briefly on the installation and with code snippets). Things like each of the components' configuration files: FreeSWITCH though "sup" commands for example, Kamailio config file, Kazoo main core configuration file for zone definition, CouchDB cluster configuration, etc. I understand each of these solutions have their own documentation, but with the packages, most of the defaults are flipped, file locations, etc. There's a lot we can cover there. I am sure you guys already know this, but just wanted to give an initial feedback on the few things I was able to find so far.

Absolutely Darren, just let me know how and I will make myself available, and I agree with David, I've had the same experiences and would love to help.

Thanks again @mc_! Yup, I noticed some of the docs can use a caring hand, it's just that I don't know enough to start documenting the platform yet, I need to gain some knowledge and experience first. But I will definitely try to contribute. Do you mind if I write you if I have some questions to polish some of those docs? would you recommend some sections to start with? Thanks!

Thanks @mc_, didn't know about that feature, it's awesome! and I am amazed on how quickly you have answered! One more question thou, do all "redirections to new destination" end up on a hangup and are usually reported? is this normal? I would think it is because the device will then re-issue the INVITE to the new destination, but I just wanted to be sure, and I wonder why it isn't already part of the ignored_hangup_causes...is that by design? like... standard behavior of the solution? BTW, I know nothing about Erlang, but I consider myself a good programmer and I am a fast learner. Not sure if I will have a much time, but if you guys need some help, I will try to assist the community whenever possible. Thanks!

Hello Forum Let me start by saying I am reeeeally new to Kazoo, so I can reaaaally use some help. I did a lot of research thou, and while I don't understand some details, I was able to get a cluster running (at least partially, hehe). These are the servers I put together: 1 * SBC Server (Kamailio) + Kazoo Apps + Monster UI 2 * Media Servers (FreeSWITCH) 3 * Database Servers (BigCouch) I used to have another SBC node, but then I realized it was causing issues with the presence (due to having two eCallManager instances with local queues and only one zone) so decided to stop the services on the second node for the time being. I've also spent some time reading multiple threads, resolved a few issues and it looks like everything is working now, but I keep getting a lot of email alerts with redirection_to_new_destination as follows: Alert redirection_to_new_destination 303 to 200 (outbound) on cc8cc1c9e996034bbc2ec09bcc72a105(cc8cc1c9e996034bbc2ec09bcc72a105) Producer node: kazoo_apps@b01.sip.smsdatacenter.com msg_id: d4dbb76ffb661496 Details app_name: ecallmgr app_version: 4.0.0 event_category: call_event event_name: CHANNEL_DESTROY msg_id: 1501007152730157 node: kazoo_apps@b01.sip.smsdatacenter.com call_id: b0dda268-7166-11e7-8c68-dd42a72235e1 billing_seconds: 0 call_direction: outbound callee_id_name: XXXXX callee_id_number: 200 caller_id_name: XXXXX caller_id_number: 303 channel_call_state: HANGUP channel_created_time: 1501007152589522 channel_name: sofia/sipinterface_1/200@XXX.sip.smsdatacenter.com channel_state: REPORTING duration_seconds: 0 from: 303@XXX.sip.smsdatacenter.com hangup_cause: REDIRECTION_TO_NEW_DESTINATION local_sdp: v=0 o=FreeSWITCH 1500975540 1500975541 IN IP4 208.82.141.118 s=FreeSWITCH c=IN IP4 208.82.141.118 t=0 0 m=audio 31612 RTP/AVP 0 8 101 13 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:13 CN/8000 a=ptime:20 a=sendrecv media_server: m01.sip.smsdatacenter.com other_leg_call_id: d881c0f6c8b53e1c1f61562adab0877d other_leg_caller_id_name: XXXXX other_leg_caller_id_number: 303 other_leg_destination_number: 0 other_leg_direction: inbound presence_id: 200@XXX.sip.smsdatacenter.com request: 200@XXX.sip.smsdatacenter.com ringing_seconds: 0 switch_nodename: freeswitch@m01.sip.smsdatacenter.com switch_uri: sip:208.82.141.118:11000 switch_url: sip:mod_sofia@208.82.141.118:11000 timestamp: 63668226352 to: 200@XXX.sip.smsdatacenter.com format: ~s ~s to ~s (~s) on ~s(~s) Channel Vars username: 200 realm: XXX.sip.smsdatacenter.com owner_id: 90dee9c96ab01212adb5333712906b24 global_resource: false ecallmgr_node: kazoo_apps@b01.sip.smsdatacenter.com channel_authorized: true call_interaction_id: 63668226342-3b71322e bridge_id: d881c0f6c8b53e1c1f61562adab0877d authorizing_type: device authorizing_id: f1bb6a88886c7d69bb662775a6da5f3d account_id: cc8cc1c9e996034bbc2ec09bcc72a105 SIP Headers x_kazoo_aor: sip:200@XXX.sip.smsdatacenter.com Account Account ID: cc8cc1c9e996034bbc2ec09bcc72a105 Account Name: XXX Account Realm: XXX.sip.smsdatacenter.com I also reviewed the FreeSWITCH logs and found out these errors are consistent with the 302 messages coming from the phones, which end up on a hang up channel. I understand 302 is how SIP handles transfers to ask the device to re-issue the invite to a new destination, I am just not sure why I am getting all these notifications each time a redirection occurs. Is this something normal? is there any way to disable it? Thanks! Much! Ivan