Search the Community

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!

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