[Issues with Presence]

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

[Issue with welcome prompt on conference]

1 hour ago, mc_ said:

Regarding the API, it's all a matter of preference I guess. Joris posted about Postman that the UI team uses to whip up API calls quickly. I have scripts the authenticate and export relevant vars to my shell's env to speed up stuff. I know how painful it can be to track down what areas of Kazoo need intervention when DB changes occur.

Anyway, if you can get logs of the first and second attempts (where first succeeds and second doesn't), it may be instructive on what the differences are. Nothing comes to mind for why that observed behavior is happening.

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

[Issue with welcome prompt on conference]

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

[Issue with welcome prompt on conference]

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!

[Lots of redirection_to_new_destination email alerts]

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: 

1. Configuring Kazoo (or maybe Kazoo Setup?)
2. 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.

[Lots of redirection_to_new_destination email alerts]

29 minutes ago, Darren Schreiber said:

@Ivan Tazelaar We're putting together a group of folks to help with docs, would you consider joining? It's just a small commitment to touchbase once a week. We'll divy up the biggest needs and split the work but also coach people on it. You get the added benefit that you can interact with our staff directly and get answers to, well, whatever you want!

 

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.

[Lots of redirection_to_new_destination email alerts]

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!

[Lots of redirection_to_new_destination email alerts]

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!

[Lots of redirection_to_new_destination email alerts]

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